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 kbarrett at openjdk.org  Tue Oct  1 01:30:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 01:30:37 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <PcfEO_LHkIlj3oFG1BjI5AgWhUzbRkFUxYDXhmFa1jU=.8059fe1e-c120-4d0f-96ba-27438aa2217a@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <lzbKsjK3JtjBSgMhnNnb_IMEHd86sJV0sPtRbWk5BN8=.60cc23a8-e846-481b-979f-8cd3ba4e18e7@github.com>
 <PcfEO_LHkIlj3oFG1BjI5AgWhUzbRkFUxYDXhmFa1jU=.8059fe1e-c120-4d0f-96ba-27438aa2217a@github.com>
Message-ID: <R_pNXcc-cSdtuj4YiVfriLUbcqo6YRYH3Jyk5E379Zs=.b4afb481-17e9-435d-8a4b-34dbe65b1221@github.com>

On Mon, 30 Sep 2024 16:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 420:
>> 
>>> 418:     /* Implementation of clear(), also used by enqueue().  A simple
>>> 419:      * assignment of the referent field won't do for some garbage
>>> 420:      * collectors.
>> 
>> Description of clear0 is rendered stale by this change.  The first sentence is no longer true, since it's now
>> clearImpl that has that role.  The second sentence probably ought to also be moved into the description of
>> clearImpl.
>
> Thanks! I tightened up comments a bit, take another look?

Yes, that's better.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1782006243

From kbarrett at openjdk.org  Tue Oct  1 01:37:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 01:37:45 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
Message-ID: <sHjJaanZFXYvLplEw2LSPX1rI4TbBxjB-QF2IQox1L8=.2bc659e3-2acc-4ff2-907e-83f0763529ae@github.com>

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

Removing my "Request changes" as request has been satisfied.

I've only really looked at the changes in java.base, which look fine.  I've skimmed some
of the compiler code, but don't feel qualified to properly review it.  So don't count or
wait for me as a reviewer.

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

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2338962626

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 jbhateja at openjdk.org  Tue Oct  1 05:09:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Oct 2024 05:09:25 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v19]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <Rgx6r8xrA1DNQm-uuRrGmNnpWlvXWxMsBrvaYsWjQjE=.4bd7bd2b-aa3f-49e0-8d7b-0fd0b17577aa@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja 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:

  Merge stashing and re-commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/28b29bc6..952920ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=17-18

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

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

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 iklam at openjdk.org  Tue Oct  1 06:14:53 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 06:14:53 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v11]
In-Reply-To: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
Message-ID: <f7JB_15dUjEOqs502DImHtQpy4isWXV7GZOfeJ5pz4M=.21fc701a-235b-4566-b18f-1e148e4621dc@github.com>

> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Problem:**
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
> 
> **Solution:**
> 
> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
> 
> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
> 
> **Review Notes:**
> 
> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
> 
> **Caveats:**
> 
> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the environment:
> 
> 
> enum Foo {
>     [....]
>     static fin...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - comments from @adinn and @ashu-mehra
 - 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
 - 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
 - Fixed typo
 - erge 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
 - fixed merge
 - 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
 - @ashu-mehra comment: assert that ConstantDescs, etc, must be initialized
 - Improved in-line comments
 - 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
 - ... and 10 more: https://git.openjdk.org/jdk/compare/3cdc7634...ffa96692

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

Changes: https://git.openjdk.org/jdk/pull/20958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20958&range=10
  Stats: 876 lines in 20 files changed: 771 ins; 19 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/20958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20958/head:pull/20958

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

From iklam at openjdk.org  Tue Oct  1 06:14:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 06:14:54 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
Message-ID: <OUTMOZXcNapNk56TIuQAHfN4KJgl_VUutCTL1km8lqs=.56b9f14f-8caf-4270-a650-fb0b48ef4a0f@github.com>

On Mon, 30 Sep 2024 12:31:54 GMT, Andrew Dinn <adinn 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 109 commits:
>> 
>>  - 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
>>  - 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-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>>  - 8340864: Remove unused lines related to vmClasses
>>    
>>    Reviewed-by: shade, kvn
>>  - 8340831: Simplify simple validation for class definition in MethodHandles.Lookup
>>    
>>    Reviewed-by: redestad
>>  - 8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger
>>    
>>    Reviewed-by: jrose, redestad, shade
>>  - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
>>    
>>    Reviewed-by: liach, alanb, darcy, dfuchs
>>  - 8340228: Open source couple more miscellaneous AWT tests
>>    
>>    Reviewed-by: prr
>>  - 8340684: Reading from an input stream backed by a closed ZipFile has no test coverage
>>    
>>    Reviewed-by: lancea
>>  - ... and 99 more: https://git.openjdk.org/jdk/compare/6029b35f...563bccb3
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 253:
> 
>> 251:       }
>> 252:       if (ik->has_aot_initialized_mirror()) {
>> 253:         ik->initialize_from_cds(CHECK);
> 
> Can we put a comment in here to explain that this call may link class ik and may link+initialize its supers and/or implemented interfaces but it will not initialize ik itself because we are relying on the mirror to provide static field data computed via an init run at assembly time when the archive was created. It really helps to underline that this is the point where we rely on init in a previous VM, bypassing (repeated) init in this VM.

I added a comment according to your suggestion. I'll also see if it's possible to require all supertypes to be aot-initialized. I think that will make the model simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1782168767

From iklam at openjdk.org  Tue Oct  1 06:14:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 06:14:54 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v3]
In-Reply-To: <XD22DRHXBwdT-QpF3ckT_VO--DDdT_DR3fU8jiDbOx8=.2ccc8b2b-5ab3-42b4-b542-52d35be919a0@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <xSQwTuf0xXRWW_RM4FzBFAkyqzit89NLOHKvYvspB0k=.8c08030a-e521-4ade-a8d7-166f2c70ad08@github.com>
 <0QRMVGKYDVfu4Ie1N6RKC5B1QPxs7sQUvdnyZxayX9o=.e4fe8dc7-4cc8-44ba-99e7-dc5cacd85147@github.com>
 <FrmqOtLdkBZbq-OBV25L_oevz_7Dbcwatrn8JwvC6Zg=.1adddf00-db2d-46a7-9be6-e5ca11abca44@github.com>
 <NBko11kDeowi9c-uFCFoPNZnym339QZbwnWj7hCFYIA=.bfdad122-b507-4f9d-929e-e970e0fb8272@github.com>
 <sBobFgwQ5VOCGB68ClWvpEG7HIX91gOkb-e2Exbu9DA=.9af72526-d192-46ce-b0f1-4565b1541445@github.com>
 <JQ49fW81nzJITauix3XnieHexJ9GGADg-oVX-fe9bBM=.b9031214-c851-4b39-8264-fd0f80286036@github.com>
 <1VQUnjdiscLRkDSW_pKI9D3HRHuRVsvuDGscxfXjCgs=.bd09973b-bba9-4ca1-9aa8-c015f5e4c9cf@github.com>
 <W-EebY82cqzQ4aEroxndAwVFrFwxXabDuVgDKap9lxg=.b1c49fff-8eaf-4c65-917e-d938959b1a7f@github.com>
 <XD22DRHXBwdT-QpF3ckT_VO--DDdT_DR3fU8jiDbOx8=.2ccc8b2b-5ab3-42b4-b542-52d35be919a0@github.com>
Message-ID: <OFygSQX3IE7PDMr_NO9c3vTYesEIlexbxbhv9AsMs2Y=.4966ea02-78c1-4693-8a68-5a3aea20da59@github.com>

On Thu, 26 Sep 2024 21:02:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> @iklam are you planning to address this? Otherwise the patch looks good to me.
>
> Yes, I plan to to address this.
> 
> I think the name `init_classes_reachable_from_archived_mirrors` is confusing, as it also initializes classes that may not be reachable from archived mirrors. I will try to rename this function and related data structures to make the meaning more obvious.
> 
> I'd like to keep the logic the same, as I still need to do the initialization in 4 steps (boo1/boot2/platform/app) for classes listed under `_runtime_default_subgraph_info`. If I split up `_runtime_default_subgraph_info` into two separate parts the code will just become more verbose.

I renamed the function to `HeapShared::init_classes_for_special_subgraph()`. I also changed other `_default_subgraph` names to `special_subgraph`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1782167674

From iklam at openjdk.org  Tue Oct  1 06:17:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 06:17:39 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
Message-ID: <NusncLQBU_wh077gzNoOYhxZkXkzJ7e4E8VhCb6Lcks=.a5b4028b-fe5f-4c45-b396-a24c0e83ea27@github.com>

On Mon, 30 Sep 2024 13:02:16 GMT, Andrew Dinn <adinn 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 109 commits:
>> 
>>  - 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
>>  - 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-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>>  - 8340864: Remove unused lines related to vmClasses
>>    
>>    Reviewed-by: shade, kvn
>>  - 8340831: Simplify simple validation for class definition in MethodHandles.Lookup
>>    
>>    Reviewed-by: redestad
>>  - 8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger
>>    
>>    Reviewed-by: jrose, redestad, shade
>>  - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
>>    
>>    Reviewed-by: liach, alanb, darcy, dfuchs
>>  - 8340228: Open source couple more miscellaneous AWT tests
>>    
>>    Reviewed-by: prr
>>  - 8340684: Reading from an input stream backed by a closed ZipFile has no test coverage
>>    
>>    Reviewed-by: lancea
>>  - ... and 99 more: https://git.openjdk.org/jdk/compare/6029b35f...563bccb3
>
> src/hotspot/share/cds/heapShared.cpp line 1009:
> 
>> 1007: //
>> 1008: // The set of classes that are required to be initialized for the archived
>> 1009: // java mirrors are recorded in _runtime_default_subgraph_info (which probably
> 
> _runtime_default_subgraph_info is derived from _default_subgraph_info, the latter being the subgraph associated with class java.lang.Object. Perhaps using the prefix `root` or `jlobject` would make this clearer i.e. `_root_subgraph_info` and `_runtime_root_subgraph_info` or `_jlobject_subgraph_info` and `_runtime_jlobject_subgraph_info`.

`root` may be a little over-loaded, because we have `HeapShared::get_root(int)` to get an arbitrary object with an integer index.

I renamed the various field/functions to `special_subgraph`, and added a comment about what this subgraph contains. What do you think?

Also, the two `subgraph_info` fields are renamed to the following:


  static KlassSubGraphInfo* _dumptime_special_subgraph;              // for collecting info during dump time
  static ArchivedKlassSubGraphInfoRecord* _runtime_special_subgraph; // for initializing classes during run time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1782171252

From iklam at openjdk.org  Tue Oct  1 06:26:57 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 06:26:57 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v12]
In-Reply-To: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
Message-ID: <N2KVpicxLRVOyuIhdAFydRmrMvzgs-T6hwR5onZLMMw=.723b6276-8d7b-4b1e-86ee-fb1bed3a4e9b@github.com>

> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Problem:**
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
> 
> **Solution:**
> 
> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
> 
> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
> 
> **Review Notes:**
> 
> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
> 
> **Caveats:**
> 
> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the environment:
> 
> 
> enum Foo {
>     [....]
>     static fin...

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

  changed dumptime_xxx to dump_time_xxx to be consistent with other fields in heapShared.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20958/files
  - new: https://git.openjdk.org/jdk/pull/20958/files/ffa96692..244a5dec

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

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

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

From iklam at openjdk.org  Tue Oct  1 06:30:42 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 06:30:42 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
Message-ID: <eRKJk58XtqwD5Ai7bqqlUrbUGdiZEg-I36QOGVP-ylA=.ca7da4d5-2e16-4c5f-a834-1127c94706ef@github.com>

On Mon, 30 Sep 2024 13:17:53 GMT, Andrew Dinn <adinn 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 109 commits:
>> 
>>  - 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
>>  - 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-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>>  - 8340864: Remove unused lines related to vmClasses
>>    
>>    Reviewed-by: shade, kvn
>>  - 8340831: Simplify simple validation for class definition in MethodHandles.Lookup
>>    
>>    Reviewed-by: redestad
>>  - 8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger
>>    
>>    Reviewed-by: jrose, redestad, shade
>>  - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
>>    
>>    Reviewed-by: liach, alanb, darcy, dfuchs
>>  - 8340228: Open source couple more miscellaneous AWT tests
>>    
>>    Reviewed-by: prr
>>  - 8340684: Reading from an input stream backed by a closed ZipFile has no test coverage
>>    
>>    Reviewed-by: lancea
>>  - ... and 99 more: https://git.openjdk.org/jdk/compare/6029b35f...563bccb3
>
> src/hotspot/share/cds/heapShared.cpp line 939:
> 
>> 937: 
>> 938:   _run_time_subgraph_info_table.serialize_header(soc);
>> 939:   soc->do_ptr(&_runtime_default_subgraph_info);
> 
> It would help to have a comment here explaining that 1) before the do_ptr call the specific subgraph_info passed into this call holds all the classes that need to be initialized on behalf of java.lang.Object 2) after the call it is includes all the extra classes that need initializing on behalf of some archived java.lang.Class mirror. This would help to clarify why it was picked as the holder for these extra classes (i.e. it is the obvious root class from which to start running initializations).
> 
> If field `_runtime_default_subgraph_info` was renamed to identify it as being the root subgraph associated with class java.lang.Object this would also be clearer (see related comment)

Actually, the `do_ptr()` call is a somewhat cryptic API for passing values and pointers between the assembly phase and the production run.

In this example, during the production run, before the `do_ptr()` call,  `_runtime_default_subgraph_info` is null. After the call, it points to the `ArchivedKlassSubGraphInfoRecord` that was created by `HeapShared::archive_subgraph_info()` during the assembly phase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1782182205

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 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 aboldtch at openjdk.org  Tue Oct  1 09:33:39 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 09:33:39 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero
In-Reply-To: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
Message-ID: <meDXPcVAoVB2IVxCOvCb848iegSSinlSNzjPgScK2YU=.63eaf82e-297b-4eba-aae1-61d543575fe8@github.com>

On Fri, 27 Sep 2024 15:16:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This implements the remaining parts of LW locking in Zero. Much of the work has already been done by Axel, this basically only implements the missing part that handles synchronized JNI entries. I basically preserved the LM_LEGACY case, except that I shuffled the code a little to match what we do in monitorexit case in bytecodeInterpreter.cpp (but should be functionally equivalent). The LM_LIGHTWEIGHT and LM_MONITOR case (the latter of which has been broken, before) simply call into the runtime.
> 
> With this change, we can now remove the block in arguments.cpp that deals with missing LM_LIGHTWEIGHT support.
> 
> Testing:
>  - [x] bootcycle-images

The `LM_LIGHTWEIGHT` changes looks good to me.

This also enables `UseObjectMonitorTable`. I believe `BasicLock::object_monitor_cache()` must be modified as well. Assuming that both `ZERO` and a supported platform (e.g. `X86`) can and will be defined in the same build. 

`ZERO` should return `nullptr` in `BasicLock::object_monitor_cache()`  as well.

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

PR Review: https://git.openjdk.org/jdk/pull/21220#pullrequestreview-2339659847

From adinn at openjdk.org  Tue Oct  1 09:50:42 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Oct 2024 09:50:42 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <OUTMOZXcNapNk56TIuQAHfN4KJgl_VUutCTL1km8lqs=.56b9f14f-8caf-4270-a650-fb0b48ef4a0f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
 <OUTMOZXcNapNk56TIuQAHfN4KJgl_VUutCTL1km8lqs=.56b9f14f-8caf-4270-a650-fb0b48ef4a0f@github.com>
Message-ID: <SahFjukrjKXoGUlBPYWAor3Gcl8UrJqKqrzXwjkl0yA=.5201ad8e-7c8f-44e8-b292-b8942c057570@github.com>

On Tue, 1 Oct 2024 06:12:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 253:
>> 
>>> 251:       }
>>> 252:       if (ik->has_aot_initialized_mirror()) {
>>> 253:         ik->initialize_from_cds(CHECK);
>> 
>> Can we put a comment in here to explain that this call may link class ik and may link+initialize its supers and/or implemented interfaces but it will not initialize ik itself because we are relying on the mirror to provide static field data computed via an init run at assembly time when the archive was created. It really helps to underline that this is the point where we rely on init in a previous VM, bypassing (repeated) init in this VM.
>
> I added a comment according to your suggestion. I'll also see if it's possible to require all supertypes to be aot-initialized. I think that will make the model simpler.

Yes, it should be simpler, although perhaps at the cost of omitting some mirrors from the heap section. Anyway, the comment is helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1782473196

From jbhateja at openjdk.org  Tue Oct  1 09:51:27 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Oct 2024 09:51:27 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v14]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

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

  Review comments resolutions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/42ca80c5..7327736f

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

  Stats: 126 lines in 4 files changed: 60 ins; 65 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

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

From jbhateja at openjdk.org  Tue Oct  1 09:55:39 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Oct 2024 09:55:39 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
Message-ID: <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>

On Mon, 30 Sep 2024 22:39:09 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I think you have to do the masking before conversion - `vec.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle()` is not the same as `vec.toShuffle()` for all inputs.
>> 
>> 
>> jshell> IntVector indexes = IntVector.fromArray(IntVector.SPECIES_256, new int[] {0, 1, 8, 9, 16, 17, 24, 25}, 0);
>> indexes ==> [0, 1, 8, 9, 16, 17, 24, 25]
>> 
>> jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1)
>> $19 ==> [0, 1, 8, 9, 0, 1, 8, 9]
>> 
>> jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1).toShuffle()
>> $20 ==> Shuffle[0, 1, -8, -7, 0, 1, -8, -7]
>> 
>> jshell> indexes.toShuffle()
>> $21 ==> Shuffle[0, 1, -8, -7, -8, -7, -8, -7]
>
> Thanks for the example. Yes, you have a point there.  So we would need to do:
>    src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);

> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2); Or even simplified to: src1.rearrange(this.toShuffle(), src2);

Yes, this may save additional allocation penalty of result array allocation which may slightly improve fall back performance, but logical operation cannot be directly applied over floating point vectors. so, we will need an explicit conversion to integral vector, which is why I opted for current fallback implementation which is in line with rest of the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1782480053

From adinn at openjdk.org  Tue Oct  1 09:59:47 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Oct 2024 09:59:47 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <NusncLQBU_wh077gzNoOYhxZkXkzJ7e4E8VhCb6Lcks=.a5b4028b-fe5f-4c45-b396-a24c0e83ea27@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
 <NusncLQBU_wh077gzNoOYhxZkXkzJ7e4E8VhCb6Lcks=.a5b4028b-fe5f-4c45-b396-a24c0e83ea27@github.com>
Message-ID: <sb5z9nu5T108qIadCcU4BLfbLsKqVoVeVq3aBBCpcRk=.0faad6c3-9c8b-47a3-b7b1-f2c63d7b690d@github.com>

On Tue, 1 Oct 2024 06:15:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/heapShared.cpp line 1009:
>> 
>>> 1007: //
>>> 1008: // The set of classes that are required to be initialized for the archived
>>> 1009: // java mirrors are recorded in _runtime_default_subgraph_info (which probably
>> 
>> _runtime_default_subgraph_info is derived from _default_subgraph_info, the latter being the subgraph associated with class java.lang.Object. Perhaps using the prefix `root` or `jlobject` would make this clearer i.e. `_root_subgraph_info` and `_runtime_root_subgraph_info` or `_jlobject_subgraph_info` and `_runtime_jlobject_subgraph_info`.
>
> `root` may be a little over-loaded, because we have `HeapShared::get_root(int)` to get an arbitrary object with an integer index.
> 
> I renamed the various field/functions to `special_subgraph`, and added a comment about what this subgraph contains. What do you think?
> 
> Also, the two `subgraph_info` fields are renamed to the following:
> 
> 
>   static KlassSubGraphInfo* _dump_time_special_subgraph;              // for collecting info during dump time
>   static ArchivedKlassSubGraphInfoRecord* _run_time_special_subgraph; // for initializing classes during run time.

I agree `root` is too ambiguous. I think renaming the fields and methods to use `special_subgraph` works well and the comments make it very clear how the dump time and runtime subgraphs are used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1782485267

From rcastanedalo at openjdk.org  Tue Oct  1 11:24:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 1 Oct 2024 11:24:52 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <vChwINsCng-QfOUe_LpgAimWHG0xWx0Fcx-HsGssGrg=.fbdffb81-171e-4098-9289-8b2e6a2ac5ec@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vChwINsCng-QfOUe_LpgAimWHG0xWx0Fcx-HsGssGrg=.fbdffb81-171e-4098-9289-8b2e6a2ac5ec@github.com>
Message-ID: <czNh2deqytw1bmBVIC_6NpHrKcfW71VjcnDQTxTNphM=.daf26e36-e210-4162-93c8-59e0d1983a59@github.com>

On Mon, 30 Sep 2024 16:56:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thanks, Vladimir!

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

PR Comment: https://git.openjdk.org/jdk/pull/19746#issuecomment-2385515540

From aboldtch at openjdk.org  Tue Oct  1 11:35:40 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 11:35:40 GMT
Subject: RFR: 8340420: ZGC: Should call `vm_shutdown_during_initialization`
 if initialization fails [v4]
In-Reply-To: <urbgixZy31lkaX_BU_m0cwqDPY_08GZMm8pBQwUrio8=.901ab1b9-0d9e-4c5d-aac6-6d5796b15974@github.com>
References: <cHdFbGY8nsCUn1zAkB5NrFaMg0voeSD-KU851w7ZMx0=.f6552eb1-cb7d-4182-b85f-38f90c340bda@github.com>
 <urbgixZy31lkaX_BU_m0cwqDPY_08GZMm8pBQwUrio8=.901ab1b9-0d9e-4c5d-aac6-6d5796b15974@github.com>
Message-ID: <BVhAr7tGNjl--G_fCUfE5Oj53DAJMx8AdV-1jsy7us0=.42c5479b-78a8-40f2-85b8-24e9775ac8e7@github.com>

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

>> ZGC does not call `vm_shutdown_during_initialization` if initialization fails during the setup of the CollectedHeap, in contrast to the other GC.
>> 
>> I propose we add a `ZInitialize::error` which we can use during initialisation to record errors. The first error recored is also stored and used as the error message when shutting down the VM. 
>> 
>> Initially used malloc to allocate the error (ed9ba5dd6805291a6b1b56566c933424230d3b4a) but feels like it is just better to have static storage for the string and not have to care about malloc potentially failing to allocate.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21254#issuecomment-2385535391

From aboldtch at openjdk.org  Tue Oct  1 11:35:41 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 11:35:41 GMT
Subject: Integrated: 8340420: ZGC: Should call
 `vm_shutdown_during_initialization` if initialization fails
In-Reply-To: <cHdFbGY8nsCUn1zAkB5NrFaMg0voeSD-KU851w7ZMx0=.f6552eb1-cb7d-4182-b85f-38f90c340bda@github.com>
References: <cHdFbGY8nsCUn1zAkB5NrFaMg0voeSD-KU851w7ZMx0=.f6552eb1-cb7d-4182-b85f-38f90c340bda@github.com>
Message-ID: <40Tf_SaytOZgsafuqaenEy0g1zsI9OYGmV_LrLAAyGI=.42bc42fa-9789-498c-8312-774f0b977714@github.com>

On Mon, 30 Sep 2024 06:36:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> ZGC does not call `vm_shutdown_during_initialization` if initialization fails during the setup of the CollectedHeap, in contrast to the other GC.
> 
> I propose we add a `ZInitialize::error` which we can use during initialisation to record errors. The first error recored is also stored and used as the error message when shutting down the VM. 
> 
> Initially used malloc to allocate the error (ed9ba5dd6805291a6b1b56566c933424230d3b4a) but feels like it is just better to have static storage for the string and not have to care about malloc potentially failing to allocate.

This pull request has now been integrated.

Changeset: f7c7958f
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7c7958f001b3242eb485efd25bbcf9e1be75d85
Stats:     119 lines in 9 files changed: 92 ins; 2 del; 25 mod

8340420: ZGC: Should call `vm_shutdown_during_initialization` if initialization fails

Reviewed-by: stefank, mli

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

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

From anton.seoane.ampudia at oracle.com  Tue Oct  1 11:43:12 2024
From: anton.seoane.ampudia at oracle.com (Anton Seoane Ampudia)
Date: Tue, 1 Oct 2024 11:43:12 +0000
Subject: [External] : Re: 8340363: Tag-specific default decorators for
 UnifiedLogging
In-Reply-To: <70804A3C-13CE-4F83-861B-BA280C7EEB47@kodewerk.com>
References: <DM4PR10MB7475D31B106FB945C71A0C71AF6B2@DM4PR10MB7475.namprd10.prod.outlook.com>
 <ac081f30-4645-4964-88e5-932593ab5272@oracle.com>
 <DM4PR10MB7475A31DE03F7EC290708654AF762@DM4PR10MB7475.namprd10.prod.outlook.com>
 <70804A3C-13CE-4F83-861B-BA280C7EEB47@kodewerk.com>
Message-ID: <DM4PR10MB74759F164D6F890717531E84AF772@DM4PR10MB7475.namprd10.prod.outlook.com>

Hello,

This proposal is targeted only for those cases where Hotspot developers agree on undecorated output. For example, C2 developers with jit+inlining. Every other use of UL except for those specific (and previously socialized and agreed-upon) cases will keep being the same as it is right now.

In summary, this is more of an ad-hoc proposal for the cases where some specific uses of -Xlog are always accompanied with ::none

Regards,
Ant?n

From: Kirk Pepperdine <kirk at kodewerk.com>
Date: Monday, 30 September 2024 at 18:07
To: Anton Seoane Ampudia <anton.seoane.ampudia at oracle.com>
Cc: David Holmes <david.holmes at oracle.com>, hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: [External] : Re: 8340363: Tag-specific default decorators for UnifiedLogging


So to be clear, is the proposal now to just drop the default decorators,
rather than allowing them to be replaced with alternate defaults? If
that is the case then it is the same as writing:

-Xlog:A+B::none

and I don't really see much value in that. But I wouldn't oppose it.

I would. At a minimum you need a timestamp.


Allowing new defaults gives more flexibility - but obviously the
developers using the specific tag combinations have to agree on what
defaults to set.

At the moment to get a reasonable GC log for G1, one needs to use the following setting.

-Xlog:gc*,gc+ref=debug,gc+phases=debug,gc+age=debug,safepoint:file=gc.log

Also, the ?noise to signal? ratio in these logs is exceptionally high.

Kind regards,
Kirk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241001/51120e83/attachment.htm>

From duke at openjdk.org  Tue Oct  1 12:54:07 2024
From: duke at openjdk.org (Mikhail Ablakatov)
Date: Tue, 1 Oct 2024 12:54:07 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
Message-ID: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>

Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.

Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.

Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

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

Commit messages:
 - fixup! 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
 - 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64

Changes: https://git.openjdk.org/jdk/pull/21286/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21286&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341194
  Stats: 1316 lines in 11 files changed: 736 ins; 0 del; 580 mod
  Patch: https://git.openjdk.org/jdk/pull/21286.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21286/head:pull/21286

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

From duke at openjdk.org  Tue Oct  1 12:54:07 2024
From: duke at openjdk.org (Mikhail Ablakatov)
Date: Tue, 1 Oct 2024 12:54:07 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <4kTqxhXa4ImTrup40tFAUqvKpLZ__nCSE8zenDK1suM=.5156ba8e-6380-4ab9-8234-011cc72057a5@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

@theRealAph, @adinn, please take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/21286#issuecomment-2385694195

From cnorrbin at openjdk.org  Tue Oct  1 12:59:12 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 1 Oct 2024 12:59:12 GMT
Subject: RFR: 8318127: align_up has potential overflow [v2]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <HcU67_3_Sv3EhEYSZf_ysrdsjquTMsh83ZYHoSkIIgU=.19f8f569-3ecf-417a-acf1-d20a32b6ce52@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

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

  checked/unchecked align functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/e50e1661..f1240c06

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

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

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

From cnorrbin at openjdk.org  Tue Oct  1 13:04:38 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 1 Oct 2024 13:04:38 GMT
Subject: RFR: 8318127: align_up has potential overflow [v2]
In-Reply-To: <HcU67_3_Sv3EhEYSZf_ysrdsjquTMsh83ZYHoSkIIgU=.19f8f569-3ecf-417a-acf1-d20a32b6ce52@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <HcU67_3_Sv3EhEYSZf_ysrdsjquTMsh83ZYHoSkIIgU=.19f8f569-3ecf-417a-acf1-d20a32b6ce52@github.com>
Message-ID: <zjSzhq2uWeXI0HgNqqd7kz3f7w-RYMIWnsCv2xYAzSM=.dd1f6a13-f3c3-4f6c-8a37-55b1526d38d6@github.com>

On Tue, 1 Oct 2024 12:59:12 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checked/unchecked align functions

Hi all, sorry for the late follow-up.
Based on the discussion, I've now added `align_up_checked` which asserts for overflow, and have reverted `align_up` to its original form.

The next steps would be to go through uses of `align_up` and change to `align_up_checked` as appropriate, but I feel that is out of scope for this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/20808#issuecomment-2385726224

From rkennke at openjdk.org  Tue Oct  1 13:46:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 1 Oct 2024 13:46:11 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
Message-ID: <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>

> This implements the remaining parts of LW locking in Zero. Much of the work has already been done by Axel, this basically only implements the missing part that handles synchronized JNI entries. I basically preserved the LM_LEGACY case, except that I shuffled the code a little to match what we do in monitorexit case in bytecodeInterpreter.cpp (but should be functionally equivalent). The LM_LIGHTWEIGHT and LM_MONITOR case (the latter of which has been broken, before) simply call into the runtime.
> 
> With this change, we can now remove the block in arguments.cpp that deals with missing LM_LIGHTWEIGHT support.
> 
> Testing:
>  - [x] bootcycle-images

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

 - Don't use monitor cache with Zero
 - Enable object monitor cache for zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21220/files
  - new: https://git.openjdk.org/jdk/pull/21220/files/50cec4b9..f5590ec0

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

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

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

From rkennke at openjdk.org  Tue Oct  1 13:46:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 1 Oct 2024 13:46:11 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <meDXPcVAoVB2IVxCOvCb848iegSSinlSNzjPgScK2YU=.63eaf82e-297b-4eba-aae1-61d543575fe8@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <meDXPcVAoVB2IVxCOvCb848iegSSinlSNzjPgScK2YU=.63eaf82e-297b-4eba-aae1-61d543575fe8@github.com>
Message-ID: <f-2pS07CqmluxTBYnLfqZCpYujnqgmCd5MUPTKSE-gQ=.872c6df0-5083-4c4d-a3b6-5c692178eda1@github.com>

On Tue, 1 Oct 2024 09:31:07 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The `LM_LIGHTWEIGHT` changes looks good to me.
> 
> This also enables `UseObjectMonitorTable`. I believe `BasicLock::object_monitor_cache()` must be modified as well. Assuming that both `ZERO` and a supported platform (e.g. `X86`) can and will be defined in the same build.
> 
> `ZERO` should return `nullptr` in `BasicLock::object_monitor_cache()` as well.

Thanks, Axel!

I made the change in basictLock.inline.hpp.

I've also run 'make bootcycle-images' to give it some testing.

Roman

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

PR Comment: https://git.openjdk.org/jdk/pull/21220#issuecomment-2385956293

From kbarrett at openjdk.org  Tue Oct  1 14:22:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 14:22:42 GMT
Subject: RFR: 8318127: align_up has potential overflow [v2]
In-Reply-To: <HcU67_3_Sv3EhEYSZf_ysrdsjquTMsh83ZYHoSkIIgU=.19f8f569-3ecf-417a-acf1-d20a32b6ce52@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <HcU67_3_Sv3EhEYSZf_ysrdsjquTMsh83ZYHoSkIIgU=.19f8f569-3ecf-417a-acf1-d20a32b6ce52@github.com>
Message-ID: <mz51sopxYDLpF2V7zE2Xw_5c8Q7nbfR9Acuv6m9aVC0=.3e9a7476-c9d0-41bb-aef8-ddb273e002c1@github.com>

On Tue, 1 Oct 2024 12:59:12 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checked/unchecked align functions

Changes requested by kbarrett (Reviewer).

src/hotspot/share/utilities/align.hpp line 80:

> 78: 
> 79: template<typename T, typename A, ENABLE_IF(std::is_integral<T>::value)>
> 80: constexpr T align_up_checked(T size, A alignment) {

I think this new version, adding align_up_checked, should not be done.

As I mentioned earlier, every use I've looked at expects the result to be not
less than the value being aligned.  That would mean all (or very nearly so)
uses would need to be changed to align_up_checked.  That's just backward.

Part of the problem the JBS issue wants to have addressed is that in the case of
signed value or pointer overflow, that actually is UB.  We want to try to catch
those.

If a modular variant is shown to be needed (and someone needs to find an actual
use case for it, and maybe a good name), then it can be added at that time. I
think such a variant should be restricted to unsigned integral values.

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

PR Review: https://git.openjdk.org/jdk/pull/20808#pullrequestreview-2340502567
PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1782956878

From kbarrett at openjdk.org  Tue Oct  1 14:22:43 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 14:22:43 GMT
Subject: RFR: 8318127: align_up has potential overflow [v2]
In-Reply-To: <Y4TB1H22t1ntkNsHxonQRBjJxhhEXS5w_LseK04Bo2g=.af9e5670-be57-4654-962d-64ddbeca37a0@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <jny-7tXX2Av0C9pIhBGQRFO801yMJz901wxe8wwks-k=.c3320afe-0ee2-4bdc-aa87-da8206e87755@github.com>
 <hpz4rj94qH_2WTGsLj5MD_OTbLgv0Kfq-WISIbcHGC0=.679e2e69-9dd7-4c7b-a5b7-898181775bde@github.com>
 <o-cP-GXA4y_uZ43-eqieqN-EpBr4b28b2IcLXncTBaI=.846c226c-2968-4983-b61e-906e44cdc39e@github.com>
 <cbYmtV2Y5f4D2gehNZJg9W4Po3Fe8rGvucX5ivIldNE=.7ddabac9-adbe-4a86-8657-de514bc80e73@github.com>
 <Y4TB1H22t1ntkNsHxonQRBjJxhhEXS5w_LseK04Bo2g=.af9e5670-be57-4654-962d-64ddbeca37a0@github.com>
Message-ID: <_MZee6D1BWdZvMXn-dS0626wASgfBEPz6KndHrprxKA=.cb2bbe83-a27a-42f5-86f3-1d9ec329480a@github.com>

On Mon, 23 Sep 2024 11:19:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There's no "perhaps" about the intended meaning in the JBS issue. I wrote that
>> issue; I remember what I meant. :) I suppose I could have been more precise.
>> 
>> So I disagree. I think align_up has an implied post-condition that the result
>> is not less than the value being aligned. That's certainly how it's used, in
>> every occurrance I've looked at. (I admit I didn't look at all ~450 uses
>> though.)
>
>> There's no "perhaps" about the intended meaning in the JBS issue. I wrote that issue; I remember what I meant. 
> 
> Sorry, I didn't mean to suggest otherwise. I was quibbling about the "mathematical result", but it's not important.
> 
>> :) I suppose I could have been more precise.
>> 
>> So I disagree. I think align_up has an implied post-condition that the result is not less than the value being aligned. That's certainly how it's used, in every occurrance I've looked at. (I admit I didn't look at all ~450 uses though.)
> 
> It seems we have a genuine difference of opinion about what the user can reasonably expect. I'd expect modular arithmetic, because C++ says so. However, I'll withdraw my objection, if only for the sake of not spending too much time discussing this issue.

BTW @theRealAph , regarding your example of the address of the the end of the page at the end of memory,
pointer arithmetic is not modular, and instead overflow is UB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1782947131

From jwaters at openjdk.org  Tue Oct  1 14:29:36 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Oct 2024 14:29:36 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <f-2pS07CqmluxTBYnLfqZCpYujnqgmCd5MUPTKSE-gQ=.872c6df0-5083-4c4d-a3b6-5c692178eda1@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <meDXPcVAoVB2IVxCOvCb848iegSSinlSNzjPgScK2YU=.63eaf82e-297b-4eba-aae1-61d543575fe8@github.com>
 <f-2pS07CqmluxTBYnLfqZCpYujnqgmCd5MUPTKSE-gQ=.872c6df0-5083-4c4d-a3b6-5c692178eda1@github.com>
Message-ID: <RU99FlGZ8hXMXPwLsKZcbxYDpbgNe-M4laSIRV6igrA=.bb3373e6-300a-4a31-beea-9827b142ec82@github.com>

On Tue, 1 Oct 2024 13:42:35 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The `LM_LIGHTWEIGHT` changes looks good to me.
> 
> This also enables `UseObjectMonitorTable`. I believe `BasicLock::object_monitor_cache()` must be modified as well. Assuming that both `ZERO` and a supported platform (e.g. `X86`) can and will be defined in the same build.
> 
> `ZERO` should return `nullptr` in `BasicLock::object_monitor_cache()` as well.

I might be missing something, but Zero cannot be combined with another VM variant in the configure step, so the risk of a CPU arch being defined at the same time as Zero cannot happen (The build system treats Zero a little strangely)

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

PR Comment: https://git.openjdk.org/jdk/pull/21220#issuecomment-2386123951

From cnorrbin at openjdk.org  Tue Oct  1 14:39:10 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 1 Oct 2024 14:39:10 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

Casper Norrbin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:

 - change reserve_memory test
 - align overflow check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/f1240c06..e50e1661

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

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

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

From cnorrbin at openjdk.org  Tue Oct  1 14:41:37 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 1 Oct 2024 14:41:37 GMT
Subject: RFR: 8318127: align_up has potential overflow [v2]
In-Reply-To: <mz51sopxYDLpF2V7zE2Xw_5c8Q7nbfR9Acuv6m9aVC0=.3e9a7476-c9d0-41bb-aef8-ddb273e002c1@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <HcU67_3_Sv3EhEYSZf_ysrdsjquTMsh83ZYHoSkIIgU=.19f8f569-3ecf-417a-acf1-d20a32b6ce52@github.com>
 <mz51sopxYDLpF2V7zE2Xw_5c8Q7nbfR9Acuv6m9aVC0=.3e9a7476-c9d0-41bb-aef8-ddb273e002c1@github.com>
Message-ID: <nrsXmrhulzBOF2gU9VfqCNZmI0j0nfWFLDj-MDWHK1M=.cc794913-5e2d-4542-ba3e-723f9e33dd7a@github.com>

On Tue, 1 Oct 2024 14:19:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Casper Norrbin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> src/hotspot/share/utilities/align.hpp line 80:
> 
>> 78: 
>> 79: template<typename T, typename A, ENABLE_IF(std::is_integral<T>::value)>
>> 80: constexpr T align_up_checked(T size, A alignment) {
> 
> I think this new version, adding align_up_checked, should not be done.
> 
> As I mentioned earlier, every use I've looked at expects the result to be not
> less than the value being aligned.  That would mean all (or very nearly so)
> uses would need to be changed to align_up_checked.  That's just backward.
> 
> Part of the problem the JBS issue wants to have addressed is that in the case of
> signed value or pointer overflow, that actually is UB.  We want to try to catch
> those.
> 
> If a modular variant is shown to be needed (and someone needs to find an actual
> use case for it, and maybe a good name), then it can be added at that time. I
> think such a variant should be restricted to unsigned integral values.

The last change, adding `align_up_checked` has been reverted. I agree that for the uses I looked at, they all assumed the aligned value to be greater or equal to the original value.

Additionally, the only tests that failed were gtests that aligned to maximum values, something that is not representative of actual use.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1782989171

From aboldtch at openjdk.org  Tue Oct  1 14:54:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 14:54:36 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>
Message-ID: <KtSLicHb3QroUYJSbNnidnceEsWjnRXk0mkpHvtG9LY=.a9bd983d-3d58-4278-9d23-4d7c263e6158@github.com>

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

>> This implements the remaining parts of LW locking in Zero. Much of the work has already been done by Axel, this basically only implements the missing part that handles synchronized JNI entries. I basically preserved the LM_LEGACY case, except that I shuffled the code a little to match what we do in monitorexit case in bytecodeInterpreter.cpp (but should be functionally equivalent). The LM_LIGHTWEIGHT and LM_MONITOR case (the latter of which has been broken, before) simply call into the runtime.
>> 
>> With this change, we can now remove the block in arguments.cpp that deals with missing LM_LIGHTWEIGHT support.
>> 
>> Testing:
>>  - [x] bootcycle-images
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Don't use monitor cache with Zero
>  - Enable object monitor cache for zero

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21220#pullrequestreview-2340609019

From aboldtch at openjdk.org  Tue Oct  1 14:54:37 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 14:54:37 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <RU99FlGZ8hXMXPwLsKZcbxYDpbgNe-M4laSIRV6igrA=.bb3373e6-300a-4a31-beea-9827b142ec82@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <meDXPcVAoVB2IVxCOvCb848iegSSinlSNzjPgScK2YU=.63eaf82e-297b-4eba-aae1-61d543575fe8@github.com>
 <f-2pS07CqmluxTBYnLfqZCpYujnqgmCd5MUPTKSE-gQ=.872c6df0-5083-4c4d-a3b6-5c692178eda1@github.com>
 <RU99FlGZ8hXMXPwLsKZcbxYDpbgNe-M4laSIRV6igrA=.bb3373e6-300a-4a31-beea-9827b142ec82@github.com>
Message-ID: <Dy2jaqLsamLode6u94SBwSIRk3nHHoQ3NiZV2wEO2Jo=.3167f022-2a7b-4b95-bc4a-b3b4964c7d70@github.com>

On Tue, 1 Oct 2024 14:26:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > The `LM_LIGHTWEIGHT` changes looks good to me.
> > This also enables `UseObjectMonitorTable`. I believe `BasicLock::object_monitor_cache()` must be modified as well. Assuming that both `ZERO` and a supported platform (e.g. `X86`) can and will be defined in the same build.
> > `ZERO` should return `nullptr` in `BasicLock::object_monitor_cache()` as well.
> 
> I might be missing something, but Zero cannot be combined with another VM variant in the configure step, so the risk of a CPU arch being defined at the same time as Zero cannot happen (The build system treats Zero a little strangely)

Good to know. Then it should not be an issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/21220#issuecomment-2386224177

From iklam at openjdk.org  Tue Oct  1 15:29:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 15:29:16 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v7]
In-Reply-To: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
Message-ID: <e9TYT8F5wUMOoypiusyV1DZZ13rLFADvjhyDZ9_-HM0=.d8ac9bbe-ea37-466c-81a6-9e3a7cb79dfc@github.com>

> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
> 
> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 14 additional commits since the last revision:

 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @coleenp comments
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @vnkozlov comment - added NOT_CDS_RETURN
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - some clean up
 - 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
 - ... and 4 more: https://git.openjdk.org/jdk/compare/7b51f877...180375ac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20959/files
  - new: https://git.openjdk.org/jdk/pull/20959/files/59dd8879..180375ac

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

  Stats: 12294 lines in 294 files changed: 9757 ins; 1520 del; 1017 mod
  Patch: https://git.openjdk.org/jdk/pull/20959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20959/head:pull/20959

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

From rkennke at openjdk.org  Tue Oct  1 15:38:38 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 1 Oct 2024 15:38:38 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <Dy2jaqLsamLode6u94SBwSIRk3nHHoQ3NiZV2wEO2Jo=.3167f022-2a7b-4b95-bc4a-b3b4964c7d70@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <meDXPcVAoVB2IVxCOvCb848iegSSinlSNzjPgScK2YU=.63eaf82e-297b-4eba-aae1-61d543575fe8@github.com>
 <f-2pS07CqmluxTBYnLfqZCpYujnqgmCd5MUPTKSE-gQ=.872c6df0-5083-4c4d-a3b6-5c692178eda1@github.com>
 <RU99FlGZ8hXMXPwLsKZcbxYDpbgNe-M4laSIRV6igrA=.bb3373e6-300a-4a31-beea-9827b142ec82@github.com>
 <Dy2jaqLsamLode6u94SBwSIRk3nHHoQ3NiZV2wEO2Jo=.3167f022-2a7b-4b95-bc4a-b3b4964c7d70@github.com>
Message-ID: <n3ixOjRTpjhCw7acTVLgEWcq3MPmGL1gQgVj2JkFqiM=.9209d26e-8214-447a-ab9b-a6d490188478@github.com>

On Tue, 1 Oct 2024 14:51:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > The `LM_LIGHTWEIGHT` changes looks good to me.
> 
> > 
> 
> > This also enables `UseObjectMonitorTable`. I believe `BasicLock::object_monitor_cache()` must be modified as well. Assuming that both `ZERO` and a supported platform (e.g. `X86`) can and will be defined in the same build.
> 
> > 
> 
> > `ZERO` should return `nullptr` in `BasicLock::object_monitor_cache()` as well.
> 
> 
> 
> I might be missing something, but Zero cannot be combined with another VM variant in the configure step, so the risk of a CPU arch being defined at the same time as Zero cannot happen (The build system treats Zero a little strangely)

No, this doesn't seem to be the case. I placed a STATIC_ASSERT in the #if defined ... block and it fired with ZERO. This means that yes, we *do* get both ZERO and (e.g.) X86 defined at the same time. And it makes sense, too. ZERO is a JVM variant and X86, AARCH64, etc are CPU arches. It is entirely possible and reasonable to build zero JVM on x86 or aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/21220#issuecomment-2386348384

From jwaters at openjdk.org  Tue Oct  1 15:45:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Oct 2024 15:45:39 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>
Message-ID: <VNg3srqty-fS3-gWvH1ITUnrycNZIQ4KRFfc6RdPuNc=.30dfebb2-1e13-40b3-bb29-c87841a65867@github.com>

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

>> This implements the remaining parts of LW locking in Zero. Much of the work has already been done by Axel, this basically only implements the missing part that handles synchronized JNI entries. I basically preserved the LM_LEGACY case, except that I shuffled the code a little to match what we do in monitorexit case in bytecodeInterpreter.cpp (but should be functionally equivalent). The LM_LIGHTWEIGHT and LM_MONITOR case (the latter of which has been broken, before) simply call into the runtime.
>> 
>> With this change, we can now remove the block in arguments.cpp that deals with missing LM_LIGHTWEIGHT support.
>> 
>> Testing:
>>  - [x] bootcycle-images
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Don't use monitor cache with Zero
>  - Enable object monitor cache for zero

> > > The `LM_LIGHTWEIGHT` changes looks good to me.
> > 
> > 
> > > 
> > 
> > 
> > > This also enables `UseObjectMonitorTable`. I believe `BasicLock::object_monitor_cache()` must be modified as well. Assuming that both `ZERO` and a supported platform (e.g. `X86`) can and will be defined in the same build.
> > 
> > 
> > > 
> > 
> > 
> > > `ZERO` should return `nullptr` in `BasicLock::object_monitor_cache()` as well.
> > 
> > 
> > I might be missing something, but Zero cannot be combined with another VM variant in the configure step, so the risk of a CPU arch being defined at the same time as Zero cannot happen (The build system treats Zero a little strangely)
> 
> No, this doesn't seem to be the case. I placed a STATIC_ASSERT in the #if defined ... block and it fired with ZERO. This means that yes, we _do_ get both ZERO and (e.g.) X86 defined at the same time. And it makes sense, too. ZERO is a JVM variant and X86, AARCH64, etc are CPU arches. It is entirely possible and reasonable to build zero JVM on x86 or aarch64.

That is very strange, the build system treats (Or is at least supposed to treat) Zero as a CPU arch. Might be time for me to revisit that code, either I made a mistake, or something is wrong. Thanks for the heads up

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

PR Comment: https://git.openjdk.org/jdk/pull/21220#issuecomment-2386364029

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 jwaters at openjdk.org  Tue Oct  1 15:49:36 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 1 Oct 2024 15:49:36 GMT
Subject: RFR: 8307532: Implement LM_LIGHTWEIGHT for Zero [v2]
In-Reply-To: <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
 <72_LEfE7xUDrGtgwB2lT0DCx8o6FMD-Kgz9LSgN5Ds4=.124c4065-8e7a-452b-9352-e113875f3c35@github.com>
Message-ID: <p0LfIIhz9xqoAf0bDBENHHm26iZoh6VEwaJK615UFeo=.e408d50c-eeb6-490f-bd24-ee0dd3290c77@github.com>

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

>> This implements the remaining parts of LW locking in Zero. Much of the work has already been done by Axel, this basically only implements the missing part that handles synchronized JNI entries. I basically preserved the LM_LEGACY case, except that I shuffled the code a little to match what we do in monitorexit case in bytecodeInterpreter.cpp (but should be functionally equivalent). The LM_LIGHTWEIGHT and LM_MONITOR case (the latter of which has been broken, before) simply call into the runtime.
>> 
>> With this change, we can now remove the block in arguments.cpp that deals with missing LM_LIGHTWEIGHT support.
>> 
>> Testing:
>>  - [x] bootcycle-images
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Don't use monitor cache with Zero
>  - Enable object monitor cache for zero

Either way, looks ok

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21220#pullrequestreview-2340775136

From lmesnik at openjdk.org  Tue Oct  1 16:04:42 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 1 Oct 2024 16:04:42 GMT
Subject: Integrated: 8340988: Update jdk/jfr/event/gc/collection tests to
 accept "CodeCache GC Threshold" as valid GC reason
In-Reply-To: <1ZSbNKjlCqyiZJgH3lC79mZI38WGreVQZ4hILJGzCao=.29b6dd30-a9c7-475d-be65-2a11ef62e71e@github.com>
References: <1ZSbNKjlCqyiZJgH3lC79mZI38WGreVQZ4hILJGzCao=.29b6dd30-a9c7-475d-be65-2a11ef62e71e@github.com>
Message-ID: <Rs6YnY7QY5eFbB5F5HbBg6qIKYGoUHI70xZtSMO3tZQ=.30181f1f-3e75-4c13-b0b5-d6c4aaf9137c@github.com>

On Sat, 28 Sep 2024 01:14:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Tests
> jdk/jdk/jfr/event/gc/collection/TestGCCauseWith* GC
> check the GC reasons. They GC might be caused by
> "CodeCache GC Threshold"
> if test is executed with Xcomp and GC caused by codecache cleanup.

This pull request has now been integrated.

Changeset: 9a7817b1
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a7817b1376d055c5a7c1005b275cc1f198e5364
Stats:     10 lines in 4 files changed: 2 ins; 0 del; 8 mod

8340988: Update jdk/jfr/event/gc/collection tests to accept "CodeCache GC Threshold" as valid GC reason

Reviewed-by: tschatzl

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

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

From kbarrett at openjdk.org  Tue Oct  1 16:33:46 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 16:33:46 GMT
Subject: RFR: 8341336: Fix -Wzero-as-null-pointer-constant warnings in
 PRODUCT-only codefix warnings in release build
Message-ID: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>

Please review this change that removes -Wzero-as-null-pointer-constant warnings
triggered by PRODUCT-only code. Most are uses of PRODUCT_RETURN0 in a pointer
context.  These are changed to use the (new) macro PRODUCT_RETURN_NULL.

Testing: mach5 tier1
Locally (linux-x64) ran tier1 testing on a release build.
(mach5 mostly does fastdebug testing)

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

Commit messages:
 - fix warnings in release build

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

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

From stefank at openjdk.org  Tue Oct  1 16:55:34 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 1 Oct 2024 16:55:34 GMT
Subject: RFR: 8341336: Fix -Wzero-as-null-pointer-constant warnings in
 PRODUCT-only codefix warnings in release build
In-Reply-To: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
References: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
Message-ID: <dXV140t0jc6m3TkIPSn4X1f7D5QF0gsYzBAcLr3XdMw=.50932ad3-e6f8-4dc6-bd03-680267e7bb35@github.com>

On Tue, 1 Oct 2024 16:29:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant warnings
> triggered by PRODUCT-only code. Most are uses of PRODUCT_RETURN0 in a pointer
> context.  These are changed to use the (new) macro PRODUCT_RETURN_NULL.
> 
> Testing: mach5 tier1
> Locally (linux-x64) ran tier1 testing on a release build.
> (mach5 mostly does fastdebug testing)

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21290#pullrequestreview-2340918860

From ccheung at openjdk.org  Tue Oct  1 17:17:53 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:17:53 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v8]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <7Hxl8pLddrlwTdc5Zhyjx46upjT6m17HQuI6SogSwNU=.6d2f0c7a-97f9-4480-a455-35ed4e00439b@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

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

  @iklam comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/a3eef6cd..4b6ca617

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

  Stats: 109 lines in 5 files changed: 83 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

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

From ccheung at openjdk.org  Tue Oct  1 17:24:39 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:24:39 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <2TjFLEwheCeUXfKrmZW_wJ_oCB7BNoknhhecGaMC2g0=.6469d724-cd72-42df-a89d-5ffb7ab995b9@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
 <2TjFLEwheCeUXfKrmZW_wJ_oCB7BNoknhhecGaMC2g0=.6469d724-cd72-42df-a89d-5ffb7ab995b9@github.com>
Message-ID: <nm7PWI7__xHyFAuwixRh3ZtlcxHXz6P1EyJlZcE222k=.907bbf57-3bf7-40dd-85fe-a2abdfd90764@github.com>

On Sun, 29 Sep 2024 04:11:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It should work because the jmod file won't be added to the `module_paths`.
>
> In my scenario, will the FMG be used? If so, the program won't be able to load the code in mod2.jmod, so the behavior will be wrong. Could you add a test case for this?

It turns out that jmod cannot be used during runtime.
>From `jdk.intenal.module.ModulePath`:

            // not recognized
            String msg;
            if (!isLinkPhase && entry.toString().endsWith(".jmod")) {
                msg = "JMOD format not supported at execution time";
            } else {
                msg = "Module format not recognized";
            }

I added some tests with jmod.

>> I'm not sure. Is your suggest equivalent to:
>>   `return (strcmp(key, "jdk.module.path"));`
>
> Yes, the C++ compiler will automatically concatenate `MODULE_PROPERTY_PREFIX PATH` into a single string.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783230047
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783230247

From ccheung at openjdk.org  Tue Oct  1 17:24:40 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:24:40 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <JgKjpc7KozfFkpYHl8YpG3vp6GvVZKTP8ibD-9lkFrI=.864de45a-e859-42f2-9073-13d0043ade3d@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
 <8zmMK9osKaE2aA051AjovRF3ilTWLZhsSQKTgans7QQ=.87813411-03bb-4b52-af61-8e7595c794e2@github.com>
 <JgKjpc7KozfFkpYHl8YpG3vp6GvVZKTP8ibD-9lkFrI=.864de45a-e859-42f2-9073-13d0043ade3d@github.com>
Message-ID: <PLbswO66Hg0pjOyaC4Bi7_qiNlNCWhuq7-iKvNaWrkI=.f9bde854-3d73-45e3-aa7a-d136e15e5cb2@github.com>

On Sun, 29 Sep 2024 06:43:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Why does it need to clear `moduleToReader` only for app loader and not for platform loader? Is it because the `moduleToReader` for the app loader may contain reference to jar files that indirectly references some file system objects?
>> 
>> Since moduleToReader is just a cache, I think it's better to always clear it for both loaders. Also, the logic can be moved into BuiltinClassLoader: 
>> 
>> 
>> class BuiltinClassLoader {
>>         ....
>>         private void resetArchivedStates() {
>>             ucp = null;
>>             resourceCache = null;
>>             setClassPath(null);  // AppClassLoader will initialize this again at runtime.
>>             moduleToReader.clear();
>>         }
>
> setClassPath(null) is the same as `ucp = null` but yes, keep it simple as otherwise there will be question each time there are changes. BuiltinClassPath should not include any code that is specific to the app class loader or the platform class loader as there are specific subclasses for that.

Ok. I've simplified the fix as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783230382

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 ccheung at openjdk.org  Tue Oct  1 17:30:10 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:30:10 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

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

  trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/4b6ca617..b9a9b75a

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

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

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

From kbarrett at openjdk.org  Tue Oct  1 17:56:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 17:56:36 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
Message-ID: <7TqPFlTer33ZvTz6X-Abf6yopsJsL4uBCZKS1u6_QzU=.72cf24d0-1a52-435c-8e62-2b541f01c818@github.com>

On Tue, 1 Oct 2024 14:39:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:
> 
>  - change reserve_memory test
>  - align overflow check

Add at least one death test (TEST_VM_ASSERT) for align_up hitting the assertion.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20808#pullrequestreview-2341029473

From sviswanathan at openjdk.org  Tue Oct  1 18:05:44 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Oct 2024 18:05:44 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
Message-ID: <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>

On Tue, 1 Oct 2024 09:53:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks for the example. Yes, you have a point there.  So we would need to do:
>>    src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);
>
>> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2); Or even simplified to: src1.rearrange(this.toShuffle(), src2);
> 
> Yes, this may save additional allocation penalty of result array allocation which may slightly improve fall back performance, but logical operation cannot be directly applied over floating point vectors. so, we will need an explicit conversion to integral vector, which is why I opted for current fallback implementation which is in line with rest of the code.

I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1783278063

From sviswanathan at openjdk.org  Tue Oct  1 18:12:39 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Oct 2024 18:12:39 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v14]
In-Reply-To: <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>
Message-ID: <5wF2qLX9Z_tquvURMW0HVnrmMla1awxtz6C0UYI0lh4=.94df7340-1a27-4d93-80fa-d4c561641a97@github.com>

On Tue, 1 Oct 2024 09:51:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2797:

> 2795: 
> 2796:   Node* operation = lowerSelectFromOp ?
> 2797:                       LowerSelectFromTwoVectorOperation(gvn(), opd1, opd2, opd3, vt) :

Thanks for bringing the lowering right here. It opens up an optimization opportunity: currently for float/double we have two casts for index (e.g. from float -> int at line 2786 and from int -> byte at line 2661 as part of LowerSelectFromTwoVectorOperation. Could this be done by one cast?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1783296741

From iwalulya at openjdk.org  Tue Oct  1 18:13:35 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 1 Oct 2024 18:13:35 GMT
Subject: RFR: 8341336: Fix -Wzero-as-null-pointer-constant warnings in
 PRODUCT-only codefix warnings in release build
In-Reply-To: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
References: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
Message-ID: <RS5ths_1XDERzMeq3WXomPav8RiTstPXLuQp9NvO0Tg=.d37c7133-bdb4-4711-ac4c-91c9510eac26@github.com>

On Tue, 1 Oct 2024 16:29:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant warnings
> triggered by PRODUCT-only code. Most are uses of PRODUCT_RETURN0 in a pointer
> context.  These are changed to use the (new) macro PRODUCT_RETURN_NULL.
> 
> Testing: mach5 tier1
> Locally (linux-x64) ran tier1 testing on a release build.
> (mach5 mostly does fastdebug testing)

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21290#pullrequestreview-2341077866

From duke at openjdk.org  Tue Oct  1 18:59:49 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Tue, 1 Oct 2024 18:59:49 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled by
 default
Message-ID: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>

`-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.

I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.

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

Commit messages:
 - Tests assume UnlockExperimentalVMOptions is disabled by default.

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

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

From ysr at openjdk.org  Tue Oct  1 18:59:49 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 1 Oct 2024 18:59:49 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default
In-Reply-To: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
Message-ID: <dDTKCjC6ncTQ8VqgU1Icg0_IEaYn6-5QaUQAFSLsrUw=.e408d22f-e9c9-4677-a9c8-8402473aa0c4@github.com>

On Fri, 27 Sep 2024 20:12:59 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
> 
> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.

The rationale for the change, and the change, both look good to me.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21233#pullrequestreview-2338714452

From stefank at openjdk.org  Tue Oct  1 19:30:36 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 1 Oct 2024 19:30:36 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default
In-Reply-To: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
Message-ID: <CtE0-ra63mAv4UenDa8gUVkXXELqj8MoCNedaho0iTE=.c75daacf-9ba6-4dbe-9d3d-b2a97f4a4c5d@github.com>

On Fri, 27 Sep 2024 20:12:59 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

> 'm not entirely satisfied by adding a @require that only applies to a subset of the checks in a test class. In VMOptionWarning, the experimental flag only applies to the first of the three scenarios it checks. But I suspect this is a general problem with @require, and I'd be happy to hear suggestions on how to avoid disabling too much.

You can add multiple run sections with different @requires lines. Then you can let each run line pass in different "tokens" to the main function and let it use that to dispatch to the various sub-tests. Maybe `test/hotspot/jtreg/gc//metaspace/TestSizeTransitions.java` could be a an OK inspiration for that.

test/jtreg-ext/requires/VMProps.java line 262:

> 260:         return "" + WB.getBooleanVMFlag("UnlockExperimentalVMOptions");
> 261:     }
> 262: 

I think an alternative here could be to just add UnlockExperimentalVMOptions to the list in vmOptFinalFlags and then use `!vm.opt.final.UnlockExperimentalVMOptions`. This is what we typically do when we want to filter on the final value of a specified flag.

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

PR Review: https://git.openjdk.org/jdk/pull/21233#pullrequestreview-2341198738
PR Review Comment: https://git.openjdk.org/jdk/pull/21233#discussion_r1783371562

From sviswanathan at openjdk.org  Tue Oct  1 22:51:43 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Oct 2024 22:51:43 GMT
Subject: Integrated: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <WcsGRuRKJidE0YutSqONyhmZ210_m6ee45RbzswJIeM=.9f23cb68-57fd-40db-8222-62999a8e7928@github.com>

On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: 83dcb02d
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83dcb02d776448aa04f3f41df489bd4355443a4d
Stats:     697 lines in 47 files changed: 549 ins; 34 del; 114 mod

8340079: Modify rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes

Reviewed-by: jbhateja, psandoz

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

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

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 iklam at openjdk.org  Wed Oct  2 01:03:04 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Oct 2024 01:03:04 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v13]
In-Reply-To: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
Message-ID: <5k1Lry1HIw7ORYiZYEBOHxSvt52v-4VWOecOAf0L1SU=.bbd552e6-0695-4a7d-a550-af5905e3dbeb@github.com>

> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Problem:**
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
> 
> **Solution:**
> 
> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
> 
> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
> 
> **Review Notes:**
> 
> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
> 
> **Caveats:**
> 
> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the environment:
> 
> 
> enum Foo {
>     [....]
>     static fin...

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - Adjust TEST.groups after merge with mainline
 - For aot-inited classes, require the <clinit> of all supertypes to be executed in assembly phase as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20958/files
  - new: https://git.openjdk.org/jdk/pull/20958/files/244a5dec..af65ba55

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

  Stats: 149 lines in 5 files changed: 117 ins; 8 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/20958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20958/head:pull/20958

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

From iklam at openjdk.org  Wed Oct  2 01:06:09 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Oct 2024 01:06:09 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v8]
In-Reply-To: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
Message-ID: <BZLINoty4WOC87MLuUNM51x4z8F_f-OB_WweVFfQNK0=.d1da149e-88e8-495d-a119-57bc5aa41bb0@github.com>

> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
> 
> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 15 additional commits since the last revision:

 - 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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @coleenp comments
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @vnkozlov comment - added NOT_CDS_RETURN
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - some clean up
 - ... and 5 more: https://git.openjdk.org/jdk/compare/b2281e30...9b787423

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20959/files
  - new: https://git.openjdk.org/jdk/pull/20959/files/180375ac..9b787423

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

  Stats: 232 lines in 7 files changed: 141 ins; 17 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/20959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20959/head:pull/20959

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

From dholmes at openjdk.org  Wed Oct  2 02:16:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 02:16:42 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
Message-ID: <WSLrm07XPgw4024Z32lDS6xnyyZ-VrGARzO8CYLlz7M=.490ea91d-5eb1-494c-970c-fdad8bd57683@github.com>

On Tue, 1 Oct 2024 17:30:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

Nothing further from me on the VM side. Just a couple of minor nits.

Thanks

src/hotspot/share/cds/filemap.cpp line 974:

> 972:   if (header()->has_full_module_graph() && !matched_module_paths) {
> 973:     CDSConfig::stop_using_optimized_module_handling();
> 974:     log_info(cds)("optimized module handling: disabled because mismatched module paths");

Suggestion:

    log_info(cds)("optimized module handling: disabled because of mismatched module paths");

src/hotspot/share/cds/heapShared.cpp line 885:

> 883:       ClassLoaderExt::num_module_paths() > 0) {
> 884:     // ArchivedModuleGraph was created with a --module-path that's different than the runtime --module-path.
> 885:     // Thus, it might contain references to modules that do not exist in runtime. We cannot use it.

Suggestion:

    // Thus, it might contain references to modules that do not exist at runtime. We cannot use it.

src/hotspot/share/classfile/classLoaderExt.cpp line 123:

> 121: 
> 122:   // Sort the module paths before storing into CDS archive for simpler
> 123:   // checking during runtime.

Suggestion:

  // checking at runtime.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2341785448
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783757502
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783754320
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783758610

From iklam at openjdk.org  Wed Oct  2 02:58:36 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Oct 2024 02:58:36 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <SahFjukrjKXoGUlBPYWAor3Gcl8UrJqKqrzXwjkl0yA=.5201ad8e-7c8f-44e8-b292-b8942c057570@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
 <OUTMOZXcNapNk56TIuQAHfN4KJgl_VUutCTL1km8lqs=.56b9f14f-8caf-4270-a650-fb0b48ef4a0f@github.com>
 <SahFjukrjKXoGUlBPYWAor3Gcl8UrJqKqrzXwjkl0yA=.5201ad8e-7c8f-44e8-b292-b8942c057570@github.com>
Message-ID: <m3zZMPZ8E6IYNPNXFKYmPe5CDrUg6YrQ0hmp_KWoCZg=.e50934b8-51c5-4e97-b745-a84c1b3f8054@github.com>

On Tue, 1 Oct 2024 09:48:00 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> I added a comment according to your suggestion. I'll also see if it's possible to require all supertypes to be aot-initialized. I think that will make the model simpler.
>
> Yes, it should be simpler, although perhaps at the cost of omitting some mirrors from the heap section. Anyway, the comment is helpful.

@adinn I added the enforcement that for an aot-inited class, all of its super types's <clinit> must also be executed during assembly phase. I think this model is easier to understand. It also forces you to check if the side effects of the supertypes' <clinit>s can also be cached. Please re-review this change: [ba6f280](https://github.com/openjdk/jdk/pull/20958/commits/ba6f2805875beb02298d1615674147b65c98a039)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1783783686

From iklam at openjdk.org  Wed Oct  2 03:00:36 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Oct 2024 03:00:36 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
Message-ID: <t-VwcaJ1AYAtJYoVowLiSgpsIZZZ7kkvGfyBAceQ-uI=.2df8b23d-e4e1-4ecf-8c2b-d29075a8be2a@github.com>

On Tue, 1 Oct 2024 17:30:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2341825251

From ccheung at openjdk.org  Wed Oct  2 05:50:14 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 05:50:14 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v10]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

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

  @dholmes-ora comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/b9a9b75a..47f164fb

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

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

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

From ccheung at openjdk.org  Wed Oct  2 05:50:14 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 05:50:14 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <WSLrm07XPgw4024Z32lDS6xnyyZ-VrGARzO8CYLlz7M=.490ea91d-5eb1-494c-970c-fdad8bd57683@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
 <WSLrm07XPgw4024Z32lDS6xnyyZ-VrGARzO8CYLlz7M=.490ea91d-5eb1-494c-970c-fdad8bd57683@github.com>
Message-ID: <WBau3nLuwAYZQxCxudtXWRERs5-ZyYmU3tJrdEfeCwY=.8c45a58c-69db-4ed3-b960-2c161acdface@github.com>

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

> Nothing further from me on the VM side. Just a couple of minor nits.
> 
> Thanks

I've pushed another commit to address the nits.
Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21048#issuecomment-2387676650

From shade at openjdk.org  Wed Oct  2 07:32:45 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Oct 2024 07:32:45 GMT
Subject: RFR: 8338379: Accesses to class init state should be properly
 synchronized [v3]
In-Reply-To: <rfpYhhTaoPmTAbE-NOvZWZu4L4coDBhPMCH4UI5X8nk=.b9f5e443-262e-4f32-b829-a4606e0d4762@github.com>
References: <HLfZCSxJFLlREAilMOVXH2oAIfplir9uiJhah5eDxAk=.9f8667e7-1b38-453f-a4ed-c7237e5c06fc@github.com>
 <rfpYhhTaoPmTAbE-NOvZWZu4L4coDBhPMCH4UI5X8nk=.b9f5e443-262e-4f32-b829-a4606e0d4762@github.com>
Message-ID: <AY7vTrHBLAwY1zho5ubEErM75c3Ld-4yZB_T0Y_A-ck=.f73dbc93-4e0e-48c3-a233-9ec40b8184bd@github.com>

On Mon, 30 Sep 2024 17:11:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for the discussion. We have not seen a clear evidence this is _the_ problem in the field, neither we were able to come up with a reproducer. We have found this gap by inspecting the code, while chasing a production bug.
>> 
>> In short, `InstanceKlass::_init_state` is used as the "witness" for initialized class state. When class initialization completes, it needs to publish the class state by writing `_init_state = _fully_initialized` with release semantics.
>> 
>> Various accessors that poll `IK::_init_state`, looking for class initialization to complete, need to read the field with acquire semantics. This is where the change fans out, touching VM, interpreter and compiler paths that e.g. implement clinit barriers. In some cases in assembler code, we can rely on hardware memory model to do what we need (i.e. acquire barriers/fences are nops).
>> 
>> I made the best _guess_ what ARM32, S390X, PPC64, RISC-V code should look like, based on what related code does for volatile loads. It would be good if port maintainers could sanity-check those.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>>  - [x] GHA to test platform buildability + adhoc platform cross-compilation
>
> Aleksey Shipilev 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 branch 'master' into JDK-8338379-class-init-checks
>  - Pick up PPC64 patch from Martin
>  - Relax to just a release
>  - Initial version

Thanks all for reviews. If there are no other comments, I'll integrate soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/21110#issuecomment-2387805633

From shade at openjdk.org  Wed Oct  2 07:33:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Oct 2024 07:33:41 GMT
Subject: RFR: 8341336: Fix -Wzero-as-null-pointer-constant warnings in
 PRODUCT-only code
In-Reply-To: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
References: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
Message-ID: <VAXQ-rkU5YuF640xlNf7ESntcLaIs38TdnTsIbvudEs=.8a5feb93-bb9a-4605-adea-dcc48419c0e0@github.com>

On Tue, 1 Oct 2024 16:29:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant warnings
> triggered by PRODUCT-only code. Most are uses of PRODUCT_RETURN0 in a pointer
> context.  These are changed to use the (new) macro PRODUCT_RETURN_NULL.
> 
> Testing: mach5 tier1
> Locally (linux-x64) ran tier1 testing on a release build.
> (mach5 mostly does fastdebug testing)

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21290#pullrequestreview-2342065301

From alanb at openjdk.org  Wed Oct  2 07:42:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 07:42:38 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v10]
In-Reply-To: <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
Message-ID: <nDSy2CigmErZcYzjiCQWJRYrOmWEHq-adxUNXd5S_D8=.44190dca-1e49-45be-8934-a49e36c21243@github.com>

On Wed, 2 Oct 2024 05:50:14 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

Thanks for the updates, I don't have any other comments.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2342081231

From mli at openjdk.org  Wed Oct  2 07:50:42 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Oct 2024 07:50:42 GMT
Subject: RFR: 8340732: RISC-V: Refactor crc32 scalar version [v2]
In-Reply-To: <29Die5DNeMk_F3aZVcXSWnX9hPIr4-vmyYZzqMDnJ6g=.49d75dd2-6454-4732-b1f1-34bcb9cb1782@github.com>
References: <cV8T7mehkX911msU0nYsCnGlmD22dovagMpdMmqSjCc=.6f256a23-5708-4941-9520-111ae2178501@github.com>
 <_Gk-ry03eJvNJv4bcpQLKKoE36Yh-SH853WYXPtdnOo=.e6f7a9f0-f7f8-41f1-aa99-ff33e16b20c2@github.com>
 <29Die5DNeMk_F3aZVcXSWnX9hPIr4-vmyYZzqMDnJ6g=.49d75dd2-6454-4732-b1f1-34bcb9cb1782@github.com>
Message-ID: <ZUBxyZQQjvx19Qfn_HCqcPx-zQiVhzJ5R0C6EbKAMtw=.9f8e4c2b-2cf6-442b-aee7-18c3c90876d7@github.com>

On Wed, 25 Sep 2024 08:51:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - merge master
>>  - bltz -> beqz
>>  - Initial commit
>
> Updated change looks good to me. Any test performed? Thanks.

Thanks @RealFYang for your reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/21150#issuecomment-2387834319

From mli at openjdk.org  Wed Oct  2 07:50:43 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Oct 2024 07:50:43 GMT
Subject: Integrated: 8340732: RISC-V: Refactor crc32 scalar version
In-Reply-To: <cV8T7mehkX911msU0nYsCnGlmD22dovagMpdMmqSjCc=.6f256a23-5708-4941-9520-111ae2178501@github.com>
References: <cV8T7mehkX911msU0nYsCnGlmD22dovagMpdMmqSjCc=.6f256a23-5708-4941-9520-111ae2178501@github.com>
Message-ID: <VrvyMeJUs4ty5QSfA-zSzHtren4D9qR_RXOLSPc-W6Y=.0191227f-6627-400d-8224-7aec294e8bff@github.com>

On Tue, 24 Sep 2024 07:22:51 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> As discussed in?https://github.com/openjdk/jdk/pull/20910#discussion_r1755150447,?it's helpful to refactor the existing scalar version of crc32 intrinsic.
> Several refactoring are done in this pr,
> 1. Simplify the `len` usage, now it only decreases (i.e. change in one direction)
> 2. Simplify the code paths
> 3. Remove one instruction in `L_by4_loop`
> 4. Remove unnecessary code
> 5. Other misc
> 
> Thanks!

This pull request has now been integrated.

Changeset: 52c2ea65
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52c2ea65c4ab6a2d25e9de465fbf20034fe79028
Stats:     57 lines in 2 files changed: 9 ins; 26 del; 22 mod

8340732: RISC-V: Refactor crc32 scalar version

Reviewed-by: fyang

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

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

From mgronlun at openjdk.org  Wed Oct  2 07:55:42 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 2 Oct 2024 07:55:42 GMT
Subject: RFR: 8340826: Should not send unload notification for scratch
 classes [v2]
In-Reply-To: <_pMZy7UcNUu1V6S2zW3mfpGFUiwlz7OBkF-rM0TV6XI=.d231d35b-1357-4dbd-9041-5ee0bda3d3dd@github.com>
References: <ARao9HxBkQeeqaEOs6jEW_KM55PNSXijhDJSKbg-SDs=.78cbbb6d-26c7-4b5c-a285-c1954f88da33@github.com>
 <_pMZy7UcNUu1V6S2zW3mfpGFUiwlz7OBkF-rM0TV6XI=.d231d35b-1357-4dbd-9041-5ee0bda3d3dd@github.com>
Message-ID: <VUAkaiTqqA62UGr036b0YPUHuiTVYLdXCBrmcDAvHVE=.a0bacb8b-ed75-4036-b7a6-80595f90fd04@github.com>

On Thu, 26 Sep 2024 18:23:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The jvmti class redefinition creates temporary scratch classes for it's own purposes. These classes are added to corresponding classloaders and might be unloaded.
>> In this case the jvmti/jfr and log events are generated twice: for original class and for it's scratch.
>> 
>> The bug could be reproduced by jfr test
>> jdk/jfr/api/metadata/eventtype/TestUnloadingEventClass.java
>> with '-Xcomp -XX:TieredStopAtLevel=1' or with '-Xcomp'
>> 
>> The test log (modified slightly) shown
>> 
>> 
>> [167.294s][info ][class,unload] unloading class jdk.jfr.api.metadata.eventtype.TestUnloadingEventClass$ToBeUnloaded 0x00000000af1006d8 allocated
>> [167.294s][info ][class,unload] unloading class jdk.jfr.api.metadata.eventtype.TestUnloadingEventClass$ToBeUnloaded 0x00000000af100248 fully_initialized
>> [167.345s][trace][class,unload] unlinking class (subclass): jdk.jfr.api.metadata.eventtype.TestUnloadingEventClass$ToBeUnloaded
>> [167.872s][trace][gc          ] GC(0) Restored 3597 marks, occupying 57552 B
>> [167.924s][info ][gc          ] GC(0) Pause Full (System.gc()) 34M->2M(136M) 691.041ms
>> Unloaded count: 2
>> 
>> 
>> instead of expected
>> 
>> 
>> 
>> [159.737s][info ][class,unload] unloading class jdk.jfr.api.metadata.eventtype.TestUnloadingEventClass$ToBeUnloaded 0x0000000041100248 state: fully_initialized
>> [159.800s][trace][class,unload] unlinking class (subclass): jdk.jfr.api.metadata.eventtype.TestUnloadingEventClass$ToBeUnloaded
>> [160.341s][trace][gc          ] GC(0) Restored 3597 marks, occupying 57552 B
>> [160.384s][info ][gc          ] GC(0) Pause Full (System.gc()) 34M->2M(136M) 710.422ms
>> 
>> 
>> 
>> The test hang because got 2 events while waiting for one.
>> The "allocated" version is the scratch class generated by JVMTI JFR agent that redefine classes.
>> 
>> The fix is to don't send notification for scratch classes. The scratch classes shouldn't have dependency so added assertion. Also, we don't expect any other not loaded classes during unloaded.
>> 
>> Thanks Coleen for details about scratch classed. 
>> 
>> Tested with tier1-5 and with :jdk_jfr with Xcomp and c1.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space added

src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 487:

> 485:   assert(klass != nullptr, "invariant");
> 486:   assert(_subsystem_callback != nullptr, "invariant");
> 487:   if (klass->is_instance_klass() && InstanceKlass::cast(klass)->is_scratch_class()) {

This is not correct. The unloaded event is generated earlier, this part is the metadata system serializing the constants referenced in said event. The result would still be an event, but it would have missing constants, such as the klass name.

Can scratch klasses short-circuit the "external" unload paths in cases of scratch klasses (which are really only implementation details). There is a property in the classfile parser about "broadcasting" that we (jfr) use to only log a single IK instance when we replace an IK with another schema extended IK.

Logically there should only be one official instance of an IK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21166#discussion_r1783977386

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 aph at openjdk.org  Wed Oct  2 09:15:42 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 2 Oct 2024 09:15:42 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <Y4TB1H22t1ntkNsHxonQRBjJxhhEXS5w_LseK04Bo2g=.af9e5670-be57-4654-962d-64ddbeca37a0@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <jny-7tXX2Av0C9pIhBGQRFO801yMJz901wxe8wwks-k=.c3320afe-0ee2-4bdc-aa87-da8206e87755@github.com>
 <hpz4rj94qH_2WTGsLj5MD_OTbLgv0Kfq-WISIbcHGC0=.679e2e69-9dd7-4c7b-a5b7-898181775bde@github.com>
 <o-cP-GXA4y_uZ43-eqieqN-EpBr4b28b2IcLXncTBaI=.846c226c-2968-4983-b61e-906e44cdc39e@github.com>
 <cbYmtV2Y5f4D2gehNZJg9W4Po3Fe8rGvucX5ivIldNE=.7ddabac9-adbe-4a86-8657-de514bc80e73@github.com>
 <Y4TB1H22t1ntkNsHxonQRBjJxhhEXS5w_LseK04Bo2g=.af9e5670-be57-4654-962d-64ddbeca37a0@github.com>
Message-ID: <Wau6964Ntu09JZV6w70gndUe-CHZX9WRyBAxoGinsDA=.d71dba22-f79c-4a6a-98c8-f69fb6c299e8@github.com>

On Mon, 23 Sep 2024 11:19:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There's no "perhaps" about the intended meaning in the JBS issue. I wrote that
>> issue; I remember what I meant. :) I suppose I could have been more precise.
>> 
>> So I disagree. I think align_up has an implied post-condition that the result
>> is not less than the value being aligned. That's certainly how it's used, in
>> every occurrance I've looked at. (I admit I didn't look at all ~450 uses
>> though.)
>
>> There's no "perhaps" about the intended meaning in the JBS issue. I wrote that issue; I remember what I meant. 
> 
> Sorry, I didn't mean to suggest otherwise. I was quibbling about the "mathematical result", but it's not important.
> 
>> :) I suppose I could have been more precise.
>> 
>> So I disagree. I think align_up has an implied post-condition that the result is not less than the value being aligned. That's certainly how it's used, in every occurrance I've looked at. (I admit I didn't look at all ~450 uses though.)
> 
> It seems we have a genuine difference of opinion about what the user can reasonably expect. I'd expect modular arithmetic, because C++ says so. However, I'll withdraw my objection, if only for the sake of not spending too much time discussing this issue.

> BTW @theRealAph , regarding your example of the address of the the end of the page at the end of memory, pointer arithmetic is not modular, and instead overflow is UB.

I wasn't talking about pointer arithmetic, as was explicit in my reply. I was talking about unsigned integer types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1784096286

From adinn at openjdk.org  Wed Oct  2 09:31:38 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Oct 2024 09:31:38 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <eRKJk58XtqwD5Ai7bqqlUrbUGdiZEg-I36QOGVP-ylA=.ca7da4d5-2e16-4c5f-a834-1127c94706ef@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
 <eRKJk58XtqwD5Ai7bqqlUrbUGdiZEg-I36QOGVP-ylA=.ca7da4d5-2e16-4c5f-a834-1127c94706ef@github.com>
Message-ID: <29M4XgPuTwMxei6435fsPciWiFGENXA3ks-Io9NSi5U=.75640d62-803a-4950-b0eb-b9cd5b2fd4da@github.com>

On Tue, 1 Oct 2024 06:27:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/heapShared.cpp line 939:
>> 
>>> 937: 
>>> 938:   _run_time_subgraph_info_table.serialize_header(soc);
>>> 939:   soc->do_ptr(&_runtime_default_subgraph_info);
>> 
>> It would help to have a comment here explaining that 1) before the do_ptr call the specific subgraph_info passed into this call holds all the classes that need to be initialized on behalf of java.lang.Object 2) after the call it is includes all the extra classes that need initializing on behalf of some archived java.lang.Class mirror. This would help to clarify why it was picked as the holder for these extra classes (i.e. it is the obvious root class from which to start running initializations).
>> 
>> If field `_runtime_default_subgraph_info` was renamed to identify it as being the root subgraph associated with class java.lang.Object this would also be clearer (see related comment)
>
> Actually, the `do_ptr()` call is a somewhat cryptic API for passing values and pointers between the assembly phase and the production run.
> 
> In this example, during the production run, before the `do_ptr()` call,  `_runtime_default_subgraph_info` is null. After the call, it points to the `ArchivedKlassSubGraphInfoRecord` that was created by `HeapShared::archive_subgraph_info()` during the assembly phase.

Ok, I see now what is gong on here. This is driven by either a `ReadClosure` or a `WriteClosure` depening on where `MetadataShared::serialize` get called from. I was mixing this up with what goes on when we see a call to `do_entry` in `CopyKlassSubGraphInfoToArchive`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1784114360

From cnorrbin at openjdk.org  Wed Oct  2 09:51:37 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 2 Oct 2024 09:51:37 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
Message-ID: <6El8BHhS_3em-PowTCVwPHYf7KW-CJ4sLOFFV4p_4qQ=.514671c3-2ec4-41a1-9ae4-8c38baed2e5c@github.com>

On Tue, 1 Oct 2024 14:39:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:
> 
>  - change reserve_memory test
>  - align overflow check

To find a middle ground, maybe a solution like this would be good, avoiding the assert when called with unsigned types. This does however have the consequence that the function behaves a bit differently depending on from where it is called.

```c++
template<typename T, typename A, ENABLE_IF(std::is_integral<T>::value)>
constexpr T align_up(T size, A alignment) {
  T mask = checked_cast<T>(alignment_mask(alignment));
  if (!std::is_unsigned<T>()) {
    assert(size <= std::numeric_limits<T>::max() - mask, "overflow");
  }
  T adjusted = size + mask;
  return align_down(adjusted, alignment);
}

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

PR Comment: https://git.openjdk.org/jdk/pull/20808#issuecomment-2388131661

From adinn at openjdk.org  Wed Oct  2 09:58:37 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Oct 2024 09:58:37 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v13]
In-Reply-To: <5k1Lry1HIw7ORYiZYEBOHxSvt52v-4VWOecOAf0L1SU=.bbd552e6-0695-4a7d-a550-af5905e3dbeb@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <5k1Lry1HIw7ORYiZYEBOHxSvt52v-4VWOecOAf0L1SU=.bbd552e6-0695-4a7d-a550-af5905e3dbeb@github.com>
Message-ID: <gAVnyEUSgUItEyiGoEMW4t8f_fAnhPbGzQ6hM0S7ZS0=.5b7039ea-28ce-4cc3-9ff4-07c29fb8d703@github.com>

On Wed, 2 Oct 2024 01:03:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> **Problem:**
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
>> 
>> **Solution:**
>> 
>> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
>> 
>> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
>> 
>> **Review Notes:**
>> 
>> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
>> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
>> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
>> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
>> 
>> **Caveats:**
>> 
>> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the e...
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust TEST.groups after merge with mainline
>  - For aot-inited classes, require the <clinit> of all supertypes to be executed in assembly phase as well

src/hotspot/share/cds/aotClassInitializer.cpp line 31:

> 29: #include "oops/instanceKlass.inline.hpp"
> 30: 
> 31: class AOTClassInitializer::AllowedSpec {

Suggestion:

// An AllowedSpec is used to match a class name Symbol against either the full name text or a leading prefix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1784202063

From mli at openjdk.org  Wed Oct  2 10:15:54 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Oct 2024 10:15:54 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
Message-ID: <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>

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

>> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>> 
>> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>> 
>> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
>> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>> 
>> ## Summary of the Changes
>> 
>> ### Platform-Independent Changes (`src/hotspot/share`)
>> 
>> These consist mainly of:
>> 
>> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
>> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
>> - temporary support for porting the JEP to the remaining platforms.
>> 
>> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>> 
>> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>> 
>> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>> 
>> #### ADL Changes
>> 
>> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>> 
>> #### `G1BarrierSetAssembler` Changes
>> 
>> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live ...
>
> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>  - riscv port refactor
>  - Remove temporary support code
>  - Merge jdk-24+17
>  - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>  - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>  - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>  - Merge jdk-24+16
>  - Ensure that detected encode-and-store patterns are matched
>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>  - ... and 43 more: https://git.openjdk.org/jdk/compare/9566d51f...14483b83

Hi, have some comments on riscv part code.
I'm not sure if the same comments also apply to other code, please have a look if necessary.

src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 55:

> 53:   }
> 54:   for (RegSetIterator<Register> reg = no_preserve.begin(); *reg != noreg; ++reg) {
> 55:     stub->dont_preserve(*reg);

Could `no_preserve` and `preserve` overlap?
If false, then seems it's not necessary to do `dont_preserve` for `no_preserve`
If true, seems it's not safe to `dont_preserve` these regs? I'm not sure.

src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:

> 167:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
> 168:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
> 169:   effect(TEMP res, TEMP tmp1, TEMP tmp2);

should `res` be `TEMP_DEF`?

src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 201:

> 199:   predicate(UseG1GC && needs_acquiring_load_reserved(n) && n->as_LoadStore()->barrier_data() != 0);
> 200:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
> 201:   effect(TEMP res, TEMP tmp1, TEMP tmp2);

should `res` be `TEMP_DEF`?

src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 233:

> 231:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
> 232:   match(Set res (CompareAndExchangeN mem (Binary oldval newval)));
> 233:   effect(TEMP res, TEMP tmp1, TEMP tmp2, TEMP tmp3);

should `res` be `TEMP_DEF`?

src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 263:

> 261:   predicate(UseG1GC && needs_acquiring_load_reserved(n) && n->as_LoadStore()->barrier_data() != 0);
> 262:   match(Set res (CompareAndExchangeN mem (Binary oldval newval)));
> 263:   effect(TEMP res, TEMP tmp1, TEMP tmp2, TEMP tmp3);

should `res` be `TEMP_DEF`?

And same comment for following instructs?

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

PR Review: https://git.openjdk.org/jdk/pull/19746#pullrequestreview-2342455263
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784240549
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784209154
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784210589
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784211728
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784212185

From kbarrett at openjdk.org  Wed Oct  2 10:20:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Oct 2024 10:20:35 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <6El8BHhS_3em-PowTCVwPHYf7KW-CJ4sLOFFV4p_4qQ=.514671c3-2ec4-41a1-9ae4-8c38baed2e5c@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
 <6El8BHhS_3em-PowTCVwPHYf7KW-CJ4sLOFFV4p_4qQ=.514671c3-2ec4-41a1-9ae4-8c38baed2e5c@github.com>
Message-ID: <zVGNeoqgoUwTLw03tBS5dPa7tvKNS677AvSk8hsg7Xw=.1749dacb-b390-4e10-b429-4aaef4fb03c3@github.com>

On Wed, 2 Oct 2024 09:48:59 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> To find a middle ground, maybe a solution like this would be good, avoiding the assert when called with unsigned types. This does however have the consequence that the function behaves a bit differently depending on from where it is called.
> 
> ```c++
> template<typename T, typename A, ENABLE_IF(std::is_integral<T>::value)>
> constexpr T align_up(T size, A alignment) {
>   T mask = checked_cast<T>(alignment_mask(alignment));
>   if (!std::is_unsigned<T>()) {
>     assert(size <= std::numeric_limits<T>::max() - mask, "overflow");
>   }
>   T adjusted = size + mask;
>   return align_down(adjusted, alignment);
> }
> ```

That's more or less the modular variant that I mentioned earlier.  Find a use-case for modular behavior, and we
can add a new function that provides that behavior.  But I think align_up should have the post-condition that
size <= result.  (I don't think it's worth making that post-condition explicit in code though.  That's what the
pre-condition is providing, and the check needs to be pre, else UB for some types comes into play.)

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

PR Comment: https://git.openjdk.org/jdk/pull/20808#issuecomment-2388274861

From kbarrett at openjdk.org  Wed Oct  2 10:20:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Oct 2024 10:20:36 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <Wau6964Ntu09JZV6w70gndUe-CHZX9WRyBAxoGinsDA=.d71dba22-f79c-4a6a-98c8-f69fb6c299e8@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <jny-7tXX2Av0C9pIhBGQRFO801yMJz901wxe8wwks-k=.c3320afe-0ee2-4bdc-aa87-da8206e87755@github.com>
 <hpz4rj94qH_2WTGsLj5MD_OTbLgv0Kfq-WISIbcHGC0=.679e2e69-9dd7-4c7b-a5b7-898181775bde@github.com>
 <o-cP-GXA4y_uZ43-eqieqN-EpBr4b28b2IcLXncTBaI=.846c226c-2968-4983-b61e-906e44cdc39e@github.com>
 <cbYmtV2Y5f4D2gehNZJg9W4Po3Fe8rGvucX5ivIldNE=.7ddabac9-adbe-4a86-8657-de514bc80e73@github.com>
 <Y4TB1H22t1ntkNsHxonQRBjJxhhEXS5w_LseK04Bo2g=.af9e5670-be57-4654-962d-64ddbeca37a0@github.com>
 <Wau6964Ntu09JZV6w70gndUe-CHZX9WRyBAxoGinsDA=.d71dba22-f79c-4a6a-98c8-f69fb6c299e8@github.com>
Message-ID: <NdbPKs7AzEKoMDRskY8Du-DbyOp19qaRI_Z2P5m5OUQ=.74631429-7a15-4021-b7bd-d819e7bc2623@github.com>

On Wed, 2 Oct 2024 09:12:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> There's no "perhaps" about the intended meaning in the JBS issue. I wrote that issue; I remember what I meant. 
>> 
>> Sorry, I didn't mean to suggest otherwise. I was quibbling about the "mathematical result", but it's not important.
>> 
>>> :) I suppose I could have been more precise.
>>> 
>>> So I disagree. I think align_up has an implied post-condition that the result is not less than the value being aligned. That's certainly how it's used, in every occurrance I've looked at. (I admit I didn't look at all ~450 uses though.)
>> 
>> It seems we have a genuine difference of opinion about what the user can reasonably expect. I'd expect modular arithmetic, because C++ says so. However, I'll withdraw my objection, if only for the sake of not spending too much time discussing this issue.
>
>> BTW @theRealAph , regarding your example of the address of the the end of the page at the end of memory, pointer arithmetic is not modular, and instead overflow is UB.
> 
> I wasn't talking about pointer arithmetic, as was explicit in my reply. I was talking about unsigned integer types.

That wasn't obvious to me, because of "the address of the end of the page at".  I took that to mean pointers were involved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1784261042

From thartmann at openjdk.org  Wed Oct  2 10:49:36 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Oct 2024 10:49:36 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
Message-ID: <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:

> 1: //
> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.

Drive-by comment: The `// *` format looks weird.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1784292673

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 thartmann at openjdk.org  Wed Oct  2 10:53:36 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Oct 2024 10:53:36 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <0WYbEFFG9EMd3IMQIYrD63o2NR6YkjHUBXknIIJCyn8=.7bb75a83-ba38-4e5c-bf94-fb6703c3a93c@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

I submitted testing and will report back once it passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21286#issuecomment-2388350574

From rcastanedalo at openjdk.org  Wed Oct  2 11:42:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 11:42:52 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
Message-ID: <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>

On Wed, 2 Oct 2024 10:10:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>>  - riscv port refactor
>>  - Remove temporary support code
>>  - Merge jdk-24+17
>>  - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>>  - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>>  - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>>  - Merge jdk-24+16
>>  - Ensure that detected encode-and-store patterns are matched
>>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>>  - ... and 43 more: https://git.openjdk.org/jdk/compare/486c5b0d...14483b83
>
> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 55:
> 
>> 53:   }
>> 54:   for (RegSetIterator<Register> reg = no_preserve.begin(); *reg != noreg; ++reg) {
>> 55:     stub->dont_preserve(*reg);
> 
> Could `no_preserve` and `preserve` overlap?
> If false, then seems it's not necessary to do `dont_preserve` for `no_preserve`
> If true, seems it's not safe to `dont_preserve` these regs? I'm not sure.

In the G1 case, the use of `dont_preserve` is an optimization to avoid spilling and reloading, in the slow path of the pre-barrier, registers (`res`) that are not live at that point. It is not necessary for correctness, but saves a few bytes in the generated code. If `res` was not marked as `dont_preserve`, it would be included in the pre-barrier stub's preserve set (`BarrierStubC2::preserve_set()`) because it is live out of the entire AD instruction (as computed by `BarrierSetC2::compute_liveness_at_stubs()`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784346898

From rcastanedalo at openjdk.org  Wed Oct  2 11:53:52 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 11:53:52 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
Message-ID: <Hb8hg-u4fHx_vjZg67WH5BGCDasejxy6fpFEvrUSiLQ=.bf419701-c4fa-4167-8662-c711bb2ff93a@github.com>

On Wed, 2 Oct 2024 09:58:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>>  - riscv port refactor
>>  - Remove temporary support code
>>  - Merge jdk-24+17
>>  - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>>  - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>>  - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>>  - Merge jdk-24+16
>>  - Ensure that detected encode-and-store patterns are matched
>>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>>  - ... and 43 more: https://git.openjdk.org/jdk/compare/0dc16d16...14483b83
>
> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
> 
>> 167:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
>> 168:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
>> 169:   effect(TEMP res, TEMP tmp1, TEMP tmp2);
> 
> should `res` be `TEMP_DEF`?

It could, but the effect would be the same (see [JDK-8058880](https://bugs.openjdk.org/browse/JDK-8058880)). I went with `TEMP` for the x64 and aarch64 platforms for consistency with the analogous ZGC ADL code, see e.g. https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad#L182-L204.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784358586

From adinn at openjdk.org  Wed Oct  2 12:34:37 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Oct 2024 12:34:37 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v13]
In-Reply-To: <5k1Lry1HIw7ORYiZYEBOHxSvt52v-4VWOecOAf0L1SU=.bbd552e6-0695-4a7d-a550-af5905e3dbeb@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <5k1Lry1HIw7ORYiZYEBOHxSvt52v-4VWOecOAf0L1SU=.bbd552e6-0695-4a7d-a550-af5905e3dbeb@github.com>
Message-ID: <ycs95iOw8Cwln8cUiSPynjrfkXRkI56hcU3J1rA8_I4=.834b56d6-51dd-4d47-a4fb-e8081f279b4a@github.com>

On Wed, 2 Oct 2024 01:03:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> **Problem:**
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
>> 
>> **Solution:**
>> 
>> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
>> 
>> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
>> 
>> **Review Notes:**
>> 
>> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
>> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
>> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
>> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
>> 
>> **Caveats:**
>> 
>> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the e...
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust TEST.groups after merge with mainline
>  - For aot-inited classes, require the <clinit> of all supertypes to be executed in assembly phase as well

Marked as reviewed by adinn (Reviewer).

@iklam The update looks good but I suggested a few changes and comments for clarity.

src/hotspot/share/cds/aotClassInitializer.cpp line 39:

> 37:     : _class_name(class_name), _is_prefix(is_prefix)
> 38:   {
> 39:     _len = (class_name == nullptr) ? 0 : (int)strlen(class_name);

Do you really want to allow class_name to be passed as nullptr? Would it not be better to terminate the array of AllowedSpec with a nullptr entry?

If so then this constructor needs an assert `class_name != nullptr`

If not then method `matches` probably ought to assert `_class_name != nullptr`

src/hotspot/share/cds/aotClassInitializer.cpp line 52:

> 50: };
> 51: 
> 52: 

I was trying to work out how to improve the commenting of this method because it currently has to refer to 'the tables in can_archive_initialized_mirror' i.e. the comment needs to describe where and why this method is called in order to explain what it does, which has a bad smell. However, it seems to me the problem is really in the way the code is structured.

It being called `is_allowed` also highlights the same problem. That name is confusing because
1. it does not make it very clear that it can be called more than once from `can_archive_initialized_mirror` with alternative specs (hence the comment)
2. passing this test is only one of several checks on whether a class can be archived e.g. an direct subtype of enum gets a free pass
3. it does not clarify that this check currently also performs verification

I think it would be clearer to split this into two methods:

    bool AOTClassInitializer::is_allowed_by_spec(AllowedSpec* specs, ik);
    void verify_spec_class(ik);

The first method would just do the iterative match test and return true or false. The second one would only be called when the first call returns true and would include the recursive testing of super and interfaces, asserting on failure. That latter call could then also be placed under ifdef ASSERT.

This would allow the comment in the verify method to be rewritten to:

// Any class whose mirror is included by an AllowSpecification requires that
//  - all super class mirrors must be included
//  - all super interface mirrors that have <clinit> must be included.

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

PR Review: https://git.openjdk.org/jdk/pull/20958#pullrequestreview-2342474269
PR Comment: https://git.openjdk.org/jdk/pull/20958#issuecomment-2388527486
PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1784220255
PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1784414294

From adinn at openjdk.org  Wed Oct  2 12:34:38 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Oct 2024 12:34:38 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v10]
In-Reply-To: <m3zZMPZ8E6IYNPNXFKYmPe5CDrUg6YrQ0hmp_KWoCZg=.e50934b8-51c5-4e97-b745-a84c1b3f8054@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
 <irp7yiQkkafJvad3oO4uvc3K_QA3mikoA6DOgdikZCU=.e8558e56-f7ea-4c37-9aa1-1a1cfa18b2f4@github.com>
 <X6vX3XcONVMjLTzy12xFPLK4BL_W0BnJtNSi2Ahd5yQ=.780e397b-75b4-406c-b173-c0339c1a9517@github.com>
 <OUTMOZXcNapNk56TIuQAHfN4KJgl_VUutCTL1km8lqs=.56b9f14f-8caf-4270-a650-fb0b48ef4a0f@github.com>
 <SahFjukrjKXoGUlBPYWAor3Gcl8UrJqKqrzXwjkl0yA=.5201ad8e-7c8f-44e8-b292-b8942c057570@github.com>
 <m3zZMPZ8E6IYNPNXFKYmPe5CDrUg6YrQ0hmp_KWoCZg=.e50934b8-51c5-4e97-b745-a84c1b3f8054@github.com>
Message-ID: <i2GZa0v6JXZTCo_lo0J8ct6q3Vp0nF0G5jbS7l0Carg=.664c1d89-8dc4-4be4-a742-7736c47ef0ea@github.com>

On Wed, 2 Oct 2024 02:56:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yes, it should be simpler, although perhaps at the cost of omitting some mirrors from the heap section. Anyway, the comment is helpful.
>
> @adinn I added the enforcement that for an aot-inited class, all of its super types's <clinit> must also be executed during assembly phase. I think this model is easier to understand. It also forces you to check if the side effects of the supertypes' <clinit>s can also be cached. Please re-review this change: [ba6f280](https://github.com/openjdk/jdk/pull/20958/commits/ba6f2805875beb02298d1615674147b65c98a039)

Yes, this change looks fine and this is a sensible restriction to avoid a grey area.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20958#discussion_r1784417656

From mli at openjdk.org  Wed Oct  2 12:57:48 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 2 Oct 2024 12:57:48 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
 <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
Message-ID: <StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>

On Wed, 2 Oct 2024 11:40:18 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> If `res` was not marked as `dont_preserve`, it would be included in the pre-barrier stub's preserve set (`BarrierStubC2::preserve_set()`) because it is live out of the entire AD instruction (as computed by `BarrierSetC2::compute_liveness_at_stubs()`).

Thanks for explanation!
I did not realize this, if that's the case, then it's good.

>> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
>> 
>>> 167:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
>>> 168:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
>>> 169:   effect(TEMP res, TEMP tmp1, TEMP tmp2);
>> 
>> should `res` be `TEMP_DEF`?
>
> It could, but the effect would be the same (see [JDK-8058880](https://bugs.openjdk.org/browse/JDK-8058880)). I went with `TEMP` for the x64 and aarch64 platforms for consistency with the analogous ZGC ADL code, see e.g. https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad#L182-L204.

I saw the riscv one in z_riscv.ad is: `effect(TEMP oldval_tmp, TEMP newval_tmp, TEMP tmp1, TEMP_DEF res);`, maybe it's good  to change riscv one?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784479784
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1784479526

From mark.reinhold at oracle.com  Wed Oct  2 13:04:34 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Wed, 2 Oct 2024 13:04:34 +0000
Subject: New candidate JEP: 491: Synchronize Virtual Threads without Pinning
Message-ID: <20241002130433.7264977CE2F@eggemoggin.niobe.net>

https://openjdk.org/jeps/491

  Summary: Improve the scalability of Java code that uses synchronized
  methods and statements by arranging for virtual threads that block in
  such constructs to release their underlying platform threads for use
  by other virtual threads.  This will eliminate nearly all cases of
  virtual threads being pinnedjep444-pinning to platform threads, which
  severely restricts the number of virtual threads available to handle an
  application's workload.

- Mark

From rkennke at openjdk.org  Wed Oct  2 13:30:38 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 2 Oct 2024 13:30:38 GMT
Subject: Integrated: 8307532: Implement LM_LIGHTWEIGHT for Zero
In-Reply-To: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
References: <13U9XvpqyKNdHhr3MdXXa8Gc3PTsfByumX-maUm0t7Y=.b33384d8-63b7-4d4f-9b29-f95d4bcc1f48@github.com>
Message-ID: <59H2Pf8J2pYJ-o-X5If69fAo2Mk4YXdsV8QNfJiGfPI=.321a7ace-131f-4e65-a7ab-0b058ce314eb@github.com>

On Fri, 27 Sep 2024 15:16:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This implements the remaining parts of LW locking in Zero. Much of the work has already been done by Axel, this basically only implements the missing part that handles synchronized JNI entries. I basically preserved the LM_LEGACY case, except that I shuffled the code a little to match what we do in monitorexit case in bytecodeInterpreter.cpp (but should be functionally equivalent). The LM_LIGHTWEIGHT and LM_MONITOR case (the latter of which has been broken, before) simply call into the runtime.
> 
> With this change, we can now remove the block in arguments.cpp that deals with missing LM_LIGHTWEIGHT support.
> 
> Testing:
>  - [x] bootcycle-images
>  - [x] java -jar jcstress-latest.jar -tb 1h

This pull request has now been integrated.

Changeset: 5e980072
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e9800721a29dbb85be76a6f56c2e2677a3274f2
Stats:     36 lines in 4 files changed: 4 ins; 16 del; 16 mod

8307532: Implement LM_LIGHTWEIGHT for Zero

Reviewed-by: aboldtch, jwaters

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

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

From stefank at openjdk.org  Wed Oct  2 13:56:11 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 2 Oct 2024 13:56:11 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class
Message-ID: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>

Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.

This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.

This PR is a suggestion for how to untangle this for the OSThread class.

Things in the code that changed with this patch that might be good to take an extra look at:
1) I dropped unnecessary includes
2) `pd_initialize/pd_destroy` was converted into constructor/destructor
3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
5) I did some reordering of functions to unify the four platforms
6) Moved `_thread_id` to the platform files
7) I stopped exposing the `thread_id_t` typedef.
8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 

Tested: tier1-3, (excluding AIX, which I can't build/test)

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

Commit messages:
 - 8341413: Stop including osThread_os.hpp in the middle of the OSThread class

Changes: https://git.openjdk.org/jdk/pull/21306/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21306&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341413
  Stats: 578 lines in 20 files changed: 251 ins; 238 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/21306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21306/head:pull/21306

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

From lmesnik at openjdk.org  Wed Oct  2 15:07:41 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 2 Oct 2024 15:07:41 GMT
Subject: RFR: 8340826: Should not send unload notification for scratch
 classes [v2]
In-Reply-To: <VUAkaiTqqA62UGr036b0YPUHuiTVYLdXCBrmcDAvHVE=.a0bacb8b-ed75-4036-b7a6-80595f90fd04@github.com>
References: <ARao9HxBkQeeqaEOs6jEW_KM55PNSXijhDJSKbg-SDs=.78cbbb6d-26c7-4b5c-a285-c1954f88da33@github.com>
 <_pMZy7UcNUu1V6S2zW3mfpGFUiwlz7OBkF-rM0TV6XI=.d231d35b-1357-4dbd-9041-5ee0bda3d3dd@github.com>
 <VUAkaiTqqA62UGr036b0YPUHuiTVYLdXCBrmcDAvHVE=.a0bacb8b-ed75-4036-b7a6-80595f90fd04@github.com>
Message-ID: <a1IJTMeEkoFPHxDaENr3u11ztQmCf84wnDJpwPBtuN4=.e20c6d91-c418-40a2-b50c-debb27880588@github.com>

On Wed, 2 Oct 2024 07:51:24 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space added
>
> src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp line 487:
> 
>> 485:   assert(klass != nullptr, "invariant");
>> 486:   assert(_subsystem_callback != nullptr, "invariant");
>> 487:   if (klass->is_instance_klass() && InstanceKlass::cast(klass)->is_scratch_class()) {
> 
> This is not correct. The unloaded event is generated earlier, this part is the metadata system serializing the constants referenced in said event. The result would still be an event, but it would have missing constants, such as the klass name.
> 
> Can scratch klasses short-circuit the "external" unload paths in cases of scratch klasses (which are really only implementation details). There is a property in the classfile parser about "broadcasting" that we (jfr) use to only log a single IK instance when we replace an IK with another schema extended IK.
> 
> Logically there should only be one official instance of an IK.

Thanks for suggestion, I filed https://bugs.openjdk.org/browse/JDK-8341421

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21166#discussion_r1784731562

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 ccheung at openjdk.org  Wed Oct  2 15:54:45 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 15:54:45 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v10]
In-Reply-To: <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
Message-ID: <fUGEG-WPTTWiBErPwR5J_NeQI6QViesWLilPIg53sgg=.d690f063-5181-4ef9-a228-46b51d2c43a9@github.com>

On Wed, 2 Oct 2024 05:50:14 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

Thanks Alan, David, Ioi for the reviews!
Also thanks Alan for your help on the core-libs changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21048#issuecomment-2389023082

From ccheung at openjdk.org  Wed Oct  2 15:54:46 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 15:54:46 GMT
Subject: Integrated: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <Qz7p9oRxxi9zz0r6JpJMUxOFt48unbIsEM0MaZppe3g=.4273b65f-457c-4479-bd93-903627875c7d@github.com>

On Tue, 17 Sep 2024 23:44:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

This pull request has now been integrated.

Changeset: 0bdfe88e
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bdfe88e4c5d2f2364b07b803aae16ca0ba7b9d2
Stats:     600 lines in 19 files changed: 549 ins; 9 del; 42 mod

8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time

Reviewed-by: alanb, dholmes, iklam

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

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

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 19:03:21 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Wed, 2 Oct 2024 19:03:21 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
Message-ID: <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>

> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
> 
> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.

Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor VMOptionWarning for better scoping of @require
 - Use simpler vm.opt.final approach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21233/files
  - new: https://git.openjdk.org/jdk/pull/21233/files/e8e42d22..e63bd7f7

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

  Stats: 73 lines in 4 files changed: 42 ins; 15 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21233/head:pull/21233

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

From duke at openjdk.org  Wed Oct  2 19:03:21 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Wed, 2 Oct 2024 19:03:21 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <CtE0-ra63mAv4UenDa8gUVkXXELqj8MoCNedaho0iTE=.c75daacf-9ba6-4dbe-9d3d-b2a97f4a4c5d@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <CtE0-ra63mAv4UenDa8gUVkXXELqj8MoCNedaho0iTE=.c75daacf-9ba6-4dbe-9d3d-b2a97f4a4c5d@github.com>
Message-ID: <RjxSWQ0UtfjrjGhUQyihN4XEadHKU1SyCr_YZzen594=.87d7637d-b40a-445c-b731-7750b12c87db@github.com>

On Tue, 1 Oct 2024 19:20:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor VMOptionWarning for better scoping of @require
>>  - Use simpler vm.opt.final approach
>
> test/jtreg-ext/requires/VMProps.java line 262:
> 
>> 260:         return "" + WB.getBooleanVMFlag("UnlockExperimentalVMOptions");
>> 261:     }
>> 262: 
> 
> I think an alternative here could be to just add UnlockExperimentalVMOptions to the list in vmOptFinalFlags and then use `!vm.opt.final.UnlockExperimentalVMOptions`. This is what we typically do when we want to filter on the final value of a specified flag.

Ah that's much easier.  I saw that there were several patterns in this file, and that approach sipped my radar.  Will update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21233#discussion_r1785090973

From duke at openjdk.org  Wed Oct  2 19:09:35 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Wed, 2 Oct 2024 19:09:35 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <CtE0-ra63mAv4UenDa8gUVkXXELqj8MoCNedaho0iTE=.c75daacf-9ba6-4dbe-9d3d-b2a97f4a4c5d@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <CtE0-ra63mAv4UenDa8gUVkXXELqj8MoCNedaho0iTE=.c75daacf-9ba6-4dbe-9d3d-b2a97f4a4c5d@github.com>
Message-ID: <SDMBp7KB2nf8grWiHPqzI4XlW45XHcrqSnDubgFrNEk=.8c96cb3d-5c37-4496-bda5-6fc48d2064c7@github.com>

On Tue, 1 Oct 2024 19:28:25 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor VMOptionWarning for better scoping of @require
>>  - Use simpler vm.opt.final approach
>
>> 'm not entirely satisfied by adding a @require that only applies to a subset of the checks in a test class. In VMOptionWarning, the experimental flag only applies to the first of the three scenarios it checks. But I suspect this is a general problem with @require, and I'd be happy to hear suggestions on how to avoid disabling too much.
> 
> You can add multiple run sections with different @requires lines. Then you can let each run line pass in different "tokens" to the main function and let it use that to dispatch to the various sub-tests. Maybe `test/hotspot/jtreg/gc//metaspace/TestSizeTransitions.java` could be a an OK inspiration for that.

@stefank Thanks for the suggestion on bringing better focus to the `@require`.  I refactored `VMOptionWarning` in a separate commit.

That said, I'm hesitant about that change because we'll need to backport this to 21, and that will be unclean due to [JDK-8236736](https://bugs.openjdk.org/browse/JDK-8236736) removing a [chunk of this file](https://github.com/openjdk/jdk/commit/bea493bcb86370dc3fb00d86c545f01fc614e000#diff-e3ce20490186bd16e73f192a52ee093fbaac7cd498d99f8fec44ab42571d3eaeR57-L64) in mainline.

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

PR Comment: https://git.openjdk.org/jdk/pull/21233#issuecomment-2389485121

From rcastanedalo at openjdk.org  Wed Oct  2 19:43:50 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 19:43:50 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
 <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
 <StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
Message-ID: <N4ocPHd0KbEF_VZngD6KkfUgDx6PH0I5IwT09MHfiyU=.955d49c1-f633-4734-8d6b-3a272076d8be@github.com>

On Wed, 2 Oct 2024 12:55:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> It could, but the effect would be the same (see [JDK-8058880](https://bugs.openjdk.org/browse/JDK-8058880)). I went with `TEMP` for the x64 and aarch64 platforms for consistency with the analogous ZGC ADL code, see e.g. https://github.com/openjdk/jdk/blob/855c8a7def21025bc2fc47594f7285a55924c213/src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad#L182-L204.
>
> I saw the riscv one in z_riscv.ad is: `effect(TEMP oldval_tmp, TEMP newval_tmp, TEMP tmp1, TEMP_DEF res);`, maybe it's good  to change riscv one?

I suggest to postpone these types of refactorings to follow-up enhancements, given that the pull request in its current form is stable, thoroughly tested, and approved by reviewers. I intend to integrate it within the following 24 hours, provided final test results look good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1785135652

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 ccheung at openjdk.org  Wed Oct  2 21:59:03 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 21:59:03 GMT
Subject: RFR: 8341053: Two CDS tests fail again with -UseCompressedOops and
 UseSerialGC/UseParallelGC
Message-ID: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>

A small fix to add a check in WB_CanWriteJavaHeapArchive to allow CDS tests to run with Parallel and Serial GC. However, if compressed oops is disabled (`-XX:-UseCompressedOops`) and specified with `-XX:+UseParallelGC `or `-XX:+UseSerialGC`, the test will be skipped.

Testing:
- [x] CDS tests with `-XX:+ParallelGC`
- [x] CDS tests with `-XX:+SerialGC`
- [x] test group `open/test/hotspot/jtreg/:hotspot_cds_only` with `-XX:-UseCompressedOops`
- [x] manually checks that the failed tests in the bug report were not run with `-XX:-UseCompressedOops -XX:+UseParallel`

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

Commit messages:
 - 8341053: Two CDS tests fail again with -UseCompressedOops and UseSerialGC/UseParallelGC

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

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

From kbarrett at openjdk.org  Wed Oct  2 22:01:40 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Oct 2024 22:01:40 GMT
Subject: RFR: 8341336: Fix -Wzero-as-null-pointer-constant warnings in
 PRODUCT-only code
In-Reply-To: <dXV140t0jc6m3TkIPSn4X1f7D5QF0gsYzBAcLr3XdMw=.50932ad3-e6f8-4dc6-bd03-680267e7bb35@github.com>
References: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
 <dXV140t0jc6m3TkIPSn4X1f7D5QF0gsYzBAcLr3XdMw=.50932ad3-e6f8-4dc6-bd03-680267e7bb35@github.com>
Message-ID: <jDg6H9_IfQyJkCYupnU-dG2HFIiMERlEiQU_xNL1DHs=.45c78e04-8943-4992-bfac-73204e8b56ac@github.com>

On Tue, 1 Oct 2024 16:53:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change that removes -Wzero-as-null-pointer-constant warnings
>> triggered by PRODUCT-only code. Most are uses of PRODUCT_RETURN0 in a pointer
>> context.  These are changed to use the (new) macro PRODUCT_RETURN_NULL.
>> 
>> Testing: mach5 tier1
>> Locally (linux-x64) ran tier1 testing on a release build.
>> (mach5 mostly does fastdebug testing)
>
> Marked as reviewed by stefank (Reviewer).

Thanks for reviews @stefank , @walulyai , and @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/21290#issuecomment-2389762364

From kbarrett at openjdk.org  Wed Oct  2 22:01:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 2 Oct 2024 22:01:41 GMT
Subject: Integrated: 8341336: Fix -Wzero-as-null-pointer-constant warnings in
 PRODUCT-only code
In-Reply-To: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
References: <hwh2S7hL7uFEvm7skPEFD04GrVluqVfc1QltHvb-55Y=.7422a115-df1a-43be-9a55-3d19ca595a2e@github.com>
Message-ID: <Bqq9b9ZtJJu30m65Hdauhrcua0_V4huhKUrbpkEZ5t8=.7a9b0dd9-d995-48a0-980e-fa00728abd0a@github.com>

On Tue, 1 Oct 2024 16:29:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant warnings
> triggered by PRODUCT-only code. Most are uses of PRODUCT_RETURN0 in a pointer
> context.  These are changed to use the (new) macro PRODUCT_RETURN_NULL.
> 
> Testing: mach5 tier1
> Locally (linux-x64) ran tier1 testing on a release build.
> (mach5 mostly does fastdebug testing)

This pull request has now been integrated.

Changeset: dc0ce1b2
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc0ce1b2f2ebf457de9524adcbce2b473749e815
Stats:     14 lines in 5 files changed: 4 ins; 4 del; 6 mod

8341336: Fix -Wzero-as-null-pointer-constant warnings in PRODUCT-only code

Reviewed-by: stefank, iwalulya, shade

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

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

From vlivanov at openjdk.org  Thu Oct  3 00:05:41 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 3 Oct 2024 00:05:41 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v8]
In-Reply-To: <BZLINoty4WOC87MLuUNM51x4z8F_f-OB_WweVFfQNK0=.d1da149e-88e8-495d-a119-57bc5aa41bb0@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <BZLINoty4WOC87MLuUNM51x4z8F_f-OB_WweVFfQNK0=.d1da149e-88e8-495d-a119-57bc5aa41bb0@github.com>
Message-ID: <Da_NkqkwIiRdggPz3uyxxkv_T54VwhSGS_WR6NGeqgs=.e7f05d31-2beb-4114-a697-b104f0f80fd7@github.com>

On Wed, 2 Oct 2024 01:06:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
>> 
>> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 15 additional commits since the last revision:
> 
>  - 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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @coleenp comments
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @vnkozlov comment - added NOT_CDS_RETURN
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - some clean up
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/d0267ed5...9b787423

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20959#pullrequestreview-2344385782

From iklam at openjdk.org  Thu Oct  3 00:40:40 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Oct 2024 00:40:40 GMT
Subject: RFR: 8341053: Two CDS tests fail again with -UseCompressedOops and
 UseSerialGC/UseParallelGC
In-Reply-To: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
References: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
Message-ID: <EQWOnInnhVXACGlnHgVmVvqfXrLZ6ln5Q57FmTefmqA=.90a50d52-f434-4b59-9d0c-92606994c14a@github.com>

On Wed, 2 Oct 2024 21:53:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A small fix to add a check in WB_CanWriteJavaHeapArchive to allow CDS tests to run with Parallel and Serial GC. However, if compressed oops is disabled (`-XX:-UseCompressedOops`) and specified with `-XX:+UseParallelGC `or `-XX:+UseSerialGC`, the test will be skipped.
> 
> Testing:
> - [x] CDS tests with `-XX:+ParallelGC`
> - [x] CDS tests with `-XX:+SerialGC`
> - [x] test group `open/test/hotspot/jtreg/:hotspot_cds_only` with `-XX:-UseCompressedOops`
> - [x] manually checks that the failed tests in the bug report were not run with `-XX:-UseCompressedOops -XX:+UseParallel`

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21314#pullrequestreview-2344446950

From dholmes at openjdk.org  Thu Oct  3 01:41:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Oct 2024 01:41:34 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class
In-Reply-To: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
Message-ID: <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>

On Wed, 2 Oct 2024 13:50:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
> 
> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
> 
> This PR is a suggestion for how to untangle this for the OSThread class.
> 
> Things in the code that changed with this patch that might be good to take an extra look at:
> 1) I dropped unnecessary includes
> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
> 5) I did some reordering of functions to unify the four platforms
> 6) Moved `_thread_id` to the platform files
> 7) I stopped exposing the `thread_id_t` typedef.
> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
> 
> Tested: tier1-3, (excluding AIX, which I can't build/test)

I personally don't have an issue with the current technique to generate a single platform-specific `OSThread` class, but this refactoring is also okay. There is some unfortunate duplication of the boiler-plate code for the class but not too bad.

I'm tempted to suggest pushing the `_startThread_lock` support into `OSThreadBase` under `#ifndef windows`, just to reduce some duplication. (I may also look at using that for Windows too in the near future, which would address it then.)

I could not see where `thread_type()` is actually used so possibly an additional cleanup opportunity there (not necessarily for this PR).

I don't have any concerns with any of the items that you flagged.

Thanks

src/hotspot/share/runtime/osThread.hpp line 29:

> 27: 
> 28: #include "utilities/macros.hpp"
> 29: #include OS_HEADER(osThread)

Suggestion:


// The actual class declaration is platform specific.
#include OS_HEADER(osThread)

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21306#pullrequestreview-2344481343
PR Review Comment: https://git.openjdk.org/jdk/pull/21306#discussion_r1785513385

From dholmes at openjdk.org  Thu Oct  3 01:45:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Oct 2024 01:45:43 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class
In-Reply-To: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
Message-ID: <LfJIY3ARZS2TQ3YhI-UeCHZ9hzcO5cMnB0EvI0dzm_o=.78d224e1-46f7-4d80-98c7-dc866724babc@github.com>

On Wed, 2 Oct 2024 13:50:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
> 
> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
> 
> This PR is a suggestion for how to untangle this for the OSThread class.
> 
> Things in the code that changed with this patch that might be good to take an extra look at:
> 1) I dropped unnecessary includes
> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
> 5) I did some reordering of functions to unify the four platforms
> 6) Moved `_thread_id` to the platform files
> 7) I stopped exposing the `thread_id_t` typedef.
> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
> 
> Tested: tier1-3, (excluding AIX, which I can't build/test)

Aside: forgot to mention, something that seemed odd to me is why we have the OSThread stuff in the os-cpu VMStructs files instead of the os one? I didn't spot anything CPU specific about that.

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2390332022

From jbhateja at openjdk.org  Thu Oct  3 05:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 05:09:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v15]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <TjvxhAjgb783SX3hLwya_KCLlKM6ci1jIZfw1ZGjCdI=.29de9360-4a15-4aaf-b3df-840e66da5385@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

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

 - Review comments resolution.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338023
 - Review comments resolutions.
 - Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.
 - Incorporating review and documentation suggestions.
 - Jcheck clearance
 - Review comments resolution.
 - Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
 - Documentation suggestions from Paul.
 - Review resolutions.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/bdfb41f9...6215ab91

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

Changes: https://git.openjdk.org/jdk/pull/20508/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=14
  Stats: 2804 lines in 89 files changed: 2785 ins; 18 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

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

From jbhateja at openjdk.org  Thu Oct  3 05:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 05:09:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v14]
In-Reply-To: <5wF2qLX9Z_tquvURMW0HVnrmMla1awxtz6C0UYI0lh4=.94df7340-1a27-4d93-80fa-d4c561641a97@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>
 <5wF2qLX9Z_tquvURMW0HVnrmMla1awxtz6C0UYI0lh4=.94df7340-1a27-4d93-80fa-d4c561641a97@github.com>
Message-ID: <uM4S2rRyAjE5sz0Syh5VfT3XNlpu_26aWzh1ljoLDQw=.82832862-0a98-43e4-8fd7-415d8ab88b44@github.com>

On Tue, 1 Oct 2024 18:10:10 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2797:
> 
>> 2795: 
>> 2796:   Node* operation = lowerSelectFromOp ?
>> 2797:                       LowerSelectFromTwoVectorOperation(gvn(), opd1, opd2, opd3, vt) :
> 
> Thanks for bringing the lowering right here. It opens up an optimization opportunity: currently for float/double we have two casts for index (e.g. from float -> int at line 2786 and from int -> byte at line 2661 as part of LowerSelectFromTwoVectorOperation. Could this be done by one cast?

This is not sub-optimal, Float to sub-word cast is two step process where we first convert float value to integer following by integer down casting to sub-word. So resulting JIT code will still be same if we directly emit F2X or the way its handled currently. All existing targets support F2X take this route. But its good to be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1785634731

From jbhateja at openjdk.org  Thu Oct  3 05:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 05:09:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
 <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
Message-ID: <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>

On Tue, 1 Oct 2024 18:03:06 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>>> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2); Or even simplified to: src1.rearrange(this.toShuffle(), src2);
>> 
>> Yes, this may save additional allocation penalty of result array allocation which may slightly improve fall back performance, but logical operation cannot be directly applied over floating point vectors. so, we will need an explicit conversion to integral vector, which is why I opted for current fallback implementation which is in line with rest of the code.
>
> I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.

You will also need additional handling for NPOT vector sizes which is handled by existing fallback implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1785634658

From stefank at openjdk.org  Thu Oct  3 05:36:35 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 05:36:35 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
Message-ID: <-Tb0SI9wHqs7PpAwinS8GIOJp146y38IEcFgnafe_jc=.63451cb1-ecce-4f46-b7fe-3c4b2dc46968@github.com>

On Wed, 2 Oct 2024 19:03:21 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

>> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
>> 
>> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.
>
> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor VMOptionWarning for better scoping of @require
>  - Use simpler vm.opt.final approach

Looks good to me.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21233#pullrequestreview-2344682575

From stefank at openjdk.org  Thu Oct  3 05:41:35 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 05:41:35 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <SDMBp7KB2nf8grWiHPqzI4XlW45XHcrqSnDubgFrNEk=.8c96cb3d-5c37-4496-bda5-6fc48d2064c7@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <CtE0-ra63mAv4UenDa8gUVkXXELqj8MoCNedaho0iTE=.c75daacf-9ba6-4dbe-9d3d-b2a97f4a4c5d@github.com>
 <SDMBp7KB2nf8grWiHPqzI4XlW45XHcrqSnDubgFrNEk=.8c96cb3d-5c37-4496-bda5-6fc48d2064c7@github.com>
Message-ID: <qO5IQiM5eVJsU1hqWP8B7Acot3LTYbBy8pbrmGQMIZY=.c3b57bba-5293-468c-869f-b3065924e64b@github.com>

On Wed, 2 Oct 2024 19:07:06 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

> That said, I'm hesitant about that change because we'll need to backport this to 21, and that will be unclean due to ...

That just means that you need to adjust the patch slightly and ask for a re-review. To me, that sounds like something that could be easily and quickly reviewed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21233#issuecomment-2390567416

From aboldtch at openjdk.org  Thu Oct  3 05:54:37 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 3 Oct 2024 05:54:37 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class
In-Reply-To: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
Message-ID: <l_ZCi8V7oTnLUsZSZbPpWliA6lI-iJYIeAgCEuy4cas=.bc775cb4-46fd-43fc-9503-5fdc2dc4f419@github.com>

On Wed, 2 Oct 2024 13:50:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
> 
> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
> 
> This PR is a suggestion for how to untangle this for the OSThread class.
> 
> Things in the code that changed with this patch that might be good to take an extra look at:
> 1) I dropped unnecessary includes
> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
> 5) I did some reordering of functions to unify the four platforms
> 6) Moved `_thread_id` to the platform files
> 7) I stopped exposing the `thread_id_t` typedef.
> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
> 
> Tested: tier1-3, (excluding AIX, which I can't build/test)

It is interesting to me that we are using `AllocFailStrategy::RETURN_NULL` when allocating the `OSThread` but then do a `AllocFailStrategy::EXIT_OOM` allocation of a Monitor in the middle of constructing the `OSThread`. 

Even though I am not sure about the usefulness of `AllocFailStrategy::RETURN_NULL`, and whether if it is ever recoverable to fail (smallish) native allocations in Hotspot. Seems like we will crash very soon in any case.

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2390579652

From mli at openjdk.org  Thu Oct  3 06:50:48 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 3 Oct 2024 06:50:48 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <N4ocPHd0KbEF_VZngD6KkfUgDx6PH0I5IwT09MHfiyU=.955d49c1-f633-4734-8d6b-3a272076d8be@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vb76mbxerbCHN5fmVs9ERapN0W1XeTdBzu8ncwCINLY=.89a1a645-8a60-44bd-aed3-3a18c6c378ab@github.com>
 <7L7jYDlFa0WnVvgiyNHI9KZrcffYwNnBB899AuMS56Q=.40b031e7-07b8-4a15-b319-c53b38a17a49@github.com>
 <StzxvdFi4HQirGwYzWf_0rUr0a75ANIZv_oUiNXs9-s=.1c4cc9c3-a02b-4328-b877-868bbd92b140@github.com>
 <N4ocPHd0KbEF_VZngD6KkfUgDx6PH0I5IwT09MHfiyU=.955d49c1-f633-4734-8d6b-3a272076d8be@github.com>
Message-ID: <4S2raWNwXSaEN1p2bAXEUKlHdqSY9AqrR7cBZDhs2QI=.e6ecddb3-be2b-4bda-88ac-8cd9fcb1301b@github.com>

On Wed, 2 Oct 2024 19:41:26 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> I saw the riscv one in z_riscv.ad is: `effect(TEMP oldval_tmp, TEMP newval_tmp, TEMP tmp1, TEMP_DEF res);`, maybe it's good  to change riscv one?
>
> I suggest to postpone these types of refactorings to follow-up enhancements, given that the pull request in its current form is stable, thoroughly tested, and approved by reviewers. I intend to integrate it within the following 24 hours, provided final test results look good.

Sounds good too. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1785711504

From rcastanedalo at openjdk.org  Thu Oct  3 08:35:54 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 3 Oct 2024 08:35:54 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
Message-ID: <BA5FZjbH5fmoijj5zqLr63CB5OwXGTPXQqMZ6tLJDQI=.1346fda3-a2a0-4b91-9296-66888ae86303@github.com>

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

>> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>> 
>> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>> 
>> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
>> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>> 
>> ## Summary of the Changes
>> 
>> ### Platform-Independent Changes (`src/hotspot/share`)
>> 
>> These consist mainly of:
>> 
>> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
>> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
>> - temporary support for porting the JEP to the remaining platforms.
>> 
>> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>> 
>> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>> 
>> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>> 
>> #### ADL Changes
>> 
>> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>> 
>> #### `G1BarrierSetAssembler` Changes
>> 
>> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live ...
>
> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>  - riscv port refactor
>  - Remove temporary support code
>  - Merge jdk-24+17
>  - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>  - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>  - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>  - Merge jdk-24+16
>  - Ensure that detected encode-and-store patterns are matched
>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>  - ... and 43 more: https://git.openjdk.org/jdk/compare/0cf6df31...14483b83

Thanks to everyone who contributed to this JEP, integrating now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19746#issuecomment-2390833194

From dholmes at openjdk.org  Thu Oct  3 08:38:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Oct 2024 08:38:35 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class
In-Reply-To: <l_ZCi8V7oTnLUsZSZbPpWliA6lI-iJYIeAgCEuy4cas=.bc775cb4-46fd-43fc-9503-5fdc2dc4f419@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <l_ZCi8V7oTnLUsZSZbPpWliA6lI-iJYIeAgCEuy4cas=.bc775cb4-46fd-43fc-9503-5fdc2dc4f419@github.com>
Message-ID: <3WUG9ODUcGH1Ryi6uH9L8MDdTNf2sryIcc08uuSdHAM=.65897417-f18e-4d6a-9b85-03e68982812c@github.com>

On Thu, 3 Oct 2024 05:51:51 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Even though I am not sure about the usefulness of `AllocFailStrategy::RETURN_NULL`, and whether if it is ever recoverable to fail (smallish) native allocations in Hotspot. Seems like we will crash very soon in any case.

True. The problem with allocations within the constructor is that we have no way to convey to the caller that we had a failure. So if allocation of OSThread fails we act like it is non-fatal because we can just throw  a Java exception from `Thread.start`. But if the constructor fails to construct things properly we have no mechanism to communicate that so we abort on internal allocation failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2390837274

From rcastanedalo at openjdk.org  Thu Oct  3 08:39:57 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 3 Oct 2024 08:39:57 GMT
Subject: Integrated: 8334060: Implementation of Late Barrier Expansion for G1
In-Reply-To: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
Message-ID: <mXBgyAGkMlBgbgtmzRdxQLV9F54iVY6Fx5T7yPZvSzw=.2649ab50-a845-455c-be82-922e721fddfc@github.com>

On Mon, 17 Jun 2024 09:49:25 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
> 
> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
> 
> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
> 
> ## Summary of the Changes
> 
> ### Platform-Independent Changes (`src/hotspot/share`)
> 
> These consist mainly of:
> 
> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
> - temporary support for porting the JEP to the remaining platforms.
> 
> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
> 
> ### Platform-Dependent Changes (`src/hotspot/cpu`)
> 
> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
> 
> #### ADL Changes
> 
> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
> 
> #### `G1BarrierSetAssembler` Changes
> 
> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live registers, provided by the `SaveLiveRegisters` class. This c...

This pull request has now been integrated.

Changeset: 0b467e90
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b467e902d591ae9feeec1669918d1588987cd1c
Stats:     7372 lines in 58 files changed: 5924 ins; 985 del; 463 mod

8334060: Implementation of Late Barrier Expansion for G1

Co-authored-by: Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Siyao Liu <siyao.l.liu at oracle.com>
Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Co-authored-by: Feilong Jiang <fjiang at openjdk.org>
Co-authored-by: Sergey Nazarkin <snazarki at openjdk.org>
Reviewed-by: kvn, tschatzl, fyang, ayang, kbarrett

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

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

From aboldtch at openjdk.org  Thu Oct  3 09:12:35 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 3 Oct 2024 09:12:35 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class
In-Reply-To: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
Message-ID: <W4gZCtUrqiyDHaUQFPqtH9lAUCdLD0BtQ2-zM58x5Z8=.40059138-914c-40c8-addd-07aa92a13e74@github.com>

On Wed, 2 Oct 2024 13:50:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
> 
> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
> 
> This PR is a suggestion for how to untangle this for the OSThread class.
> 
> Things in the code that changed with this patch that might be good to take an extra look at:
> 1) I dropped unnecessary includes
> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
> 5) I did some reordering of functions to unify the four platforms
> 6) Moved `_thread_id` to the platform files
> 7) I stopped exposing the `thread_id_t` typedef.
> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
> 
> Tested: tier1-3, (excluding AIX, which I can't build/test)

> > Even though I am not sure about the usefulness of `AllocFailStrategy::RETURN_NULL`, and whether if it is ever recoverable to fail (smallish) native allocations in Hotspot. Seems like we will crash very soon in any case.
> 
> The problem with allocations within the constructor is that we have no way to convey to the caller that we had a failure.

Setting a bool field during construction is something we do in a lot of places to signal if the construction was successful.

```c++
  OSThread* osthread = new (std::nothrow) OSThread();
  if (osthread == nullptr || osthread->has_constructor_failed()) {
    delete osthread;
    return false;
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2390909425

From adinn at openjdk.org  Thu Oct  3 10:15:37 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Oct 2024 10:15:37 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v8]
In-Reply-To: <BZLINoty4WOC87MLuUNM51x4z8F_f-OB_WweVFfQNK0=.d1da149e-88e8-495d-a119-57bc5aa41bb0@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <BZLINoty4WOC87MLuUNM51x4z8F_f-OB_WweVFfQNK0=.d1da149e-88e8-495d-a119-57bc5aa41bb0@github.com>
Message-ID: <GwZ7vga44YDpr4c1MTUXsU1HTNMiI5oKA-FNui3E418=.a2925074-d39b-4f8b-a8bf-2c3ca0e39767@github.com>

On Wed, 2 Oct 2024 01:06:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
>> 
>> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 15 additional commits since the last revision:
> 
>  - 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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @coleenp comments
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @vnkozlov comment - added NOT_CDS_RETURN
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - some clean up
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1d1c0d8e...9b787423

This all looks good.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20959#pullrequestreview-2345196930

From stefank at openjdk.org  Thu Oct  3 11:34:35 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 11:34:35 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>
Message-ID: <f2rsb3zho2xszCbg1SHg11MKMXtPXSEgkoK8l4lNBY4=.5ee2d8c2-f566-4baa-a1df-cf1852be8a22@github.com>

On Thu, 3 Oct 2024 01:30:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Move NONCOPYABLE
>>  - Move VMStructs fields out of the CPU files
>>  - Add comment to the include of the platform specific class
>
> src/hotspot/share/runtime/osThread.hpp line 29:
> 
>> 27: 
>> 28: #include "utilities/macros.hpp"
>> 29: #include OS_HEADER(osThread)
> 
> Suggestion:
> 
> 
> // The actual class declaration is platform specific.
> #include OS_HEADER(osThread)

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21306#discussion_r1786066476

From stefank at openjdk.org  Thu Oct  3 11:29:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 11:29:55 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
Message-ID: <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>

> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
> 
> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
> 
> This PR is a suggestion for how to untangle this for the OSThread class.
> 
> Things in the code that changed with this patch that might be good to take an extra look at:
> 1) I dropped unnecessary includes
> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
> 5) I did some reordering of functions to unify the four platforms
> 6) Moved `_thread_id` to the platform files
> 7) I stopped exposing the `thread_id_t` typedef.
> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
> 
> Tested: tier1-3, (excluding AIX, which I can't build/test)

Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:

 - Move NONCOPYABLE
 - Move VMStructs fields out of the CPU files
 - Add comment to the include of the platform specific class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21306/files
  - new: https://git.openjdk.org/jdk/pull/21306/files/27a9567c..04260b95

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

  Stats: 225 lines in 21 files changed: 48 ins; 143 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/21306.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21306/head:pull/21306

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

From coleenp at openjdk.org  Thu Oct  3 11:45:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Oct 2024 11:45:39 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
Message-ID: <_5vE6BU1LTgyAIuSUfanQe_e4Hb-cKhsBmfRVoG0Dq0=.e3925bc6-5009-41d0-ae0c-42a45f896f97@github.com>

On Thu, 3 Oct 2024 11:29:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
>> 
>> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
>> 
>> This PR is a suggestion for how to untangle this for the OSThread class.
>> 
>> Things in the code that changed with this patch that might be good to take an extra look at:
>> 1) I dropped unnecessary includes
>> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
>> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
>> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
>> 5) I did some reordering of functions to unify the four platforms
>> 6) Moved `_thread_id` to the platform files
>> 7) I stopped exposing the `thread_id_t` typedef.
>> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
>> 
>> Tested: tier1-3, (excluding AIX, which I can't build/test)
>
> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Move NONCOPYABLE
>  - Move VMStructs fields out of the CPU files
>  - Add comment to the include of the platform specific class

Nice cleanup but one question about SA.

src/hotspot/os_cpu/bsd_aarch64/vmStructs_bsd_aarch64.hpp line 40:

> 38:   /******************************/                                                                                                   \
> 39:   nonstatic_field(OSThread,                      _thread_id,                                      OSThread::thread_id_t)             \
> 40:   nonstatic_field(OSThread,                      _unique_thread_id,                               uint64_t)

Does the SA actually use these?  I don't see any SA changes in this patch.  If it doesn't, we should remove it until there is someone that might add support for this.  We're not enhancing the SA at this point.

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

PR Review: https://git.openjdk.org/jdk/pull/21306#pullrequestreview-2345378519
PR Review Comment: https://git.openjdk.org/jdk/pull/21306#discussion_r1786079576

From eosterlund at openjdk.org  Thu Oct  3 12:09:41 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 3 Oct 2024 12:09:41 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <ixtfOfUmd7Qvf1icAGdzNWdP4rA_CAeIOnHT5X4OWIU=.7bdfd24b-f7aa-462b-ae65-6fda54dec9dd@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>
 <rcGTOJcKY3ZAscPyEi3G5zKbPXRdHnJqibX5fiP4Elw=.8347be15-1ae3-4125-9f72-e230d2018a1a@github.com>
 <Lm3cvu-YkJizbmEGvRISkK4y57V46IKdGBY7INNmjD4=.70226a4a-322b-4e04-acfa-b64a16883031@github.com>
 <ixtfOfUmd7Qvf1icAGdzNWdP4rA_CAeIOnHT5X4OWIU=.7bdfd24b-f7aa-462b-ae65-6fda54dec9dd@github.com>
Message-ID: <WzpvuDoA-1FylguokFAivFxQG0E2PQvkWwkwx875piQ=.d9c0d4a7-edff-40af-9c98-c6d4b75b8a81@github.com>

On Mon, 30 Sep 2024 16:32:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I think we need a new ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop* p) and to make that the selected slow path function when ZBarrierNoKeepalive is set on a StorePNode. Its implementation would call ZBarrier::no_keep_alive_store_barrier_on_heap_oop_field. This should do the trick.
> 
> Thanks! See new commits: is that the shape you were thinking of?

Yeah that's perfect. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2391252177

From eosterlund at openjdk.org  Thu Oct  3 12:16:38 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 3 Oct 2024 12:16:38 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
Message-ID: <GFRSx-YcBOAyZfgBied8BTn3uz2IbEM4VZDh3quDmXE=.c79bb9eb-f314-42bf-aa01-2bd0792fba26@github.com>

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

Changes requested by eosterlund (Reviewer).

src/hotspot/share/opto/library_call.cpp line 7002:

> 7000:   // Add memory barrier to prevent commoning the accesses in this code,
> 7001:   // since GC can change the value of referent at any time.
> 7002:   insert_mem_bar(Op_MemBarCPUOrder);

I think this CPU memory barrier and comment above are confusing and obviously just taken from the referent loading intrinsics. The commoning it is talking about is to short circuit a second load with the result of a first load of the referent field, since the compiler "knows" the first load would give the "same" answer unless "something happened" (GC clearing it).
In this case the mutator just cleared it, so what the compiler thinks is that null is stored in that field. And that's completely accurate, and the GC is not going to transition the field from null to some random other object.
Let's remove this CPU memory barrier and the misleading comments.

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

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2345438249
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786116003

From stefank at openjdk.org  Thu Oct  3 12:53:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 12:53:38 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <_5vE6BU1LTgyAIuSUfanQe_e4Hb-cKhsBmfRVoG0Dq0=.e3925bc6-5009-41d0-ae0c-42a45f896f97@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
 <_5vE6BU1LTgyAIuSUfanQe_e4Hb-cKhsBmfRVoG0Dq0=.e3925bc6-5009-41d0-ae0c-42a45f896f97@github.com>
Message-ID: <zWvm1IuUstcGiPZykCuz-uOk1Qi3SIiIrpSmk1sygQw=.a2281c42-0ce1-4652-9d8f-9f3aa3eaf8a3@github.com>

On Thu, 3 Oct 2024 11:42:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Move NONCOPYABLE
>>  - Move VMStructs fields out of the CPU files
>>  - Add comment to the include of the platform specific class
>
> src/hotspot/os_cpu/bsd_aarch64/vmStructs_bsd_aarch64.hpp line 40:
> 
>> 38:   /******************************/                                                                                                   \
>> 39:   nonstatic_field(OSThread,                      _thread_id,                                      OSThread::thread_id_t)             \
>> 40:   nonstatic_field(OSThread,                      _unique_thread_id,                               uint64_t)
> 
> Does the SA actually use these?  I don't see any SA changes in this patch.  If it doesn't, we should remove it until there is someone that might add support for this.  We're not enhancing the SA at this point.

I think the SA is using these. There are references to them in the various SA files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21306#discussion_r1786170685

From stefank at openjdk.org  Thu Oct  3 12:58:37 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 12:58:37 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>
Message-ID: <4sy1WlbzzIubllOdQCX-bOWEfiJuDOI3lMrOfYtRXLA=.5bb0ed39-d163-48ac-9b8a-fdf7b6baf004@github.com>

On Thu, 3 Oct 2024 01:39:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I personally don't have an issue with the current technique to generate a single platform-specific `OSThread` class, but this refactoring is also okay.

Thanks for not blocking this suggestion.

> There is some unfortunate duplication of the boiler-plate code for the class but not too bad.

I pushed a change that moved the NONCOPYABLE macro. I did a little experiment with moving even more code to the OSThreadBase, but I'm not sure if this is wanted or not. I've put that change here in-case someone wants to take a look:
https://github.com/openjdk/jdk/compare/pr/21306...stefank:jdk:osThread_follow_up

> 
> I'm tempted to suggest pushing the `_startThread_lock` support into `OSThreadBase` under `#ifndef windows`, just to reduce some duplication. (I may also look at using that for Windows too in the near future, which would address it then.)

I'll leave this for next time someone wants to do a little bit of clean-up in this area.

One interesting thing that we found while looking at this is that the AIX port has the `_startThread_lock`, but it doesn't use it to coordinate the starting of the created thread. It's unclear to me if that's a bug in that port.

> 
> I could not see where `thread_type()` is actually used so possibly an additional cleanup opportunity there (not necessarily for this PR).

Maybe one reason to keep it is as an aid when debugging with a debugger? OTOH, while playing around with the patch linked above I found that the field is not available on Windows, and it's also left uninitialized when we call `create_attached_thread`.

> 
> I don't have any concerns with any of the items that you flagged.
> 
> Thanks

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2391353698

From coleenp at openjdk.org  Thu Oct  3 13:57:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Oct 2024 13:57:38 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <zWvm1IuUstcGiPZykCuz-uOk1Qi3SIiIrpSmk1sygQw=.a2281c42-0ce1-4652-9d8f-9f3aa3eaf8a3@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
 <_5vE6BU1LTgyAIuSUfanQe_e4Hb-cKhsBmfRVoG0Dq0=.e3925bc6-5009-41d0-ae0c-42a45f896f97@github.com>
 <zWvm1IuUstcGiPZykCuz-uOk1Qi3SIiIrpSmk1sygQw=.a2281c42-0ce1-4652-9d8f-9f3aa3eaf8a3@github.com>
Message-ID: <Hqk6XHXT2uA99YyHUm38qH_Slg6fTUDdYVDOYkpLQo0=.ea56483e-c9fe-4d57-9484-870f52731003@github.com>

On Thu, 3 Oct 2024 12:50:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/vmStructs_bsd_aarch64.hpp line 40:
>> 
>>> 38:   /******************************/                                                                                                   \
>>> 39:   nonstatic_field(OSThread,                      _thread_id,                                      OSThread::thread_id_t)             \
>>> 40:   nonstatic_field(OSThread,                      _unique_thread_id,                               uint64_t)
>> 
>> Does the SA actually use these?  I don't see any SA changes in this patch.  If it doesn't, we should remove it until there is someone that might add support for this.  We're not enhancing the SA at this point.
>
> I think the SA is using these. There are references to them in the various SA files.

Ok.  I see now why you don't also have to change SA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21306#discussion_r1786270497

From coleenp at openjdk.org  Thu Oct  3 13:57:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Oct 2024 13:57:38 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
Message-ID: <_9RM23JZ7IhmylZ95l7t_JVUMOG5hN53AeblNXvsnoQ=.67f41994-a421-4ab1-acd9-9f0f627874c1@github.com>

On Thu, 3 Oct 2024 11:29:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
>> 
>> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
>> 
>> This PR is a suggestion for how to untangle this for the OSThread class.
>> 
>> Things in the code that changed with this patch that might be good to take an extra look at:
>> 1) I dropped unnecessary includes
>> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
>> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
>> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
>> 5) I did some reordering of functions to unify the four platforms
>> 6) Moved `_thread_id` to the platform files
>> 7) I stopped exposing the `thread_id_t` typedef.
>> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
>> 
>> Tested: tier1-3, (excluding AIX, which I can't build/test)
>
> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Move NONCOPYABLE
>  - Move VMStructs fields out of the CPU files
>  - Add comment to the include of the platform specific class

Looks good. Thanks for removing this inline include.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21306#pullrequestreview-2345697108

From stefank at openjdk.org  Thu Oct  3 14:05:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Oct 2024 14:05:38 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <cc3GukWQxZYflozseloNBibhobc2vRmO_i8eH9qRzwE=.91e5d480-afab-4916-bb5e-a2e2a0e80f11@github.com>
Message-ID: <5LB7JNnF2V9w4l0z7Zj1WPAocWL4JToA61f9keaNf0A=.e6d1c0c0-f11a-40cb-a406-2dc96eb25793@github.com>

On Thu, 3 Oct 2024 11:29:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
>> 
>> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
>> 
>> This PR is a suggestion for how to untangle this for the OSThread class.
>> 
>> Things in the code that changed with this patch that might be good to take an extra look at:
>> 1) I dropped unnecessary includes
>> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
>> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
>> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
>> 5) I did some reordering of functions to unify the four platforms
>> 6) Moved `_thread_id` to the platform files
>> 7) I stopped exposing the `thread_id_t` typedef.
>> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
>> 
>> Tested: tier1-3, (excluding AIX, which I can't build/test)
>
> Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Move NONCOPYABLE
>  - Move VMStructs fields out of the CPU files
>  - Add comment to the include of the platform specific class

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2391508402

From shade at openjdk.org  Thu Oct  3 16:57:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 16:57:39 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <GFRSx-YcBOAyZfgBied8BTn3uz2IbEM4VZDh3quDmXE=.c79bb9eb-f314-42bf-aa01-2bd0792fba26@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
 <GFRSx-YcBOAyZfgBied8BTn3uz2IbEM4VZDh3quDmXE=.c79bb9eb-f314-42bf-aa01-2bd0792fba26@github.com>
Message-ID: <zxDyh8g2y3ovrRYwS68Z8v1VmSlfgTe4axCNpD426g4=.b5ba863d-66fc-4723-8c2d-21799e710168@github.com>

On Thu, 3 Oct 2024 12:14:08 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also dispatch to slow-path on other arches
>
> src/hotspot/share/opto/library_call.cpp line 7002:
> 
>> 7000:   // Add memory barrier to prevent commoning the accesses in this code,
>> 7001:   // since GC can change the value of referent at any time.
>> 7002:   insert_mem_bar(Op_MemBarCPUOrder);
> 
> I think this CPU memory barrier and comment above are confusing and obviously just taken from the referent loading intrinsics. The commoning it is talking about is to short circuit a second load with the result of a first load of the referent field, since the compiler "knows" the first load would give the "same" answer unless "something happened" (GC clearing it).
> In this case the mutator just cleared it, so what the compiler thinks is that null is stored in that field. And that's completely accurate, and the GC is not going to transition the field from null to some random other object.
> Let's remove this CPU memory barrier and the misleading comments.

Right. I removed it in my local patch queue. Now I have to reconcile this PR with late barrier expansion in G1, I'll push the update once that is done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786549120

From shade at openjdk.org  Thu Oct  3 16:57:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 16:57:40 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
 <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>
Message-ID: <MsPOYHq_-sRol1vs_8uBPp2b2DuCSHQRLzTPWH8V1mg=.bfbce9b8-c16c-46bc-90af-d9185255409e@github.com>

On Wed, 2 Oct 2024 10:47:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also dispatch to slow-path on other arches
>
> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:
> 
>> 1: //
>> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 
> Drive-by comment: The `// *` format looks weird.

Actually, this constellation of single-line comments should be replaced with a multi-line comment block. The fix is now in my (unpublished) patch queue, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786548233

From shade at openjdk.org  Thu Oct  3 17:15:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 17:15:03 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
Message-ID: <vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>

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

>> This changeset implements JEP 475 (Late Barrier Expansion for G1), including support for the x64 and aarch64 platforms. See the [JEP description](https://openjdk.org/jeps/475) for further detail.
>> 
>> We aim to integrate this work in JDK 24. The purpose of this pull request is double-fold:
>> 
>> - to allow maintainers of the arm (32-bit), ppc, riscv, s390, and x86 (32-bit) ports to contribute a port of these platforms in time for JDK 24; and
>> - to allow reviewers to review the platform-independent, x64 and aarch64, and test changes in parallel with the porting work.
>> 
>> ## Summary of the Changes
>> 
>> ### Platform-Independent Changes (`src/hotspot/share`)
>> 
>> These consist mainly of:
>> 
>> - a complete rewrite of `G1BarrierSetC2`, to instruct C2 to expand G1 barriers late instead of early;
>> - a few minor changes to C2 itself, to support removal of redundant decompression operations and to address an OopMap construction issue triggered by this JEP's increased usage of ADL `TEMP` operands; and
>> - temporary support for porting the JEP to the remaining platforms.
>> 
>> The temporary support code (guarded by the pre-processor flag `G1_LATE_BARRIER_MIGRATION_SUPPORT`) will **not** be part of the final pull request, and hence does not need to be reviewed.
>> 
>> ### Platform-Dependent Changes (`src/hotspot/cpu`)
>> 
>> These include changes to the ADL instruction definitions and the `G1BarrierSetAssembler` class of the x64 and aarch64 platforms.
>> 
>> #### ADL Changes
>> 
>> The changeset uses ADL predicates to force C2 to implement memory accesses tagged with barrier information using G1-specific, barrier-aware instruction versions (e.g. `g1StoreP` instead of the GC-agnostic `storeP`). These new instruction versions generate machine code accordingly to the corresponding tagged barrier information, relying on the G1 barrier implementations provided by the `G1BarrierSetAssembler` class. In the aarch64 platform, the bulk of the ADL code is generated from a higher-level version using m4, to reduce redundancy.
>> 
>> #### `G1BarrierSetAssembler` Changes
>> 
>> Both platforms basically reuse the barrier implementation for the bytecode interpreter, with the different barrier tests and operations refactored into dedicated functions. Besides this, `G1BarrierSetAssembler` is extended with assembly-stub routines that implement the out-of-line, slow path of the barriers. These routines include calls from the barrier into the JVM, which require support for saving and restoring live ...
>
> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>  - riscv port refactor
>  - Remove temporary support code
>  - Merge jdk-24+17
>  - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>  - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>  - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>  - Merge jdk-24+16
>  - Ensure that detected encode-and-store patterns are matched
>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>  - ... and 43 more: https://git.openjdk.org/jdk/compare/9bb3ef4e...14483b83

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 335:

> 333:       assert(!use_ReduceInitialCardMarks(),
> 334:              "post-barriers are only needed for tightly-coupled initialization stores when ReduceInitialCardMarks is disabled");
> 335:       access.set_barrier_data(access.barrier_data() ^ G1C2BarrierPre);

I have been looking at this code after integration, and I wonder if `^` is really correct here? Was the intend to remove `G1C2BarrierPre` from the barrier data? What happens if `get_store_barrier` does not actually set it? Do we flip the bit back?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1786573527

From sviswanathan at openjdk.org  Thu Oct  3 17:30:45 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 17:30:45 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v19]
In-Reply-To: <Rgx6r8xrA1DNQm-uuRrGmNnpWlvXWxMsBrvaYsWjQjE=.4bd7bd2b-aa3f-49e0-8d7b-0fd0b17577aa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <Rgx6r8xrA1DNQm-uuRrGmNnpWlvXWxMsBrvaYsWjQjE=.4bd7bd2b-aa3f-49e0-8d7b-0fd0b17577aa@github.com>
Message-ID: <Q8p2kG7qU5nko7ELoX6Xrxlsg7JXYdroCdpCzlEkf-E=.9af66ab2-fd9f-4e9f-888f-3dd0774b89a8@github.com>

On Tue, 1 Oct 2024 05:09:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja 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:
> 
>   Merge stashing and re-commit

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 140:

> 138:      * @param b the second operand.
> 139:      * @return the saturating addition of the operands.
> 140:      * @see VectorOperators#SADD

This should be SUADD.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 167:

> 165:      * @param b the second operand.
> 166:      * @return the saturating difference of the operands.
> 167:      * @see VectorOperators#SSUB

This should be SUSUB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786595393
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786595850

From matsaave at openjdk.org  Thu Oct  3 17:48:39 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Oct 2024 17:48:39 GMT
Subject: RFR: 8341053: Two CDS tests fail again with -UseCompressedOops and
 UseSerialGC/UseParallelGC
In-Reply-To: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
References: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
Message-ID: <VRNdeCyHWZ_tT1qFgNo05PBOc8uBwRS_mvEQ-a7jj1Q=.4c1e1879-b5ba-4b76-a950-8ded4737a792@github.com>

On Wed, 2 Oct 2024 21:53:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A small fix to add a check in WB_CanWriteJavaHeapArchive to allow CDS tests to run with Parallel and Serial GC. However, if compressed oops is disabled (`-XX:-UseCompressedOops`) and specified with `-XX:+UseParallelGC `or `-XX:+UseSerialGC`, the test will be skipped.
> 
> Testing:
> - [x] CDS tests with `-XX:+ParallelGC`
> - [x] CDS tests with `-XX:+SerialGC`
> - [x] test group `open/test/hotspot/jtreg/:hotspot_cds_only` with `-XX:-UseCompressedOops`
> - [x] manually checks that the failed tests in the bug report were not run with `-XX:-UseCompressedOops -XX:+UseParallel`

LGTM!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21314#pullrequestreview-2346325510

From sviswanathan at openjdk.org  Thu Oct  3 17:53:42 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 17:53:42 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
 <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
 <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
Message-ID: <n965SL7FQ_uU5-y-LPIStvMgWKeScMXeBkYbcKdri4Y=.96172206-5aec-4626-af89-372b6cf4b133@github.com>

On Thu, 3 Oct 2024 05:04:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.
>
> You will also need additional handling for NPOT vector sizes which is handled by existing fallback implementation.

The intrinsic is limited to power of two. We can safely do src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2) for integral types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1786637638

From sviswanathan at openjdk.org  Thu Oct  3 18:18:44 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 18:18:44 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v15]
In-Reply-To: <TjvxhAjgb783SX3hLwya_KCLlKM6ci1jIZfw1ZGjCdI=.29de9360-4a15-4aaf-b3df-840e66da5385@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <TjvxhAjgb783SX3hLwya_KCLlKM6ci1jIZfw1ZGjCdI=.29de9360-4a15-4aaf-b3df-840e66da5385@github.com>
Message-ID: <UY7D7-cVhI8qBm4VzmK7RDT5R6iNo1sytclt0oa8bZk=.a832b4cb-1147-4dfe-b572-8342a761a0e0@github.com>

On Thu, 3 Oct 2024 05:09:22 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Review comments resolution.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338023
>  - Review comments resolutions.
>  - Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.
>  - Incorporating review and documentation suggestions.
>  - Jcheck clearance
>  - Review comments resolution.
>  - Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
>  - Documentation suggestions from Paul.
>  - Review resolutions.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/bdfb41f9...6215ab91

Thanks for making the changes. It looks to me that  the following checks at lines 2963-2071 in file vectorIntrinsics.cpp is now only needed when lowerSelectFromOp is false. Could you please verify and update accordingly?

 if (is_floating_point_type(elem_bt)) {
    if (!arch_supports_vector(Op_AndV, num_elem, index_elem_bt, VecMaskNotUsed)              ||
        !arch_supports_vector(cast_vopc, num_elem, index_elem_bt, VecMaskNotUsed)            ||
        !arch_supports_vector(Op_Replicate, num_elem, index_elem_bt, VecMaskNotUsed)) {
      log_if_needed("  ** index wrapping not supported: vlen=%d etype=%s" ,
                     num_elem, type2name(elem_bt));
      return false; // not supported
    }
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2392036048

From sviswanathan at openjdk.org  Thu Oct  3 18:41:40 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 18:41:40 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
 <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
 <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
Message-ID: <95BWoQiYfM-c7esOvzluxwrXbh_sQD9MAUm9-5JhULc=.c3f1f31e-5b13-4698-9481-e02a763b1ce6@github.com>

On Thu, 3 Oct 2024 05:04:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.
>
> You will also need additional handling for NPOT vector sizes which is handled by existing fallback implementation.

Agree, so we can't assume power of two in fallback.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1786691519

From shade at openjdk.org  Thu Oct  3 18:48:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 18:48:55 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v7]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <bj0w7Ne_uiYmwLdiUcItNyFa2GA4hqlMpUZxNZplu74=.8f383fb0-a1dd-4fe4-aed0-b31260b19490@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

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

 - Reconcile with late barrier expansion in G1
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Review comments
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Also dispatch to slow-path on other arches
 - Fix other arches
 - Tighten up comments in Reference javadoc
 - Attempt at implementing ZGC AArch64 parts
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Amend the test case for guaranteing it works under different compilation regimes
 - ... and 5 more: https://git.openjdk.org/jdk/compare/ebb4759c...c3338302

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

Changes: https://git.openjdk.org/jdk/pull/20139/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=06
  Stats: 372 lines in 25 files changed: 351 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

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

From jbhateja at openjdk.org  Thu Oct  3 19:05:14 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:05:14 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v16]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

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

  Sharpening intrinsic exit check.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/6215ab91..1cca8e24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=14-15

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

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

From jbhateja at openjdk.org  Thu Oct  3 19:13:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:13:22 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v20]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Typographic error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/952920ae..f5b5e6f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=18-19

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

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

From psandoz at openjdk.org  Thu Oct  3 19:21:43 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 3 Oct 2024 19:21:43 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v20]
In-Reply-To: <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>
Message-ID: <RS_W7uDGWq3EkfjkFUERraJljQKCXQnYiy5Ap-qhtlY=.e5f53613-0f15-483e-bc05-2e1c8875217f@github.com>

On Thu, 3 Oct 2024 19:13:22 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typographic error

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 46:

> 44:      * @return the smaller of {@code a} and {@code b}.
> 45:      * @see VectorOperators#UMIN
> 46:      * @since 24

Remove `@since 24` in the documentation of each method and place in the documentation on the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786732581

From jbhateja at openjdk.org  Thu Oct  3 19:55:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:55:03 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v21]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <59ZQPsSgxrGE2E4vGKs0PvO7KJIJdAhKCkZb8OPv4qI=.7762bee0-fcb0-4ab5-ae29-1069d7d64ca4@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Doc fixups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/f5b5e6f5..3beac2db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=19-20

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

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

From psandoz at openjdk.org  Thu Oct  3 19:55:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 3 Oct 2024 19:55:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v21]
In-Reply-To: <59ZQPsSgxrGE2E4vGKs0PvO7KJIJdAhKCkZb8OPv4qI=.7762bee0-fcb0-4ab5-ae29-1069d7d64ca4@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <59ZQPsSgxrGE2E4vGKs0PvO7KJIJdAhKCkZb8OPv4qI=.7762bee0-fcb0-4ab5-ae29-1069d7d64ca4@github.com>
Message-ID: <CDI4nALJMy3cuzF9pYU4IYy0wAdvWYaApYdqgRPku94=.e9426f79-b2af-462f-a7eb-f9545b8a132d@github.com>

On Thu, 3 Oct 2024 19:51:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc fixups

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 30:

> 28:  * The class {@code VectorMath} contains methods for performing
> 29:  * scalar numeric operations in support of vector numeric operations.
> 30:  * @author  Paul Sandoz

We no longer use the `@author` tag on newly added classes, can you please remove it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786769928

From jbhateja at openjdk.org  Thu Oct  3 19:55:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:55:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v20]
In-Reply-To: <RS_W7uDGWq3EkfjkFUERraJljQKCXQnYiy5Ap-qhtlY=.e5f53613-0f15-483e-bc05-2e1c8875217f@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>
 <RS_W7uDGWq3EkfjkFUERraJljQKCXQnYiy5Ap-qhtlY=.e5f53613-0f15-483e-bc05-2e1c8875217f@github.com>
Message-ID: <FcFuMTSu9mgyzFIWQJcp3XQ-MfLgGL9f3Eiqjz6Na0w=.710b4907-131d-440d-89c5-a09e57091b4a@github.com>

On Thu, 3 Oct 2024 19:18:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typographic error
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 46:
> 
>> 44:      * @return the smaller of {@code a} and {@code b}.
>> 45:      * @see VectorOperators#UMIN
>> 46:      * @since 24
> 
> Remove `@since 24` in the documentation of each method and place in the documentation on the class.

DONE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786767732

From matsaave at openjdk.org  Thu Oct  3 20:10:09 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Oct 2024 20:10:09 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java from
 JDK-8324259 is failing
Message-ID: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>

DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 

When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

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

Commit messages:
 - 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java from JDK-8324259 is failing

Changes: https://git.openjdk.org/jdk/pull/21329/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21329&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341452
  Stats: 45 lines in 4 files changed: 31 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21329/head:pull/21329

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

From matsaave at openjdk.org  Thu Oct  3 20:16:54 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 3 Oct 2024 20:16:54 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS
Message-ID: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>

8341444: Unnecessary check for JSRs in CDS

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

Commit messages:
 - 8341444: Unnecessary check for JSRs in CDS

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

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

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 sviswanathan at openjdk.org  Thu Oct  3 21:07:40 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 21:07:40 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v16]
In-Reply-To: <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
Message-ID: <S6s7vF_RYOFLIoRy5J5aqiJP9fM88D6HzKJ2RSARrHI=.4323d103-1ea4-44c0-9b01-a46999070f49@github.com>

On Thu, 3 Oct 2024 19:05:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sharpening intrinsic exit check.

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2346694947

From duke at openjdk.org  Thu Oct  3 21:27:41 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Thu, 3 Oct 2024 21:27:41 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
Message-ID: <edCsOwutzgntj3FGnZy0XquBhmWjkmCRDBsfNe3BYBU=.feed19e8-b4e9-472b-8cfa-83f619203dc6@github.com>

On Wed, 2 Oct 2024 19:03:21 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

>> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
>> 
>> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.
>
> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor VMOptionWarning for better scoping of @require
>  - Use simpler vm.opt.final approach

Unfortunately I found another batch of 6 tests with the same issue, will post with another commit once they are patched.

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

PR Comment: https://git.openjdk.org/jdk/pull/21233#issuecomment-2392365353

From eastigeevich at openjdk.org  Thu Oct  3 22:25:36 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Thu, 3 Oct 2024 22:25:36 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM
In-Reply-To: <rXAC_O26HXlVgjA-uz_NlY48wMEDeV6t9IB3YtYHB-o=.ef3160ea-b299-4269-85d5-2934698655c8@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <Juvz6Oj7vk1W4xxlZXkfz0asUVLIhO00-bM8IIdP_ro=.c63c189b-433c-4748-944d-85d44bccd369@github.com>
 <vqgfqxWAv_soSLK7ZJwFy8V5K_DGr6KnNTRlAu2EWd0=.d37581f7-1658-496c-841f-dffbe5238233@github.com>
 <dfqtLjLMMS_gWaTgG-FuVKwm6HyeVwWAFtePVhK_dZo=.b7ec672f-29db-452a-b12e-cc0896a7f7ee@github.com>
 <R2AdTwigicPuJHFbDOIV_-e1Xs-O7Tt3T8j-Y8taX1g=.ce5a5980-4280-4ee8-9e60-3f290bd7f745@github.com>
 <NK_MHHcZzrQ78v9RRTAkXqBibJLVbTcKvWkMIh59eg0=.6bcad355-7a02-4710-89ca-d56b8b374ca2@github.com>
 <fRdb1PbgRdGUTyQ8eAextk0aGs_DXRIq6RDrAHxyS50=.8d4055b3-15b7-44e5-963d-2abcdf7abcd8@github.com>
 <rXAC_O26HXlVgjA-uz_NlY48wMEDeV6t9IB3YtYHB-o=.ef3160ea-b299-4269-85d5-2934698655c8@github.com>
Message-ID: <Zed6DSRapKMBylgc0P9EmQsFbdwWSHddYQnjBp1LdUA=.5e6d1207-1279-4a44-8781-2895fe5bf0f2@github.com>

On Mon, 16 Sep 2024 18:13:25 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>>> > @vnkozlov Many thanks! Do you reproduce the regression on a public benchmark that I can also try? Now I restrict CodeEntryAlignment=16 for V1 and V2 only. And I restart my performance tests.
>>> 
>>> This may have as much to do with the smallish icache
>> 
>> Sorry, I meant last level cache
>
> @theRealAph 
>> It makes little sense to set the default CodeEntryAlignment to less than the icache line size. except in severely constrained environments.
> 
> Why do we need CodeEntryAlignment? The instruction prefetcher has more time to load the next cache line if execution starts at the beginning of the current cache line. But this consideration makes more sense for OptoLoopAlignment. Ideally, the entire loop body fits into a limited number of instruction cache lines - this is unlikely to happen with the entire nmethod body.
> 
> I have experimented with code entry alignment on native application (repeatedly calling a large number of aligned/unaligned short methods) and found that for Neoverse N2 CPU 64-byte alignment is preferable, while no difference was observed for Neoverse V2. I am not sure if this is a feature of the processor implementation or a feature of the Neoverse architecture. The Neoverse N2/V2 technical reference manuals are pretty much the same about L1 instruction memory system features.

@bulasevich, @theRealAph, @vnkozlov 
I see that gcc uses "32:16" for all neoverses.
This is aligned with what I found in the Neoverse-N1 Optimization Guide:

> Consider aligning subroutine entry points and branch targets to 32B boundaries, within the bounds of the code-density requirements of the program. This will ensure that the subsequent fetch can maximize bandwidth following the taken branch by bringing in all useful instructions

It is interesting that I don't see this in the N2&V1&V2 Optimization guides.

IMO we should consider setting CodeEntryAlignmentto for Neoverses to 32 and keep 64 for others.
Any objections?

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

PR Comment: https://git.openjdk.org/jdk/pull/20864#issuecomment-2392440723

From jbhateja at openjdk.org  Fri Oct  4 00:01:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 4 Oct 2024 00:01:59 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v22]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <hTNfN3mdbuIvNUqr1DV48gpKQP-RFOInpRktdAvi1YE=.2804ce60-a7b3-4a49-a3fe-10c8e5e3f2ec@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Update VectorMath.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/3beac2db..550eeb9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=20-21

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

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

From duke at openjdk.org  Fri Oct  4 00:09:36 2024
From: duke at openjdk.org (duke)
Date: Fri, 4 Oct 2024 00:09:36 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
Message-ID: <bVEmFwhDk-oP4XdoWHrKxpP2HBFocP-IMYsFLmptvRU=.64a45db0-b982-4806-9d78-5f2176b5f58f@github.com>

On Wed, 2 Oct 2024 19:03:21 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

>> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
>> 
>> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.
>
> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor VMOptionWarning for better scoping of @require
>  - Use simpler vm.opt.final approach

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

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

PR Comment: https://git.openjdk.org/jdk/pull/21233#issuecomment-2392539205

From duke at openjdk.org  Fri Oct  4 00:09:36 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Fri, 4 Oct 2024 00:09:36 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
Message-ID: <kk0bLn4lCb4QE_UOYVzYWJPYa8e6lASMcyQASmTHWEk=.e63d8d3f-b97d-4879-ac6f-97b4828a25af@github.com>

On Wed, 2 Oct 2024 19:03:21 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

>> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
>> 
>> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.
>
> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor VMOptionWarning for better scoping of @require
>  - Use simpler vm.opt.final approach

It turns out that the other affected tests were under `compiler/rtm/*` which was removed on 2024-06-10 for JDK24: https://bugs.openjdk.org/browse/JDK-8329141

So this PR is good as-is for mainline.

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

PR Comment: https://git.openjdk.org/jdk/pull/21233#issuecomment-2392537227

From dholmes at openjdk.org  Fri Oct  4 02:21:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Oct 2024 02:21:34 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>

On Thu, 3 Oct 2024 17:43:50 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

Apologies for leaving review comments immediately before disappearing on vacation. No need to wait for me to return and respond.

P.S you also need to unProblemList the test.

src/hotspot/share/cds/metaspaceShared.cpp line 757:

> 755:   // Some classes are used at CDS runtime but are not loaded, and therefore archived, at
> 756:   // dumptime. We can perform dummmy calls to these classes at dumptime to ensure they
> 757:   // are archived.

This code doesn't just load classes though, it loads, links, initializes them and creates a unwanted instance. Isn't there a simpler way to do this? Do these classes have to be initialized?

src/hotspot/share/cds/metaspaceShared.cpp line 764:

> 762: 
> 763: void MetaspaceShared::make_dummy_calls(TRAPS) {
> 764:   // Exercise the manifest processing code

Nit: can we think of a better name rather than "dummy"?

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

PR Review: https://git.openjdk.org/jdk/pull/21329#pullrequestreview-2346963837
PR Comment: https://git.openjdk.org/jdk/pull/21329#issuecomment-2392660124
PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1787029188
PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1787029620

From dholmes at openjdk.org  Fri Oct  4 05:03:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Oct 2024 05:03:47 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <4sy1WlbzzIubllOdQCX-bOWEfiJuDOI3lMrOfYtRXLA=.5bb0ed39-d163-48ac-9b8a-fdf7b6baf004@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>
 <4sy1WlbzzIubllOdQCX-bOWEfiJuDOI3lMrOfYtRXLA=.5bb0ed39-d163-48ac-9b8a-fdf7b6baf004@github.com>
Message-ID: <99Pzlnpz1I2C5i1pQyyNgGy6gGrLBtNMjz-QfOLgPhI=.35d546f0-587a-4563-8da4-ef7c1ef28735@github.com>

On Thu, 3 Oct 2024 12:56:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> One interesting thing that we found while looking at this is that the AIX port has the _startThread_lock, but it doesn't use it to coordinate the starting of the created thread. It's unclear to me if that's a bug in that port.

Looks like a copy'n'paste bug. AIX starts the new thread in the suspended state the same as Windows. So less sharing of the startThread_lock than I thought at present.

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2392826420

From dholmes at openjdk.org  Fri Oct  4 05:41:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Oct 2024 05:41:37 GMT
Subject: RFR: 8341413: Stop including osThread_os.hpp in the middle of the
 OSThread class [v2]
In-Reply-To: <4sy1WlbzzIubllOdQCX-bOWEfiJuDOI3lMrOfYtRXLA=.5bb0ed39-d163-48ac-9b8a-fdf7b6baf004@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
 <tZSvIOV51E6Gd-Jttk_xtmAOab2K9fytFob2YA0I4ug=.5533651c-5187-4ab8-8d38-5855b688f549@github.com>
 <4sy1WlbzzIubllOdQCX-bOWEfiJuDOI3lMrOfYtRXLA=.5bb0ed39-d163-48ac-9b8a-fdf7b6baf004@github.com>
Message-ID: <4XJJV49Jwmrb8IoSHvnsqB_ygldlKRf1-U3-M7AOUkw=.780e881c-c062-436b-9c6d-9d343734868d@github.com>

On Thu, 3 Oct 2024 12:56:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I found that the field is not available on Windows, and it's also left uninitialized when we call create_attached_thread.

I did some archaeology on this one. The thread_type was introduced way back in May 2000 on Linux as it was needed for the newly started thread to determine whether it had to install (and later remove) an alternate signal stack. When we later stopped using alt-signal-stack (I'm going to guess this was when we switched from LinuxThreads to NPTL) the field was no longer used, but meanwhile we used the ThreadType enum to control initial stack sizes. So Windows never had a thread_type field and BSD/AIX likely just blindly copied it from the Linux code. 

Attaching a thread never involved using alt-signal-stack so for attached threads it was left uninitialized.

So I think we can clean this up - I will file a RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/21306#issuecomment-2392862035

From dholmes at openjdk.org  Fri Oct  4 06:00:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 4 Oct 2024 06:00:36 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS
In-Reply-To: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
Message-ID: <HgJHowiCeGe2KVSTypys61MQ-tk3rioujwxTP0um7dA=.42b4a606-609e-49b4-92b4-7866f9edccf5@github.com>

On Thu, 3 Oct 2024 17:45:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> 8341444: Unnecessary check for JSRs in CDS

Again apologies for commenting and running off on vacation, but this one does not look right to me based on the description.

src/hotspot/share/interpreter/bytecodeStream.hpp line 198:

> 196:       if (len == 0) len = Bytecodes::length_at(_method(), bcp);
> 197:       if (len <= 0 || (_bci > _end_bci - len) || (_bci - len >= _next_bci)) {
> 198:         fatal("Should have been caught by verifier");

Verification may be disabled, This may be a risky change in behaviour.

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

> 2457:   // don't have any methods share the Universe::_the_empty_method_array which is in the RO region.
> 2458:   if (_methods != nullptr && _methods->length() > 0 && !can_be_verified_at_dumptime()) {
> 2459:     // To handle jsr bytecode, new Method* maybe stored into _methods

Based on the comment we only need to do this if the method does contain a JSR bytecode - now we will do it for all cases where verification can't be done at dumptime. ??

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

PR Review: https://git.openjdk.org/jdk/pull/21330#pullrequestreview-2347186887
PR Review Comment: https://git.openjdk.org/jdk/pull/21330#discussion_r1787187496
PR Review Comment: https://git.openjdk.org/jdk/pull/21330#discussion_r1787188984

From mli at openjdk.org  Fri Oct  4 09:04:41 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 4 Oct 2024 09:04:41 GMT
Subject: RFR: 8341261: Tests assume UnlockExperimentalVMOptions is disabled
 by default [v2]
In-Reply-To: <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
 <QxSGtkThh5jmidEZXh5pda8dQBXp_Qo3GNiEnjWvQa8=.2fcbe279-e6d4-4f72-b1c8-e6ee1205de10@github.com>
Message-ID: <_1NPZVnk8ltAgXyrn3dEwrRsMiuTuhXhJoTx2g0UFvs=.22f01a45-105e-4a4e-b438-9457b210800b@github.com>

On Wed, 2 Oct 2024 19:03:21 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

>> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
>> 
>> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.
>
> Todd V. Jonker has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor VMOptionWarning for better scoping of @require
>  - Use simpler vm.opt.final approach

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21233#pullrequestreview-2347521193

From duke at openjdk.org  Fri Oct  4 09:04:42 2024
From: duke at openjdk.org (Todd V. Jonker)
Date: Fri, 4 Oct 2024 09:04:42 GMT
Subject: Integrated: 8341261: Tests assume UnlockExperimentalVMOptions is
 disabled by default
In-Reply-To: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
References: <3FgNf9LnlQX4j1dvbDRwwVhSn3jKPjuwkhf8HZAkMGM=.5b2dec3a-3152-4e59-947f-d90fa3ae07d4@github.com>
Message-ID: <fVzT61WDwiiWp3r6B3QhZP4QlPV-pLrFwbCXy7fFZe0=.9fd47db6-7b93-46b1-b391-b9fbebce6436@github.com>

On Fri, 27 Sep 2024 20:12:59 GMT, Todd V. Jonker <duke at openjdk.org> wrote:

> `-UnlockExperimentalVMOptions` isn't necessarily the default: a distro may enable it in order to default-enable other features like JVMCI/Graal.
> 
> I'm not entirely satisfied by adding a `@require` that only applies to a subset of the checks in a test class.  In `VMOptionWarning`, the experimental flag only applies to the first of the three scenarios it checks.  But I suspect this is a general problem with `@require`, and I'd be happy to hear suggestions on how to avoid disabling too much.

This pull request has now been integrated.

Changeset: 1bdd79e7
Author:    Todd V. Jonker <jonker at amazon.com>
URL:       https://git.openjdk.org/jdk/commit/1bdd79e7b2086197ab64161e89bbe8cc180f07ed
Stats:     64 lines in 3 files changed: 44 ins; 6 del; 14 mod

8341261: Tests assume UnlockExperimentalVMOptions is disabled by default

Reviewed-by: stefank, mli, ysr

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

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

From rcastanedalo at openjdk.org  Fri Oct  4 09:20:59 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 4 Oct 2024 09:20:59 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
Message-ID: <Ow8TBwe8NiA77jJ34JUCHwSsVyPlGyrlAeKFKGTigQI=.f1b250ed-6dae-438d-a862-b0164767a8f1@github.com>

On Thu, 3 Oct 2024 17:12:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roberto Casta?eda Lozano 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 53 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'feilongjiang/JEP-475-RISC-V' into JDK-8334060-g1-late-barrier-expansion
>>  - riscv port refactor
>>  - Remove temporary support code
>>  - Merge jdk-24+17
>>  - Relax 'must match' assertion in ppc's g1StoreN after limiting pinning bypass optimization
>>  - Remove unnecessary reg-to-reg moves in aarch64's g1CompareAndX instructions
>>  - Reintroduce matcher assert and limit pinning bypass optimization to non-shared EncodeP nodes
>>  - Merge jdk-24+16
>>  - Ensure that detected encode-and-store patterns are matched
>>  - Merge remote-tracking branch 'snazarkin/arm32-JDK-8334060-g1-late-barrier-expansion' into JDK-8334060-g1-late-barrier-expansion
>>  - ... and 43 more: https://git.openjdk.org/jdk/compare/0165cb32...14483b83
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 335:
> 
>> 333:       assert(!use_ReduceInitialCardMarks(),
>> 334:              "post-barriers are only needed for tightly-coupled initialization stores when ReduceInitialCardMarks is disabled");
>> 335:       access.set_barrier_data(access.barrier_data() ^ G1C2BarrierPre);
> 
> I have been looking at this code after integration, and I wonder if `^` is really correct here? Was the intend to remove `G1C2BarrierPre` from the barrier data? What happens if `get_store_barrier` does not actually set it? Do we flip the bit back?

Yes, the intend (and actual effect) is to remove `G1C2BarrierPre` from the barrier data. Using an XOR (`^`) is correct because at that program point `G1C2BarrierPre` is guaranteed to be set. This is because an `access` corresponding to a tightly-coupled initialization store is always of type `C2OptAccess`, hence `!access.is_parse_access()` and `get_store_barrier(access)` trivially returns `G1C2BarrierPre | G1C2BarrierPost`. Having said this, it would be clearly less convoluted to simply clear `G1C2BarrierPre` instead of flipping it. I will file a RFE, thanks.

As a side note, this complexity is necessary to handle `!ReduceInitialCardMarks`. I keep wondering if the benefit of being able to disable `ReduceInitialCardMarks` [1,2,3] is worth the significant complexity required in the GC-C2 interface to deal with it.

[1] https://docs.oracle.com/en/java/javase/23/gctuning/garbage-first-garbage-collector-tuning.html
[2] https://bugs.openjdk.org/browse/JDK-8166899
[3] https://bugs.openjdk.org/browse/JDK-8167077

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1787425169

From rcastanedalo at openjdk.org  Fri Oct  4 09:37:53 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 4 Oct 2024 09:37:53 GMT
Subject: RFR: 8334060: Implementation of Late Barrier Expansion for G1
 [v27]
In-Reply-To: <Ow8TBwe8NiA77jJ34JUCHwSsVyPlGyrlAeKFKGTigQI=.f1b250ed-6dae-438d-a862-b0164767a8f1@github.com>
References: <ClHEkY_xzx37VNyLJr9F9eWSjXfdCRQcbmAhomsY7kU=.f4c3c125-caed-467f-b9fa-213d14f7908a@github.com>
 <YYVkTHSwqRigZMpp3wjVjULgwfhawfXCszR2iKEPazA=.a7b37dee-07cd-45e9-aeed-0f90cba1268a@github.com>
 <vz_qfsQGfiikePNlQj8Wae9rSr8qGA8Or4_oincOBmY=.a477b15b-73cd-433d-acbc-ccda765a166a@github.com>
 <Ow8TBwe8NiA77jJ34JUCHwSsVyPlGyrlAeKFKGTigQI=.f1b250ed-6dae-438d-a862-b0164767a8f1@github.com>
Message-ID: <DsrNX6ZGnVuKeparyk9sLtruBnL_FqBNSQctnRrYXgs=.7f1385ab-431d-42b9-9883-d8f5b6c98a18@github.com>

On Fri, 4 Oct 2024 09:17:47 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 335:
>> 
>>> 333:       assert(!use_ReduceInitialCardMarks(),
>>> 334:              "post-barriers are only needed for tightly-coupled initialization stores when ReduceInitialCardMarks is disabled");
>>> 335:       access.set_barrier_data(access.barrier_data() ^ G1C2BarrierPre);
>> 
>> I have been looking at this code after integration, and I wonder if `^` is really correct here? Was the intend to remove `G1C2BarrierPre` from the barrier data? What happens if `get_store_barrier` does not actually set it? Do we flip the bit back?
>
> Yes, the intend (and actual effect) is to remove `G1C2BarrierPre` from the barrier data. Using an XOR (`^`) is correct because at that program point `G1C2BarrierPre` is guaranteed to be set. This is because an `access` corresponding to a tightly-coupled initialization store is always of type `C2OptAccess`, hence `!access.is_parse_access()` and `get_store_barrier(access)` trivially returns `G1C2BarrierPre | G1C2BarrierPost`. Having said this, it would be clearly less convoluted to simply clear `G1C2BarrierPre` instead of flipping it. I will file a RFE, thanks.
> 
> As a side note, this complexity is necessary to handle `!ReduceInitialCardMarks`. I keep wondering if the benefit of being able to disable `ReduceInitialCardMarks` [1,2,3] is worth the significant complexity required in the GC-C2 interface to deal with it.
> 
> [1] https://docs.oracle.com/en/java/javase/23/gctuning/garbage-first-garbage-collector-tuning.html
> [2] https://bugs.openjdk.org/browse/JDK-8166899
> [3] https://bugs.openjdk.org/browse/JDK-8167077

Reported here: [JDK-8341525](https://bugs.openjdk.org/browse/JDK-8341525).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1787448241

From duke at openjdk.org  Fri Oct  4 10:20:48 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 4 Oct 2024 10:20:48 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3
Message-ID: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>

There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

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

Commit messages:
 - 8341527: AVX-512 intrinsic for SHA3

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

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

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 duke at openjdk.org  Fri Oct  4 10:53:50 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 4 Oct 2024 10:53:50 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v2]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <S0EDKqafsdHh73AhLprrfcPkbwuStKZxQX6CMTK0Hhc=.6bf8046f-90f1-46f6-b117-5f74a5c3f352@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

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

  fix debug build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21352/files
  - new: https://git.openjdk.org/jdk/pull/21352/files/37e1058c..c91b80db

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

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

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

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 duke at openjdk.org  Fri Oct  4 11:40:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 4 Oct 2024 11:40:14 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v3]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <0o74WoWTyO-F8FE7hW2rvk10-UeHH84gGZ0xAECq2UA=.6b155eea-1515-4317-ac4a-5275f9e702b5@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

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

  fix windows build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21352/files
  - new: https://git.openjdk.org/jdk/pull/21352/files/c91b80db..e48dd674

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

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

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

From stefank at openjdk.org  Fri Oct  4 11:45:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 4 Oct 2024 11:45:43 GMT
Subject: Integrated: 8341413: Stop including osThread_os.hpp in the middle of
 the OSThread class
In-Reply-To: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
References: <ajTA_oWo7O7PqCGNuiGA-czbZULUAxdhBRxA88A4y6s=.ab408ae4-ec5d-4ff3-83cb-d5bae2de1723@github.com>
Message-ID: <fLrOrxqpL5711X6bizXwlAqLXPOMlC1MwGyFI1n8Gio=.78e0c37f-8687-4854-8497-790396bc4da2@github.com>

On Wed, 2 Oct 2024 13:50:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Some HotSpot files have an interesting include pattern where the platform dependent code is included straight into the class containing the shared implementation.
> 
> This has various interesting effects to the code layout and readability of the code. I propose we stop doing this, where possible, and instead clearly separate the shared code and the platform specific code in separate classes. This then allows us to use the standard include patterns that we use for most of our code.
> 
> This PR is a suggestion for how to untangle this for the OSThread class.
> 
> Things in the code that changed with this patch that might be good to take an extra look at:
> 1) I dropped unnecessary includes
> 2) `pd_initialize/pd_destroy` was converted into constructor/destructor
> 3) Member initialization lists are used. Note that some variables that used to be uninitialized are now getting initialized. `_caller_sigmask` is one of the interesting once, because it's sizable array. I still don't think that is problematic because all the other code we run to start threads, but if I get push back on this I'll comment it out.
> 4) (3) switched the order of the `new Monitor` call and the `sigemptyset` call
> 5) I did some reordering of functions to unify the four platforms
> 6) Moved `_thread_id` to the platform files
> 7) I stopped exposing the `thread_id_t` typedef.
> 8) I created a virtual `thread_id_for_printing` function for those calls that want a unified integer type that can be printed. An alternative to this could be to use a non-virtual call, but that requires us to to define `OSThreadBase::thread_id_for_printing` in the platform files. 
> 
> Tested: tier1-3, (excluding AIX, which I can't build/test)

This pull request has now been integrated.

Changeset: 72ac72fe
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72ac72fe1f3faca299d3fb2b20d3af29c3fa1e56
Stats:     786 lines in 31 files changed: 294 ins; 376 del; 116 mod

8341413: Stop including osThread_os.hpp in the middle of the OSThread class

Reviewed-by: coleenp, dholmes

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

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

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 rcastanedalo at openjdk.org  Fri Oct  4 14:05:49 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 4 Oct 2024 14:05:49 GMT
Subject: RFR: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
Message-ID: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>

This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.

Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.

#### Testing
- tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
- tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

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

Commit messages:
 - Clear pre-barrier bit of tightly-coupled initialization stores using bit clearing rather than toggling

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

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

From mdoerr at openjdk.org  Fri Oct  4 14:21:40 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Oct 2024 14:21:40 GMT
Subject: RFR: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
In-Reply-To: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
References: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
Message-ID: <hSjsJB3jDj0eDtQuKRQjTzAx_E54b7ROFvAZgYhA8no=.704a01db-c4a9-43ec-94d9-95172ba37c1b@github.com>

On Fri, 4 Oct 2024 13:04:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.
> 
> Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.
> 
> #### Testing
> - tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
> - tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21356#pullrequestreview-2348198153

From rrich at openjdk.org  Fri Oct  4 15:02:38 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 4 Oct 2024 15:02:38 GMT
Subject: RFR: 8339386: Assertion on AIX - original PC must be in the main
 code section of the compiled method
In-Reply-To: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
References: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
Message-ID: <JISThvfzCLjsXCrOurOPBwGm5Pojglxn46zMEd8sJY4=.02b4d8a9-e5a3-4641-a2a5-ea5f2157b2f4@github.com>

On Wed, 25 Sep 2024 19:20:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We should make sure to read the `sender_pc` only once to make it signal safe (e.g. using `volatile`). Now, we can check if it is a deopt PC and if so, if the original PC is within the nmethod.
> In case of interpreter frame on top of compiled deoptimized frame we need to use the unextendedSP (2nd commit).

I'd expect more frequent failures of the assertion given that the wrong unextended sp was used. It shouldn't be too difficult to write a reproducer but that's not really needed.
The fix does look good.
Thanks, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21189#pullrequestreview-2348293871

From kbarrett at openjdk.org  Fri Oct  4 15:31:34 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Oct 2024 15:31:34 GMT
Subject: RFR: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
In-Reply-To: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
References: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
Message-ID: <zWu9EqN_PkHyYuHVqjvnsbNmHhYLBygjRPeJsmTAV5Q=.1d45a382-32e1-4155-a24c-9795763a259b@github.com>

On Fri, 4 Oct 2024 13:04:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.
> 
> Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.
> 
> #### Testing
> - tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
> - tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21356#pullrequestreview-2348354290

From ccheung at openjdk.org  Fri Oct  4 16:17:41 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 4 Oct 2024 16:17:41 GMT
Subject: RFR: 8341053: Two CDS tests fail again with -UseCompressedOops and
 UseSerialGC/UseParallelGC
In-Reply-To: <EQWOnInnhVXACGlnHgVmVvqfXrLZ6ln5Q57FmTefmqA=.90a50d52-f434-4b59-9d0c-92606994c14a@github.com>
References: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
 <EQWOnInnhVXACGlnHgVmVvqfXrLZ6ln5Q57FmTefmqA=.90a50d52-f434-4b59-9d0c-92606994c14a@github.com>
Message-ID: <9NlDcTYX-cD-eVxw7qLBjpES5HLls0cPHK-kA_YDPQ8=.1ff6b321-882a-4d0b-94f0-422c186cfcd3@github.com>

On Thu, 3 Oct 2024 00:38:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A small fix to add a check in WB_CanWriteJavaHeapArchive to allow CDS tests to run with Parallel and Serial GC. However, if compressed oops is disabled (`-XX:-UseCompressedOops`) and specified with `-XX:+UseParallelGC `or `-XX:+UseSerialGC`, the test will be skipped.
>> 
>> Testing:
>> - [x] CDS tests with `-XX:+ParallelGC`
>> - [x] CDS tests with `-XX:+SerialGC`
>> - [x] test group `open/test/hotspot/jtreg/:hotspot_cds_only` with `-XX:-UseCompressedOops`
>> - [x] manually checks that the failed tests in the bug report were not run with `-XX:-UseCompressedOops -XX:+UseParallel`
>
> LGTM

Thanks @iklam, @matias9927 for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/21314#issuecomment-2394042033

From ccheung at openjdk.org  Fri Oct  4 16:17:41 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 4 Oct 2024 16:17:41 GMT
Subject: Integrated: 8341053: Two CDS tests fail again with -UseCompressedOops
 and UseSerialGC/UseParallelGC
In-Reply-To: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
References: <CMTO3F5nw3etqSRobQ9AoNWlB0KBo_YdECBD-hkIF1s=.fc5ea19c-460c-4231-9dff-173d2637026b@github.com>
Message-ID: <VsVBCBUIlLhXN8uPtlbXouGvJJJCxCgCnRqzCGMV3b8=.9f72d52d-4016-4f46-a14a-3ae0a175146d@github.com>

On Wed, 2 Oct 2024 21:53:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> A small fix to add a check in WB_CanWriteJavaHeapArchive to allow CDS tests to run with Parallel and Serial GC. However, if compressed oops is disabled (`-XX:-UseCompressedOops`) and specified with `-XX:+UseParallelGC `or `-XX:+UseSerialGC`, the test will be skipped.
> 
> Testing:
> - [x] CDS tests with `-XX:+ParallelGC`
> - [x] CDS tests with `-XX:+SerialGC`
> - [x] test group `open/test/hotspot/jtreg/:hotspot_cds_only` with `-XX:-UseCompressedOops`
> - [x] manually checks that the failed tests in the bug report were not run with `-XX:-UseCompressedOops -XX:+UseParallel`

This pull request has now been integrated.

Changeset: 42f32551
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42f32551cd2aaa4b7609cc887cb33fc58ac12779
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8341053: Two CDS tests fail again with -UseCompressedOops and UseSerialGC/UseParallelGC

Reviewed-by: iklam, matsaave

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

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

From coleenp at openjdk.org  Fri Oct  4 17:37:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Oct 2024 17:37:37 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS
In-Reply-To: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
Message-ID: <XLy0XoJdXQa1Hg46ZnQBAWWGbyWhYufjw_2lOw01zN0=.d0b4d9fc-77df-4f00-ad21-aaf0ccc846bf@github.com>

On Thu, 3 Oct 2024 17:45:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> 8341444: Unnecessary check for JSRs in CDS

I think you should take out the 'fatal' error in bytecodeStream.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21330#pullrequestreview-2348691799

From coleenp at openjdk.org  Fri Oct  4 17:37:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Oct 2024 17:37:38 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS
In-Reply-To: <HgJHowiCeGe2KVSTypys61MQ-tk3rioujwxTP0um7dA=.42b4a606-609e-49b4-92b4-7866f9edccf5@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
 <HgJHowiCeGe2KVSTypys61MQ-tk3rioujwxTP0um7dA=.42b4a606-609e-49b4-92b4-7866f9edccf5@github.com>
Message-ID: <E3oc2kBWPHWSRRpIbyXcWWc6qOFutvTm93l3JGYAvFY=.bf1764e3-9b30-4dc4-9ab4-2bf2c9a34a83@github.com>

On Fri, 4 Oct 2024 05:50:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 8341444: Unnecessary check for JSRs in CDS
>
> src/hotspot/share/interpreter/bytecodeStream.hpp line 198:
> 
>> 196:       if (len == 0) len = Bytecodes::length_at(_method(), bcp);
>> 197:       if (len <= 0 || (_bci > _end_bci - len) || (_bci - len >= _next_bci)) {
>> 198:         fatal("Should have been caught by verifier");
> 
> Verification may be disabled, This may be a risky change in behaviour.

If verification is disabled, this fatal is better than what might come next.  But there may be callers now or in the future that check for Bytecodes::_illegal, so I don't think we should have this assert even though we don't have any code that hits it.

> src/hotspot/share/oops/instanceKlass.cpp line 2459:
> 
>> 2457:   // don't have any methods share the Universe::_the_empty_method_array which is in the RO region.
>> 2458:   if (_methods != nullptr && _methods->length() > 0 && !can_be_verified_at_dumptime()) {
>> 2459:     // To handle jsr bytecode, new Method* maybe stored into _methods
> 
> Based on the comment we only need to do this if the method does contain a JSR bytecode - now we will do it for all cases where verification can't be done at dumptime. ??

Yes, we will put these in RW space the time.  Using the BytecodeStream to look for JSRs in unverified code is risky, so we avoid doing this optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21330#discussion_r1788058857
PR Review Comment: https://git.openjdk.org/jdk/pull/21330#discussion_r1788063152

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 sviswanathan at openjdk.org  Fri Oct  4 18:29:39 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 4 Oct 2024 18:29:39 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <AGZWheV39lKipgVZiRn0I6J8QxkoZJO9q_D0UBcd67A=.ba153fae-f68d-4782-8b5b-409123ea1ea1@github.com>

On Mon, 19 Aug 2024 21:34:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8341052: SHA-512 implementation using SHA-NI

The line 1306 in vm_version_x86.cpp needs to be changed from:
 if (UseSHA && supports_avx2() && supports_bmi2()) {
to
  if (UseSHA && supports_avx2() && (supports_bmi2() || supports_sha512())) {

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

PR Comment: https://git.openjdk.org/jdk/pull/20633#issuecomment-2394336870

From sviswanathan at openjdk.org  Fri Oct  4 18:40:36 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 4 Oct 2024 18:40:36 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <iTw6KauNij1D5lhOiCZsYGxy6QIM6fm4QpIT9ymLw28=.b7efaeff-5eb1-4841-bb15-7780be58fd8a@github.com>

On Mon, 19 Aug 2024 21:34:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8341052: SHA-512 implementation using SHA-NI

src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 1526:

> 1524:     address K512_W = StubRoutines::x86::k512_W_addr();
> 1525: 
> 1526:     vbroadcasti128(xmm15, ExternalAddress(StubRoutines::x86::pshuffle_byte_flip_mask_addr_sha512()), rbx);

rbx is save on entry register. Better to use a save on call register as temp, say r10.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1560:

> 1558: address StubGenerator::generate_sha512_implCompress(bool multi_block, const char *name) {
> 1559:   assert(VM_Version::supports_avx2() || VM_Version::supports_sha512(), "");
> 1560:   assert(VM_Version::supports_bmi2(), "");

The SHA512 algorithm is also using AVX2 instructions but doesn't need bmi2.
So this needs to be changed to:
 assert(VM_Version::supports_avx2(), "");
 assert(VM_Version::supports_bmi2()  || VM_Version::supports_sha512(), "");

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 446:

> 444:     0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
> 445: };
> 446: 

Extra blank line could be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1788140453
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1788127094
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1788041727

From duke at openjdk.org  Fri Oct  4 19:47:38 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 4 Oct 2024 19:47:38 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <dq5DbMcq3fGQ-fQ0_VMPnKYu5FxclxDOYe82S0GxB4o=.a07a1952-e1c4-42c0-91c7-5f6da49dd8e9@github.com>

On Fri, 27 Sep 2024 14:21:57 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

test/micro/org/openjdk/bench/java/lang/MinMaxLoopBench.java line 107:

> 105:     @Benchmark
> 106:     public int[] intLoopMin() {
> 107:         final int[] result = new int[size];

it would be better to not have this allocation here unless is what you want to measure 
i.e. allocation and assignment in a fresh new array which would escape.
The optimization still kicks-in if you reuse the same `result` saved as an instance field?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1788235692

From sviswanathan at openjdk.org  Fri Oct  4 20:46:34 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 4 Oct 2024 20:46:34 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <jQPCGJPuvuts8CZvPfpLVP0uZYwAl31nSDO8cjCobuo=.66325c1c-03d6-4fd8-92fe-b75800e5eb28@github.com>

On Mon, 19 Aug 2024 21:34:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> 8341052: SHA-512 implementation using SHA-NI

src/hotspot/cpu/x86/assembler_x86.cpp line 6766:

> 6764: 
> 6765: void Assembler::sha512msg1(XMMRegister dst, XMMRegister src) {
> 6766:   assert(VM_Version::supports_sha512(), "");

For all the new sha512 instructions, this should be:
assert(VM_Version::supports_sha512() && VM_Version::supports_avx(), "");

src/hotspot/cpu/x86/assembler_x86.cpp line 6767:

> 6765: void Assembler::sha512msg1(XMMRegister dst, XMMRegister src) {
> 6766:   assert(VM_Version::supports_sha512(), "");
> 6767:   InstructionAttr attributes(AVX_256bit, /* vex_w */ false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

For all the new sha512 instructions legacy_mode should be true.

src/hotspot/cpu/x86/assembler_x86.cpp line 11696:

> 11694: }
> 11695: 
> 11696: void Assembler::vbroadcasti128(XMMRegister dst, Address src) {

Please see vbroadcastf128, good to take vector_len as argument here also and have an assert to confirm that it is AVX-256 bit. 
Also need:
attributes.set_address_attributes(/* tuple_type */ EVEX_T4, /* input_size_in_bits */ EVEX_32bit);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1788266957
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1788269351
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1788284731

From syan at openjdk.org  Sat Oct  5 07:55:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 5 Oct 2024 07:55:13 GMT
Subject: RFR: 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp
Message-ID: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>

Hi all,
  This PR fix some typos bugs for RISC-V, and a typo bug in test directory. Trivial fix, no risk.

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

Commit messages:
 - 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp

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

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

From lucy at openjdk.org  Sat Oct  5 10:00:47 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Sat, 5 Oct 2024 10:00:47 GMT
Subject: RFR: 8339386: Assertion on AIX - original PC must be in the main
 code section of the compiled method
In-Reply-To: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
References: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
Message-ID: <AVcbOE_GO9olWFXiLhZKX4J-7NBvzFtxYAYANI0F0-Y=.4dd6d7dc-a364-44ca-9b98-2e51d386aa77@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 25 Sep 2024 19:20:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We should make sure to read the `sender_pc` only once to make it signal safe (e.g. using `volatile`). Now, we can check if it is a deopt PC and if so, if the original PC is within the nmethod.
> In case of interpreter frame on top of compiled deoptimized frame we need to use the unextendedSP (2nd commit).

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21189#pullrequestreview-2349523450

From syan at openjdk.org  Sat Oct  5 10:09:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 5 Oct 2024 10:09:03 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter to
 link to source code
Message-ID: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>

Hi all,
The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.

Additonal testing:

- [x] riscv native build with slowdebug and fastdebug
- [ ] jtreg test(include tier1/2/3 etc.) with release build

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

Commit messages:
 - 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter to link to source code

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

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

From syan at openjdk.org  Sat Oct  5 10:23:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 5 Oct 2024 10:23:40 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
Message-ID: <MMSqlFSP-813wLVOw8wzwOfqctN1clB3Am1-vdphWvs=.0bd13c3c-c652-444a-be19-4532e5f96390@github.com>

On Sat, 5 Oct 2024 10:03:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
> 
> Additonal testing:
> 
> - [x] riscv native build with slowdebug and fastdebug
> - [ ] jtreg tier1 test with release build

The output of command `build/linux-riscv64-server-slowdebug/images/jdk/bin/java -Xint -XX:+PrintInterpreter -version`
[jdk24-riscv.log](https://github.com/user-attachments/files/17265783/jdk24-riscv.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/21370#issuecomment-2395008810

From duke at openjdk.org  Sat Oct  5 16:47:12 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Sat, 5 Oct 2024 16:47:12 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
 - fix windows build
 - fix debug build
 - 8341527: AVX-512 intrinsic for SHA3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21352/files
  - new: https://git.openjdk.org/jdk/pull/21352/files/e48dd674..1b5b71f0

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

  Stats: 32335 lines in 517 files changed: 26010 ins; 3807 del; 2518 mod
  Patch: https://git.openjdk.org/jdk/pull/21352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21352/head:pull/21352

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

From mdoerr at openjdk.org  Sat Oct  5 18:47:40 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 5 Oct 2024 18:47:40 GMT
Subject: RFR: 8339386: Assertion on AIX - original PC must be in the main
 code section of the compiled method
In-Reply-To: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
References: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
Message-ID: <QOYWCJhanr8SbENRptQReC4GPUZpfhbwB2VKykg1aW4=.f5b29242-79fc-41be-962d-3c6e30827ab3@github.com>

On Wed, 25 Sep 2024 19:20:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We should make sure to read the `sender_pc` only once to make it signal safe (e.g. using `volatile`). Now, we can check if it is a deopt PC and if so, if the original PC is within the nmethod.
> In case of interpreter frame on top of compiled deoptimized frame we need to use the unextendedSP (2nd commit).

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21189#issuecomment-2395153881

From mdoerr at openjdk.org  Sat Oct  5 18:47:40 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 5 Oct 2024 18:47:40 GMT
Subject: Integrated: 8339386: Assertion on AIX - original PC must be in the
 main code section of the compiled method
In-Reply-To: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
References: <QnGCIEGGxZBXi3fITJ215t_ShPYIaDpnUg8Ck8LlGW0=.5dd14f79-6065-43cd-a3b2-96732aabe0fa@github.com>
Message-ID: <BWpNxDRbkp2Ioi4QNJ8egbx2-ymRXGJXz6OFXz2sHtM=.a912986c-f5a6-4092-9e1e-7ca6c9042ac3@github.com>

On Wed, 25 Sep 2024 19:20:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We should make sure to read the `sender_pc` only once to make it signal safe (e.g. using `volatile`). Now, we can check if it is a deopt PC and if so, if the original PC is within the nmethod.
> In case of interpreter frame on top of compiled deoptimized frame we need to use the unextendedSP (2nd commit).

This pull request has now been integrated.

Changeset: 9a25f822
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a25f822fb2529c1cae3ae909761381789d7b7b1
Stats:     12 lines in 1 file changed: 9 ins; 0 del; 3 mod

8339386: Assertion on AIX - original PC must be in the main code section of the compiled method

Reviewed-by: rrich, lucy

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

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

From duke at openjdk.org  Sat Oct  5 19:35:43 2024
From: duke at openjdk.org (duke)
Date: Sat, 5 Oct 2024 19:35:43 GMT
Subject: Withdrawn: 8332602: [s390x] Improve itable_stub
In-Reply-To: <FrbZJthoYbG0tT81EkQWC30W5MlwXt4ivMdS2iNeasc=.7b554482-7c08-40ad-9412-3b8fdd835c3c@github.com>
References: <FrbZJthoYbG0tT81EkQWC30W5MlwXt4ivMdS2iNeasc=.7b554482-7c08-40ad-9412-3b8fdd835c3c@github.com>
Message-ID: <I5LBrQAJeMg5Qk0_5hPwCtNtyILNc1ROqpUjOjDrzrs=.2ba493a4-ee68-4038-aff3-effc14ffb441@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Thu, 13 Jun 2024 13:10:35 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x Port similar to [JDK-8305959 (x86)](https://bugs.openjdk.org/browse/JDK-8305959) and [JDK-8307352(aarch64)](https://bugs.openjdk.org/browse/JDK-8307352)
> 
> Testing: I ran `tier1` test on fastdebug & release VM; I didn't see any regression there;
> 
> Benchmarking: 
> 
> Without Patch: 
> Benchmark                        Mode  Cnt   Score    Error  Units
> InterfaceCalls.test1stInt2Types  avgt   12   1.924 ?  0.001  ns/op
> InterfaceCalls.test1stInt3Types  avgt   12  13.925 ?  0.014  ns/op
> InterfaceCalls.test1stInt5Types  avgt   12  16.591 ?  0.045  ns/op
> InterfaceCalls.test2ndInt2Types  avgt   12   2.028 ?  0.013  ns/op
> InterfaceCalls.test2ndInt3Types  avgt   12   7.634 ?  0.049  ns/op
> InterfaceCalls.test2ndInt5Types  avgt   12  16.231 ?  1.222  ns/op
> InterfaceCalls.testIfaceCall     avgt   12  16.587 ?  0.058  ns/op
> InterfaceCalls.testIfaceExtCall  avgt   12  17.532 ?  0.024  ns/op
> InterfaceCalls.testMonomorphic   avgt   12   0.746 ?  0.001  ns/op
> Finished running test 'micro:vm.compiler.InterfaceCalls'
> 
> 
> With Patch: 
> 
> Benchmark                        Mode  Cnt   Score    Error  Units
> InterfaceCalls.test1stInt2Types  avgt   12   1.929 ?  0.012  ns/op
> InterfaceCalls.test1stInt3Types  avgt   12  13.280 ?  0.093  ns/op
> InterfaceCalls.test1stInt5Types  avgt   12  16.169 ?  0.364  ns/op
> InterfaceCalls.test2ndInt2Types  avgt   12   6.758 ?  4.473  ns/op
> InterfaceCalls.test2ndInt3Types  avgt   12  11.772 ?  2.411  ns/op
> InterfaceCalls.test2ndInt5Types  avgt   12  15.099 ?  0.081  ns/op
> InterfaceCalls.testIfaceCall     avgt   12  15.972 ?  0.021  ns/op
> InterfaceCalls.testIfaceExtCall  avgt   12  16.600 ?  0.322  ns/op
> InterfaceCalls.testMonomorphic   avgt   12   0.746 ?  0.001  ns/op
> Finished running test 'micro:vm.compiler.InterfaceCalls'

This pull request has been closed without being integrated.

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

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

From syan at openjdk.org  Sun Oct  6 03:59:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 6 Oct 2024 03:59:39 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
Message-ID: <YA2Z0kgNGCEBqwa0woA0-7PIi_n_REVRJN3tpidtG7E=.a69f1a71-5879-477b-ab2e-7c91e97cbb2e@github.com>

On Sat, 5 Oct 2024 10:03:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
> 
> Additonal testing:
> 
> - [x] riscv native build with slowdebug and fastdebug
> - [x] jtreg tier1 test with release build

[jdk24-jtreg-tier1.log](https://github.com/user-attachments/files/17268036/jdk24-jtreg-tier1.log)
Two tests run timeouted, I think the timeout issue is unreleated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21370#issuecomment-2395281580

From jwaters at openjdk.org  Sun Oct  6 05:09:40 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 6 Oct 2024 05:09:40 GMT
Subject: RFR: 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp
In-Reply-To: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
References: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
Message-ID: <ZkG6TjkifeUhM_MTLoy9SmCwuz55FeGERMovrb4CHHY=.eccfdf2b-83ce-4f90-8c24-b2ace408f8d4@github.com>

On Sat, 5 Oct 2024 07:49:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR fix some typos bugs for RISC-V, and a typo bug in test directory. Trivial fix, no risk.

Looks good regardless

src/hotspot/cpu/riscv/methodHandles_riscv.cpp line 447:

> 445:     }
> 446:   }
> 447: 

This whitespace deletion seems a bit random, but I have no opinion on it

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21368#pullrequestreview-2350453529
PR Review Comment: https://git.openjdk.org/jdk/pull/21368#discussion_r1788884512

From syan at openjdk.org  Sun Oct  6 08:17:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 6 Oct 2024 08:17:41 GMT
Subject: RFR: 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp
In-Reply-To: <ZkG6TjkifeUhM_MTLoy9SmCwuz55FeGERMovrb4CHHY=.eccfdf2b-83ce-4f90-8c24-b2ace408f8d4@github.com>
References: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
 <ZkG6TjkifeUhM_MTLoy9SmCwuz55FeGERMovrb4CHHY=.eccfdf2b-83ce-4f90-8c24-b2ace408f8d4@github.com>
Message-ID: <zOprs8ppThwe-YPvjsYpc0tYsctNevo3t5cn3DuKPpo=.98b00b2e-f52a-4f4f-aa73-144be87dea8c@github.com>

On Sun, 6 Oct 2024 05:06:31 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Hi all,
>>   This PR fix some typos bugs for RISC-V, and a typo bug in test directory. Trivial fix, no risk.
>
> src/hotspot/cpu/riscv/methodHandles_riscv.cpp line 447:
> 
>> 445:     }
>> 446:   }
>> 447: 
> 
> This whitespace deletion seems a bit random, but I have no opinion on it

Okey.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21368#discussion_r1788962457

From qamai at openjdk.org  Sun Oct  6 08:32:20 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 6 Oct 2024 08:32:20 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  [vectorapi] Refactor VectorShuffle implementation

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

Changes: https://git.openjdk.org/jdk/pull/21042/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=01
  Stats: 5013 lines in 64 files changed: 2737 ins; 1068 del; 1208 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

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

From qamai at openjdk.org  Sun Oct  6 10:11:48 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 6 Oct 2024 10:11:48 GMT
Subject: RFR: 8341102: Add element type information to vector types [v3]
In-Reply-To: <l_Vrxk69jcMuC-lIAgn2w9UF196tQ9ZQ9nD8wGsOq1U=.b34d00b3-77af-46ae-a398-de8555a08778@github.com>
References: <l_Vrxk69jcMuC-lIAgn2w9UF196tQ9ZQ9nD8wGsOq1U=.b34d00b3-77af-46ae-a398-de8555a08778@github.com>
Message-ID: <BZKKhoZGxrHUjmcoTSvhn9ZhoFFTgfdi86l_NOD-oLc=.89b1df2e-906b-408f-bb40-b96c6ecd3376@github.com>

> Hi,
> 
> This patch adds the type information of each element in a `TypeVect`. This helps constant folding vectors as well as strength reduction of several complex operations such as `Rearrange`. Some notable points:
> 
> - I only implement `ConV` rule on x86, looking at other architectures it seems that I would not only need to implement the `ConV` implementations, but several other rules that match `ReplicateNode` of a constant.
> - I changed the implementation of an array constant in `constanttable`, I think working with `jbyte` is easier as it allows `memcpy` and at this point, we are close to the metal anyway.
> - Constant folding for a `VectorUnboxNode`, this is special because an element of a normal stable array is only constant if it is non-zero, so implementing constant folding on a load node seems less trivial.
> - Memory fences because `Vector::payload` is a final field and we should respect that.
> - Several places expect a `const Type*` when in reality it expects a `BasicType`, I refactor that so that the intent is clearer and there is less room for possible errors, this is needed because `byte`, `short` and `int` share the same kind of `const Type*`.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  add element types to vector types

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

Changes: https://git.openjdk.org/jdk/pull/21229/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21229&range=02
  Stats: 1431 lines in 39 files changed: 887 ins; 330 del; 214 mod
  Patch: https://git.openjdk.org/jdk/pull/21229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21229/head:pull/21229

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

From qamai at openjdk.org  Sun Oct  6 10:27:35 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 6 Oct 2024 10:27:35 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
Message-ID: <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>

On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   [vectorapi] Refactor VectorShuffle implementation

I have adapted the patch in accordance with https://github.com/openjdk/jdk/pull/20634, I moved the index wrapping into C2 instead of making it a separate step as I think it seems clearer. Also, I think in the future we can eliminate this step so putting it in C2 would make the progress easier.

Please take a look, thanks a lot.

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

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2395383093

From fyang at openjdk.org  Sun Oct  6 11:07:39 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 6 Oct 2024 11:07:39 GMT
Subject: RFR: 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp
In-Reply-To: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
References: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
Message-ID: <iYkLcT3A-5bWkR5aa-b4tFq15ieyzruMymseDTczMEk=.21ea7ced-d27a-4676-91f3-02a0fc365f26@github.com>

On Sat, 5 Oct 2024 07:49:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR fix some typos bugs for RISC-V, and a typo bug in test directory. Trivial fix, no risk.

Marked as reviewed by fyang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21368#pullrequestreview-2350507371

From syan at openjdk.org  Sun Oct  6 12:23:42 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 6 Oct 2024 12:23:42 GMT
Subject: RFR: 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp
In-Reply-To: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
References: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
Message-ID: <zxPLJBIKth4TLJINq6inJpi_MCbBOIzE57W1ViQ9D-s=.c5026c83-5105-4791-9871-8bc4a0a8ab50@github.com>

On Sat, 5 Oct 2024 07:49:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR fix some typos bugs for RISC-V, and a typo bug in test directory. Trivial fix, no risk.

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21368#issuecomment-2395419393

From syan at openjdk.org  Sun Oct  6 12:23:42 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 6 Oct 2024 12:23:42 GMT
Subject: Integrated: 8337713: RISC-V: fix typos in macroAssembler_riscv.cpp
In-Reply-To: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
References: <H-nUlIzuOBb2HbikFhZSxA7u746qo8V9Io8mDVSXTQQ=.f214ee2b-c468-4ce8-8911-4185f5bb3f0b@github.com>
Message-ID: <P9a3P-FybIRXcFS4vbACn2isugBquHfk3gL0PSyrPyg=.13aaeaed-cb9e-4585-a9e0-bc3c77073156@github.com>

On Sat, 5 Oct 2024 07:49:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   This PR fix some typos bugs for RISC-V, and a typo bug in test directory. Trivial fix, no risk.

This pull request has now been integrated.

Changeset: 50426b38
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50426b3841240c5fda0df11439e52fa1ae9e7e07
Stats:     5 lines in 3 files changed: 0 ins; 1 del; 4 mod

8337713: RISC-V: fix typos in macroAssembler_riscv.cpp

Reviewed-by: jwaters, fyang

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

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

From shade at openjdk.org  Sun Oct  6 14:41:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 6 Oct 2024 14:41:43 GMT
Subject: RFR: 8340547: Starting many threads can delay safepoints [v3]
In-Reply-To: <DEanpPm3VDyhXOjQSH7VzYAvmJrAgm-fq6bwfidxdIE=.60c1a580-7ebb-4d71-8e32-c068cbe88547@github.com>
References: <dj3wx0Hq2u6Kiwg7wjmPGqvriHlcGeOa_v4maKF3c3w=.456dcfff-4eef-4426-9c0f-3c6e1c2ab653@github.com>
 <xHtEAkyMVRjDTPfyQaPGpk6YONy4D4bBMv93_Fw8PoQ=.cd151795-54b6-4990-b9b6-464fc754bfe8@github.com>
 <0Dr860QgmZaGHq1QGgz5bqKLpiwVSZL-lDOV1JNjkdk=.1c09c464-e9cd-4f66-88c1-2b97e3a9f7ce@github.com>
 <nmGwV8kYDctpXErytPvNh0RXLD8GQ4fzVICrEvaTeyI=.3da3ed31-c2ad-478a-ac8f-cc332946f504@github.com>
 <DEanpPm3VDyhXOjQSH7VzYAvmJrAgm-fq6bwfidxdIE=.60c1a580-7ebb-4d71-8e32-c068cbe88547@github.com>
Message-ID: <WTsmdR-qWgwKFRVYlQcS3BK985xJnvwEtIMoL-2XcDI=.a487e628-4953-4003-849b-8752f1a08374@github.com>

On Wed, 25 Sep 2024 20:30:28 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> If JVM_StartThread is only called by Thread.start0, then how about putting the new lock in Java instead?
>> 
>> What benefit do you see of that? One downside is that the lock will be coarser than necessary. I'd rather keep the lock as tightly scoped as possible.
>
>> > If JVM_StartThread is only called by Thread.start0, then how about putting the new lock in Java instead?
>> 
>> What benefit do you see of that? One downside is that the lock will be coarser than necessary. I'd rather keep the lock as tightly scoped as possible.
> 
> I just thought it would be simpler, but I see your point.  A coarser lock will serialize more of the native path.

@dean-long -- do you have any more comments about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/21111#issuecomment-2395463996

From shade at openjdk.org  Sun Oct  6 14:43:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 6 Oct 2024 14:43:09 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

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

  More precise bit-unmasks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/c3338302..cf808b9a

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

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

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

From shade at openjdk.org  Sun Oct  6 14:43:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 6 Oct 2024 14:43:37 GMT
Subject: RFR: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
In-Reply-To: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
References: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
Message-ID: <tf33vzUMdIu9bKnH4bZIevIvA0tuS_S703K5N_aYOIM=.2f3b2bad-7c49-4d30-8295-bc832f5d234f@github.com>

On Fri, 4 Oct 2024 13:04:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.
> 
> Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.
> 
> #### Testing
> - tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
> - tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

Looks fine to me, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21356#pullrequestreview-2350547031

From shade at openjdk.org  Sun Oct  6 14:58:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 6 Oct 2024 14:58:42 GMT
Subject: RFR: 8336103: Clean up confusing Method::is_initializer [v4]
In-Reply-To: <ZkX0GJUUXe-unxZGENazMqmH7xXv7wtavvH1YagJSiM=.6d6dc39e-4cb3-4f77-92e1-13858a27d19d@github.com>
References: <bCys51DaXKl64gEdV10WAKffH5KEwwHZH3oIYBHmL38=.0568b7d5-1b38-40bd-8932-07050c69bd8d@github.com>
 <ZkX0GJUUXe-unxZGENazMqmH7xXv7wtavvH1YagJSiM=.6d6dc39e-4cb3-4f77-92e1-13858a27d19d@github.com>
Message-ID: <MSl638-f3sOPk-pEg2zZPmC5PhrbpurJXxP5PFVtCfk=.5bb3e59a-5053-4026-a447-1ae208c2229d@github.com>

On Fri, 27 Sep 2024 09:57:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> All around Hotspot, we have calls to `method->is_initializer()`. That method tests for both instance and static initializers. In many cases, the uses imply we actually want to test for constructor, not static initializer. Sometimes we filter explicitly for `!m->is_static()`, sometimes we don't.  At this point, I think the best way to prevent future accidents is to remove the confusing `is_initializer`.
>> 
>> The behavioral changes have been handled by already integrated PRs, see the links in JBS. The changes left here are not (supposed to be) changing the behavior.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fix

Thank you! I think I need another formal Reviewer comment before I can integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/20120#issuecomment-2395469026

From fyang at openjdk.org  Mon Oct  7 03:19:34 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 7 Oct 2024 03:19:34 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
Message-ID: <HDavm10mHEt4uOkSOio5CZKLZ5UsKHUTrBJe6So7qmE=.fd4ca0a0-4ea8-469c-9baa-d5f6bcc69a56@github.com>

On Sat, 5 Oct 2024 10:03:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
> 
> Additonal testing:
> 
> - [x] riscv native build with slowdebug and fastdebug
> - [x] jtreg tier1 test with release build

Seems fine to me. One minor question though.

src/hotspot/cpu/riscv/methodHandles_riscv.cpp line 4:

> 2:  * Copyright (c) 1997, 2024, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2014, Red Hat Inc. All rights reserved.
> 4:  * Copyright (c) 2020, 2024, Huawei Technologies Co., Ltd. All rights reserved.

Should we update other vendor's copyright year?

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

PR Review: https://git.openjdk.org/jdk/pull/21370#pullrequestreview-2350763545
PR Review Comment: https://git.openjdk.org/jdk/pull/21370#discussion_r1789418876

From syan at openjdk.org  Mon Oct  7 04:05:53 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 04:05:53 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code [v2]
In-Reply-To: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
Message-ID: <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
> 
> Additonal testing:
> 
> - [x] riscv native build with slowdebug and fastdebug
> - [x] jtreg tier1 test with release build

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

  revert copyright year change of Huawei

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21370/files
  - new: https://git.openjdk.org/jdk/pull/21370/files/1ba36f6d..f18d6fe3

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

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

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

From syan at openjdk.org  Mon Oct  7 04:05:53 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 04:05:53 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code [v2]
In-Reply-To: <HDavm10mHEt4uOkSOio5CZKLZ5UsKHUTrBJe6So7qmE=.fd4ca0a0-4ea8-469c-9baa-d5f6bcc69a56@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
 <HDavm10mHEt4uOkSOio5CZKLZ5UsKHUTrBJe6So7qmE=.fd4ca0a0-4ea8-469c-9baa-d5f6bcc69a56@github.com>
Message-ID: <CA96IuAsO49LC3T4bzOglYp8276R8UH4gI0RZ6r6K4c=.fc11bf0f-c968-4e86-ad52-33dcf1632047@github.com>

On Mon, 7 Oct 2024 03:15:42 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert copyright year change of Huawei
>
> src/hotspot/cpu/riscv/methodHandles_riscv.cpp line 4:
> 
>> 2:  * Copyright (c) 1997, 2024, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2014, Red Hat Inc. All rights reserved.
>> 4:  * Copyright (c) 2020, 2024, Huawei Technologies Co., Ltd. All rights reserved.
> 
> Should we update other vendor's copyright year?

Okey, the copyright year change of other vendor has been reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21370#discussion_r1789448193

From thartmann at openjdk.org  Mon Oct  7 05:52:41 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Oct 2024 05:52:41 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <MsPOYHq_-sRol1vs_8uBPp2b2DuCSHQRLzTPWH8V1mg=.bfbce9b8-c16c-46bc-90af-d9185255409e@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
 <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>
 <MsPOYHq_-sRol1vs_8uBPp2b2DuCSHQRLzTPWH8V1mg=.bfbce9b8-c16c-46bc-90af-d9185255409e@github.com>
Message-ID: <xSCUM-L7cSdzEVpm1hfdTs03wHLUX_dIgPHUkwI-23A=.895766f0-4e78-4a2f-855c-13d0cde4e279@github.com>

On Thu, 3 Oct 2024 16:54:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:
>> 
>>> 1: //
>>> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>> 
>> Drive-by comment: The `// *` format looks weird.
>
> Actually, this constellation of single-line comments should be replaced with a multi-line comment block. The fix is now in my (unpublished) patch queue, thanks.

Yes, that's what I meant. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1789539477

From thartmann at openjdk.org  Mon Oct  7 05:53:34 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Oct 2024 05:53:34 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <LscydtVll9revP9tphwa7YgX94eSZ96cftG4U7vWksc=.709df707-e1fd-4307-b78c-d61670e98648@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

Testing looks good. I leave it to the original reviewers to re-review this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21286#issuecomment-2395964292

From thartmann at openjdk.org  Mon Oct  7 07:06:56 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Oct 2024 07:06:56 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type and
 let legitimize_address() fix out-of-range operands
Message-ID: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>

Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.

Thanks,
Tobias

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

Commit messages:
 - Revert "8338442: AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands"

Changes: https://git.openjdk.org/jdk/pull/21381/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21381&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341612
  Stats: 373 lines in 7 files changed: 250 ins; 12 del; 111 mod
  Patch: https://git.openjdk.org/jdk/pull/21381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21381/head:pull/21381

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

From chagedorn at openjdk.org  Mon Oct  7 07:06:56 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 7 Oct 2024 07:06:56 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
Message-ID: <YLcpNj0VmEhNe3yyyHLN8jFsPXqfQ417xxZY42Em2g0=.40910040-bef9-4dc2-b016-31aa9f3c2e2f@github.com>

On Mon, 7 Oct 2024 06:58:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
> 
> Thanks,
> Tobias

That's reasonable, looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21381#pullrequestreview-2351055864

From thartmann at openjdk.org  Mon Oct  7 07:06:56 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Oct 2024 07:06:56 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
Message-ID: <hc4j9kheaHJ7fbBZ2DvouXQQ3EmxeGmq4FOdDYeEhlM=.db504189-f1f9-4abb-8469-898689fca9f8@github.com>

On Mon, 7 Oct 2024 06:58:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
> 
> Thanks,
> Tobias

Thanks for the review, Christian!

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2396081970

From shade at openjdk.org  Mon Oct  7 07:08:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Oct 2024 07:08:40 GMT
Subject: Integrated: 8338379: Accesses to class init state should be properly
 synchronized
In-Reply-To: <HLfZCSxJFLlREAilMOVXH2oAIfplir9uiJhah5eDxAk=.9f8667e7-1b38-453f-a4ed-c7237e5c06fc@github.com>
References: <HLfZCSxJFLlREAilMOVXH2oAIfplir9uiJhah5eDxAk=.9f8667e7-1b38-453f-a4ed-c7237e5c06fc@github.com>
Message-ID: <ft7u_HX9GBhueBoLeF5vVJ6R0x9dq8PQjo--Th443zM=.3da246f9-53f3-4582-b63a-bd9e8f9ee0c6@github.com>

On Fri, 20 Sep 2024 14:02:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for the discussion. We have not seen a clear evidence this is _the_ problem in the field, neither we were able to come up with a reproducer. We have found this gap by inspecting the code, while chasing a production bug.
> 
> In short, `InstanceKlass::_init_state` is used as the "witness" for initialized class state. When class initialization completes, it needs to publish the class state by writing `_init_state = _fully_initialized` with release semantics.
> 
> Various accessors that poll `IK::_init_state`, looking for class initialization to complete, need to read the field with acquire semantics. This is where the change fans out, touching VM, interpreter and compiler paths that e.g. implement clinit barriers. In some cases in assembler code, we can rely on hardware memory model to do what we need (i.e. acquire barriers/fences are nops).
> 
> I made the best _guess_ what ARM32, S390X, PPC64, RISC-V code should look like, based on what related code does for volatile loads. It would be good if port maintainers could sanity-check those.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`
>  - [x] GHA to test platform buildability + adhoc platform cross-compilation

This pull request has now been integrated.

Changeset: 6600161a
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6600161ad46fe5b1e742409481bf225cd87f07c9
Stats:     32 lines in 17 files changed: 15 ins; 0 del; 17 mod

8338379: Accesses to class init state should be properly synchronized

Reviewed-by: mdoerr, dholmes, coleenp, fyang, amitkumar

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

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

From shade at openjdk.org  Mon Oct  7 07:12:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Oct 2024 07:12:37 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
Message-ID: <U94RybBZYLr6lYZpwpLxegMOjzqHWz9rlhlcJQtcBYQ=.12f49b83-2966-4137-a09d-9e2480877787@github.com>

On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More precise bit-unmasks

Tests pass with the new change. I eyeballed G1 perfasm output on new benchmark, and there are no barriers in sight as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2396092920

From thartmann at openjdk.org  Mon Oct  7 08:00:45 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Oct 2024 08:00:45 GMT
Subject: Integrated: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX
 type and let legitimize_address() fix out-of-range operands
In-Reply-To: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
Message-ID: <Qyl2CEe5XL7Nd5takYs6SucZJhhRz6y_l5quijgjuk0=.fcbf4756-7afc-4b70-840b-d0438f801c48@github.com>

On Mon, 7 Oct 2024 06:58:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 92186a27
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92186a27743732964b5cf3be339fd568da2aa4ba
Stats:     373 lines in 7 files changed: 250 ins; 12 del; 111 mod

8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

Reviewed-by: chagedorn

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

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

From tschatzl at openjdk.org  Mon Oct  7 08:13:36 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Oct 2024 08:13:36 GMT
Subject: RFR: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
In-Reply-To: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
References: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
Message-ID: <MS5GAjrQKLpDmAmDFC2ItpQmBv6De1rr9-8Bf6LVwlE=.25a3aba5-af72-4153-a1df-ba86f9d1f516@github.com>

On Fri, 4 Oct 2024 13:04:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.
> 
> Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.
> 
> #### Testing
> - tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
> - tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21356#pullrequestreview-2351222607

From luhenry at openjdk.org  Mon Oct  7 08:18:38 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 7 Oct 2024 08:18:38 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code [v2]
In-Reply-To: <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
 <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>
Message-ID: <kf9uHCoeF1MqKUFU5ZHsJrBqKYx3UkAvxvjPG99sNAA=.ff62b058-0409-4a3b-8b1c-423074d58c64@github.com>

On Mon, 7 Oct 2024 04:05:53 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
>> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
>> 
>> Additonal testing:
>> 
>> - [x] riscv native build with slowdebug and fastdebug
>> - [x] jtreg tier1 test with release build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert copyright year change of Huawei

Marked as reviewed by luhenry (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21370#pullrequestreview-2351233216

From eosterlund at openjdk.org  Mon Oct  7 08:18:41 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 7 Oct 2024 08:18:41 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
Message-ID: <1wozINQzLtWk9n5DJDqTW_BBQgwmOGQpJAfOJR70uC0=.7668e905-c863-4e69-bca1-695de43cb80a@github.com>

On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More precise bit-unmasks

One last thing...

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 342:

> 340:   }
> 341:   if ((on_weak || on_phantom) && no_keepalive) {
> 342:     // Be extra paranoid around this path. Only accept null stores,

I think there might be some orthogonal stuff that is unnecessarily mixed up here. When no_keepalive is manually specified, then we shouldn't do the pre-write barrier, regardless of reference strength. Similarly, when the new value is null, we don't need to perform the post write barrier, regardless of reference strength. Roberto added some code in refine_barrier_by_new_val_type that already *should* take care of the latter part. It allows types to flow around a bit, and then checks if the type of the new value is provably null, and then removes the post write barrier. The existing logic for that should be strictly more powerful than the new check you added, I think.

Based on the above explanation, I think I'm proposing this block is replaced with this simpler condition:

if (no_keepalive) {
  access.set_barrier_data(access.barrier_data() & ~G1C2BarrierPre);
}

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

Changes requested by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2351232319
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1789742277

From lucy at openjdk.org  Mon Oct  7 08:27:43 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 7 Oct 2024 08:27:43 GMT
Subject: RFR: 8339220: [s390x] TestIfMinMax.java failure [v3]
In-Reply-To: <Lg0gC_iYoB-52Lv20IOrCvNC9Khv6AoCpajxZlM5dvc=.ecb1820f-783a-4ad1-b278-0da25dbbbaf7@github.com>
References: <5DtK26dlgE6Aacoldf6_VEDVfSzlym7EC6FW1O-iwiE=.218dba46-f28d-4765-9dd3-0d9043838b61@github.com>
 <Lg0gC_iYoB-52Lv20IOrCvNC9Khv6AoCpajxZlM5dvc=.ecb1820f-783a-4ad1-b278-0da25dbbbaf7@github.com>
Message-ID: <taSUqHpUTr39P-EPef6TP7I2VNqmz2qNrPX658Pu6Es=.2c31c8e0-802d-4786-bbdb-1b83429775a1@github.com>

On Thu, 26 Sep 2024 13:03:12 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This test enables Conditional moves for long operands for s390x. Which fixes the test-case.
>> 
>> Ran tier1 and not saw any regression.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from Lutz

Looks good now.
Sorry for the delay, and thanks for the review reminder. This PR flew below radar coverage.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21198#pullrequestreview-2351254728

From rcastanedalo at openjdk.org  Mon Oct  7 08:28:38 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 7 Oct 2024 08:28:38 GMT
Subject: RFR: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
In-Reply-To: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
References: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
Message-ID: <DzGhpyaAi0xHx72KjCjpu9AMn1llMbCfyl26I3UKCTs=.b786241b-5ef8-46df-bba3-ed3a85ddf579@github.com>

On Fri, 4 Oct 2024 13:04:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.
> 
> Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.
> 
> #### Testing
> - tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
> - tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

Thanks Aleksey, Martin, Kim, and Thomas for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/21356#issuecomment-2396252478

From rcastanedalo at openjdk.org  Mon Oct  7 08:31:41 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 7 Oct 2024 08:31:41 GMT
Subject: Integrated: 8341525: G1: use bit clearing to remove tightly-coupled
 initialization store pre-barriers
In-Reply-To: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
References: <UpStgVdsYdose0-jbE_P_F78YI7Ohyi2oZNMP-aY3_c=.b503ef44-3fa5-4d92-b370-9578dc7b9a50@github.com>
Message-ID: <t5HVWhAvxgM0_h8QFfY3SzwVOF4rKKcVtQhem7RqglE=.1b008753-26bd-4452-8b4d-6c5b144d8528@github.com>

On Fri, 4 Oct 2024 13:04:52 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This cleanup applies bit clearing rather than bit toggling to clear the G1 pre-barrier bit of tightly-coupled initializing stores when `ReduceInitialCardMarks` is disabled. Although using bit toggling is correct in this context (see [JBS issue description](https://bugs.openjdk.org/browse/JDK-8341525)), bit clearing communicates more clearly (no pun intended) the intent of setting the pre-barrier bit to zero regardless of its previous value. No new tests are added because there already exist tests that exercise this case, for example `testCloneObjectWithFewFields` in `test/hotspot/jtreg/compiler/gcbarriers/TestG1BarrierGeneration.java`.
> 
> Thanks to @shipilev for [reporting](https://github.com/openjdk/jdk/pull/19746#discussion_r1786573527) this maintainability issue.
> 
> #### Testing
> - tier1-5 (linux-x64, linux-aarch64, windows-x64, macosx-x64, and macosx-aarch64; release and debug mode).
> - tier1-3 with `-XX:-ReduceInitialCardMarks` (linux-x64; debug mode).

This pull request has now been integrated.

Changeset: 81ebbb24
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81ebbb2463df8b014bb209dc4028668fc78e8327
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8341525: G1: use bit clearing to remove tightly-coupled initialization store pre-barriers

Reviewed-by: mdoerr, kbarrett, shade, tschatzl

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

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

From fyang at openjdk.org  Mon Oct  7 08:32:36 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 7 Oct 2024 08:32:36 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code [v2]
In-Reply-To: <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
 <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>
Message-ID: <FTb-8a1SdFhWHyQBVrIref0s4Ce3bpVE03NOfCwaT3k=.679ad1ff-6f98-4cd4-83b4-62095fae74d5@github.com>

On Mon, 7 Oct 2024 04:05:53 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
>> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
>> 
>> Additonal testing:
>> 
>> - [x] riscv native build with slowdebug and fastdebug
>> - [x] jtreg tier1 test with release build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert copyright year change of Huawei

Update change looks good.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21370#pullrequestreview-2351267293

From syan at openjdk.org  Mon Oct  7 08:42:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 08:42:41 GMT
Subject: RFR: 8341562: RISC-V: Generate comments in -XX:+PrintInterpreter
 to link to source code [v2]
In-Reply-To: <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
 <lSg1fKS_dfwf94RTNHSk3tHOwcHAiPOY7QiUGq8dlbM=.402a5bd5-2f9b-4216-bdc5-15a482df2554@github.com>
Message-ID: <9BDDvlih8Qww44tQSkNyK4awPDE24UcfDqDWI7rhB3o=.22230af0-d332-455a-9577-5d1b54701fe3@github.com>

On Mon, 7 Oct 2024 04:05:53 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
>> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
>> 
>> Additonal testing:
>> 
>> - [x] riscv native build with slowdebug and fastdebug
>> - [x] jtreg tier1 test with release build
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert copyright year change of Huawei

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21370#issuecomment-2396279129

From syan at openjdk.org  Mon Oct  7 08:42:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 08:42:41 GMT
Subject: Integrated: 8341562: RISC-V: Generate comments in
 -XX:+PrintInterpreter to link to source code
In-Reply-To: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
References: <sFfS40zxLShsrSaGVPTZ4GYAA7hu3yjNkVeZ_eUot00=.89437422-2fe3-44f9-ae79-c8c12ea57168@github.com>
Message-ID: <hBX8F3JnhnGxhKgCYWY7QMuxm0WW2_qTsoQ_YBIolHg=.80744761-036c-4c1f-9b4a-d47f96a3ab19@github.com>

On Sat, 5 Oct 2024 10:03:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on RISC-V either.
> 
> Additonal testing:
> 
> - [x] riscv native build with slowdebug and fastdebug
> - [x] jtreg tier1 test with release build

This pull request has now been integrated.

Changeset: 747a3fa3
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/747a3fa31d9a9512475615c91d2ee9c2d2a94e8e
Stats:     23 lines in 3 files changed: 11 ins; 0 del; 12 mod

8341562: RISC-V: Generate comments in -XX:+PrintInterpreter to link to source code

Reviewed-by: fyang, luhenry

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

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

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 aph at openjdk.org  Mon Oct  7 09:05:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Oct 2024 09:05:39 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
Message-ID: <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>

On Mon, 7 Oct 2024 06:58:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
> 
> Thanks,
> Tobias

Oh dear. it's a shame I never got to see the bug report at the time it was filed, but it was just marked as a C2 bug.
The right thing to do, I think, is to make the segfault handler code a bit smarter. We'll need to go through the process again, with the original fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2396340364

From adinn at openjdk.org  Mon Oct  7 09:09:36 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Oct 2024 09:09:36 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <vyemLe_tJz9pwlZ2RN7xWPMR18Zy4eXLqmkkdb1FWJ4=.c3acf0f0-77c8-4c8f-a85f-637e4f4af799@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

Thanks for fixing this, @TobiHartmann.
New version looks good.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21286#pullrequestreview-2351356491

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 anton.seoane.ampudia at oracle.com  Mon Oct  7 09:11:49 2024
From: anton.seoane.ampudia at oracle.com (Anton Seoane Ampudia)
Date: Mon, 7 Oct 2024 09:11:49 +0000
Subject: [External] : Re: 8340363: Tag-specific default decorators for
 UnifiedLogging
In-Reply-To: <DM4PR10MB74759F164D6F890717531E84AF772@DM4PR10MB7475.namprd10.prod.outlook.com>
References: <DM4PR10MB7475D31B106FB945C71A0C71AF6B2@DM4PR10MB7475.namprd10.prod.outlook.com>
 <ac081f30-4645-4964-88e5-932593ab5272@oracle.com>
 <DM4PR10MB7475A31DE03F7EC290708654AF762@DM4PR10MB7475.namprd10.prod.outlook.com>
 <70804A3C-13CE-4F83-861B-BA280C7EEB47@kodewerk.com>
 <DM4PR10MB74759F164D6F890717531E84AF772@DM4PR10MB7475.namprd10.prod.outlook.com>
Message-ID: <DM4PR10MB7475DCE2EC98B8EDFAD21568AF7D2@DM4PR10MB7475.namprd10.prod.outlook.com>

After some review and discussion, I am closing the original PR 8340363: Tag-specific default decorators for UnifiedLogging<https://github.com/openjdk/jdk/pull/20988>
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>.

Thanks,
Ant?n

From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Anton Seoane Ampudia <anton.seoane.ampudia at oracle.com>
Date: Tuesday, 1 October 2024 at 13:44
To: Kirk Pepperdine <kirk at kodewerk.com>
Cc: David Holmes <david.holmes at oracle.com>, hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: Re: [External] : Re: 8340363: Tag-specific default decorators for UnifiedLogging
Hello,

This proposal is targeted only for those cases where Hotspot developers agree on undecorated output. For example, C2 developers with jit+inlining. Every other use of UL except for those specific (and previously socialized and agreed-upon) cases will keep being the same as it is right now.

In summary, this is more of an ad-hoc proposal for the cases where some specific uses of -Xlog are always accompanied with ::none

Regards,
Ant?n

From: Kirk Pepperdine <kirk at kodewerk.com>
Date: Monday, 30 September 2024 at 18:07
To: Anton Seoane Ampudia <anton.seoane.ampudia at oracle.com>
Cc: David Holmes <david.holmes at oracle.com>, hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: [External] : Re: 8340363: Tag-specific default decorators for UnifiedLogging


So to be clear, is the proposal now to just drop the default decorators,
rather than allowing them to be replaced with alternate defaults? If
that is the case then it is the same as writing:

-Xlog:A+B::none

and I don't really see much value in that. But I wouldn't oppose it.

I would. At a minimum you need a timestamp.

Allowing new defaults gives more flexibility - but obviously the
developers using the specific tag combinations have to agree on what
defaults to set.

At the moment to get a reasonable GC log for G1, one needs to use the following setting.

-Xlog:gc*,gc+ref=debug,gc+phases=debug,gc+age=debug,safepoint:file=gc.log

Also, the ?noise to signal? ratio in these logs is exceptionally high.

Kind regards,
Kirk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241007/2753880e/attachment-0001.htm>

From luhenry at openjdk.org  Mon Oct  7 09:19:39 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 7 Oct 2024 09:19:39 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <4oXN9TokV6OkJe4BMIF4GBI7g8LA8KZTiZwSksTU_Qw=.6f3da3ea-63f0-472b-8505-d736ab959aa3@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <4oXN9TokV6OkJe4BMIF4GBI7g8LA8KZTiZwSksTU_Qw=.6f3da3ea-63f0-472b-8505-d736ab959aa3@github.com>
Message-ID: <jOepSJ6WBTW8h4aGfEQJmtUZM_hOWQ-yabgAaoVMA-0=.47e478e4-0726-4dd6-aa18-e14a748fcdf2@github.com>

On Mon, 30 Sep 2024 10:33:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bits > 512

Marked as reviewed by luhenry (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2351378119

From duke at openjdk.org  Mon Oct  7 09:21:39 2024
From: duke at openjdk.org (duke)
Date: Mon, 7 Oct 2024 09:21:39 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <WFu4sBtELl-RXrgrWd_M-hSzENaWuSTzGgH3EnE75lE=.83e70090-be2b-4217-948f-1f7a39805334@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

@mikabl-arm 
Your change (at version 90e682289e4149e7d17540232ca1cd589be08a89) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21286#issuecomment-2396376312

From rcastanedalo at openjdk.org  Mon Oct  7 09:29:38 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 7 Oct 2024 09:29:38 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
 <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
Message-ID: <XjNsxOdQFM6m0UuBtiq4lPm7cTyahmfsrZbFss2Z_JU=.ddc9dd9e-6844-4ef2-a646-f2fd96e8758e@github.com>

On Mon, 7 Oct 2024 09:03:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
>> 
>> Thanks,
>> Tobias
>
> Oh dear. it's a shame I never got to see the bug report at the time it was filed, but it was just marked as a C2 bug.
> The right thing to do, I think, is to make the segfault handler code a bit smarter. We'll need to go through the process again, with the original fix.

Hi @theRealAph, note that there are other concerns about [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) besides risk of implicit null check bugs, see https://bugs.openjdk.org/browse/JDK-8340646?focusedId=14709872&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14709872.

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2396395720

From mli at openjdk.org  Mon Oct  7 09:50:16 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 7 Oct 2024 09:50:16 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
Message-ID: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
> 
> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
> 
> ### Test
> test/jdk/jdk/incubator/vector
> 
> ### Performance
> data on bananapi
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743
> Double128Vector....

Hamlin Li 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 master
 - bits > 512
 - fix test macro
 - check frm after sleef call
 - use all arg v regs
 - misc
 - refine comment
 - comment
 - modify cflags style
 - fix make warning
 - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

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

Changes: https://git.openjdk.org/jdk/pull/21083/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21083&range=09
  Stats: 289 lines in 14 files changed: 241 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/21083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21083/head:pull/21083

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

From aph at openjdk.org  Mon Oct  7 10:01:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Oct 2024 10:01:39 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
 <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
Message-ID: <bkhJv3G4hroa4EfacsA1-MDzAVOOxf9Km0-4H-r2WVY=.ad5caa40-77ef-41b3-9487-195065a00945@github.com>

On Mon, 7 Oct 2024 09:03:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Let's backout [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) for now, given [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646) and [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437). Backout applies cleanly.
>> 
>> Thanks,
>> Tobias
>
> Oh dear. it's a shame I never got to see the bug report at the time it was filed, but it was just marked as a C2 bug.
> The right thing to do, I think, is to make the segfault handler code a bit smarter. We'll need to go through the process again, with the original fix.

> Hi @theRealAph, note that there are other concerns about [JDK-8338442](https://bugs.openjdk.org/browse/JDK-8338442) besides risk of implicit null check bugs, see https://bugs.openjdk.org/browse/JDK-8340646?focusedId=14709872&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14709872.

I see. However, the root cause of the problem is assumptions elsewhere that output code has a particular sequence of instructions, surely? There are many ways that AArch64 can address the same memory, and there has never been any guarantee that a particular sequence of instructions will be used. We already know that C2 will generate either `ldr r1 [reg, offset]` or `add r2, reg,offset; ldr r1 [r2]`, or many other possibilities. This is all normal stuff that an optimizing compiler does.

Sure, if we have a particular pattern that must do something special that needs to generate an exact known sequence of instructions, we can handle it separately from general memory accesses.

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2396467211

From rehn at openjdk.org  Mon Oct  7 10:46:42 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 7 Oct 2024 10:46:42 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
Message-ID: <hip40jsy4_MgNUr5ClXqgqljH-8uGQ8VCNVM24bDFuM=.c9e5022d-aeba-4923-8760-76c57489038d@github.com>

On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li 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 master
>  - bits > 512
>  - fix test macro
>  - check frm after sleef call
>  - use all arg v regs
>  - misc
>  - refine comment
>  - comment
>  - modify cflags style
>  - fix make warning
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

Not a in-depth review, but looks good.
Thanks for your work, and patience!

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2351572045

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 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 bulasevich at openjdk.org  Mon Oct  7 13:21:57 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Mon, 7 Oct 2024 13:21:57 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
Message-ID: <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>

> With this change, I have adjusted the default settings for CodeCacheSegmentSize and CodeEntryAlignment for AARCH and ARM32. The main goal is to improve code density by reducing the number of wasted bytes (approximately **4%** waste). Improving code density may also have the side effect of boosting performance in large applications
> 
> Each nmethod occupies a number of code cache segments (minimum allocation blocks). Since the size of an nmethod is not aligned to 128 bytes, the last occupied segment is half empty. Reducing the size of the code cache segments correspondingly minimizes waste. However, we should be careful about reducing the CodeCacheSegmentSize too much, as smaller segment sizes will increase the overhead of the CodeHeap::_segmap bitmap. A CodeCacheSegmentSize of 64 seems to be an optimal balance.
> 
> The current large default value for CodeCacheSegmentSize (64+64) was historically introduced with the comment "Tiered compilation has large code-entry alignment" which doesn't make much sense to me. The history of this comment and value is as follows:
> - The PPC port was introduced with CodeEntryAlignment=128 (recently reduced to 64: https://github.com/openjdk/jdk/commit/09a78b5d) and CodeCacheSegmentSize was adjusted accordingly for that platform.
> - Soon after, the 128-byte alignment was applied to all platforms to hide a debug mode warning (https://github.com/openjdk/jdk/commit/e8bc971d). Despite the change (and Segmented Code Cache introduced later), the warning can still be reproduced today using the -XX:+VerifyCodeCache fastdebug option in large applications (10K nmethods ~ 10K free blocks in between them).
> 
> I believe it is time to remove the comment and update the default value.
> 
> I also suggest updating the default CodeEntryAlignment value for AARCH. The current setting is much larger than for x86 and was likely based on the typical cache line size of 64 bytes. Cortex-A57, A72 architecture software optimisation guides recommend a 32-byte alignment for subroutine entry points. Neoverse architecture software optimisation guides do not mention recommended entry point alignment.
> 
> For reference, the default [function_align setting in GCC](https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/cortexa72.h#L44) is typically 16 or 32 bytes, depending on the target architecture.
> 
> Hotspot performance tests with -XX:CodeCacheSegmentSize=64 and -XX:CodeEntryAlignment=16 options showed the following results:
> - No performance impact on ...

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

  Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20864/files
  - new: https://git.openjdk.org/jdk/pull/20864/files/10ecb900..0939006d

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

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

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

From eastigeevich at openjdk.org  Mon Oct  7 13:21:57 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 7 Oct 2024 13:21:57 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
Message-ID: <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>

On Mon, 7 Oct 2024 13:18:32 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> With this change, I have adjusted the default settings for CodeCacheSegmentSize and CodeEntryAlignment for AARCH and ARM32. The main goal is to improve code density by reducing the number of wasted bytes (approximately **4%** waste). Improving code density may also have the side effect of boosting performance in large applications
>> 
>> Each nmethod occupies a number of code cache segments (minimum allocation blocks). Since the size of an nmethod is not aligned to 128 bytes, the last occupied segment is half empty. Reducing the size of the code cache segments correspondingly minimizes waste. However, we should be careful about reducing the CodeCacheSegmentSize too much, as smaller segment sizes will increase the overhead of the CodeHeap::_segmap bitmap. A CodeCacheSegmentSize of 64 seems to be an optimal balance.
>> 
>> The current large default value for CodeCacheSegmentSize (64+64) was historically introduced with the comment "Tiered compilation has large code-entry alignment" which doesn't make much sense to me. The history of this comment and value is as follows:
>> - The PPC port was introduced with CodeEntryAlignment=128 (recently reduced to 64: https://github.com/openjdk/jdk/commit/09a78b5d) and CodeCacheSegmentSize was adjusted accordingly for that platform.
>> - Soon after, the 128-byte alignment was applied to all platforms to hide a debug mode warning (https://github.com/openjdk/jdk/commit/e8bc971d). Despite the change (and Segmented Code Cache introduced later), the warning can still be reproduced today using the -XX:+VerifyCodeCache fastdebug option in large applications (10K nmethods ~ 10K free blocks in between them).
>> 
>> I believe it is time to remove the comment and update the default value.
>> 
>> I also suggest updating the default CodeEntryAlignment value for AARCH. The current setting is much larger than for x86 and was likely based on the typical cache line size of 64 bytes. Cortex-A57, A72 architecture software optimisation guides recommend a 32-byte alignment for subroutine entry points. Neoverse architecture software optimisation guides do not mention recommended entry point alignment.
>> 
>> For reference, the default [function_align setting in GCC](https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/cortexa72.h#L44) is typically 16 or 32 bytes, depending on the target architecture.
>> 
>> Hotspot performance tests with -XX:CodeCacheSegmentSize=64 and -XX:CodeEntryAlignment=16 options showed the following result...
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 263:

> 261:     }
> 262:     if (FLAG_IS_DEFAULT(CodeEntryAlignment)) {
> 263:       FLAG_SET_DEFAULT(CodeEntryAlignment, 32);

Why only for V1/V2? What about N1/N2?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1790211802

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 fgao at openjdk.org  Mon Oct  7 13:35:38 2024
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 7 Oct 2024 13:35:38 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
 <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
Message-ID: <6CwoWlnLh3PxCSnVsMVAnfB_fM1F_bSmNf396fYzKG4=.5018f286-40e6-469c-bc66-e321b25cb450@github.com>

On Mon, 7 Oct 2024 09:03:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The right thing to do, I think, is to make the segfault handler code a bit smarter. We'll need to go through the process again, with the original fix.

Hi @theRealAph , with the original fix, what do you think of the idea that we just skip implicit null check if we need extra lea to handle some special memory access on `aarch64`?  Suppose these special memory accesses are uncommon.


diff --git a/src/hotspot/share/opto/lcm.cpp b/src/hotspot/share/opto/lcm.cpp
index 3c6de96074a..aaa50ca15b7 100644
--- a/src/hotspot/share/opto/lcm.cpp
+++ b/src/hotspot/share/opto/lcm.cpp
@@ -261,6 +261,14 @@ void PhaseCFG::implicit_null_check(Block* block, Node *proj, Node *val, int allo
       continue;
     }
 
+    // Check if the offset is addressable. On aarch64 platforms, if the offset is
+    // not addressable, C2 will emit an extra lea before the address can be used.
+    // But ImplicitNullChecks assumes that the first emitted instruction is the
+    // implicit null check pc.
+    if (!Matcher::offset_is_addressable(mach)) {
+      continue;
+    }
+
     // check if the offset is not too high for implicit exception
     {
       intptr_t offset = 0;

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2396950342

From anton.seoane.ampudia at oracle.com  Mon Oct  7 13:50:12 2024
From: anton.seoane.ampudia at oracle.com (Anton Seoane Ampudia)
Date: Mon, 7 Oct 2024 13:50:12 +0000
Subject: 8288298: Resolve parsing ambiguities in UL
Message-ID: <DM4PR10MB74750042939F85C055C7D36FAF7D2@DM4PR10MB7475.namprd10.prod.outlook.com>

Hi all,

During the migration of compiler logs to the UnifiedLogging framework, I have observed that multiline logging does not include decorators for all the lines, instead only adding them for the first one and leaving the rest ?dangling?. I have found out that this is already a reported issue in JDK-8288298<https://bugs.openjdk.org/browse/JDK-8288298>, and written a tentative fix for it.

Some initial testing has been yielding insignificant performance changes with normal logging use cases, but before going forward with it I would like to request for comments and opinions on this. As far as I know, it would simplify somewhat ?manual reading? of logs, as everything starts right now in the same column, as well as automated parsing as there would be no line ambiguities. Copying from the JBS description:

> log_info(gc)("A\nB"); currently outputs:
> [0s][gc] A
> B
> And after this change will output:
> [0s][gc] A
> [1s][gc] B
>
> This change allows UL to be parsed by regex. Example for per-line parsing:
>
> ^\[ [^\[\]]* \] \[ [^\[\]]* \] (\[ [^\[\]]* \])?

It is worth mentioning that the special case with -Xlog:foldmultilines=true is not affected by this (i.e., if foldmultilines is set to true we do not carry out the line-by-line decorating).

Thanks,
Ant?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241007/4817c072/attachment-0001.htm>

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 bulasevich at openjdk.org  Mon Oct  7 14:13:37 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Mon, 7 Oct 2024 14:13:37 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
Message-ID: <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>

On Mon, 7 Oct 2024 13:18:32 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 263:
> 
>> 261:     }
>> 262:     if (FLAG_IS_DEFAULT(CodeEntryAlignment)) {
>> 263:       FLAG_SET_DEFAULT(CodeEntryAlignment, 32);
> 
> Why only for V1/V2? What about N1/N2?

There are reasons against the change for N1/N2
- Vladimir saw a regression when testing -XX:CodeEntryAlignment=16 on Ampere (Neoverse N1)
- with native codes experiment I found that code entry 64B is preferable on G2 (Neoverse N1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1790304217

From aph-open at littlepinkcloud.com  Mon Oct  7 14:18:51 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 7 Oct 2024 15:18:51 +0100
Subject: Request for discussion: rewrite invokeinterface dispatch, JMH
 benchmark
Message-ID: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>

I've been looking at rewriting invokeinterface, with a view to making
it more efficient and predictable on today's hardware, hopefully (near)
O(1) execution time. Also, we (again, hopefully) wouldn't need to
dynamically generate and manage itable stubs.

I've been trying a few approaches and don't yet have anything ready to
present, but I've come across an interesting anomaly in our
benchmarking. No matter what I did, and however bad my experiment, the
performance barely changed at all! It was as though my changes were
doing nothing, but eyeballing the generated code showed it was
different.

org.openjdk.bench.vm.compiler.InterfaceCalls.test2ndInt5Types looks
like this:

     as[0] = new FirstClass();
     as[1] = new SecondClass();
     as[2] = new ThirdClass();
     as[3] = new FourthClass();
     as[4] = new FifthClass();

     // ...

     int l = 0;

     @Benchmark
     public int test2ndInt5Types() {
         SecondInterface ai = (SecondInterface) as[l];
         l = ++ l % asLength;
         return ai.getIntSecond();
     }

That is to say, we serially step through an array, invoking the same
interface method on a different concrete class in turn.

The performance (Apple M1) is sparklingly good:

InterfaceCalls.test2ndInt5Types    6.026 ? 0.009      ns/op

But this is so fast as to be incredible, only 19.3 clocks per
invocation, including the control loop and the called method. A load
from L1 cache takes about 3-4 cycles, and there are several dependent
loads in the method lookup path. I suspected that because this
benchmark is unrealistically predictable, it does not fairly represent
real-world performance.

So, let's try mixing it up a little, and jump about rather than
cycling through the array:

     static final int scramble(int n) {
         int x = n;
         x ^= x << 13;
         x ^= x >>> 17;
         x ^= x << 5;
         return x == 0 ? 1 : x;
     }

     @Benchmark
     public int test2ndInt5TypesScrambled() {
         l = scramble(l);
         SecondInterface ai = (SecondInterface) as[Math.floorMod(l, asLength)];
         return ai.getIntSecond();
     }

This adds only a few instructions, but the measured performance is
radically different:

InterfaceCalls.test2ndInt5TypesScrambled  19.363 ? 0.084      ns/op

This is 62 clocks per invocation, and I suspect this result is far
more realistic. But is it really? Maybe invokeinterface calls are
generally very predictable, so the benchmark we already have is
representative.

Questions:

- Which benchmarks should we be optimizing for? I guess it could be
   the scrambled one, but maybe that would have no benefit if generally
   (or overwhelmingly often) invokeinterface is predictable.

- How many of the (micro-)benchmarks in HotSpot suffer from this
   problem? I'm guessing a lot of them, and perhaps it's partly because
   they were written in the days when speculative execution were less
   aggressive and branch prediction wasn't so good.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at openjdk.org  Mon Oct  7 14:26:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Oct 2024 14:26:39 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <6CwoWlnLh3PxCSnVsMVAnfB_fM1F_bSmNf396fYzKG4=.5018f286-40e6-469c-bc66-e321b25cb450@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
 <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
 <6CwoWlnLh3PxCSnVsMVAnfB_fM1F_bSmNf396fYzKG4=.5018f286-40e6-469c-bc66-e321b25cb450@github.com>
Message-ID: <Ag18LAT2JSCKSZ0KTXnm8wXBBUDp-fdqotfxHHgU5as=.10cc1305-86aa-44ab-8d0a-43fe36dd5089@github.com>

On Mon, 7 Oct 2024 13:33:12 GMT, Fei Gao <fgao at openjdk.org> wrote:

> > The right thing to do, I think, is to make the segfault handler code a bit smarter. We'll need to go through the process again, with the original fix.
> 
> Hi @theRealAph , with the original fix, what do you think of the idea that we just skip implicit null check if we need extra lea to handle some special memory access on `aarch64`? Suppose these special memory accesses are uncommon.

That looks reasonable and conservative. An alternative would be to adjust the implicit null check relocs to point to the actual trapping load.

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2397080494

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 mli at openjdk.org  Mon Oct  7 15:22:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 7 Oct 2024 15:22:39 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
Message-ID: <Ab7AQfYiDHrW_PQwEODVGTtlOltHcI5I5XTtkCp-wTA=.fe966350-88d6-45a2-bed1-aee27333646e@github.com>

On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li 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 master
>  - bits > 512
>  - fix test macro
>  - check frm after sleef call
>  - use all arg v regs
>  - misc
>  - refine comment
>  - comment
>  - modify cflags style
>  - fix make warning
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

Thanks everyone for your reviewing!

I'll push this later after I finally verify the performance with the latest patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2397229170

From adinn at openjdk.org  Mon Oct  7 15:32:40 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Oct 2024 15:32:40 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <o41FS6xp61m-_tdyAtWSZT0SNp_uXGDSWDKTRTbosas=.4b8716cf-0541-427f-ba5c-ffc499471738@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

@theRealAph Want to look at this?

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

PR Comment: https://git.openjdk.org/jdk/pull/21286#issuecomment-2397254018

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 aph at openjdk.org  Mon Oct  7 17:07:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 7 Oct 2024 17:07:39 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com>

On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

src/hotspot/cpu/aarch64/aarch64.ad line 16575:

> 16573:                          vRegD_V0 vtmp0, vRegD_V1 vtmp1, vRegD_V2 vtmp2, vRegD_V3 vtmp3,
> 16574:                          vRegD_V4 vtmp4, vRegD_V5 vtmp5, vRegD_V6 vtmp6, vRegD_V7 vtmp7,
> 16575:                          vRegD_V12 vtmp8, vRegD_V13 vtmp9, rFlagsReg cr)

It would be much better to pass all the vtemp registers to the `arrays_hashcode()`, then assert the registers are correct.

See `LOOKUP_SECONDARY_SUPERS_TABLE_REGISTERS` in `MacroAssembler`. It is asserted in the stub and in the inlined code. If this had been done in the patch that had to be backed out, it wouldn't have had to be backed out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21286#discussion_r1790587005

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 eric.caspole at oracle.com  Mon Oct  7 19:47:25 2024
From: eric.caspole at oracle.com (Eric Caspole)
Date: Mon, 7 Oct 2024 15:47:25 -0400
Subject: Request for discussion: rewrite invokeinterface dispatch, JMH
 benchmark
In-Reply-To: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>
References: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>
Message-ID: <66b3d384-e1be-44e6-bfe1-dd429ab1f0f4@oracle.com>

Hi Andrew,

That is a great discovery. I tend to think we might both cases, the 
totally predictable and not predictable, because sometimes we really do 
want to see differences between hardware. We rewrote this one a couple 
years ago because the type-swapping previously used had more much 
overhead than whatever improvement we were evaluating in the itbl stub. 
A very lightweight way to do this is welcome.

It is true a lot of these JMH were started/written more than 10 years 
ago but now there are so many JMH to scan, we will just have to keep 
this kind of thing in mind as we are using them.

Regards,

Eric


On 10/7/24 10:18 AM, Andrew Haley wrote:
> I've been looking at rewriting invokeinterface, with a view to making
> it more efficient and predictable on today's hardware, hopefully (near)
> O(1) execution time. Also, we (again, hopefully) wouldn't need to
> dynamically generate and manage itable stubs.
>
> I've been trying a few approaches and don't yet have anything ready to
> present, but I've come across an interesting anomaly in our
> benchmarking. No matter what I did, and however bad my experiment, the
> performance barely changed at all! It was as though my changes were
> doing nothing, but eyeballing the generated code showed it was
> different.
>
> org.openjdk.bench.vm.compiler.InterfaceCalls.test2ndInt5Types looks
> like this:
>
> ??? as[0] = new FirstClass();
> ??? as[1] = new SecondClass();
> ??? as[2] = new ThirdClass();
> ??? as[3] = new FourthClass();
> ??? as[4] = new FifthClass();
>
> ??? // ...
>
> ??? int l = 0;
>
> ??? @Benchmark
> ??? public int test2ndInt5Types() {
> ??????? SecondInterface ai = (SecondInterface) as[l];
> ??????? l = ++ l % asLength;
> ??????? return ai.getIntSecond();
> ??? }
>
> That is to say, we serially step through an array, invoking the same
> interface method on a different concrete class in turn.
>
> The performance (Apple M1) is sparklingly good:
>
> InterfaceCalls.test2ndInt5Types??? 6.026 ? 0.009????? ns/op
>
> But this is so fast as to be incredible, only 19.3 clocks per
> invocation, including the control loop and the called method. A load
> from L1 cache takes about 3-4 cycles, and there are several dependent
> loads in the method lookup path. I suspected that because this
> benchmark is unrealistically predictable, it does not fairly represent
> real-world performance.
>
> So, let's try mixing it up a little, and jump about rather than
> cycling through the array:
>
> ??? static final int scramble(int n) {
> ??????? int x = n;
> ??????? x ^= x << 13;
> ??????? x ^= x >>> 17;
> ??????? x ^= x << 5;
> ??????? return x == 0 ? 1 : x;
> ??? }
>
> ??? @Benchmark
> ??? public int test2ndInt5TypesScrambled() {
> ??????? l = scramble(l);
> ??????? SecondInterface ai = (SecondInterface) as[Math.floorMod(l, 
> asLength)];
> ??????? return ai.getIntSecond();
> ??? }
>
> This adds only a few instructions, but the measured performance is
> radically different:
>
> InterfaceCalls.test2ndInt5TypesScrambled? 19.363 ? 0.084 ns/op
>
> This is 62 clocks per invocation, and I suspect this result is far
> more realistic. But is it really? Maybe invokeinterface calls are
> generally very predictable, so the benchmark we already have is
> representative.
>
> Questions:
>
> - Which benchmarks should we be optimizing for? I guess it could be
> ? the scrambled one, but maybe that would have no benefit if generally
> ? (or overwhelmingly often) invokeinterface is predictable.
>
> - How many of the (micro-)benchmarks in HotSpot suffer from this
> ? problem? I'm guessing a lot of them, and perhaps it's partly because
> ? they were written in the days when speculative execution were less
> ? aggressive and branch prediction wasn't so good.
>

From duke at openjdk.org  Mon Oct  7 21:17:36 2024
From: duke at openjdk.org (Mikhail Ablakatov)
Date: Mon, 7 Oct 2024 21:17:36 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
In-Reply-To: <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
 <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com>
Message-ID: <WZIP8OwfSX0-oxfQ7brEqgxcvjNOw7HGmVRmsLUhyiU=.464f8c5d-a39d-43e2-90d1-b554d42ad15c@github.com>

On Mon, 7 Oct 2024 17:04:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
>> 
>> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
>> 
>> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.
>
> src/hotspot/cpu/aarch64/aarch64.ad line 16575:
> 
>> 16573:                          vRegD_V0 vtmp0, vRegD_V1 vtmp1, vRegD_V2 vtmp2, vRegD_V3 vtmp3,
>> 16574:                          vRegD_V4 vtmp4, vRegD_V5 vtmp5, vRegD_V6 vtmp6, vRegD_V7 vtmp7,
>> 16575:                          vRegD_V12 vtmp8, vRegD_V13 vtmp9, rFlagsReg cr)
> 
> It would be much better to pass all the vtemp registers to the `arrays_hashcode()`, then assert the registers are correct.
> 
> See `LOOKUP_SECONDARY_SUPERS_TABLE_REGISTERS` in `MacroAssembler`. It is asserted in the stub and in the inlined code. If this had been done in the patch that had to be backed out, it wouldn't have had to be backed out.

Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21286#discussion_r1790885413

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 syan at openjdk.org  Tue Oct  8 06:28:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 8 Oct 2024 06:28:37 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter to
 link to source code
Message-ID: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>

Hi all,
The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.

Additonal testing:

- [ ] aarch64 native build with slowdebug and fastdebug
- [ ] jtreg tests(include tier1/tier2/tier3 etc.) with release build

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

Commit messages:
 - 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter to link to source code

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

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

From syan at openjdk.org  Tue Oct  8 06:42:56 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 8 Oct 2024 06:42:56 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
Message-ID: <cP_FNWmpDzddRQd8JWnwQgV8H1C8-Wy40aeBBPXWB94=.5bc940c7-296b-4e05-97fd-3bd17bebf709@github.com>

On Tue, 8 Oct 2024 06:17:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.
> 
> Additonal testing:
> 
> - [x] aarch64 native build with slowdebug and fastdebug
> - [ ] jtreg tests(include tier1/tier2/tier3 etc.) with release build

Test command `java -Xint -XX:+PrintInterpreter -version` output before this PR:
[jdk24-aarch64.log](https://github.com/user-attachments/files/17289022/jdk24-aarch64.log)

Test command `java -Xint -XX:+PrintInterpreter -version` output after this PR:
[jdk24-aarch64-jbs8341688.log](https://github.com/user-attachments/files/17289027/jdk24-aarch64-jbs8341688.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/21400#issuecomment-2398975658

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 aph at openjdk.org  Tue Oct  8 09:08:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 8 Oct 2024 09:08:57 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
Message-ID: <eERm1oI80_WjOXPVH4qxTnmX9jD6uxtHTjuVTk2CBZU=.83493358-0c96-4f2d-8d0b-305ef6e5c55d@github.com>

On Tue, 8 Oct 2024 06:17:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.
> 
> Additonal testing:
> 
> - [x] aarch64 native build with slowdebug and fastdebug
> - [ ] jtreg tests(include tier1/tier2/tier3 etc.) with release build

Sweet! Is that really all there is to it? :-)

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21400#pullrequestreview-2353886776

From amitkumar at openjdk.org  Tue Oct  8 09:22:14 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 8 Oct 2024 09:22:14 GMT
Subject: RFR: 8339220: [s390x] TestIfMinMax.java failure [v2]
In-Reply-To: <cmrPBfLCt5yxmV6ST9ZB6ND0qZYcu8owe5y5eofHXT4=.466c1416-0149-46b5-b8ff-29beddc9d460@github.com>
References: <5DtK26dlgE6Aacoldf6_VEDVfSzlym7EC6FW1O-iwiE=.218dba46-f28d-4765-9dd3-0d9043838b61@github.com>
 <Y882h7z9X3MAkcs8gbcc0Dc8FpAI3yFconSqkjEMK_0=.50e818d8-f699-477b-9a92-af46df94561c@github.com>
 <KfSE0uarRO77-1PzjoLb06M61u_x2X76cSWP6_voXFg=.80f2c530-30b1-4224-8c37-6403ec0bfff7@github.com>
 <cmrPBfLCt5yxmV6ST9ZB6ND0qZYcu8owe5y5eofHXT4=.466c1416-0149-46b5-b8ff-29beddc9d460@github.com>
Message-ID: <UfpSFJM7krP0kwzrT9mMm4jeEBl56OkmryljAXIbLok=.d2bbd7aa-11e9-4d17-8d77-d6daddad2fd0@github.com>

On Thu, 26 Sep 2024 11:41:34 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Changes requested by lucy (Reviewer).
>
>> But I assume @RealLucy can tell us something useful :-)
> 
> Yes, the s390x port was alive before it was donated to OpenJDK. :-) If there is general interest, I can dig in the internal history in search for more details.

Thanks @RealLucy @theRealAph  for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21198#issuecomment-2399310363

From amitkumar at openjdk.org  Tue Oct  8 09:22:15 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 8 Oct 2024 09:22:15 GMT
Subject: Integrated: 8339220: [s390x] TestIfMinMax.java failure
In-Reply-To: <5DtK26dlgE6Aacoldf6_VEDVfSzlym7EC6FW1O-iwiE=.218dba46-f28d-4765-9dd3-0d9043838b61@github.com>
References: <5DtK26dlgE6Aacoldf6_VEDVfSzlym7EC6FW1O-iwiE=.218dba46-f28d-4765-9dd3-0d9043838b61@github.com>
Message-ID: <DROiaQ80H6_qmW81nEbKaBXtyLRKfgwoCEFzaPiIOqg=.a394d65f-bc80-45b7-a0ae-9359ad1e2e2f@github.com>

On Thu, 26 Sep 2024 06:08:40 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This test enables Conditional moves for long operands for s390x. Which fixes the test-case.
> 
> Ran tier1 and not saw any regression.

This pull request has now been integrated.

Changeset: 59ac7039
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59ac7039d3ace0ec481742c3a10c81f1675e12da
Stats:     12 lines in 2 files changed: 5 ins; 1 del; 6 mod

8339220: [s390x] TestIfMinMax.java failure

Reviewed-by: lucy, aph

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

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

From duke at openjdk.org  Tue Oct  8 09:47:47 2024
From: duke at openjdk.org (Mikhail Ablakatov)
Date: Tue, 8 Oct 2024 09:47:47 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
 [v2]
In-Reply-To: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
Message-ID: <1et13399iAB7nE79C_UCtljStqiP46OnP120XjbuyC4=.427dd552-ef34-450e-b67f-e5d752fd8dbb@github.com>

> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487.
> 
> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP  registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad  is just a cleanup as some registers on the list were not used by the stub at all anymore.
> 
> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed.

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

  Ensure that the inline code and the stub use the same registers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21286/files
  - new: https://git.openjdk.org/jdk/pull/21286/files/90e68228..9c6ad7a5

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

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

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

From aph at openjdk.org  Tue Oct  8 09:47:47 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 8 Oct 2024 09:47:47 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
 [v2]
In-Reply-To: <WZIP8OwfSX0-oxfQ7brEqgxcvjNOw7HGmVRmsLUhyiU=.464f8c5d-a39d-43e2-90d1-b554d42ad15c@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
 <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com>
 <WZIP8OwfSX0-oxfQ7brEqgxcvjNOw7HGmVRmsLUhyiU=.464f8c5d-a39d-43e2-90d1-b554d42ad15c@github.com>
Message-ID: <ODsEMY4wzwbAqSzmlxvkydX7hYcec6s0e8ylx1jCEug=.f1686001-bbeb-4703-8d1e-a15ff016fc33@github.com>

On Mon, 7 Oct 2024 21:14:31 GMT, Mikhail Ablakatov <duke at openjdk.org> wrote:

> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well.

I'm not sure we could do _much_ better. A great advantage of using a macro is that it enforces consistent naming across the stub and the inlined code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21286#discussion_r1791555923

From duke at openjdk.org  Tue Oct  8 09:47:47 2024
From: duke at openjdk.org (Mikhail Ablakatov)
Date: Tue, 8 Oct 2024 09:47:47 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
 [v2]
In-Reply-To: <ODsEMY4wzwbAqSzmlxvkydX7hYcec6s0e8ylx1jCEug=.f1686001-bbeb-4703-8d1e-a15ff016fc33@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
 <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com>
 <WZIP8OwfSX0-oxfQ7brEqgxcvjNOw7HGmVRmsLUhyiU=.464f8c5d-a39d-43e2-90d1-b554d42ad15c@github.com>
 <ODsEMY4wzwbAqSzmlxvkydX7hYcec6s0e8ylx1jCEug=.f1686001-bbeb-4703-8d1e-a15ff016fc33@github.com>
Message-ID: <rekBrf0ts90iTkGI4Hrih3cwBl0ACG1bOvvv2NUlK3w=.6bb5bb07-5c6a-49e0-a10f-7e6e29cff56f@github.com>

On Tue, 8 Oct 2024 09:42:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well.
>
>> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well.
> 
> I'm not sure we could do _much_ better. A great advantage of using a macro is that it enforces consistent naming across the stub and the inlined code.

Fixed by https://github.com/openjdk/jdk/pull/21286/commits/9c6ad7a59b3144766a888e136dc4084f2b8e83fd.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21286#discussion_r1791557808

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 fgao at openjdk.org  Tue Oct  8 10:31:08 2024
From: fgao at openjdk.org (Fei Gao)
Date: Tue, 8 Oct 2024 10:31:08 GMT
Subject: RFR: 8341612: [BACKOUT] 8338442: AArch64: Clean up IndOffXX type
 and let legitimize_address() fix out-of-range operands
In-Reply-To: <Ag18LAT2JSCKSZ0KTXnm8wXBBUDp-fdqotfxHHgU5as=.10cc1305-86aa-44ab-8d0a-43fe36dd5089@github.com>
References: <S8oyUBGmKUoI_JbXWiXc-XMPm9bT2wOSblQmUJtk9g0=.8fe1132b-9107-4c30-8156-fe1c6d53d7a1@github.com>
 <SoO99c3xymQNgIBud_bWIVKgTg9YeuaDqML6FB0uIpc=.dc7e72a8-9ecf-4d1c-b374-4ff068f5121b@github.com>
 <6CwoWlnLh3PxCSnVsMVAnfB_fM1F_bSmNf396fYzKG4=.5018f286-40e6-469c-bc66-e321b25cb450@github.com>
 <Ag18LAT2JSCKSZ0KTXnm8wXBBUDp-fdqotfxHHgU5as=.10cc1305-86aa-44ab-8d0a-43fe36dd5089@github.com>
Message-ID: <LoqH-Ds6TiNVngA6C6tGhVfaWNCsb8BvKKlhlbnfnIM=.b8ae2281-8437-4b57-a7cb-1f95dd6180b4@github.com>

On Mon, 7 Oct 2024 14:23:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > Hi @theRealAph , with the original fix, what do you think of the idea that we just skip implicit null check if we need extra lea to handle some special memory access on `aarch64`? Suppose these special memory accesses are uncommon.
> 
> That looks reasonable and conservative. An alternative would be to adjust the implicit null check relocs to point to the actual trapping load.

Yeah, make sense. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21381#issuecomment-2399468515

From mli at openjdk.org  Tue Oct  8 10:38:00 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 10:38:00 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v2]
In-Reply-To: <cnHIG4iBi3sNmKHtJaYvBFXlAzQx7rM4Kh1Mu2mjJK0=.21a362ff-5409-471b-912a-0cafafacebcb@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <zHQ08fHleTGrjTH2iWZYKBghX2xUNWYDkt3rIvAQGJM=.cd9ed3bb-5e52-4b6d-bb99-a6ba32b49f3d@github.com>
 <cnHIG4iBi3sNmKHtJaYvBFXlAzQx7rM4Kh1Mu2mjJK0=.21a362ff-5409-471b-912a-0cafafacebcb@github.com>
Message-ID: <_Wl8esckGIb1QJqJxxDl1nKYVQupH2I1rJyNQw_1x98=.ab1468ba-1201-4b3a-b611-70f725576622@github.com>

On Mon, 23 Sep 2024 13:12:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify cflags style
>
> Build changes look ok.

@erikj79 @RealFYang Hi, can you help to reapprove the pr? I guess it's because the new "re-review/approve" rule. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2399481221

From mli at openjdk.org  Tue Oct  8 10:41:05 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 10:41:05 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v9]
In-Reply-To: <jOepSJ6WBTW8h4aGfEQJmtUZM_hOWQ-yabgAaoVMA-0=.47e478e4-0726-4dd6-aa18-e14a748fcdf2@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <4oXN9TokV6OkJe4BMIF4GBI7g8LA8KZTiZwSksTU_Qw=.6f3da3ea-63f0-472b-8505-d736ab959aa3@github.com>
 <jOepSJ6WBTW8h4aGfEQJmtUZM_hOWQ-yabgAaoVMA-0=.47e478e4-0726-4dd6-aa18-e14a748fcdf2@github.com>
Message-ID: <jScXHXfB5d7gHvT2w87SISvBsd2k3yAl2EXNY9U_LuM=.e5101b8c-a67e-45c7-9941-096129a292ce@github.com>

On Mon, 7 Oct 2024 09:16:42 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   bits > 512
>
> Marked as reviewed by luhenry (Committer).

@luhenry I merged this pr with the master to resolve conflict after your approval, so I think I also needs your reapproval. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2399487094

From aph-open at littlepinkcloud.com  Tue Oct  8 11:07:23 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 8 Oct 2024 12:07:23 +0100
Subject: [openjdk/jdk] 8338526: Don't store abstract and interface Klasses
 in class metaspace (PR #19157)
In-Reply-To: <openjdk/jdk/pull/19157/c2340431106@github.com>
References: <openjdk/jdk/pull/19157@github.com>
 <openjdk/jdk/pull/19157/c2340431106@github.com>
Message-ID: <b5b4ce8b-fda4-49ab-a5d0-cb0fdf34c8e1@littlepinkcloud.com>

On 9/10/24 12:42, Coleen Phillimore wrote:
 > Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.

I'm a bit concerned about this one.

I'm working on megamorphic dispatch, and a uniform representation of
compressed class pointers allows me to squeeze klass+offset into a
single 64-bit word. This in turn allows fast and simple method
lookups. I need, at least, to be able to use compressed interface
pointers. If interfaces are "somewhere else", and thus incompressible,
I can't do what I need to do. If, however, klass and non-klass
metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
rather use compressed klass pointers without having to decode them.

All I need is a way to represent interface pointers in a compact way
in lookup tables, and to be able to get from compressed class pointers
to the address. As long as interface pointers are in a 32-bit range
and there's a fast way to get from compressed class to address that's
OK.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at openjdk.org  Tue Oct  8 11:10:06 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 8 Oct 2024 11:10:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <kSwMoNMtYWBlfxQQaVB0DJ6AqBlA499dW3VLznfXO5Q=.522d5cc2-513e-4f80-a8b6-5589683b1a1f@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

On 9/10/24 12:42, Coleen Phillimore wrote:
 > Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.

I'm a bit concerned about this one.

I'm working on megamorphic dispatch, and a uniform representation of
compressed class pointers allows me to squeeze klass+offset into a
single 64-bit word. This in turn allows fast and simple method
lookups. I need, at least, to be able to use compressed interface
pointers. If interfaces are "somewhere else", and thus incompressible,
I can't do what I need to do. If, however, klass and non-klass
metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
rather use compressed klass pointers without having to decode them.

All I need is a way to represent interface pointers in a compact way
in lookup tables, and to be able to get from compressed class pointers
to the address. As long as interface pointers are in a 32-bit range
and there's a fast way to get from compressed class to address that's
OK.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2399545521

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 luhenry at openjdk.org  Tue Oct  8 12:19:00 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 8 Oct 2024 12:19:00 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
Message-ID: <w8yjREj7SqA1evq3pFsgIaJMVj43ZRiBvSwMJAjPR8Y=.e5ef02c0-2056-4233-bb2a-5a1f5839ce7d@github.com>

On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li 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 master
>  - bits > 512
>  - fix test macro
>  - check frm after sleef call
>  - use all arg v regs
>  - misc
>  - refine comment
>  - comment
>  - modify cflags style
>  - fix make warning
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

Marked as reviewed by luhenry (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2354313164

From jsjolen at openjdk.org  Tue Oct  8 12:35:59 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 8 Oct 2024 12:35:59 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
Message-ID: <Qxy9PJ-K8X3WEIGFjqpItq9pv_LM4qt0B7uWQdzsD9Q=.659b0807-10c8-43ba-91e9-d06758621364@github.com>

On Tue, 8 Oct 2024 06:17:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.
> 
> Additonal testing:
> 
> - [x] aarch64 native build with slowdebug and fastdebug
> - [x] jtreg tests(include tier1/tier2/tier3 etc.) with release build

LGTM, thanks. I'm OK with the added comments to the set_vtos_enry_points function.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21400#pullrequestreview-2354354012

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 syan at openjdk.org  Tue Oct  8 13:01:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 8 Oct 2024 13:01:58 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <eERm1oI80_WjOXPVH4qxTnmX9jD6uxtHTjuVTk2CBZU=.83493358-0c96-4f2d-8d0b-305ef6e5c55d@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
 <eERm1oI80_WjOXPVH4qxTnmX9jD6uxtHTjuVTk2CBZU=.83493358-0c96-4f2d-8d0b-305ef6e5c55d@github.com>
Message-ID: <CSpCe4q_dkHorLtsCt9Hf3osFQKb0VnflZv4AJ0_5GA=.12d752e5-0d7d-4e71-a860-b27a48ab6a94@github.com>

On Tue, 8 Oct 2024 09:06:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Sweet! Is that really all there is to it? :-)

I think so, the option `-XX:+PrintInterpreter` only print 200+ bytecode's assemble.

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

PR Comment: https://git.openjdk.org/jdk/pull/21400#issuecomment-2399780917

From ihse at openjdk.org  Tue Oct  8 13:28:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 13:28:02 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
Message-ID: <JaTIvQYFnSc7noCcw5USHKAVNfwC0JZ1egs1CKrnsvo=.2f63a5c8-8ffc-4192-b652-5338c8d2c0f9@github.com>

On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li 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 master
>  - bits > 512
>  - fix test macro
>  - check frm after sleef call
>  - use all arg v regs
>  - misc
>  - refine comment
>  - comment
>  - modify cflags style
>  - fix make warning
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

Changes requested by ihse (Reviewer).

make/modules/jdk.incubator.vector/Lib.gmk line 41:

> 39: endif
> 40: 
> 41: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, riscv64)+$(INCLUDE_COMPILER2), true+true+true)

Please add a 

################################################################################
## Build libsleef
################################################################################

header, for consistency.

make/modules/jdk.incubator.vector/Lib.gmk line 50:

> 48:       DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \
> 49:       CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \
> 50:       LDFLAGS := $(LDFLAGS_JDKLIB) \

Sorry for the late comment, I've been out ill. The LDFLAGS line is no longer needed and should be removed.

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

PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2354485136
PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1791874837
PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1791870691

From ihse at openjdk.org  Tue Oct  8 13:28:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 13:28:03 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <JaTIvQYFnSc7noCcw5USHKAVNfwC0JZ1egs1CKrnsvo=.2f63a5c8-8ffc-4192-b652-5338c8d2c0f9@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
 <JaTIvQYFnSc7noCcw5USHKAVNfwC0JZ1egs1CKrnsvo=.2f63a5c8-8ffc-4192-b652-5338c8d2c0f9@github.com>
Message-ID: <g4igwzpaMmeQ3D_UYfPgIjbc_EbfptHlOmYkfvi4Zl4=.baa8cb7c-be0d-4424-85f0-1bcc2da4ed1f@github.com>

On Tue, 8 Oct 2024 13:23:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hamlin Li 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 master
>>  - bits > 512
>>  - fix test macro
>>  - check frm after sleef call
>>  - use all arg v regs
>>  - misc
>>  - refine comment
>>  - comment
>>  - modify cflags style
>>  - fix make warning
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262
>
> make/modules/jdk.incubator.vector/Lib.gmk line 50:
> 
>> 48:       DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \
>> 49:       CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \
>> 50:       LDFLAGS := $(LDFLAGS_JDKLIB) \
> 
> Sorry for the late comment, I've been out ill. The LDFLAGS line is no longer needed and should be removed.

So is the `LIBS` line as well. And the CFLAGS line should be just:

       CFLAGS := -march=rv64gcv, \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1791874092

From ihse at openjdk.org  Tue Oct  8 13:31:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 13:31:00 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
Message-ID: <hV1PlBz7aKb32n087G3Pdlk6cV_JeT41dHxwvJm2EZQ=.7deacb23-0d6f-4649-b2ab-a1ebc3b99b2a@github.com>

On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li 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 master
>  - bits > 512
>  - fix test macro
>  - check frm after sleef call
>  - use all arg v regs
>  - misc
>  - refine comment
>  - comment
>  - modify cflags style
>  - fix make warning
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

I apologize for bringing in new requests for changes when you were so close to integrating. I understand it must be frustrating. Hopefully, it's a trivial fix and I can re-approve the new version as soon as you commit it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2399852407

From mli at openjdk.org  Tue Oct  8 13:44:01 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 13:44:01 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <g4igwzpaMmeQ3D_UYfPgIjbc_EbfptHlOmYkfvi4Zl4=.baa8cb7c-be0d-4424-85f0-1bcc2da4ed1f@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
 <JaTIvQYFnSc7noCcw5USHKAVNfwC0JZ1egs1CKrnsvo=.2f63a5c8-8ffc-4192-b652-5338c8d2c0f9@github.com>
 <g4igwzpaMmeQ3D_UYfPgIjbc_EbfptHlOmYkfvi4Zl4=.baa8cb7c-be0d-4424-85f0-1bcc2da4ed1f@github.com>
Message-ID: <IEwzvfO_fDPOQFwzoOfhv_A6GXzs4kgpo6jHq_Nf6DY=.590f078e-a743-4f12-9030-1c91171934c6@github.com>

On Tue, 8 Oct 2024 13:25:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/jdk.incubator.vector/Lib.gmk line 50:
>> 
>>> 48:       DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \
>>> 49:       CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \
>>> 50:       LDFLAGS := $(LDFLAGS_JDKLIB) \
>> 
>> Sorry for the late comment, I've been out ill. The LDFLAGS line is no longer needed and should be removed.
>
> So is the `LIBS` line as well. And the CFLAGS line should be just:
> 
>        CFLAGS := -march=rv64gcv, \

No worries, it's not late. Take care!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1791902678

From mli at openjdk.org  Tue Oct  8 13:44:01 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 13:44:01 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <IEwzvfO_fDPOQFwzoOfhv_A6GXzs4kgpo6jHq_Nf6DY=.590f078e-a743-4f12-9030-1c91171934c6@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
 <JaTIvQYFnSc7noCcw5USHKAVNfwC0JZ1egs1CKrnsvo=.2f63a5c8-8ffc-4192-b652-5338c8d2c0f9@github.com>
 <g4igwzpaMmeQ3D_UYfPgIjbc_EbfptHlOmYkfvi4Zl4=.baa8cb7c-be0d-4424-85f0-1bcc2da4ed1f@github.com>
 <IEwzvfO_fDPOQFwzoOfhv_A6GXzs4kgpo6jHq_Nf6DY=.590f078e-a743-4f12-9030-1c91171934c6@github.com>
Message-ID: <Dn_vrnVc_3554FyvirhLI7m_8ND-TOzLN79nXTpjNYk=.ea0fd9a5-2f36-4136-9522-e5ee61fb0dad@github.com>

On Tue, 8 Oct 2024 13:40:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> So is the `LIBS` line as well. And the CFLAGS line should be just:
>> 
>>        CFLAGS := -march=rv64gcv, \
>
> No worries, it's not late. Take care!

Do you suggest something like below?

       EXTRA_SRC := libsleef/generated, \
       DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \
       DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \
-      CFLAGS := $(CFLAGS_JDKLIB) -march=rv64gcv, \
-      LDFLAGS := $(LDFLAGS_JDKLIB) \
-          $(call SET_SHARED_LIBRARY_ORIGIN), \
-      LIBS := $(JDKLIB_LIBS) \
+      CFLAGS := -march=rv64gcv \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1791903343

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 mli at openjdk.org  Tue Oct  8 14:07:45 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 14:07:45 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v11]
In-Reply-To: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
Message-ID: <E2gXPyFutgIxWE1y6i5favHqA9RLIi2C1Lu_BDn3rZ0=.6967b4a3-a281-42ad-a681-045a6ce3d2bf@github.com>

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
> 
> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
> 
> ### Test
> test/jdk/jdk/incubator/vector
> 
> ### Performance
> data on bananapi
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743
> Double128Vector....

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

  make minor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21083/files
  - new: https://git.openjdk.org/jdk/pull/21083/files/55434262..f5ec5160

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

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

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

From mli at openjdk.org  Tue Oct  8 14:07:46 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 14:07:46 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v10]
In-Reply-To: <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <5G-HkObn_JQIw5lX1lAH2ECQ3PAIandCj986i_uPA7Y=.b12b2b99-2e80-479c-a616-37bd5ae4a1be@github.com>
Message-ID: <zjaBc7rl4sZOQWrml3I-SpwaIzA9pvIG7DD4X4b0Oaw=.da9ce271-c15c-47d1-90fd-bbdf2c851965@github.com>

On Mon, 7 Oct 2024 09:50:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li 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 master
>  - bits > 512
>  - fix test macro
>  - check frm after sleef call
>  - use all arg v regs
>  - misc
>  - refine comment
>  - comment
>  - modify cflags style
>  - fix make warning
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/28977972...55434262

I've run some jtreg test, and check the generated libsleef.so, it should be good. No further jmh test re-run as seems it's not necessary.

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2399951196

From ihse at openjdk.org  Tue Oct  8 14:49:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 14:49:05 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v11]
In-Reply-To: <E2gXPyFutgIxWE1y6i5favHqA9RLIi2C1Lu_BDn3rZ0=.6967b4a3-a281-42ad-a681-045a6ce3d2bf@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <E2gXPyFutgIxWE1y6i5favHqA9RLIi2C1Lu_BDn3rZ0=.6967b4a3-a281-42ad-a681-045a6ce3d2bf@github.com>
Message-ID: <EKtxs0LR91awRKGVB3HsTXJaJwebWNz8nnysn7H81Ec=.411e0d43-1e82-43bd-97a6-d8e117b0b02f@github.com>

On Tue, 8 Oct 2024 14:07:45 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make minor

make/modules/jdk.incubator.vector/Lib.gmk line 53:

> 51:       DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \
> 52:       DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \
> 53:       CFLAGS := -march=rv64gcv \

Suggestion:

      CFLAGS := -march=rv64gcv, \


This is strictly not needed here (that was why it worked for you) but we always include the trailing comma so adding a new line does not need to modify the one above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1792024010

From mli at openjdk.org  Tue Oct  8 14:56:56 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 14:56:56 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v12]
In-Reply-To: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
Message-ID: <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
> 
> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
> 
> ### Test
> test/jdk/jdk/incubator/vector
> 
> ### Performance
> data on bananapi
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743
> Double128Vector....

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

  keep comma

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21083/files
  - new: https://git.openjdk.org/jdk/pull/21083/files/f5ec5160..76b8bbc5

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

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

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

From mli at openjdk.org  Tue Oct  8 14:56:57 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 14:56:57 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v11]
In-Reply-To: <EKtxs0LR91awRKGVB3HsTXJaJwebWNz8nnysn7H81Ec=.411e0d43-1e82-43bd-97a6-d8e117b0b02f@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <E2gXPyFutgIxWE1y6i5favHqA9RLIi2C1Lu_BDn3rZ0=.6967b4a3-a281-42ad-a681-045a6ce3d2bf@github.com>
 <EKtxs0LR91awRKGVB3HsTXJaJwebWNz8nnysn7H81Ec=.411e0d43-1e82-43bd-97a6-d8e117b0b02f@github.com>
Message-ID: <6Il-efH0ovc21AKO12qc-qHQtQja-4rUZREzijBIFSo=.bca80111-c99c-44df-91fc-8601ed9909d1@github.com>

On Tue, 8 Oct 2024 14:46:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make minor
>
> make/modules/jdk.incubator.vector/Lib.gmk line 53:
> 
>> 51:       DISABLED_WARNINGS_gcc := unused-function sign-compare tautological-compare ignored-qualifiers, \
>> 52:       DISABLED_WARNINGS_clang := unused-function sign-compare tautological-compare ignored-qualifiers, \
>> 53:       CFLAGS := -march=rv64gcv \
> 
> Suggestion:
> 
>       CFLAGS := -march=rv64gcv, \
> 
> 
> This is strictly not needed here (that was why it worked for you) but we always include the trailing comma so adding a new line does not need to modify the one above.

I see, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21083#discussion_r1792035366

From matsaave at openjdk.org  Tue Oct  8 15:04:00 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 8 Oct 2024 15:04:00 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing
In-Reply-To: <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>
Message-ID: <HP10VGfvN8cc2oOJJ_MF7ijo7YVOl0hDQJB7I3_Ltu0=.bfcea475-5d11-4f29-a443-16a6c97ef333@github.com>

On Fri, 4 Oct 2024 02:14:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> src/hotspot/share/cds/metaspaceShared.cpp line 757:
> 
>> 755:   // Some classes are used at CDS runtime but are not loaded, and therefore archived, at
>> 756:   // dumptime. We can perform dummmy calls to these classes at dumptime to ensure they
>> 757:   // are archived.
> 
> This code doesn't just load classes though, it loads, links, initializes them and creates a unwanted instance. Isn't there a simpler way to do this? Do these classes have to be initialized?

The classes make calls to other classes that need to be loaded as well, this code acts like a shortcut to load a list of classes that we use at runtime. These calls mirror the ones used at runtime.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1792051531

From ihse at openjdk.org  Tue Oct  8 15:09:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 15:09:02 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v12]
In-Reply-To: <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
Message-ID: <k-2-fKRBzZnqq7mSLDMukr9DOxbXfrJK0p1kkLiwjSw=.3bdef84f-62fe-4220-a949-93de66bdafaf@github.com>

On Tue, 8 Oct 2024 14:56:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep comma

Now it looks good! Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2354796105

From luhenry at openjdk.org  Tue Oct  8 15:13:01 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 8 Oct 2024 15:13:01 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v12]
In-Reply-To: <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
Message-ID: <DAAZLE1S9ROXfFqwHedTf_F8qsoLr2kcFJggxZjGycY=.ccdee837-74ee-4781-ae20-05a05321c2b4@github.com>

On Tue, 8 Oct 2024 14:56:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep comma

Marked as reviewed by luhenry (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21083#pullrequestreview-2354806194

From eastigeevich at openjdk.org  Tue Oct  8 15:14:03 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 8 Oct 2024 15:14:03 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
Message-ID: <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>

On Mon, 7 Oct 2024 14:10:58 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> There are reasons against the change for N1/N2
> 
>     * Vladimir saw a regression when testing -XX:CodeEntryAlignment=16 on Ampere (Neoverse N1)

The regression is for 16 not 32. Maybe 32 won't cause regressions. 

> 
>     * with native codes experiment I found that code entry 64B is preferable on G2 (Neoverse N1)

Could you share more data?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1792067353

From mli at openjdk.org  Tue Oct  8 15:18:14 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 15:18:14 GMT
Subject: Integrated: 8320500: [vectorapi] RISC-V: Optimize vector math
 operations with SLEEF
In-Reply-To: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
Message-ID: <grHVSqKR8nH45klAHZZ2AqoyV8h9T5CoWgAXuB-xD-U=.4c358862-7653-4f2c-98df-f2111d9ccb82@github.com>

On Thu, 19 Sep 2024 08:32:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this patch?
> Thanks!
> 
> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
> 
> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
> 
> ### Test
> test/jdk/jdk/incubator/vector
> 
> ### Performance
> data on bananapi
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 36.55 | 560765.066 | 2669.33 | ns/op | 1.743
> Double128Vector....

This pull request has now been integrated.

Changeset: 580eb62d
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/580eb62dc097efeb51c76b095c1404106859b673
Stats:     290 lines in 14 files changed: 242 ins; 0 del; 48 mod

8320500: [vectorapi] RISC-V: Optimize vector math operations with SLEEF

Reviewed-by: luhenry, ihse, erikj, fyang, rehn

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

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

From mli at openjdk.org  Tue Oct  8 15:18:13 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 8 Oct 2024 15:18:13 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v12]
In-Reply-To: <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
Message-ID: <PtovUElJ6elNnZOBAWNYKL8KTZaZzTBrLF5IoPgh52U=.d2066d8e-d82d-4ab6-8e3d-fa99a9a0d207@github.com>

On Tue, 8 Oct 2024 14:56:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep comma

Sorry for the inconvenience. Thanks for your quick re-reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2400132507

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 matsaave at openjdk.org  Tue Oct  8 15:47:58 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 8 Oct 2024 15:47:58 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing
In-Reply-To: <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>
Message-ID: <tIVfPANyyMmzc37REpp8-Z0S4cyC0XLICHbS6SK9md4=.77e92321-7395-456b-8753-2ec8100946dd@github.com>

On Fri, 4 Oct 2024 02:15:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> src/hotspot/share/cds/metaspaceShared.cpp line 764:
> 
>> 762: 
>> 763: void MetaspaceShared::make_dummy_calls(TRAPS) {
>> 764:   // Exercise the manifest processing code
> 
> Nit: can we think of a better name rather than "dummy"?

Would `exercise_runtime_cds_code()` be better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1792122561

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 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 psandoz at openjdk.org  Tue Oct  8 16:40:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 8 Oct 2024 16:40:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v22]
In-Reply-To: <hTNfN3mdbuIvNUqr1DV48gpKQP-RFOInpRktdAvi1YE=.2804ce60-a7b3-4a49-a3fe-10c8e5e3f2ec@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <hTNfN3mdbuIvNUqr1DV48gpKQP-RFOInpRktdAvi1YE=.2804ce60-a7b3-4a49-a3fe-10c8e5e3f2ec@github.com>
Message-ID: <JoZsJYyhpqnavTrbcULlOVUj9bU36I-BzD4c-M4xVLs=.b1f11a41-2241-4910-86b1-196726d97d40@github.com>

On Fri, 4 Oct 2024 00:01:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update VectorMath.java

Java changes look good (see comments to fix some typos). Needs another HotSpot reviewer.

Marked as reviewed by psandoz (Reviewer).

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 275:

> 273:      * @param b the second operand.
> 274:      * @return the saturating addition of the operands.
> 275:      * @see VectorOperators#SADD

Suggestion:

     * @see VectorOperators#SUADD

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 301:

> 299:      * @param b the second operand.
> 300:      * @return the saturating difference of the operands.
> 301:      * @see VectorOperators#SSUB

Suggestion:

     * @see VectorOperators#SUSUB

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 413:

> 411:      * @param b the second operand.
> 412:      * @return the saturating addition of the operands.
> 413:      * @see VectorOperators#SADD

Suggestion:

     * @see VectorOperators#SUADD

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 439:

> 437:      * @param b the second operand.
> 438:      * @return the saturating difference of the operands.
> 439:      * @see VectorOperators#SSUB

Suggestion:

     * @see VectorOperators#SUSUB

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 551:

> 549:      * @param b the second operand.
> 550:      * @return the saturating addition of the operands.
> 551:      * @see VectorOperators#SADD

Suggestion:

     * @see VectorOperators#SUADD

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 577:

> 575:      * @param b the second operand.
> 576:      * @return the saturating difference of the operands.
> 577:      * @see VectorOperators#SSUB

Suggestion:

     * @see VectorOperators#SUSUB

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

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2354993291
PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2355019508
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792178593
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792178872
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792179260
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792179485
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792179780
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792180281

From psandoz at openjdk.org  Tue Oct  8 17:13:10 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 8 Oct 2024 17:13:10 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v16]
In-Reply-To: <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
Message-ID: <DKnd321onRNE_6ejF24rlrlbBvyeSh8AcyyVlsJZ-xE=.f0f38b83-09a8-4f21-b443-e9b4d89540fc@github.com>

On Thu, 3 Oct 2024 19:05:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sharpening intrinsic exit check.

test/jdk/jdk/incubator/vector/templates/Unit-header.template line 408:

> 406:                 for (j = 0; j < vector_len; j++) {
> 407:                     idx = i + j;
> 408:                     wrapped_index =(((int)order[idx]) & (2 * vector_len -1));

This assumes a power of two, can we change to use `Math.floorMod`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1792232986

From matsaave at openjdk.org  Tue Oct  8 17:18:46 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 8 Oct 2024 17:18:46 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v2]
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <WDcmugGg1Ho_cXfOrD11YeSKCvWaj-AsqJhBMHlo-zM=.04d842f5-a0d1-4617-88be-3a818170bb9e@github.com>

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

Matias Saavedra Silva 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:

 - Removed test from problem list
 - Merge branch 'master' into dumpRuntimeClassesTest_8341452
 - 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java from JDK-8324259 is failing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21329/files
  - new: https://git.openjdk.org/jdk/pull/21329/files/1ab1cbc7..fad43ec3

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

  Stats: 14592 lines in 256 files changed: 12478 ins; 1306 del; 808 mod
  Patch: https://git.openjdk.org/jdk/pull/21329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21329/head:pull/21329

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

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 john.r.rose at oracle.com  Tue Oct  8 19:11:58 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 08 Oct 2024 12:11:58 -0700
Subject: 8288298: Resolve parsing ambiguities in UL
In-Reply-To: <DM4PR10MB74750042939F85C055C7D36FAF7D2@DM4PR10MB7475.namprd10.prod.outlook.com>
References: <DM4PR10MB74750042939F85C055C7D36FAF7D2@DM4PR10MB7475.namprd10.prod.outlook.com>
Message-ID: <C0AD7CBA-AA60-419C-BF57-042EFD4E732C@oracle.com>

Full disclosure up front:  I dislike output formats which are 99% 
parseable, but fail to design for full disambiguation of all outputs.  
We have some of this sort of technical debt in UL, and we should just 
fix it. That way tool vendors will stop bumping into this kind of thing.

I?m going to give a number of opinions toward this goal.  As a group, 
they are the best way I know (in this moment) to comprehensively fix all 
the parsing problems.  Many of the opinions align with present UL 
realities (happily) and I hope we can adjust remaining UL realities to 
reach 100% unambiguous parsing.

A. Decorators must be delimited in such a way that they cannot be 
confused with each other or with the following message line.

A1. Therefore, decorator text must never contain the end-decorator 
character.

A1a. For most robust, simple parsing, decorator text should not contain 
any other relevant delimiter character:  Begin decorator, begin message, 
newline.  (Yes, allowing newline would still allow decorators to be 
parsed but imagine the problems.  Just forbid any of ?[] \n?.)

A1b. To avoid off-by-one problems (and also do a good deed for 
multi-line outputs), decorator text must also be non-empty.  So no 
?[][2s] hello!?

A2. Therefore, message text must never begin with the begin-decorator 
character.

A2a. Message text should begin with its own delimiter, not just ?any 
character other than begin-decorator?.  We use space today; good; this 
lets simple word-splitting isolate the message (as long as decorators 
cannot contain ? ?).

B. Message text should be terminated by a newline, but should not be 
subject to any other parsing requirement.  Once you split at the first 
space, you have your message line, with no further decoding.

B1. Thus, the occasional introduction of doubled backslashes and 
backslash-newline is a bad idea.  It just introduces more ambiguities.  
(?Which grammar was I parsing? Oh, THAT one!??)

B2. If message text contains embedded newlines, they should be 
unambiguously marked, so that the newline that terminates the whole 
message can be found.

C. In the setting of UL, the best way to mark a continuation line is to 
vary the syntax at the BEGINNING of the following line, not the END of 
the preceding line.  This is because UL already has heavy parsing 
activity at the beginnings of lines; there is no good reason to add more 
parsing activity elsewhere.

C1. The format for a continuation line should be some decorator-like 
syntax that is not exactly legal as a real decorator, and so cannot be 
confused with it.  Something like ?[] second line? or ?[ ] second 
line? or the like.  If it were ?[ ]? (begin-decorator, space, 
end-decorator) then a buggy line-split that was forgetting to look for 
continuation lines would produce ?] second line? as the message, 
which is a good clue about what went wrong.

D. UL lines, along with their associated continuation lines, should 
never interrupt each other.  Concurrent output should be arranged so 
that each line (with its continuation lines) precedes or follows (does 
not interrupt) a neighboring lines (along with THEIR associated 
continuation lines).

D1. If continuation lines are very difficult to keep with their leading 
UL lines, then we should consider adjusting the syntax to allow 
decorations which help match up a line with its continuations.  This 
seems to require an ID number, which ideally be given a characteristic 
syntax distinct from other decorators.  Something like ?[#1]? and 
with ?#? illegal for other decorators (see A1a above).

E. UL is designed both human readers and mechanical parsers.  The above 
points support mechanical parsers, including very simple ones, and do 
not impair human readers either.

Examples (without ID numbers):

```
[foo][bar] this is the first line
[ ] and this is the second
[ ] and this is the third
  [not a decorator] this line has no decorators, and stands alone
  this is the first of two, again without decorators
[ ] this is the promised second
```

Note there is no ?\n? or ?\\?.  Those complicate parsers and are 
hard to read by humans as well.


With ID numbers (which link together multi-line messages):

```
[foo][bar][#42] this is the first line
[ ][#42] and this is the second
  [not a decorator] this line has no decorators, and stands alone
  [#99]this is the first of two, again without decorators
[ ][#99] this is the promised second
[ ][#42] and this is the third (for the first line; it got lost in 
concurrency)
```

Here are some possible regexes:

```
     // Regexes to recognize and strip decorations.
     public static final String DECORATOR_CHAR = "[^] \n]";
     public static final String ONE_DECORATION = "\\[(" + DECORATOR_CHAR 
+ "+)\\]";
     public static final String DECORATION_PREFIX = "\\A(" + 
ONE_DECORATION + ")* ?";
     public static final String FIRST_DECORATION = "\\A" + 
ONE_DECORATION;
     public static final String SEQUENCE_ID = "\\[#[0-9]+\\]";
     public static final String CONTINUATION_PREFIX = "\\A\\[ \\](" + 
SEQUENCE_ID + ")? ?";
```

For simplicity the syntax allows decorators which look like sequence 
IDs, but they should not be emitted, unless they really are sequence 
IDs.

Test code: https://cr.openjdk.org/~jrose/scripts/LogStripTest.java.txt

I hope this helps.  Thanks for working on this stuff, it?s important.

? John

On 7 Oct 2024, at 6:50, Anton Seoane Ampudia wrote:

> Hi all,
>
> During the migration of compiler logs to the UnifiedLogging framework, 
> I have observed that multiline logging does not include decorators for 
> all the lines, instead only adding them for the first one and leaving 
> the rest ?dangling?. I have found out that this is already a 
> reported issue in 
> JDK-8288298<https://bugs.openjdk.org/browse/JDK-8288298> , and written 
> a tentative fix for it.
>
> Some initial testing has been yielding insignificant performance 
> changes with normal logging use cases, but before going forward with 
> it I would like to request for comments and opinions on this. As far 
> as I know, it would simplify somewhat ?manual reading? of logs, as 
> everything starts right now in the same column, as well as automated 
> parsing as there would be no line ambiguities. Copying from the JBS 
> description:
>
>> log_info(gc)("A\nB"); currently outputs:
>> [0s][gc] A
>> B
>> And after this change will output:
>> [0s][gc] A
>> [1s][gc] B
>>
>> This change allows UL to be parsed by regex. Example for per-line 
>> parsing:
>>
>> ^\[ [^\[\]]* \] \[ [^\[\]]* \] (\[ [^\[\]]* \])?
>
> It is worth mentioning that the special case with 
> -Xlog:foldmultilines=true is not affected by this (i.e., if 
> foldmultilines is set to true we do not carry out the line-by-line 
> decorating).
>
> Thanks,
> Ant?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241008/c0918a10/attachment-0001.htm>

From jbhateja at openjdk.org  Tue Oct  8 19:25:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 8 Oct 2024 19:25:24 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
 - Update VectorMath.java
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Typographical error fixups
 - Doc fixups
 - Typographic error
 - Merge stashing and re-commit
 - Tuning extra spaces.
 - Tests for newly added VectorMath.* operations
 - Test cleanups.
 - ... and 16 more: https://git.openjdk.org/jdk/compare/7312eea3...ce76c3e5

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

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=22
  Stats: 9206 lines in 51 files changed: 8778 ins; 27 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From bulasevich at openjdk.org  Tue Oct  8 21:33:59 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 8 Oct 2024 21:33:59 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
Message-ID: <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>

On Tue, 8 Oct 2024 15:11:03 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> Could you share more data?

This is a simple native benchmark: https://cr.openjdk.org/~bulasevich/AlignBench.cpp

The program tests the performance of code starting from different alignments 
using a generated block of code that primarily consists of NOP (no operation)
and RET (return from subroutine) instructions.

In this experiment (though it may not be meaningful for real-world scenarios) 
on G2 execution time increases with misalignment from the 64-byte boundary, with the 
best performance at exact 64-byte alignment and slower times as the offset grows.

align_64+0: 391.457ms 391.157ms 391.481ms
align_64+4: 392.245ms 392.057ms 391.792ms
align_64+8: 392.154ms 392.962ms 392.65ms
align_64+12: 393.485ms 393.307ms 393.658ms
align_64+16: 394.434ms 394.679ms 394.284ms
align_64+20: 395.681ms 395.709ms 394.843ms
align_64+24: 395.799ms 396.396ms 395.977ms
align_64+28: 397.379ms 397.278ms 397.359ms
align_64+32: 397.677ms 397.82ms 397.95ms
align_64+36: 399.08ms 398.88ms 399.075ms
align_64+40: 399.829ms 400.118ms 399.981ms
align_64+44: 400.916ms 400.747ms 401.241ms
align_64+48: 401.736ms 401.831ms 402.54ms
align_64+52: 402.705ms 402.569ms 402.446ms
align_64+56: 403.718ms 403.822ms 403.535ms
align_64+60: 404.722ms 404.824ms 404.726ms
align_64+64: 390.852ms 390.669ms 391.051ms

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1792534735

From iklam at openjdk.org  Tue Oct  8 21:47:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 21:47:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression and
 string concat
Message-ID: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>

This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).

This PR implements the AOT-linking of invokedynamic callsites:
- We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
- The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.

**Review Notes:**

- Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
- `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
- In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
- Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).

**Rough Edges:**

- Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
- If the identity is significant for a static field in a complex class, but not all of the static fields of this class can be archived, I use the `AOTHolder` pattern to break out the fields that need to be archived. See discussion on [leyden-dev](https://mail.openjdk.org/pipermail/leyden-dev/2024-August/000911.html).

---
See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

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

Depends on: https://git.openjdk.org/jdk/pull/21049

Commit messages:
 - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
 - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
 - 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
 - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
 - Limit the use of AOTHolder
 - 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 'remerge' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - more clean up
 - Cleaned up AOTClassInitializer::can_archive_initialized_mirror()
 - more clean up
 - ... and 14 more: https://git.openjdk.org/jdk/compare/1b067b7b...195303f2

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293336
  Stats: 1674 lines in 52 files changed: 1534 ins; 39 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

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

From shade at openjdk.org  Tue Oct  8 21:47:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Oct 2024 21:47:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Cursory review:

src/hotspot/share/cds/aotClassInitializer.cpp line 47:

> 45: 
> 46:   Symbol* name = ik->name();
> 47:   if (name->equals("jdk/internal/constant/PrimitiveClassDescImpl") ||

Could we / should we start using `vmSymbols` constants for these? I think you can directly compare the `Symbol*`-s then, like `name == vmSymbols::jdk_internal_constant_PrimitiveClassDescImpl_Holder() `.

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 476:

> 474:   if (bsm_klass->equals("java/lang/invoke/StringConcatFactory") &&
> 475:       bsm_name->equals("makeConcatWithConstants")) {
> 476:     return true;

I think all BSM entries in SCF are deterministic, really. So we can just check for the class?

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

PR Review: https://git.openjdk.org/jdk/pull/21143#pullrequestreview-2331919072
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1777490992
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1777474219

From iklam at openjdk.org  Tue Oct  8 21:47:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 21:47:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
Message-ID: <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>

On Thu, 26 Sep 2024 17:29:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> src/hotspot/share/cds/aotClassInitializer.cpp line 47:
> 
>> 45: 
>> 46:   Symbol* name = ik->name();
>> 47:   if (name->equals("jdk/internal/constant/PrimitiveClassDescImpl") ||
> 
> Could we / should we start using `vmSymbols` constants for these? I think you can directly compare the `Symbol*`-s then, like `name == vmSymbols::jdk_internal_constant_PrimitiveClassDescImpl_Holder() `.

Not every class in this table is inside vmSymbols, and I don't want to have to edit vmSymbols whenever a new class is added here (and having to do garbage collection in vmSymbols when a class is removed from here).

I pushed a new version that's more table driven, and avoid most strcmp calls by filtering with the symbol length.

> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 476:
> 
>> 474:   if (bsm_klass->equals("java/lang/invoke/StringConcatFactory") &&
>> 475:       bsm_name->equals("makeConcatWithConstants")) {
>> 476:     return true;
> 
> I think all BSM entries in SCF are deterministic, really. So we can just check for the class?

We haven't done much testing with the other SCF BSMs, so I think it's better to do that in a follow-up REF.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782287180
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782282918

From adinn at openjdk.org  Tue Oct  8 21:47:20 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 450:

> 448: 
> 449:   Symbol* mh_sig = cp->method_handle_signature_ref_at(mh_index);
> 450:   if (!check_lambda_metafactory_signature(cp, mh_sig, false)) {

This appears to be rerunning the previous check without a log message -- or am I missing something here?

src/hotspot/share/cds/archiveBuilder.cpp line 234:

> 232:       _klasses->append(klass);
> 233:       if (klass->is_hidden() && klass->is_instance_klass()) {
> 234:         update_hidden_class_loader_type(InstanceKlass::cast(klass));

Can you explain why this 'update' is needed. Are the shared classloader type and classpath index not already set? Or do they need adjusting? Perhaps a comment would help.

src/hotspot/share/cds/cdsConfig.cpp line 486:

> 484: bool CDSConfig::allow_only_single_java_thread() {
> 485:   // See comments in JVM_StartThread()
> 486:   return is_dumping_static_archive();

The test in `JVM_StartThread()` calls `CDSConfig::is_dumping_static_archive()`. Should it be updated to call `CDSConfig::allow_only_single_java_thread()`?

src/hotspot/share/cds/cdsHeapVerifier.cpp line 126:

> 124: 
> 125:   // Integer for 0 and 1 are in java/lang/Integer$IntegerCache and are archived
> 126:   ADD_EXCL("sun/invoke/util/ValueConversions",           "ONE_INT",                // E

At line 46 the example that explains how the verifier works discusses save and restore of field `Foo#archivedFoo`. I believe that field was supposed to be declared as `static` but it is actually declared as an instance field.

src/hotspot/share/cds/cdsHeapVerifier.cpp line 274:

> 272:     char* class_name = info->_holder->name()->as_C_string();
> 273:     char* field_name = info->_name->as_C_string();
> 274:     if (strstr(class_name, "java/lang/invoke/BoundMethodHandle$Species_") == class_name &&

Can we have a comment to explain this special case?

src/hotspot/share/cds/classListParser.cpp line 609:

> 607:   // We store a pre-generated version of the lambda proxy class in the AOT cache,
> 608:   // which will be loaded via JVM_LookupLambdaProxyClassFromArchive().
> 609:   // This eliminate dynamic class generation of the proxy class, but we still need to

"This eliminate" --> "This eliminates"

src/hotspot/share/cds/heapShared.cpp line 893:

> 891: void KlassSubGraphInfo::check_allowed_klass(InstanceKlass* ik) {
> 892:   if (CDSConfig::is_dumping_invokedynamic()) {
> 893:     // We allow LambdaProxy classes in platform and app loaders as well.

Do we not want an assert here to describe the extra classes we are allowing?

Also, does the comment at line 1975 now need to be updated -- it refers to this check which has been widened.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1790514322
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791663789
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791897685
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791917239
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791947118
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791952296
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792002443

From liach at openjdk.org  Tue Oct  8 21:47:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:

> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
> 403:         if (AOTHolder.archivedMethodTypes != null) {
> 404:             MethodType mt = AOTHolder.archivedMethodTypes.get(primordialMT);

Can we populate these AOT MTs into the internTable so we only look up once?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1775644045

From iklam at openjdk.org  Tue Oct  8 21:47:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>
Message-ID: <CN7Hdbyjs1viSsFMNtZ-9slELL9R8kBJ-LhvSVBf5Xo=.3e167a5a-3dbe-43fc-be21-3c35c66538a3@github.com>

On Wed, 25 Sep 2024 17:14:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:
> 
>> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
>> 403:         if (AOTHolder.archivedMethodTypes != null) {
>> 404:             MethodType mt = AOTHolder.archivedMethodTypes.get(primordialMT);
> 
> Can we populate these AOT MTs into the internTable so we only look up once?

There's a trade off here -- start-up will be slowed down if the archivedMethodTypes table is big. Also, `internTable` uses more memory as it wraps every entry inside a weak reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782292378

From aturbanov at openjdk.org  Tue Oct  8 21:47:20 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <tRBuAYS4zPRHHpFEZ--9YqSiU8Q-_dKmRaqQ3_-sg04=.21e766a9-f4db-4bcd-839a-e748bbaaa2ad@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

test/lib/jdk/test/lib/cds/CDSTestUtils.java line 877:

> 875:             }
> 876:         }
> 877:         if (lastMatch != null && lastMatch.equals("-XX:+" +  optionName)) {

Suggestion:

        if (lastMatch != null && lastMatch.equals("-XX:+" + optionName)) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1777059374

From duke at openjdk.org  Tue Oct  8 22:02:01 2024
From: duke at openjdk.org (AGSaidi)
Date: Tue, 8 Oct 2024 22:02:01 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
Message-ID: <zSMwh1pqUv8xJa4ArP9ehV-echdyRSDnHxhlJdUHcxY=.56549bea-c7b4-4526-bea4-61ab60873c00@github.com>

On Mon, 7 Oct 2024 13:18:32 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 263:
> 
>> 261:     }
>> 262:     if (FLAG_IS_DEFAULT(CodeEntryAlignment)) {
>> 263:       FLAG_SET_DEFAULT(CodeEntryAlignment, 32);
> 
> Why only for V1/V2? What about N1/N2?

I?d like to see the same for N1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1790231163

From duke at openjdk.org  Tue Oct  8 22:02:01 2024
From: duke at openjdk.org (AGSaidi)
Date: Tue, 8 Oct 2024 22:02:01 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
Message-ID: <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>

On Tue, 8 Oct 2024 21:31:36 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>>> There are reasons against the change for N1/N2
>>> 
>>>     * Vladimir saw a regression when testing -XX:CodeEntryAlignment=16 on Ampere (Neoverse N1)
>> 
>> The regression is for 16 not 32. Maybe 32 won't cause regressions. 
>> 
>>> 
>>>     * with native codes experiment I found that code entry 64B is preferable on G2 (Neoverse N1)
>> 
>> Could you share more data?
>
>> Could you share more data?
> 
> This is a simple native benchmark: https://cr.openjdk.org/~bulasevich/AlignBench.cpp
> 
> The program tests the performance of code starting from different alignments 
> using a generated block of code that primarily consists of NOP (no operation)
> and RET (return from subroutine) instructions.
> 
> In this experiment (though it may not be meaningful for real-world scenarios) 
> on G2 execution time increases with misalignment from the 64-byte boundary, with the 
> best performance at exact 64-byte alignment and slower times as the offset grows.
> 
> align_64+0: 391.457ms 391.157ms 391.481ms
> align_64+4: 392.245ms 392.057ms 391.792ms
> align_64+8: 392.154ms 392.962ms 392.65ms
> align_64+12: 393.485ms 393.307ms 393.658ms
> align_64+16: 394.434ms 394.679ms 394.284ms
> align_64+20: 395.681ms 395.709ms 394.843ms
> align_64+24: 395.799ms 396.396ms 395.977ms
> align_64+28: 397.379ms 397.278ms 397.359ms
> align_64+32: 397.677ms 397.82ms 397.95ms
> align_64+36: 399.08ms 398.88ms 399.075ms
> align_64+40: 399.829ms 400.118ms 399.981ms
> align_64+44: 400.916ms 400.747ms 401.241ms
> align_64+48: 401.736ms 401.831ms 402.54ms
> align_64+52: 402.705ms 402.569ms 402.446ms
> align_64+56: 403.718ms 403.822ms 403.535ms
> align_64+60: 404.722ms 404.824ms 404.726ms
> align_64+64: 390.852ms 390.669ms 391.051ms

This benchmark certainly has some limitations as nops are special and can be discarded and having the 64B alignment means the core can quickly fetch and throw away as many nops as possible. I'm not sure that it's particularly representative of a real output and the benefits that code density can bring here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1792557931

From iklam at openjdk.org  Tue Oct  8 22:54:59 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 22:54:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
Message-ID: <H0JcdmiiOBaDQVFyTCDQ6ynQnyRaPc3gbQ9O6qP2Cj4=.7cf7a669-cd73-47bc-9d79-c1d8f031b993@github.com>

On Mon, 7 Oct 2024 16:09:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 450:
> 
>> 448: 
>> 449:   Symbol* mh_sig = cp->method_handle_signature_ref_at(mh_index);
>> 450:   if (!check_lambda_metafactory_signature(cp, mh_sig, false)) {
> 
> This appears to be rerunning the previous check without a log message -- or am I missing something here?

It was a cut-and-paste mistake. I've removed this line in [195303f](https://github.com/openjdk/jdk/pull/21143/commits/195303f2c6939b93b6152c6610bd38faff5ae3c7) , where I also fixed some minor bugs with `AOTConstantPoolResolver::is_indy_resolution_deterministic()` and added more comments in the C++ code about what checks are being made.

I also added tests code in AOTLinkedLambdas.java to cover all the type checks that happen inside `is_indy_resolution_deterministic()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792594084

From svkamath at openjdk.org  Wed Oct  9 00:04:38 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 9 Oct 2024 00:04:38 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v2]
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <HQgp7PRsEfM4ra_SIfA3YSdKdwd7rlJeD2hPDDQ6Jfo=.2de470a4-6e40-4080-b243-e9ae89130250@github.com>

> 8341052: SHA-512 implementation using SHA-NI

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

  Updated code as per review comment & updated test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20633/files
  - new: https://git.openjdk.org/jdk/pull/20633/files/16298c56..afeb5028

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

  Stats: 20 lines in 8 files changed: 2 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20633/head:pull/20633

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

From kvn at openjdk.org  Wed Oct  9 00:13:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 00:13:03 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <vGjmPl73Jq54k8FJpF2LgCLjf7wahlG98nYF_lucoY0=.61e1d4fd-f8ca-4265-a777-6ee40475eb06@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

Few comments.

@dougxc will this affect Graal?

src/hotspot/share/asm/register.hpp line 204:

> 202:     return r;
> 203:   }
> 204: 

Is this related change?

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

PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2355700667
PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2401022513
PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1792619252

From kvn at openjdk.org  Wed Oct  9 00:13:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 00:13:04 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <HDLt--v-bi0ID2k9biidLDwHWc93BhnQNyVY2ax7Dhw=.c82d1429-b71a-4ce3-baaf-b1764b482e46@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <HDLt--v-bi0ID2k9biidLDwHWc93BhnQNyVY2ax7Dhw=.c82d1429-b71a-4ce3-baaf-b1764b482e46@github.com>
Message-ID: <9zgAGVDBtk3oNrYhgz2CgiZytXsxNNZu4H9McoARviY=.1eb9dc3f-c15f-4ec3-8a29-6277bf4947dc@github.com>

On Mon, 16 Sep 2024 08:02:15 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/cpu/aarch64/aarch64.ad line 16079:
> 
>> 16077: 
>> 16078:   ins_encode %{
>> 16079:     bool success = false;
> 
> Suggestion:

This line is not removed yet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1792613884

From sviswanathan at openjdk.org  Wed Oct  9 00:18:57 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 00:18:57 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v2]
In-Reply-To: <HQgp7PRsEfM4ra_SIfA3YSdKdwd7rlJeD2hPDDQ6Jfo=.2de470a4-6e40-4080-b243-e9ae89130250@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <HQgp7PRsEfM4ra_SIfA3YSdKdwd7rlJeD2hPDDQ6Jfo=.2de470a4-6e40-4080-b243-e9ae89130250@github.com>
Message-ID: <WyFi3Itj0pW0msw5Bn1r1_4y5I5MzwFrt-Iv7AHwEkY=.66683c26-c022-492e-a41a-d5c5ac88e76d@github.com>

On Wed, 9 Oct 2024 00:04:38 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8341052: SHA-512 implementation using SHA-NI
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code as per review comment & updated test case

The following comment is still pending:
The line 1306 in vm_version_x86.cpp needs to be changed from:
if (UseSHA && supports_avx2() && supports_bmi2()) {
to
if (UseSHA && supports_avx2() && (supports_bmi2() || supports_sha512())) {

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

PR Comment: https://git.openjdk.org/jdk/pull/20633#issuecomment-2401027548

From iklam at openjdk.org  Wed Oct  9 00:43:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 00:43:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <jkeNe6K_JLN5TuwnQqdIa4uQoMrU76QEhlokU-U4G8I=.fcc14767-5caf-443c-9ba3-bc876c7d3718@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

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

  @adinn comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/195303f2..ebfbb238

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

  Stats: 115 lines in 8 files changed: 52 ins; 50 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

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

From iklam at openjdk.org  Wed Oct  9 01:00:02 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 01:00:02 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
Message-ID: <oNj2jiOmoXcwc1q_uC6_OL0fN_gieQu3CZjkDLEX3L4=.007c03d4-4a94-4278-ba4e-cb3f0a166bda@github.com>

On Tue, 8 Oct 2024 11:01:45 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @adinn comments
>
> src/hotspot/share/cds/archiveBuilder.cpp line 234:
> 
>> 232:       _klasses->append(klass);
>> 233:       if (klass->is_hidden() && klass->is_instance_klass()) {
>> 234:         update_hidden_class_loader_type(InstanceKlass::cast(klass));
> 
> Can you explain why this 'update' is needed. Are the shared classloader type and classpath index not already set? Or do they need adjusting? Perhaps a comment would help.

Thanks for pointing this out. This code was necessary because `ClassLoader::record_result()` was not handling hidden classes. I fixed this by moving the logic from `update_hidden_class_loader_type()` to `ClassLoader::record_hidden_class()`.

> src/hotspot/share/cds/cdsConfig.cpp line 486:
> 
>> 484: bool CDSConfig::allow_only_single_java_thread() {
>> 485:   // See comments in JVM_StartThread()
>> 486:   return is_dumping_static_archive();
> 
> The test in `JVM_StartThread()` calls `CDSConfig::is_dumping_static_archive()`. Should it be updated to call `CDSConfig::allow_only_single_java_thread()`?

I updated `JVM_StartThread()`  to call `CDSConfig::allow_only_single_java_thread()`

> src/hotspot/share/cds/cdsHeapVerifier.cpp line 126:
> 
>> 124: 
>> 125:   // Integer for 0 and 1 are in java/lang/Integer$IntegerCache and are archived
>> 126:   ADD_EXCL("sun/invoke/util/ValueConversions",           "ONE_INT",                // E
> 
> At line 46 the example that explains how the verifier works discusses save and restore of field `Foo#archivedFoo`. I believe that field was supposed to be declared as `static` but it is actually declared as an instance field.

I edited the comment to add `static` to the declaration of `Foo#archivedFoo`.

> src/hotspot/share/cds/cdsHeapVerifier.cpp line 274:
> 
>> 272:     char* class_name = info->_holder->name()->as_C_string();
>> 273:     char* field_name = info->_name->as_C_string();
>> 274:     if (strstr(class_name, "java/lang/invoke/BoundMethodHandle$Species_") == class_name &&
> 
> Can we have a comment to explain this special case?

This check is no longer necessary, the Species_XXX classes are now added to the aot-init list in `AOTClassInitializer::can_archive_initialized_mirror()`. I've removed these two lines.

> src/hotspot/share/cds/classListParser.cpp line 609:
> 
>> 607:   // We store a pre-generated version of the lambda proxy class in the AOT cache,
>> 608:   // which will be loaded via JVM_LookupLambdaProxyClassFromArchive().
>> 609:   // This eliminate dynamic class generation of the proxy class, but we still need to
> 
> "This eliminate" --> "This eliminates"

Fixed

> src/hotspot/share/cds/heapShared.cpp line 893:
> 
>> 891: void KlassSubGraphInfo::check_allowed_klass(InstanceKlass* ik) {
>> 892:   if (CDSConfig::is_dumping_invokedynamic()) {
>> 893:     // We allow LambdaProxy classes in platform and app loaders as well.
> 
> Do we not want an assert here to describe the extra classes we are allowing?
> 
> Also, does the comment at line 1975 now need to be updated -- it refers to this check which has been widened.

I updated `KlassSubGraphInfo::check_allowed_klass()` to do proper checks for lambda proxy classes that are allowed. I also update the comment at at line 1975 to be consistent with `check_allowed_klass()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792659021
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792659000
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658987
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658960
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658948
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658912

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 duke at openjdk.org  Wed Oct  9 03:59:58 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 9 Oct 2024 03:59:58 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <jkeNe6K_JLN5TuwnQqdIa4uQoMrU76QEhlokU-U4G8I=.fcc14767-5caf-443c-9ba3-bc876c7d3718@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <jkeNe6K_JLN5TuwnQqdIa4uQoMrU76QEhlokU-U4G8I=.fcc14767-5caf-443c-9ba3-bc876c7d3718@github.com>
Message-ID: <mAbClDkMiSSo8BuA_JfwKzrlh1kV3iddZW945-Mvt2U=.6ff76f65-38c3-40a0-982d-94370e67dcd6@github.com>

On Wed, 9 Oct 2024 00:43:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @adinn comments

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

PR Review: https://git.openjdk.org/jdk/pull/21143#pullrequestreview-2355889520

From duke at openjdk.org  Wed Oct  9 03:59:59 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 9 Oct 2024 03:59:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
 <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>
Message-ID: <72Bo7ZIdbj2kt7jz282D-eWtaJQPWiuIZr9FvaYWAC8=.1ac0cf97-427c-4562-a2e4-b87b47372698@github.com>

On Tue, 1 Oct 2024 07:53:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 476:
>> 
>>> 474:   if (bsm_klass->equals("java/lang/invoke/StringConcatFactory") &&
>>> 475:       bsm_name->equals("makeConcatWithConstants")) {
>>> 476:     return true;
>> 
>> I think all BSM entries in SCF are deterministic, really. So we can just check for the class?
>
> We haven't done much testing with the other SCF BSMs, so I think it's better to do that in a follow-up REF.

`StringConcatFactory?::makeConcat(?)` is?definitely deterministic, as?it simply?delegates to?`StringConcatFactory?::makeConcatWithConstants(?)` with?the?recipe being?based on?the?number of?`MethodType` parameters:
https://github.com/openjdk/jdk/blob/de90204b60c408ef258a2d2515ad252de4b23536/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java#L231-L240

And?there is?no?other bootstrap?method in?`StringConcatFactory` at?the?moment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792745509

From amitkumar at openjdk.org  Wed Oct  9 05:17:07 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 9 Oct 2024 05:17:07 GMT
Subject: RFR: 8327652: S390x: Implements SLP support [v11]
In-Reply-To: <gT5D69TH1SyWEqeZj2QN__H9UqzMDLa7uE9754fQIw4=.783cf99b-3d0e-4678-9d21-3d53c2fd9ea7@github.com>
References: <xTrycoPw1Ati71ZzYe6cEUQyY-28KMxp93PC9_JuvYM=.5a3da904-b552-4e2f-9199-d3644271298d@github.com>
 <gT5D69TH1SyWEqeZj2QN__H9UqzMDLa7uE9754fQIw4=.783cf99b-3d0e-4678-9d21-3d53c2fd9ea7@github.com>
Message-ID: <Qpnaqv1xKvEbUCCz8GwRE3xwofPe7HWX9hS5tVPDGx4=.9a987458-9373-4a8b-964f-eeb38bc7c9fc@github.com>

On Mon, 23 Sep 2024 04:40:18 GMT, Sidraya Jayagond <sjayagond at openjdk.org> wrote:

>> This PR Adds SIMD support on s390x.
>
> Sidraya Jayagond has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace errors

@sid8606 Can you disable vector optimisation in string_compress, string_inflate, and string_inflate_const? Also, please address some of the suggestions that haven't been taken care of yet.

I got minimal working solution for preserving the vector registers here: https://github.com/offamitkumar/jdk/commit/71929af968533d96e126724ac1aa3350818d615b, So we are, I guess, ready to merge this one.

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

PR Review: https://git.openjdk.org/jdk/pull/18162#pullrequestreview-2356034656

From john.r.rose at oracle.com  Wed Oct  9 05:53:43 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 08 Oct 2024 22:53:43 -0700
Subject: [openjdk/jdk] 8338526: Don't store abstract and interface Klasses
 in class metaspace (PR #19157)
In-Reply-To: <b5b4ce8b-fda4-49ab-a5d0-cb0fdf34c8e1@littlepinkcloud.com>
References: <openjdk/jdk/pull/19157@github.com>
 <openjdk/jdk/pull/19157/c2340431106@github.com>
 <b5b4ce8b-fda4-49ab-a5d0-cb0fdf34c8e1@littlepinkcloud.com>
Message-ID: <F2151D7D-447C-4BE3-A5B5-211258FAFC10@oracle.com>

On 8 Oct 2024, at 4:07, Andrew Haley wrote:

> On 9/10/24 12:42, Coleen Phillimore wrote:
>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.
>
> I'm a bit concerned about this one.
>
> I'm working on megamorphic dispatch, and a uniform representation of
> compressed class pointers allows me to squeeze klass+offset into a
> single 64-bit word. This in turn allows fast and simple method
> lookups. I need, at least, to be able to use compressed interface
> pointers. If interfaces are "somewhere else", and thus incompressible,
> I can't do what I need to do.

This is an interesting use of compressed klass pointers.

It looks like the compression needs to be partial, down to about 32 bits.

A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout.

So it looks like (a) having ALL klass IDs fit in 32 bits, and (b) having all CONCRETE klass IDs fit into a smaller part of the same range, would meet all requirements.  Doing it right might require TWO new companion types for Klass*, a compact concrete klass ID, and a 32-bit klass ID (supertype to compact concrete klass ID).  I think the larger one could be called narrowKlass (current name), and maybe the narrower concrete ID could be called narrowConcreteKlass or narrowestKlass or something like that.

(Because of CDS, and maybe other factors, some compact concrete klass IDs will actually point to interfaces or abstract classes.  So narrowConcreteKlass suggests a property of its referents that isn?t exactly true.)

> ? If, however, klass and non-klass
> metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
> rather use compressed klass pointers without having to decode them.

The way I read this is to think about putting, not klass and non-klass, but concrete-klass and non-concrete-klass IDs in the same range.  (By ID I mean a compressed Klass pointer, or alternatively an index into some sort of special table that we haven?t needed to invent.)

> All I need is a way to represent interface pointers in a compact way
> in lookup tables, and to be able to get from compressed class pointers
> to the address. As long as interface pointers are in a 32-bit range
> and there's a fast way to get from compressed class to address that's
> OK.

From iklam at openjdk.org  Wed Oct  9 05:55:59 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 05:55:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <72Bo7ZIdbj2kt7jz282D-eWtaJQPWiuIZr9FvaYWAC8=.1ac0cf97-427c-4562-a2e4-b87b47372698@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
 <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>
 <72Bo7ZIdbj2kt7jz282D-eWtaJQPWiuIZr9FvaYWAC8=.1ac0cf97-427c-4562-a2e4-b87b47372698@github.com>
Message-ID: <vAIoiCdG5bfF08cocrFBjWAz2u2hDGC5mhh_xt5DdKE=.be66c604-6dc8-430c-af58-2a9270b3f284@github.com>

On Wed, 9 Oct 2024 03:49:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> We haven't done much testing with the other SCF BSMs, so I think it's better to do that in a follow-up REF.
>
> [`StringConcatFactory?::makeConcat(?)`] is?definitely deterministic, as?it simply?delegates to?[`StringConcatFactory?::makeConcatWithConstants(?)`] with?the?recipe being?based on?the?number of?[`MethodType`] parameters:
> https://github.com/openjdk/jdk/blob/de90204b60c408ef258a2d2515ad252de4b23536/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java#L231-L240
> 
> And?there is?no?other bootstrap?method in?[`StringConcatFactory`] at?the?moment.
> 
> [`MethodType`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/MethodType.html
> [`StringConcatFactory`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/StringConcatFactory.html
> [`StringConcatFactory?::makeConcat(?)`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/StringConcatFactory.html#makeConcat(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType)
> [`StringConcatFactory?::makeConcatWithConstants(?)`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/StringConcatFactory.html#makeConcatWithConstants(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType,java.lang.String,java.lang.Object...)

Since the comment says "This bootstrap method is unlikely to be used in practice", I am not sure if we can sufficiently test it (with aot-linking).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792884101

From aph at openjdk.org  Wed Oct  9 05:57:08 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 05:57:08 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <mgOY64rd3_MhQGa03f0FJJg3OrvDtxIpGR4VPWyHzpA=.39a0949a-c050-49d0-a7f6-0bbb6c79c32d@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

On 8 Oct 2024, at 4:07, Andrew Haley wrote:

> On 9/10/24 12:42, Coleen Phillimore wrote:
>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.
>
> I'm a bit concerned about this one.
>
> I'm working on megamorphic dispatch, and a uniform representation of
> compressed class pointers allows me to squeeze klass+offset into a
> single 64-bit word. This in turn allows fast and simple method
> lookups. I need, at least, to be able to use compressed interface
> pointers. If interfaces are "somewhere else", and thus incompressible,
> I can't do what I need to do.

This is an interesting use of compressed klass pointers.

It looks like the compression needs to be partial, down to about 32 bits.

A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout.

So it looks like (a) having ALL klass IDs fit in 32 bits, and (b) having all CONCRETE klass IDs fit into a smaller part of the same range, would meet all requirements.  Doing it right might require TWO new companion types for Klass*, a compact concrete klass ID, and a 32-bit klass ID (supertype to compact concrete klass ID).  I think the larger one could be called narrowKlass (current name), and maybe the narrower concrete ID could be called narrowConcreteKlass or narrowestKlass or something like that.

(Because of CDS, and maybe other factors, some compact concrete klass IDs will actually point to interfaces or abstract classes.  So narrowConcreteKlass suggests a property of its referents that isn?t exactly true.)

> ? If, however, klass and non-klass
> metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
> rather use compressed klass pointers without having to decode them.

The way I read this is to think about putting, not klass and non-klass, but concrete-klass and non-concrete-klass IDs in the same range.  (By ID I mean a compressed Klass pointer, or alternatively an index into some sort of special table that we haven?t needed to invent.)

> All I need is a way to represent interface pointers in a compact way
> in lookup tables, and to be able to get from compressed class pointers
> to the address. As long as interface pointers are in a 32-bit range
> and there's a fast way to get from compressed class to address that's
> OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401375521

From qamai at openjdk.org  Wed Oct  9 06:03:04 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Oct 2024 06:03:04 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <mgOY64rd3_MhQGa03f0FJJg3OrvDtxIpGR4VPWyHzpA=.39a0949a-c050-49d0-a7f6-0bbb6c79c32d@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <mgOY64rd3_MhQGa03f0FJJg3OrvDtxIpGR4VPWyHzpA=.39a0949a-c050-49d0-a7f6-0bbb6c79c32d@github.com>
Message-ID: <ve9dW2jlxfWmaZ1jHQLWFRKs7GQi1GmH21rRiVjJV1Y=.e3599398-cc21-47f0-ac7f-77f8539c4b25@github.com>

On Wed, 9 Oct 2024 05:53:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.
>
> On 8 Oct 2024, at 4:07, Andrew Haley wrote:
> 
>> On 9/10/24 12:42, Coleen Phillimore wrote:
>>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.
>>
>> I'm a bit concerned about this one.
>>
>> I'm working on megamorphic dispatch, and a uniform representation of
>> compressed class pointers allows me to squeeze klass+offset into a
>> single 64-bit word. This in turn allows fast and simple method
>> lookups. I need, at least, to be able to use compressed interface
>> pointers. If interfaces are "somewhere else", and thus incompressible,
>> I can't do what I need to do.
> 
> This is an interesting use of compressed klass pointers.
> 
> It looks like the compression needs to be partial, down to about 32 bits.
> 
> A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout.
> 
> So it looks like (a) having ALL klass IDs fit in 32 bits, and (b) having all CONCRETE klass IDs fit into a smaller part of the same range, would meet all requirements.  Doing it right might require TWO new companion types for Klass*, a compact concrete klass ID, and a 32-bit klass ID (supertype to compact concrete klass ID).  I think the larger one could be called narrowKlass (current name), and maybe the narrower concrete ID could be called narrowConcreteKlass or narrowestKlass or something like that.
> 
> (Because of CDS, and maybe other factors, some compact concrete klass IDs will actually point to interfaces or abstract classes.  So narrowConcreteKlass suggests a property of its referents that isn?t exactly true.)
> 
>> ? If, however, klass and non-klass
>> metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
>> rather use compressed klass pointers without having to decode them.
> 
> The way I read this is to think about putting, not klass and non-klass, but concrete-klass and non-concrete-klass IDs in the same range.  (By ID I mean a compressed Klass pointer, or alternatively an index into some sort of special table that we haven?t needed to invent.)
> 
>> All I need is a way to represent interface pointers in a compact way
>> in lookup tables, and to be able to get from compressed class pointers
>> to the address. As long as interface pointers are in a 32-bit range
>> and there's a fast way to get from compressed class to address that's
>> OK.

@theRealAph I do not know your idea regarding this matter but does compressing interface pointers independently from concrete class pointers help?

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401380082

From jrose at openjdk.org  Wed Oct  9 06:10:05 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 06:10:05 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

If the interfaces had a compact numbering, and there were a side table mapping the compact numbers to interface Klass* pointers, then I think Andrew's code would still work (with natural adjustments).

But managing such a side table is at least as complicated as just doing the pointer compression stuff we do.  (Hence my comment that we haven't had to invent side tables yet.)

Because of CDS I don't think we can treat concretes and abstracts (or even just classes and interfaces) as disjoint metadata types with separate independent compression tactics or representations.  I think we need a subtype/supertype relation between the "narrowest" and merely "narrower" klass IDs.

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401391441

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 rkennke at openjdk.org  Wed Oct  9 06:37:07 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 9 Oct 2024 06:37:07 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
 <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
 <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
Message-ID: <xf8xFVs7FxitPbz2_I4a-pq5gnu_IPVyvmAtjci2Xs8=.433d8116-a466-4561-a6f6-7bd27aca8d94@github.com>

On Tue, 3 Sep 2024 15:50:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>>> 
>>> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.
>> 
>> I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.
>
>> @tstuefe Do you have more comments on this PR?
> 
> Sorry, I was swamped the past days. I'll take a look tomorrow.

AFAIK, @tstuefe (currently on vacation) has a working prototype of a Klass-lookup-table with good performance and reasonable ?management cost?. This would make make many things much simpler and also help solve this problem because it makes irrelevant where a Klass lives.

Roman

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401435370

From john.r.rose at oracle.com  Wed Oct  9 06:40:19 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 08 Oct 2024 23:40:19 -0700
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <CN7Hdbyjs1viSsFMNtZ-9slELL9R8kBJ-LhvSVBf5Xo=.3e167a5a-3dbe-43fc-be21-3c35c66538a3@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>
 <CN7Hdbyjs1viSsFMNtZ-9slELL9R8kBJ-LhvSVBf5Xo=.3e167a5a-3dbe-43fc-be21-3c35c66538a3@github.com>
Message-ID: <1AE115AD-52F1-4E64-B878-E512B3E9158A@oracle.com>

On 8 Oct 2024, at 14:47, Ioi Lam wrote:

> On Wed, 25 Sep 2024 17:14:54 GMT, Chen Liang <liach at openjdk.org> wrote:
>
>>> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
>>> 403:         if (AOTHolder.archivedMethodTypes != null) {
>>> 404:             MethodType mt = AOTHolder.archivedMethodTypes.get(primordialMT);
>>
>> Can we populate these AOT MTs into the internTable so we only look up once?
>
> There's a trade off here --
> start-up will be slowed down if the archivedMethodTypes table is big. Also, `internTable` uses more memory as it wraps every entry inside a weak reference.

I think there is a design pattern should be thinking about,
which I have been calling the ?Three Table Solution?.  (And
there might be just Two Tables.)  The runtime table is the
existing intern table with its weak references.  It is
designed for fast queries, fast updates, and good relations
with the GC.  It does not have the best possible footprint.
The AOT table is archivedMethodTypes.  It is designed for
compactness, fast static boot-up, and reasonably fast queries.
It is read-only.  (It is permitted to have slower queries,
such as in a log N tree instead of O(1) hash table, but if
that is the case then entries should be migrated into the
main runtime table as they are extracted.)

A third table, maybe, is the startup table; it collects
entries at startup before the big main runtime table can
be created.  It might also serve instead of the runtime
table during the assembly phase.  Its main property is
simplicity, meaning lack of complex init-dependencies
on the rest of the JDK.  It does not need weak refs,
or any other kind of scalability, because it will
be quickly retired when the system boots up.  In
fact, the AOT table is likely to fulfill all early
queries, so the startup table is probably empty,
as long as an AOT cache is available.  The startup
table might be useful for exploded builds, as well
as for the assembly phase.  Note that while the
startup table exists, the main runtime table is
not yet created; its static reference is null.
(It should be a @Stable field!)

That third table is not very useful if we can figure
out how to use the main runtime table (with its
weak refs) at all init phases.  So maybe this design
pattern is the Two Table Solution, if we can tame
weak refs for Leyden.

But I do think we have a long-term need for two
tables, with an AOT one optimized for fast boot-up
and compactness (and slow to create, and not mutated
during startup).

The order of operations could be:

A. check AOT table; if present, return
B. check main table or startup table; if present, return
C. make new object, install in appropriate table, return

But in some cases it is better to always check the main
table first, if it exists.  (A @Stable reference will
make the query method inline, after the JIT gets ahold
of the object.)  Like this:

A. check main table; if present, return
B. check AOT table or startup table
B1. if present, and if main table exists, move to main table
B2. if present, then return
C. make new object, install in appropriate table, return

> PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782292378

From dnsimon at openjdk.org  Wed Oct  9 06:47:02 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Oct 2024 06:47:02 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <vGjmPl73Jq54k8FJpF2LgCLjf7wahlG98nYF_lucoY0=.61e1d4fd-f8ca-4265-a777-6ee40475eb06@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <vGjmPl73Jq54k8FJpF2LgCLjf7wahlG98nYF_lucoY0=.61e1d4fd-f8ca-4265-a777-6ee40475eb06@github.com>
Message-ID: <wr5tVmGJKKQArCIBZ5CmbJi3Ok9Or6JXEceEX_qEhfM=.69ea78c8-19c0-4910-81a4-15840829fc42@github.com>

On Wed, 9 Oct 2024 00:10:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @dougxc will this affect Graal?

@mur47x111 can you please check (if you haven't already).

Thanks for the heads up @vnkozlov .

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

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2401452929

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:40:00 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Oct 2024 07:40:00 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
Message-ID: <ru0koTyWprBh2VhXwHgw-RQenImZOZaI7zzp--KEdCs=.08e22d1e-1b31-4191-8fbb-a7d64267a60f@github.com>

On Tue, 8 Oct 2024 06:17:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.
> 
> Additonal testing:
> 
> - [x] aarch64 native build with slowdebug and fastdebug
> - [x] jtreg tests(include tier1/tier2/tier3 etc.) with release build

One has to wonder why this wasn't done earlier if the implementation was already there and enabling it simply required writing a simple hook into the assembler

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21400#pullrequestreview-2356304142

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 rehn at openjdk.org  Wed Oct  9 08:10:24 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 9 Oct 2024 08:10:24 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
Message-ID: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>

Hi, please consider.

RISC-V don't have dedicated call/ret instructions.
Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
The cpu have a return-address stack where it stores return addresses for prediction.
There are two possible calling conventions: x1 and x5 (or using both for co-routines).
This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:

| rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
| ------------- | ------------- | ------------- |------------- |
|No | No | ? | None|
|No | Yes | ? | Pop|
|Yes | No | ? | Push|
|Yes | Yes | No | Pop, then push|
|Yes | Yes | Yes | Push|

And additionally:
"A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."

As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
This causes performance issues as the predictions is often wrong.

Average time for 10 best iterations:
| Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
|-- | -- | -- | -- |
|future-genetic | 22126.6 | 20461.8 | -7.52%|
|akka-uct | 97119.6 | 97498 | 0.39%|
|movie-lens | 82359.3 | 81009.2 | -1.64%|
|scala-doku | 29246.1 | 24518.6 | -16.16%|
|chi-square | 10207.3 | 10624.9 | 4.09%|
|fj-kmeans | 55127.9 | 56169.1 | 1.89%|
|finagle-http | 24845 | 24891.9 | 0.19%|
|reactors | 97473.9 | 96655.5 | -0.84%|
|dec-tree | 8322.99 | 8243.11 | -0.96%|
|naive-bayes | 79249.1 | 76851.9 | -3.02%|
|als | 52678 | 51245.9 | -2.72%|
|par-mnemonics | 52237.4 | 53149.8 | 1.75%|
|scala-kmeans | 2990.88 | 2992.14 | 0.04%|
|philosophers | 9156.9 | 7754.5 | -15.32%|
|log-regression | 7621.65 | 7540.85 | -1.06%|
|gauss-mix | 9835.7 | 9396.25 | -4.47%|
|mnemonics | 73087.3 | 69426.6 | -5.01%|
|dotty | 10970.9 | 10719.1 | -2.30%|
|finagle-chirper | 23386.1 | 23630.3 | 1.04%|
|recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|

For some of workloads, e.g. call to small function in a loop, it really matters.

This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
And changes all jumps to use x6(/t1) instead of x5(/t0).
This patch was incrementally done, i.e. the first change removed the default t0.
I visited all places makings jumps, to make sure t1 was available.
Then changed to default t1 and removed argument in many cases.

Other approaches was tested, e.g. completely switch t0 <-> t1.
This was much harder and more intrusive as you need to do the switch completely in one go.
The use of x6(/t1) as flag register in C2 was luckily not an issue as RFLAGS is always killed when making a jump.
But please inspect this.

**Note** jump label was a bit more tricky. To solve that this patch defaults to only use JAL when no register is supplied, now default. We never jump to a label so far away that we need a longer range.
But please consider this carefully.

Secondly **note** CompiledICData was moved to x5(/t0), as x1+x6 (ra/t1) is used for the call.
Please inspect this also. (as this can go silently unnotice but causing UV to go into runtime for IC miss)

Arguably this is a performance bug, not an enhancement.

No issues found running t1->t3 fastdebug, re-testing more to make sure.

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

Commit messages:
 - Draft

Changes: https://git.openjdk.org/jdk/pull/21406/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340241
  Stats: 148 lines in 19 files changed: 18 ins; 3 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

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

From jbhateja at openjdk.org  Wed Oct  9 08:18:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 9 Oct 2024 08:18:31 GMT
Subject: RFR: 8341832: Incorrect continuation address of synthetic SIGSEGV for
 APX in product builds
Message-ID: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>

- Enable APX EGPRs state save restoration check which triggers synthetic SIGSEGV and verifies modified EGPRs state across OS signal handling for non-product builds to match with [corresponding logic in signal handlers.](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L251)

- Currently we haven't enabled APX support in product builds and intend to do so once entire planned support ([JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030)) is validated and checked into JDK-mainline, we are following incremental development approach for APX and hence don't want partial APX support to be enabled in intermediate releases.

Kindly review.

Best Regards,
Jatin

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

Commit messages:
 - 8341832: Incorrect continuation address of synthetic SIGSEGV for APX in product builds

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

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

From aph at openjdk.org  Wed Oct  9 08:22:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 08:22:57 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <ru0koTyWprBh2VhXwHgw-RQenImZOZaI7zzp--KEdCs=.08e22d1e-1b31-4191-8fbb-a7d64267a60f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
 <ru0koTyWprBh2VhXwHgw-RQenImZOZaI7zzp--KEdCs=.08e22d1e-1b31-4191-8fbb-a7d64267a60f@github.com>
Message-ID: <MBnytd2pzGyjItT3-dV5CFiT7W4Vkmq-mvs0CqUYRLQ=.70a0aa8a-a820-4586-afca-4c0adc073283@github.com>

On Wed, 9 Oct 2024 07:36:52 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> One has to wonder why this wasn't done earlier if the implementation was already there and enabling it simply required writing a simple hook into the assembler

https://mail.openjdk.org/pipermail/hotspot-dev/2018-June/032711.html didn't include AArch64 code. AArch64 wasn't a priority at the time, and many x86 changes never reached the AArch64 back end.

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

PR Comment: https://git.openjdk.org/jdk/pull/21400#issuecomment-2401660677

From luhenry at openjdk.org  Wed Oct  9 08:40:59 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 9 Oct 2024 08:40:59 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <qhmukXdJ8yepuv_-KslX-GEnnFT5prihr3sBPFFQd3w=.d3a946de-9fa9-403e-ac3e-c0c2026a33e7@github.com>

On Tue, 8 Oct 2024 12:54:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2895:

> 2893:   // All calls and jumps must go via MASM.
> 2894:   void jalr(Register Rd, Register Rs, const int32_t offset) {
> 2895:     assert(Rd != x5 && Rs != x5, "Register x5 not used for calls/jumps.");

Suggestion:

    assert(Rd != x5 && Rs != x5, "Register x5 should not be used for calls/jumps.");

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2910:

> 2908: 
> 2909:   void jal(Register Rd, const int32_t offset) {
> 2910:     assert(Rd != x5, "Register x5 not used for calls/jumps.");

Suggestion:

    assert(Rd != x5, "Register x5 should not be used for calls/jumps.");

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 944:

> 942: void MacroAssembler::load_link_jump(const address source, Register temp) {
> 943:   assert(temp != noreg && temp != x0, "expecting a register");
> 944:   assert(temp != x5, "Register x5 not used for calls.");

Suggestion:

  assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 973:

> 971:     Assembler::jal(x0, distance);
> 972:   } else {
> 973:     assert(temp != x5 && temp != x1, "Register x5/x1 not used for jumps.");

Suggestion:

    assert(temp != noreg && temp != x0, "expecting a register");
    assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

To keep the order consistent with https://github.com/openjdk/jdk/pull/21406/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR943

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1012:

> 1010: void MacroAssembler::jr(Register Rd, int32_t offset) {
> 1011:   assert(Rd != noreg, "expecting a register");
> 1012:   assert(Rd != x5, "Register x5 not used for jumps.");

Same as above:
Suggestion:

  assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1020:

> 1018:   assert_cond(dest != nullptr);
> 1019:   assert(temp != noreg, "expecting a register");
> 1020:   assert(temp != x5, "Register x5 not used for jumps.");

Same as above:
Suggestion:

  assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1029:

> 1027: void MacroAssembler::jalr(Register Rs, int32_t offset) {
> 1028:   assert(Rs != noreg, "expecting a register");
> 1029:   assert(Rs != x1, "expecting a register");

Same as above:
Suggestion:

  assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1035:

> 1033: 
> 1034: void MacroAssembler::rt_call(address dest, Register tmp) {
> 1035:   assert(tmp != x5, "Register x5 not used for jumps.");

Same as above:
Suggestion:

  assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793100714
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793100993
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793105370
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793107051
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793107792
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793107865
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793107965
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1793108193

From shade at openjdk.org  Wed Oct  9 08:44:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Oct 2024 08:44:34 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

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

 - Simplify: just do keep alive checks
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - More precise bit-unmasks
 - Reconcile with late barrier expansion in G1
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Review comments
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Also dispatch to slow-path on other arches
 - Fix other arches
 - Tighten up comments in Reference javadoc
 - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

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

Changes: https://git.openjdk.org/jdk/pull/20139/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=08
  Stats: 361 lines in 25 files changed: 340 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

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

From shade at openjdk.org  Wed Oct  9 08:44:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Oct 2024 08:44:35 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <1wozINQzLtWk9n5DJDqTW_BBQgwmOGQpJAfOJR70uC0=.7668e905-c863-4e69-bca1-695de43cb80a@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
 <1wozINQzLtWk9n5DJDqTW_BBQgwmOGQpJAfOJR70uC0=.7668e905-c863-4e69-bca1-695de43cb80a@github.com>
Message-ID: <N9Uf3-NXRx83CwpY5v4BVueYU3bfaN33tiODxBt_mBc=.fa0a6ff5-d945-44c5-ab70-1d484bb1c8af@github.com>

On Mon, 7 Oct 2024 08:15:21 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More precise bit-unmasks
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 342:
> 
>> 340:   }
>> 341:   if ((on_weak || on_phantom) && no_keepalive) {
>> 342:     // Be extra paranoid around this path. Only accept null stores,
> 
> I think there might be some orthogonal stuff that is unnecessarily mixed up here. When no_keepalive is manually specified, then we shouldn't do the pre-write barrier, regardless of reference strength. Similarly, when the new value is null, we don't need to perform the post write barrier, regardless of reference strength. Roberto added some code in refine_barrier_by_new_val_type that already *should* take care of the latter part. It allows types to flow around a bit, and then checks if the type of the new value is provably null, and then removes the post write barrier. The existing logic for that should be strictly more powerful than the new check you added, I think.
> 
> Based on the above explanation, I think I'm proposing this block is replaced with this simpler condition:
> 
> if (no_keepalive) {
>   access.set_barrier_data(access.barrier_data() & ~G1C2BarrierPre);
> }

Right. We also do not need this complexity in Shenandoah barriers. This check was dragged here from the load barriers that _want_ to check if we are reading the `Reference.referent` and feed it to SATB _unless_ there is a no-keep-alive. For store barriers it is unnecessary, and we can just do keep-alive checks straight up. Should be done in new commit, testing now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1793115683

From aph-open at littlepinkcloud.com  Wed Oct  9 09:00:00 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 9 Oct 2024 10:00:00 +0100
Subject: [openjdk/jdk] 8338526: Don't store abstract and interface Klasses
 in class metaspace (PR #19157)
In-Reply-To: <F2151D7D-447C-4BE3-A5B5-211258FAFC10@oracle.com>
References: <openjdk/jdk/pull/19157@github.com>
 <openjdk/jdk/pull/19157/c2340431106@github.com>
 <b5b4ce8b-fda4-49ab-a5d0-cb0fdf34c8e1@littlepinkcloud.com>
 <F2151D7D-447C-4BE3-A5B5-211258FAFC10@oracle.com>
Message-ID: <fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com>

On 10/9/24 06:53, John Rose wrote:

 > It looks like the compression needs to be partial, down to about 32 bits.

Yes, that's true. Slightly fewer bits would be nice, for tags.

 > So it looks like (a) having ALL klass IDs fit in 32 bits, and (b)
 > having all CONCRETE klass IDs fit into a smaller part of the same
 > range, would meet all requirements. Doing it right might require TWO
 > new companion types for Klass*, a compact concrete klass ID, and a
 > 32-bit klass ID (supertype to compact concrete klass ID). I think
 > the larger one could be called narrowKlass (current name), and maybe
 > the narrower concrete ID could be called narrowConcreteKlass or
 > narrowestKlass or something like that.

I see, I think.

Simply keeping all of metadata in a single 32-bit range would be very
useful. We could have instantiable Klasses in one region, followed by
non-instantiable Klasses.

 > (Because of CDS, and maybe other factors, some compact concrete
 > klass IDs will actually point to interfaces or abstract classes. So
 > narrowConcreteKlass suggests a property of its referents that isn?t
 > exactly true.)

 > The way I read this is to think about putting, not klass and
 > non-klass, but concrete-klass and non-concrete-klass IDs in the same
 > range. (By ID I mean a compressed Klass pointer, or alternatively an
 > index into some sort of special table that we haven?t needed to
 > invent.)

While I've now thought of a way to encode Klass pointers that doesn't
need them all to be in the same 32-bit range, it may well be very
useful in other contexts to ensure that they will be.

Maybe we could reduce the footprint of Klass instances. Right now,
though, my invokeinterface prototypes *increase* the size of Klass
instances, so I really want to have the possibility of using
compressed metadata pointers.

For what it's worth, I'm relieved that we're not yet making Klass
pointers a table index. Another chained load in the path of method
dispatch, at a time when I'm trying to get rid of chained loads, would
be a Bad Thing for me.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at openjdk.org  Wed Oct  9 09:03:09 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 09:03:09 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <_VdTzvXOhImLlu7ZA9PRxqK3TSrKYWAyQGXWr-XYsO0=.d8f8f09f-b655-4514-a536-1066a0dddc68@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

On 10/9/24 06:53, John Rose wrote:

 > It looks like the compression needs to be partial, down to about 32 bits.

Yes, that's true. Slightly fewer bits would be nice, for tags.

 > So it looks like (a) having ALL klass IDs fit in 32 bits, and (b)
 > having all CONCRETE klass IDs fit into a smaller part of the same
 > range, would meet all requirements. Doing it right might require TWO
 > new companion types for Klass*, a compact concrete klass ID, and a
 > 32-bit klass ID (supertype to compact concrete klass ID). I think
 > the larger one could be called narrowKlass (current name), and maybe
 > the narrower concrete ID could be called narrowConcreteKlass or
 > narrowestKlass or something like that.

I see, I think.

Simply keeping all of metadata in a single 32-bit range would be very
useful. We could have instantiable Klasses in one region, followed by
non-instantiable Klasses.

 > (Because of CDS, and maybe other factors, some compact concrete
 > klass IDs will actually point to interfaces or abstract classes. So
 > narrowConcreteKlass suggests a property of its referents that isn?t
 > exactly true.)

 > The way I read this is to think about putting, not klass and
 > non-klass, but concrete-klass and non-concrete-klass IDs in the same
 > range. (By ID I mean a compressed Klass pointer, or alternatively an
 > index into some sort of special table that we haven?t needed to
 > invent.)

While I've now thought of a way to encode Klass pointers that doesn't
need them all to be in the same 32-bit range, it may well be very
useful in other contexts to ensure that they will be.

Maybe we could reduce the footprint of Klass instances. Right now,
though, my invokeinterface prototypes *increase* the size of Klass
instances, so I really want to have the possibility of using
compressed metadata pointers.

For what it's worth, I'm relieved that we're not yet making Klass
pointers a table index. Another chained load in the path of method
dispatch, at a time when I'm trying to get rid of chained loads, would
be a Bad Thing for me.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401747594

From syan at openjdk.org  Wed Oct  9 09:06:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 09:06:03 GMT
Subject: RFR: 8341688: Aarch64: Generate comments in -XX:+PrintInterpreter
 to link to source code
In-Reply-To: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
Message-ID: <MgVKnd0vjsjHjlAK31QKYqOfNf3rO3Ttjmn2Yw8LY2A=.b5b38caf-b5b6-41e6-ba4b-2a807aa55071@github.com>

On Tue, 8 Oct 2024 06:17:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.
> 
> Additonal testing:
> 
> - [x] aarch64 native build with slowdebug and fastdebug
> - [x] jtreg tests(include tier1/tier2/tier3 etc.) with release build

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21400#issuecomment-2401752959

From syan at openjdk.org  Wed Oct  9 09:06:04 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 09:06:04 GMT
Subject: Integrated: 8341688: Aarch64: Generate comments in
 -XX:+PrintInterpreter to link to source code
In-Reply-To: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
References: <guE6JSVDeeITaE_SVXIaV85DB1rOlkPYjM_ThXWlplg=.5067281c-bb4e-4a02-8487-d2e20d74bd7f@github.com>
Message-ID: <3TG52aG2hnzg8f5mqwnwNoKkF7smmHuTKxtapaCqiUY=.60ceefd5-2ba6-42c8-808e-b9c792015e39@github.com>

On Tue, 8 Oct 2024 06:17:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The command "java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter" can be used to print a disassembly of the HotSpot interpreter.
> In [JDK-8204267](https://bugs.openjdk.org/browse/JDK-8204267), the interpreter generate comments to link the instructions back to the C++ source code that generates them, but the releated PR only support x86 backend, I think it's doable on aarch64 either.
> 
> Additonal testing:
> 
> - [x] aarch64 native build with slowdebug and fastdebug
> - [x] jtreg tests(include tier1/tier2/tier3 etc.) with release build

This pull request has now been integrated.

Changeset: d636e0d3
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d636e0d31483575cb6a37cef9faf88aff52d6a14
Stats:     22 lines in 3 files changed: 11 ins; 0 del; 11 mod

8341688: Aarch64: Generate comments in -XX:+PrintInterpreter to link to source code

Reviewed-by: aph, jsjolen, jwaters

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

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

From dmitry.chuyko at bell-sw.com  Wed Oct  9 09:18:14 2024
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Wed, 9 Oct 2024 14:18:14 +0500
Subject: Request for discussion: rewrite invokeinterface dispatch,
 JMH benchmark
In-Reply-To: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>
References: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>
Message-ID: <CAP+EAz2dAzhVr8Dcq-vB_-d-qbUdmaMCCycdV80qw+WcmRMvuA@mail.gmail.com>

Hello Andrew,

Your observations are quite interesting. If you remember
https://github.com/openjdk/jdk/pull/13460, example micro-benchmark
improvements for x86 were ~10% and only ~3% in Naive Bayes. Those results
greatly varied depending on the CPU microarchitecture and some CPUs also
showed almost no difference (some data is in the PR). However, we did not
complicate predictability in benchmarks. Also, other micro-benchmarks were
not too sensitive to the change at all. It is hard to say what are the
patterns in applications where dispatching has significant weight (which
can be as high as 15%), but won't be surprising to meet both
predictable and not predictable scenarios. It might be that the predictable
case is more common but the non-predictable case brings more pain when it
happens.

-Dmitry

On Mon, Oct 7, 2024 at 7:19?PM Andrew Haley <aph-open at littlepinkcloud.com>
wrote:

> I've been looking at rewriting invokeinterface, with a view to making
> it more efficient and predictable on today's hardware, hopefully (near)
> O(1) execution time. Also, we (again, hopefully) wouldn't need to
> dynamically generate and manage itable stubs.
>
> I've been trying a few approaches and don't yet have anything ready to
> present, but I've come across an interesting anomaly in our
> benchmarking. No matter what I did, and however bad my experiment, the
> performance barely changed at all! It was as though my changes were
> doing nothing, but eyeballing the generated code showed it was
> different.
>
> org.openjdk.bench.vm.compiler.InterfaceCalls.test2ndInt5Types looks
> like this:
>
>      as[0] = new FirstClass();
>      as[1] = new SecondClass();
>      as[2] = new ThirdClass();
>      as[3] = new FourthClass();
>      as[4] = new FifthClass();
>
>      // ...
>
>      int l = 0;
>
>      @Benchmark
>      public int test2ndInt5Types() {
>          SecondInterface ai = (SecondInterface) as[l];
>          l = ++ l % asLength;
>          return ai.getIntSecond();
>      }
>
> That is to say, we serially step through an array, invoking the same
> interface method on a different concrete class in turn.
>
> The performance (Apple M1) is sparklingly good:
>
> InterfaceCalls.test2ndInt5Types    6.026 ? 0.009      ns/op
>
> But this is so fast as to be incredible, only 19.3 clocks per
> invocation, including the control loop and the called method. A load
> from L1 cache takes about 3-4 cycles, and there are several dependent
> loads in the method lookup path. I suspected that because this
> benchmark is unrealistically predictable, it does not fairly represent
> real-world performance.
>
> So, let's try mixing it up a little, and jump about rather than
> cycling through the array:
>
>      static final int scramble(int n) {
>          int x = n;
>          x ^= x << 13;
>          x ^= x >>> 17;
>          x ^= x << 5;
>          return x == 0 ? 1 : x;
>      }
>
>      @Benchmark
>      public int test2ndInt5TypesScrambled() {
>          l = scramble(l);
>          SecondInterface ai = (SecondInterface) as[Math.floorMod(l,
> asLength)];
>          return ai.getIntSecond();
>      }
>
> This adds only a few instructions, but the measured performance is
> radically different:
>
> InterfaceCalls.test2ndInt5TypesScrambled  19.363 ? 0.084      ns/op
>
> This is 62 clocks per invocation, and I suspect this result is far
> more realistic. But is it really? Maybe invokeinterface calls are
> generally very predictable, so the benchmark we already have is
> representative.
>
> Questions:
>
> - Which benchmarks should we be optimizing for? I guess it could be
>    the scrambled one, but maybe that would have no benefit if generally
>    (or overwhelmingly often) invokeinterface is predictable.
>
> - How many of the (micro-)benchmarks in HotSpot suffer from this
>    problem? I'm guessing a lot of them, and perhaps it's partly because
>    they were written in the days when speculative execution were less
>    aggressive and branch prediction wasn't so good.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241009/88462dd9/attachment.htm>

From jbhateja at openjdk.org  Wed Oct  9 10:12:57 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 9 Oct 2024 10:12:57 GMT
Subject: RFR: 8341832: Incorrect continuation address of synthetic SIGSEGV
 for APX in product builds
In-Reply-To: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
References: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
Message-ID: <e3UyzyZWq2YeQ1B9YUwhbQkwlgqlOAYNtrv_j8a-EOs=.01dd8535-2be9-44a8-927d-e4a4043b20bb@github.com>

On Wed, 9 Oct 2024 08:09:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Enable APX EGPRs state save restoration check which triggers synthetic SIGSEGV and verifies modified EGPRs state across OS signal handling for non-product builds to match with [corresponding logic in signal handlers.](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L251)
> 
> - Currently we haven't enabled APX support in product builds and intend to do so once entire planned support ([JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030)) is validated and checked into JDK-mainline, we are following incremental development approach for APX and hence don't want partial APX support to be enabled in intermediate releases.
> 
> Kindly review.
> 
> Best Regards,
> Jatin

Hi @TobiHartmann , @vnkozlov , @sviswa7 can you kindly check this small patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21419#issuecomment-2401895714

From galder at openjdk.org  Wed Oct  9 11:07:59 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 9 Oct 2024 11:07:59 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
 <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>
Message-ID: <1hqzRjRFI8wC_c65Nc0rDAni6sxkuSqMdMeGEDZLcXo=.30446bbb-0646-4830-b840-82c0a7d882b6@github.com>

On Mon, 30 Sep 2024 10:35:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> You've probably seen this but the new test is failing IR verification:
> 
> ```
> Failed IR Rules (4) of Methods (4)
> ----------------------------------
> 1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> 
> 2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> 
> 3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> 
> 4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MinF.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> ```

@TobiHartmann the reason for this failure is that hotspot doesn't check whether max/min[F,D] intrinsics are available for x86. E.g.


  case vmIntrinsics::_maxD:
  case vmIntrinsics::_maxD_strict:
    if (!Matcher::match_rule_supported(Op_MaxD)) return false;
    break;


I tried to replicate the test failures with the latest master, but it doesn't build with x86:


* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/g/1/jdk-intrinsify-max-min-long/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp:747), pid=319052, tid=319399
#  Error: Unimplemented()
#
# JRE version: OpenJDK Runtime Environment (24.0) (fastdebug build 24-internal-adhoc.g.jdk-intrinsify-max-min-long)
# Java VM: OpenJDK Server VM (fastdebug 24-internal-adhoc.g.jdk-intrinsify-max-min-long, mixed mode, tiered, g1 gc, linux-x86)
# Problematic frame:
# V  [libjvm.so+0x529eca]  BarrierSetAssembler::refine_register(Node const*, int)+0x1a


This build failure is caused by the late barrier expansion work, which is unimplemented for x86:


OptoReg::Name BarrierSetAssembler::refine_register(const Node* node, OptoReg::Name opto_reg) {
  Unimplemented(); // This must be implemented to support late barrier expansion.
}


Looking at some other recent PRs, seems like there's no full build of x86 done any more, with only hotspot being build, and there is no testing executed. E.g. https://github.com/rwestrel/jdk/actions/runs/11145151555.

So, if x86 builds are not run, seems like there's no need to fix this? Otherwise there are several ways this can be fixed: disable test for x86, or to check max/min[F,D] intrinsics are available for x86 before adding the nodes to the IR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2402013495

From thartmann at openjdk.org  Wed Oct  9 11:24:59 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 9 Oct 2024 11:24:59 GMT
Subject: RFR: 8341832: Incorrect continuation address of synthetic SIGSEGV
 for APX in product builds
In-Reply-To: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
References: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
Message-ID: <F7prEG5_n20MWgzSCtipvcAfcKhgblE03nB_S7olliA=.1c4f7f44-fcfa-45f0-b0d7-5ca64ced4ba2@github.com>

On Wed, 9 Oct 2024 08:09:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Enable APX EGPRs state save restoration check which triggers synthetic SIGSEGV and verifies modified EGPRs state across OS signal handling for non-product builds to match with [corresponding logic in signal handlers.](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L251)
> 
> - Currently we haven't enabled APX support in product builds and intend to do so once entire planned support ([JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030)) is validated and checked into JDK-mainline, we are following incremental development approach for APX and hence don't want partial APX support to be enabled in intermediate releases.
> 
> Kindly review.
> 
> Best Regards,
> Jatin

Looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21419#pullrequestreview-2356853675

From aph-open at littlepinkcloud.com  Wed Oct  9 11:41:26 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 9 Oct 2024 12:41:26 +0100
Subject: Request for discussion: rewrite invokeinterface dispatch, JMH
 benchmark
In-Reply-To: <CAP+EAz2dAzhVr8Dcq-vB_-d-qbUdmaMCCycdV80qw+WcmRMvuA@mail.gmail.com>
References: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>
 <CAP+EAz2dAzhVr8Dcq-vB_-d-qbUdmaMCCycdV80qw+WcmRMvuA@mail.gmail.com>
Message-ID: <81a0ce3d-8389-4f94-a30e-1fd69c60ca03@littlepinkcloud.com>

On 10/9/24 10:18, Dmitry Chuyko wrote:
> If you remember
> https://github.com/openjdk/jdk/pull/13460, example micro-benchmark
> improvements for x86 were ~10% and only ~3% in Naive Bayes.

Ah, yes. Good point. I guess now we know why.

> Those results
> greatly varied depending on the CPU microarchitecture and some CPUs also
> showed almost no difference (some data is in the PR). However, we did not
> complicate predictability in benchmarks. Also, other micro-benchmarks were
> not too sensitive to the change at all. It is hard to say what are the
> patterns in applications where dispatching has significant weight (which
> can be as high as 15%), but won't be surprising to meet both
> predictable and not predictable scenarios. It might be that the predictable
> case is more common but the non-predictable case brings more pain when it
> happens.

Indeed. My guess would be that if it's as high as 15%, that's probably because
branch prediction fails.

My thinking is that I'll optimize for the unpredictable case, and the result
of that work won't much affect the performance in the highly-predictable one.

My goal with this work, apart from removing code to handle the stubs and the
unverified entry points, is to make invokeinterface performance more stable
and predictable, especially in cases where the CPU can't predict accurately
what'll happen.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


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 yzheng at openjdk.org  Wed Oct  9 11:58:04 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 9 Oct 2024 11:58:04 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <SOzpV5N5saFEyA9GsKdYS_veWvWCp_XwT96dZp7aVho=.70d1f14b-10c3-44c4-9de9-af6bf55d544c@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

Graal-side change is ready

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

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2402113612

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 cnorrbin at openjdk.org  Wed Oct  9 12:37:40 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 9 Oct 2024 12:37:40 GMT
Subject: RFR: 8318127: align_up has potential overflow [v4]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <qEicfNvOJ3k_yVujyifJPKouOXqieg7UPRVu9mOYMnE=.f6fe6589-a48e-45e0-b239-902d67605da9@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

Casper Norrbin has updated the pull request incrementally with two additional commits since the last revision:

 - update copyright header
 - align_up death tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/e50e1661..09f28289

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

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

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

From cnorrbin at openjdk.org  Wed Oct  9 12:37:41 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 9 Oct 2024 12:37:41 GMT
Subject: RFR: 8318127: align_up has potential overflow [v3]
In-Reply-To: <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <-jFjjO95iicJEN82USlv2DFMpGPbDeGp13yopPIYN34=.9db3312f-e089-4d37-bafb-17847ba63f61@github.com>
Message-ID: <9sMS9ErAG-2tKMNphb7zpxdjLNTKc_SwT-A1RwTEhSw=.6127a2f1-716a-48e6-80a8-e71833e8bbb7@github.com>

On Tue, 1 Oct 2024 14:39:10 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains two commits:
> 
>  - change reserve_memory test
>  - align overflow check

I've added a few death tests that uses combinations of signed/unsigned and small/large integer types to check for overflow

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

PR Comment: https://git.openjdk.org/jdk/pull/20808#issuecomment-2402190260

From gcao at openjdk.org  Wed Oct  9 12:46:06 2024
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 9 Oct 2024 12:46:06 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <o_FXvFuZFuLWzeJIQeEBtqAPx8FAl4jYd0w3I-9i5hs=.551302a5-6f7e-4d0a-825b-a61ca291bd3f@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

Hi, I ran some jmh tests on the arm64 platform and the performance `SecondarySupersLookup.testPositive` seems to have decreased, is this as expected?
before this patch:

Benchmark                             Mode  Cnt   Score   Error  Units
SecondarySupersLookup.testNegative00  avgt   15   2.455 ? 0.215  ns/op
SecondarySupersLookup.testNegative01  avgt   15   2.481 ? 0.202  ns/op
SecondarySupersLookup.testNegative02  avgt   15   2.455 ? 0.216  ns/op
SecondarySupersLookup.testNegative03  avgt   15   2.457 ? 0.212  ns/op
SecondarySupersLookup.testNegative04  avgt   15   2.463 ? 0.209  ns/op
SecondarySupersLookup.testNegative05  avgt   15   2.462 ? 0.211  ns/op
SecondarySupersLookup.testNegative06  avgt   15   2.455 ? 0.216  ns/op
SecondarySupersLookup.testNegative07  avgt   15   2.455 ? 0.215  ns/op
SecondarySupersLookup.testNegative08  avgt   15   2.456 ? 0.215  ns/op
SecondarySupersLookup.testNegative09  avgt   15   2.499 ? 0.199  ns/op
SecondarySupersLookup.testNegative10  avgt   15   2.456 ? 0.214  ns/op
SecondarySupersLookup.testNegative16  avgt   15   2.459 ? 0.214  ns/op
SecondarySupersLookup.testNegative20  avgt   15   2.458 ? 0.216  ns/op
SecondarySupersLookup.testNegative30  avgt   15   2.458 ? 0.215  ns/op
SecondarySupersLookup.testNegative32  avgt   15   2.457 ? 0.217  ns/op
SecondarySupersLookup.testNegative40  avgt   15   2.456 ? 0.217  ns/op
SecondarySupersLookup.testNegative50  avgt   15   2.482 ? 0.209  ns/op
SecondarySupersLookup.testNegative55  avgt   15  12.217 ? 1.594  ns/op
SecondarySupersLookup.testNegative56  avgt   15  12.756 ? 1.523  ns/op
SecondarySupersLookup.testNegative57  avgt   15  11.641 ? 1.264  ns/op
SecondarySupersLookup.testNegative58  avgt   15  11.088 ? 0.066  ns/op
SecondarySupersLookup.testNegative59  avgt   15  11.668 ? 1.256  ns/op
SecondarySupersLookup.testNegative60  avgt   15  21.025 ? 0.146  ns/op
SecondarySupersLookup.testNegative61  avgt   15  20.944 ? 0.175  ns/op
SecondarySupersLookup.testNegative62  avgt   15  21.159 ? 0.297  ns/op
SecondarySupersLookup.testNegative63  avgt   15  49.390 ? 1.943  ns/op
SecondarySupersLookup.testNegative64  avgt   15  49.426 ? 0.989  ns/op
SecondarySupersLookup.testPositive01  avgt   15   1.710 ? 0.070  ns/op
SecondarySupersLookup.testPositive02  avgt   15   1.726 ? 0.071  ns/op
SecondarySupersLookup.testPositive03  avgt   15   1.565 ? 0.169  ns/op
SecondarySupersLookup.testPositive04  avgt   15   1.591 ? 0.064  ns/op
SecondarySupersLookup.testPositive05  avgt   15   1.684 ? 0.115  ns/op
SecondarySupersLookup.testPositive06  avgt   15   1.546 ? 0.156  ns/op
SecondarySupersLookup.testPositive07  avgt   15   1.522 ? 0.134  ns/op
SecondarySupersLookup.testPositive08  avgt   15   1.479 ? 0.114  ns/op
SecondarySupersLookup.testPositive09  avgt   15   1.742 ? 0.061  ns/op
SecondarySupersLookup.testPositive10  avgt   15   1.531 ? 0.123  ns/op
SecondarySupersLookup.testPositive16  avgt   15   1.540 ? 0.150  ns/op
SecondarySupersLookup.testPositive20  avgt   15   1.558 ? 0.169  ns/op
SecondarySupersLookup.testPositive30  avgt   15   1.531 ? 0.096  ns/op
SecondarySupersLookup.testPositive32  avgt   15   1.541 ? 0.139  ns/op
SecondarySupersLookup.testPositive40  avgt   15   1.487 ? 0.101  ns/op
SecondarySupersLookup.testPositive50  avgt   15   1.521 ? 0.144  ns/op
SecondarySupersLookup.testPositive60  avgt   15   1.512 ? 0.163  ns/op
SecondarySupersLookup.testPositive63  avgt   15   1.745 ? 0.100  ns/op
SecondarySupersLookup.testPositive64  avgt   15   1.557 ? 0.190  ns/op
Finished running test 'micro:vm.lang.SecondarySupersLookup'


Apply this patch:

Benchmark                             Mode  Cnt   Score   Error  Units
SecondarySupersLookup.testNegative00  avgt   15   2.559 ? 0.141  ns/op
SecondarySupersLookup.testNegative01  avgt   15   2.603 ? 0.119  ns/op
SecondarySupersLookup.testNegative02  avgt   15   2.550 ? 0.145  ns/op
SecondarySupersLookup.testNegative03  avgt   15   2.588 ? 0.117  ns/op
SecondarySupersLookup.testNegative04  avgt   15   2.556 ? 0.144  ns/op
SecondarySupersLookup.testNegative05  avgt   15   2.623 ? 0.090  ns/op
SecondarySupersLookup.testNegative06  avgt   15   2.674 ? 0.074  ns/op
SecondarySupersLookup.testNegative07  avgt   15   2.615 ? 0.132  ns/op
SecondarySupersLookup.testNegative08  avgt   15   2.559 ? 0.136  ns/op
SecondarySupersLookup.testNegative09  avgt   15   2.581 ? 0.119  ns/op
SecondarySupersLookup.testNegative10  avgt   15   2.612 ? 0.111  ns/op
SecondarySupersLookup.testNegative16  avgt   15   2.571 ? 0.142  ns/op
SecondarySupersLookup.testNegative20  avgt   15   2.594 ? 0.119  ns/op
SecondarySupersLookup.testNegative30  avgt   15   2.560 ? 0.144  ns/op
SecondarySupersLookup.testNegative32  avgt   15   2.653 ? 0.129  ns/op
SecondarySupersLookup.testNegative40  avgt   15   2.594 ? 0.115  ns/op
SecondarySupersLookup.testNegative50  avgt   15   2.604 ? 0.125  ns/op
SecondarySupersLookup.testNegative55  avgt   15  12.003 ? 1.077  ns/op
SecondarySupersLookup.testNegative56  avgt   15  11.483 ? 0.053  ns/op
SecondarySupersLookup.testNegative57  avgt   15  12.506 ? 1.394  ns/op
SecondarySupersLookup.testNegative58  avgt   15  12.027 ? 1.157  ns/op
SecondarySupersLookup.testNegative59  avgt   15  13.481 ? 1.117  ns/op
SecondarySupersLookup.testNegative60  avgt   15  20.952 ? 0.080  ns/op
SecondarySupersLookup.testNegative61  avgt   15  21.006 ? 0.196  ns/op
SecondarySupersLookup.testNegative62  avgt   15  21.007 ? 0.098  ns/op
SecondarySupersLookup.testNegative63  avgt   15  48.050 ? 1.293  ns/op
SecondarySupersLookup.testNegative64  avgt   15  49.669 ? 0.730  ns/op
SecondarySupersLookup.testPositive01  avgt   15   4.235 ? 0.044  ns/op
SecondarySupersLookup.testPositive02  avgt   15   4.215 ? 0.032  ns/op
SecondarySupersLookup.testPositive03  avgt   15   4.211 ? 0.032  ns/op
SecondarySupersLookup.testPositive04  avgt   15   4.219 ? 0.022  ns/op
SecondarySupersLookup.testPositive05  avgt   15   4.244 ? 0.025  ns/op
SecondarySupersLookup.testPositive06  avgt   15   4.217 ? 0.038  ns/op
SecondarySupersLookup.testPositive07  avgt   15   4.221 ? 0.034  ns/op
SecondarySupersLookup.testPositive08  avgt   15   4.233 ? 0.030  ns/op
SecondarySupersLookup.testPositive09  avgt   15   4.266 ? 0.069  ns/op
SecondarySupersLookup.testPositive10  avgt   15   4.223 ? 0.039  ns/op
SecondarySupersLookup.testPositive16  avgt   15   4.234 ? 0.023  ns/op
SecondarySupersLookup.testPositive20  avgt   15   4.223 ? 0.038  ns/op
SecondarySupersLookup.testPositive30  avgt   15   4.219 ? 0.033  ns/op
SecondarySupersLookup.testPositive32  avgt   15   4.225 ? 0.052  ns/op
SecondarySupersLookup.testPositive40  avgt   15   7.201 ? 2.232  ns/op
SecondarySupersLookup.testPositive50  avgt   15   4.198 ? 0.022  ns/op
SecondarySupersLookup.testPositive60  avgt   15   6.369 ? 1.828  ns/op
SecondarySupersLookup.testPositive63  avgt   15  55.590 ? 0.208  ns/op
SecondarySupersLookup.testPositive64  avgt   15  58.098 ? 1.861  ns/op
Finished running test 'micro:vm.lang.SecondarySupersLookup'

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

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2402219616

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 fyang at openjdk.org  Wed Oct  9 13:25:35 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 9 Oct 2024 13:25:35 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <4LWBxQY9CotXHdSuIxJJxnO3FnhasE_L-IdiqlypeDA=.08e02e97-7025-4dd1-8f18-0961322ddc4d@github.com>

On Tue, 8 Oct 2024 12:54:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Great finding. Apparently, we didn't realize such an impact of this prediction hints before. Let me try this on hardwares from other vendors to see.
BTW: Does this have anything to do with the use of x6(/t1) as flag register in C2? Seems to me it's all about encoding of x1 and x5 in jalr.

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

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2402314672

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 kbarrett at openjdk.org  Wed Oct  9 13:51:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Oct 2024 13:51:01 GMT
Subject: RFR: 8318127: align_up has potential overflow [v4]
In-Reply-To: <qEicfNvOJ3k_yVujyifJPKouOXqieg7UPRVu9mOYMnE=.f6fe6589-a48e-45e0-b239-902d67605da9@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <qEicfNvOJ3k_yVujyifJPKouOXqieg7UPRVu9mOYMnE=.f6fe6589-a48e-45e0-b239-902d67605da9@github.com>
Message-ID: <NHzAFqEckrEDT9ErUsDtlS0RG2mtxSX6oYtjVTI_euU=.c82e7dcc-cc21-4262-a17c-722fad88b49e@github.com>

On Wed, 9 Oct 2024 12:37:40 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyright header
>  - align_up death tests

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/utilities/test_align.cpp line 164:

> 162: static void test_fail_alignment() {
> 163:   A alignment = max_alignment<A>();
> 164:   T value = std::numeric_limits<T>::max() - checked_cast<T>(alignment) + 10;

I think a simpler expression here would be

T value = align_down(std::numeric_limits<T>::max(), alignment) + 1;

I found it a bit harder to convince myself the original was correct.

test/hotspot/gtest/utilities/test_align.cpp line 165:

> 163:   A alignment = max_alignment<A>();
> 164:   T value = std::numeric_limits<T>::max() - checked_cast<T>(alignment) + 10;
> 165:   // Aligning up would overflow, as there isnt enough room for alignment

s/isnt/isn't/

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

PR Review: https://git.openjdk.org/jdk/pull/20808#pullrequestreview-2357186705
PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1793555574
PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1793542078

From cnorrbin at openjdk.org  Wed Oct  9 14:16:19 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 9 Oct 2024 14:16:19 GMT
Subject: RFR: 8318127: align_up has potential overflow [v5]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <zrz0vf8F4D41wnSrNf6q5vaNel_sUvgJCTp_lj3u13U=.ac97ead8-b55f-4529-9de5-dc473ec99c50@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

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

  test feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/09f28289..be66c7c4

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

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

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

From cnorrbin at openjdk.org  Wed Oct  9 14:19:38 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 9 Oct 2024 14:19:38 GMT
Subject: RFR: 8318127: align_up has potential overflow [v6]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <VjnE3N3KfR3acM3JPqAPqIr-1OJohmeBE7YadewUTC4=.ee0c8bce-1a8c-467e-847b-26a5631c3a57@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

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

  ifdef

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/be66c7c4..a62a898a

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

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

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

From cnorrbin at openjdk.org  Wed Oct  9 14:19:38 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 9 Oct 2024 14:19:38 GMT
Subject: RFR: 8318127: align_up has potential overflow [v4]
In-Reply-To: <NHzAFqEckrEDT9ErUsDtlS0RG2mtxSX6oYtjVTI_euU=.c82e7dcc-cc21-4262-a17c-722fad88b49e@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <qEicfNvOJ3k_yVujyifJPKouOXqieg7UPRVu9mOYMnE=.f6fe6589-a48e-45e0-b239-902d67605da9@github.com>
 <NHzAFqEckrEDT9ErUsDtlS0RG2mtxSX6oYtjVTI_euU=.c82e7dcc-cc21-4262-a17c-722fad88b49e@github.com>
Message-ID: <pbZpP15hsdkZN5iWl7kBfxgP28FP9_pgppLY2LOaj5Y=.bb82a31e-3d8d-42e3-8424-331fc69f5977@github.com>

On Wed, 9 Oct 2024 13:43:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyright header
>>  - align_up death tests
>
> test/hotspot/gtest/utilities/test_align.cpp line 164:
> 
>> 162: static void test_fail_alignment() {
>> 163:   A alignment = max_alignment<A>();
>> 164:   T value = std::numeric_limits<T>::max() - checked_cast<T>(alignment) + 10;
> 
> I think a simpler expression here would be
> 
> T value = align_down(std::numeric_limits<T>::max(), alignment) + 1;
> 
> I found it a bit harder to convince myself the original was correct.

Changed now! I agree that this is clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1793614484

From aph-open at littlepinkcloud.com  Wed Oct  9 14:34:46 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 9 Oct 2024 15:34:46 +0100
Subject: Request for discussion: rewrite invokeinterface dispatch, JMH
 benchmark
In-Reply-To: <CAP+EAz2dAzhVr8Dcq-vB_-d-qbUdmaMCCycdV80qw+WcmRMvuA@mail.gmail.com>
References: <72c33074-e266-4ce0-837d-2d0b96fa6a5c@littlepinkcloud.com>
 <CAP+EAz2dAzhVr8Dcq-vB_-d-qbUdmaMCCycdV80qw+WcmRMvuA@mail.gmail.com>
Message-ID: <70d1ac84-4d6d-4324-9afd-999f08565ca3@littlepinkcloud.com>

On 10/9/24 10:18, Dmitry Chuyko wrote:
 > Your observations are quite interesting. If you remember
 > https://github.com/openjdk/jdk/pull/13460, example micro-benchmark
 > improvements for x86 were ~10% and only ~3% in Naive Bayes.

In addition, if we compare and contrast your figures with my (rather
old) desktop machine, we see this:

Your benchmark results, from the PR, before and after in two columns, ns/op:

CPU: AMD EPYC 7502P (2019)
InterfaceCalls.test1stInt2Types    5.157    5.135    0.43%
InterfaceCalls.test1stInt3Types    9.882    9.807    0.76%
InterfaceCalls.test1stInt5Types    9.864    9.802    0.63%
InterfaceCalls.test2ndInt2Types    6.664    5.432   18.49%
InterfaceCalls.test2ndInt3Types   10.411   10.046    3.51%
InterfaceCalls.test2ndInt5Types   10.49    10.075    3.96%
InterfaceCalls.testIfaceCall      46.789   46.72     0.15%
InterfaceCalls.testIfaceExtCall   50.724   46.55     8.23%
InterfaceCalls.testMonomorphic     4.823    4.826    0.06%

My results, today, JDK head, AMD Ryzen Threadripper 2950X (2018) is much more
like the Apple M1:

InterfaceCalls.test1stInt2Types  2.172
InterfaceCalls.test1stInt3Types  5.721
InterfaceCalls.test1stInt5Types  6.468
InterfaceCalls.test2ndInt2Types  2.202
InterfaceCalls.test2ndInt3Types  5.981
InterfaceCalls.test2ndInt5Types  5.992
InterfaceCalls.testIfaceCall     5.722
InterfaceCalls.testIfaceExtCall  5.947
InterfaceCalls.testMonomorphic   0.990

I think the 2950X has a faster clock, but the dramatic thing is that
testIface* are the same speed as all the other "real" interface calls,
at 6ns. I guess 2950X also has better branch prediction.

Let's try to test that guess on 2950X:
                                            Regular    Scrambled
InterfaceCalls.test2ndInt5Types            5.985  20.853
InterfaceCalls.test2ndInt5TypesScrambled

:-)

Looking at some more detailed stats, the scrambled version does twice as many
memory loads and has a missed branch on each iteration, suggesting that the
CPU always speculates an entire iteration, gets it wrong, then has to do it
all again.
                                                         Regular    Scrambled
InterfaceCalls.test2ndInt5Types:L1-dcache-loads:u          31.975     60.393
InterfaceCalls.test2ndInt5Types:branch-misses:u            ? 10??      1.263

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


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 bulasevich at openjdk.org  Wed Oct  9 15:02:07 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 9 Oct 2024 15:02:07 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
Message-ID: <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>

On Wed, 9 Oct 2024 14:58:01 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> This benchmark certainly has some limitations as nops are special and can be discarded and having the 64B alignment means the core can quickly fetch and throw away as many nops as possible. I'm not sure that it's particularly representative of a real output and the benefits that code density can bring here.
>
> The behavior remains unchanged when replacing the NOP with an ADD x1,x1,x1 instruction. That said, I fully agree with you that the benchmark is peculiar, and the result doesn't necessarily indicate whether the platform is sensitive to code entry alignment. Additionally, I'd like to point out that on the same N1 platform, EEMBC's CoreMark benchmark runs 0.07% faster (a small difference, I know) on G2 when built with -falign-functions=64 compared to -falign-functions=16, with the result for -falign-functions=32 falling in between. This makes me doubt that CodeEntryAlignment=16/32 is reasonable for N1.
> 
> Let me ask Vladimir if it is possible to check the performance with CodeEntryAlignment=32 setting.

Dear @vnkozlov,
Sorry for bothering you. Is it possible to check if CodeEntryAlignment=32 setting causes the regression on Ampere system with the internal benchmark?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793687533

From bulasevich at openjdk.org  Wed Oct  9 15:02:06 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 9 Oct 2024 15:02:06 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
Message-ID: <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>

On Tue, 8 Oct 2024 21:58:17 GMT, AGSaidi <duke at openjdk.org> wrote:

>>> Could you share more data?
>> 
>> This is a simple native benchmark: https://cr.openjdk.org/~bulasevich/AlignBench.cpp
>> 
>> The program tests the performance of code starting from different alignments 
>> using a generated block of code that primarily consists of NOP (no operation)
>> and RET (return from subroutine) instructions.
>> 
>> In this experiment (though it may not be meaningful for real-world scenarios) 
>> on G2 execution time increases with misalignment from the 64-byte boundary, with the 
>> best performance at exact 64-byte alignment and slower times as the offset grows.
>> 
>> align_64+0: 391.457ms 391.157ms 391.481ms
>> align_64+4: 392.245ms 392.057ms 391.792ms
>> align_64+8: 392.154ms 392.962ms 392.65ms
>> align_64+12: 393.485ms 393.307ms 393.658ms
>> align_64+16: 394.434ms 394.679ms 394.284ms
>> align_64+20: 395.681ms 395.709ms 394.843ms
>> align_64+24: 395.799ms 396.396ms 395.977ms
>> align_64+28: 397.379ms 397.278ms 397.359ms
>> align_64+32: 397.677ms 397.82ms 397.95ms
>> align_64+36: 399.08ms 398.88ms 399.075ms
>> align_64+40: 399.829ms 400.118ms 399.981ms
>> align_64+44: 400.916ms 400.747ms 401.241ms
>> align_64+48: 401.736ms 401.831ms 402.54ms
>> align_64+52: 402.705ms 402.569ms 402.446ms
>> align_64+56: 403.718ms 403.822ms 403.535ms
>> align_64+60: 404.722ms 404.824ms 404.726ms
>> align_64+64: 390.852ms 390.669ms 391.051ms
>
> This benchmark certainly has some limitations as nops are special and can be discarded and having the 64B alignment means the core can quickly fetch and throw away as many nops as possible. I'm not sure that it's particularly representative of a real output and the benefits that code density can bring here.

The behavior remains unchanged when replacing the NOP with an ADD x1,x1,x1 instruction. That said, I fully agree with you that the benchmark is peculiar, and the result doesn't necessarily indicate whether the platform is sensitive to code entry alignment. Additionally, I'd like to point out that on the same N1 platform, EEMBC's CoreMark benchmark runs 0.07% faster (a small difference, I know) on G2 when built with -falign-functions=64 compared to -falign-functions=16, with the result for -falign-functions=32 falling in between. This makes me doubt that CodeEntryAlignment=16/32 is reasonable for N1.

Let me ask Vladimir if it is possible to check the performance with CodeEntryAlignment=32 setting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793685554

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 rehn at openjdk.org  Wed Oct  9 15:17:03 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 9 Oct 2024 15:17:03 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <4LWBxQY9CotXHdSuIxJJxnO3FnhasE_L-IdiqlypeDA=.08e02e97-7025-4dd1-8f18-0961322ddc4d@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <4LWBxQY9CotXHdSuIxJJxnO3FnhasE_L-IdiqlypeDA=.08e02e97-7025-4dd1-8f18-0961322ddc4d@github.com>
Message-ID: <x6_mRBxZpbv3RTV8V1q1ZENJUDRHziY3tGPe-lFk5tg=.12daf778-5438-4116-94e4-b476d83e0026@github.com>

On Wed, 9 Oct 2024 13:12:39 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Great finding. Apparently, we didn't realize such an impact of this prediction hints before. Let me try this on hardwares from other vendors to see. BTW: Does this have anything to do with the use of x6(/t1) as flag register in C2? Seems to me it's all about encoding of x1 and x5 in jalr.

Thanks! The issue in C2 is that you now know need to kill CR if your code in any scenario may execute a JALR (assuming the code do return), and that is not obvious.

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

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2402619218

From ngasson at openjdk.org  Wed Oct  9 15:29:09 2024
From: ngasson at openjdk.org (Nick Gasson)
Date: Wed, 9 Oct 2024 15:29:09 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v12]
In-Reply-To: <PtovUElJ6elNnZOBAWNYKL8KTZaZzTBrLF5IoPgh52U=.d2066d8e-d82d-4ab6-8e3d-fa99a9a0d207@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
 <PtovUElJ6elNnZOBAWNYKL8KTZaZzTBrLF5IoPgh52U=.d2066d8e-d82d-4ab6-8e3d-fa99a9a0d207@github.com>
Message-ID: <iATf3GKDJ-p-J9g2bjGBbVlz1O-eLniZGrR-5nruuMs=.43585ef9-5385-4dd8-8f83-2f3f19b97f59@github.com>

On Tue, 8 Oct 2024 15:13:06 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   keep comma
>
> Sorry for the inconvenience. Thanks for your quick re-reviews!

@Hamlin-Li are you still planning to re-submit the AArch64 backend changes that were in #18605 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2402652893

From shade at openjdk.org  Wed Oct  9 15:33:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Oct 2024 15:33:12 GMT
Subject: RFR: 8340547: Starting many threads can delay safepoints [v6]
In-Reply-To: <ACKmFOfB3kpOJZv6X3mNUjWExeSkVrYuahsaPMG_aYw=.4e49ab1a-b7a3-4c1c-baa9-f0582b6f64ea@github.com>
References: <dj3wx0Hq2u6Kiwg7wjmPGqvriHlcGeOa_v4maKF3c3w=.456dcfff-4eef-4426-9c0f-3c6e1c2ab653@github.com>
 <ACKmFOfB3kpOJZv6X3mNUjWExeSkVrYuahsaPMG_aYw=.4e49ab1a-b7a3-4c1c-baa9-f0582b6f64ea@github.com>
Message-ID: <hPKuchoTAD_UbGSCTV-tNVK5NDFvn-3uOu7vXkyfjuU=.77cbfede-5e6b-4461-a8b8-2cb59b1921d8@github.com>

On Mon, 30 Sep 2024 10:49:21 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Mitigate the impact of JVM_StartThread on safepoint synchronization, by adding a new ThreadStart_lock which limits the number of JVM_StartThread invocations competing for Threads_lock at any given time to 1.
>> This gives a VM thread trying to call a safepoint a much better chance of acquiring Threads_lock when there are many JVM_StartThread invocations in flight, at the cost of one extra lock/unlock for every new thread.
>> 
>> Can be disabled with new diagnostic flag `-XX:-UseExtraThreadStartLock`.
>> 
>> Before (ThreadStartTtsp.java is shared in JDK-8340547):
>> 
>> java -Xlog:safepoint ThreadStartTtsp.java | grep -o 'Reaching safepoint: [0-9]* ns'
>> Reaching safepoint: 1291591 ns
>> Reaching safepoint: 59962 ns
>> Reaching safepoint: 1958065 ns
>> Reaching safepoint: 14456666258 ns <-- 14 seconds!
>> ...
>> 
>> 
>> After:
>> 
>> java -Xlog:safepoint ThreadStartTtsp.java | grep -o 'Reaching safepoint: [0-9]* ns'
>> Reaching safepoint: 214269 ns
>> Reaching safepoint: 60253 ns
>> Reaching safepoint: 2040680 ns
>> Reaching safepoint: 3089284 ns
>> Reaching safepoint: 2998303 ns
>> Reaching safepoint: 4433713 ns <-- 4.4ms
>> Reaching safepoint: 3368436 ns
>> Reaching safepoint: 2986519 ns
>> Reaching safepoint: 3269102 ns
>> ...
>> 
>> 
>> 
>> **Alternatives**
>> 
>> I considered some other options for mitigating this. For example, could we reduce the time spent holding the lock in StartThread? Most of the time is spent managing the threads list for ThreadSMR support, and each time we add a thread to that list we need to copy the whole list and free every entry in the original, which is slow. But I didn't see an easy way to avoid this.
>> I also looked at some kind of signal from the VM thread that it is ready to start synchronizing that StartThread could check before trying to grab Threads_lock, but I didn't find anything better than this extra lock.
>
> Oli Gillespie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into threadlock-ttsp
>  - PR feedback
>  - Improve doc
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Improve comment
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Also address Thread::exit
>  - Fix lock ranking
>  - Fix build and address comments
>  - Remove unused code
>  - Improve ttsp while creating threads

All right, if Dean has more comments, we can handle them after the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/21111#issuecomment-2402655575

From ogillespie at openjdk.org  Wed Oct  9 15:33:12 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Wed, 9 Oct 2024 15:33:12 GMT
Subject: Integrated: 8340547: Starting many threads can delay safepoints
In-Reply-To: <dj3wx0Hq2u6Kiwg7wjmPGqvriHlcGeOa_v4maKF3c3w=.456dcfff-4eef-4426-9c0f-3c6e1c2ab653@github.com>
References: <dj3wx0Hq2u6Kiwg7wjmPGqvriHlcGeOa_v4maKF3c3w=.456dcfff-4eef-4426-9c0f-3c6e1c2ab653@github.com>
Message-ID: <SJ8OWVQM9PzWmYarBEHZYZvC5e6K0fMSzrgRUGlxu8Y=.32062bc0-b2c0-487f-8948-262a4dae28b4@github.com>

On Fri, 20 Sep 2024 15:31:42 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Mitigate the impact of JVM_StartThread on safepoint synchronization, by adding a new ThreadStart_lock which limits the number of JVM_StartThread invocations competing for Threads_lock at any given time to 1.
> This gives a VM thread trying to call a safepoint a much better chance of acquiring Threads_lock when there are many JVM_StartThread invocations in flight, at the cost of one extra lock/unlock for every new thread.
> 
> Can be disabled with new diagnostic flag `-XX:-UseExtraThreadStartLock`.
> 
> Before (ThreadStartTtsp.java is shared in JDK-8340547):
> 
> java -Xlog:safepoint ThreadStartTtsp.java | grep -o 'Reaching safepoint: [0-9]* ns'
> Reaching safepoint: 1291591 ns
> Reaching safepoint: 59962 ns
> Reaching safepoint: 1958065 ns
> Reaching safepoint: 14456666258 ns <-- 14 seconds!
> ...
> 
> 
> After:
> 
> java -Xlog:safepoint ThreadStartTtsp.java | grep -o 'Reaching safepoint: [0-9]* ns'
> Reaching safepoint: 214269 ns
> Reaching safepoint: 60253 ns
> Reaching safepoint: 2040680 ns
> Reaching safepoint: 3089284 ns
> Reaching safepoint: 2998303 ns
> Reaching safepoint: 4433713 ns <-- 4.4ms
> Reaching safepoint: 3368436 ns
> Reaching safepoint: 2986519 ns
> Reaching safepoint: 3269102 ns
> ...
> 
> 
> 
> **Alternatives**
> 
> I considered some other options for mitigating this. For example, could we reduce the time spent holding the lock in StartThread? Most of the time is spent managing the threads list for ThreadSMR support, and each time we add a thread to that list we need to copy the whole list and free every entry in the original, which is slow. But I didn't see an easy way to avoid this.
> I also looked at some kind of signal from the VM thread that it is ready to start synchronizing that StartThread could check before trying to grab Threads_lock, but I didn't find anything better than this extra lock.

This pull request has now been integrated.

Changeset: e704c055
Author:    Oli Gillespie <ogillespie at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e704c055a4cf2aab77cc2b3d034f5a8b8d9e3331
Stats:     15 lines in 5 files changed: 12 ins; 0 del; 3 mod

8340547: Starting many threads can delay safepoints

Reviewed-by: shade, qamai, dholmes

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

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

From mli at openjdk.org  Wed Oct  9 15:38:09 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 9 Oct 2024 15:38:09 GMT
Subject: RFR: 8320500: [vectorapi] RISC-V: Optimize vector math operations
 with SLEEF [v12]
In-Reply-To: <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
References: <EOo3NRBr0A_SY8-fE7PNbXXwThYO9oVTzFSEINbsDaM=.aa7d2b34-46de-4ca4-afc4-22fcdfa77650@github.com>
 <Nu6d1Nuh1lzG6mHHlUI9JDzuA2BbPTtsAZG8SYMYuNI=.5aaea56b-59e0-4482-a94a-420bb169ebed@github.com>
Message-ID: <5OJuk4mxYp70C1meiibmgM1dyMFw9pAYG9P_uLKNmRU=.074a7e75-ddb3-46e8-9654-e05f73436dbe@github.com>

On Tue, 8 Oct 2024 14:56:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review this patch?
>> Thanks!
>> 
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added the sleef source (in particular the generated sleef inline headers). We use sleef api to vectorize the math operations in vector api.
>> 
>> On machine with vector intrinsic support on riscv (e.g. gcc 14+) it will generate libsleef.so with the bridge functions to sleef api, otherwise without the bridge functions.
>> 
>> ### Test
>> test/jdk/jdk/incubator/vector
>> 
>> ### Performance
>> data on bananapi
>> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
>> Benchmark - bananapi | (size) | Mode | Cnt | Score +intrinsic | Error +intrinsic | Score -intrinsic | Error -intrinsic | Units | Improvement
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> Double128Vector.ACOS | 1024 | avgt | 10 | 112444.388 | 655.761 | 208554.742 | 1508.709 | ns/op | 1.855
>> Double128Vector.ASIN | 1024 | avgt | 10 | 104121.259 | 243.167 | 208314.499 | 2833.61 | ns/op | 2.001
>> Double128Vector.ATAN | 1024 | avgt | 10 | 136941.263 | 243.486 | 284024.53 | 2204.224 | ns/op | 2.074
>> Double128Vector.ATAN2 | 1024 | avgt | 10 | 163228.681 | 435.455 | 427589.587 | 3045.192 | ns/op | 2.62
>> Double128Vector.CBRT | 1024 | avgt | 10 | 146395.753 | 239.355 | 317136.654 | 1330.869 | ns/op | 2.166
>> Double128Vector.COS | 1024 | avgt | 10 | 154865.298 | 235.697 | 305721.518 | 1319.313 | ns/op | 1.974
>> Double128Vector.COSH | 1024 | avgt | 10 | 189212.943 | 262.399 | 220756.27 | 61324.863 | ns/op | 1.167
>> Double128Vector.EXP | 1024 | avgt | 10 | 113941.594 | 219.647 | 252853.07 | 891.272 | ns/op | 2.219
>> Double128Vector.EXPM1 | 1024 | avgt | 10 | 184552.939 | 513.715 | 254087.184 | 2144.997 | ns/op | 1.377
>> Double128Vector.HYPOT | 1024 | avgt | 10 | 111580.194 | 423.282 | 374537.338 | 2091.811 | ns/op | 3.357
>> Double128Vector.LOG | 1024 | avgt | 10 | 110680.548 | 192.731 | 265391.129 | 2653.519 | ns/op | 2.398
>> Double128Vector.LOG10 | 1024 | avgt | 10 | 116708.105 | 167.095 | 285764.405 | 2489.08 | ns/op | 2.449
>> Double128Vector.LOG1P | 1024 | avgt | 10 | 115633.302 | 567.7 | 317235.967 | 1062.848 | ns/op | 2.743
>> Double128Vector.POW | 1024 | avgt | 10 | 321655.14 | 3...
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep comma

Yes, I could probably send out for review next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/21083#issuecomment-2402670718

From aph at openjdk.org  Wed Oct  9 15:49:16 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 15:49:16 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <_VdTzvXOhImLlu7ZA9PRxqK3TSrKYWAyQGXWr-XYsO0=.d8f8f09f-b655-4514-a536-1066a0dddc68@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <_VdTzvXOhImLlu7ZA9PRxqK3TSrKYWAyQGXWr-XYsO0=.d8f8f09f-b655-4514-a536-1066a0dddc68@github.com>
Message-ID: <lAos3zp20SvqluCYMxKQF_YBZhu-UvK_DiBn1sRlhqc=.3da3dec3-d3f7-4f62-bd82-26520006ccac@github.com>

On Wed, 9 Oct 2024 09:00:06 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.
>
> On 10/9/24 06:53, John Rose wrote:
> 
>  > It looks like the compression needs to be partial, down to about 32 bits.
> 
> Yes, that's true. Slightly fewer bits would be nice, for tags.
> 
>  > So it looks like (a) having ALL klass IDs fit in 32 bits, and (b)
>  > having all CONCRETE klass IDs fit into a smaller part of the same
>  > range, would meet all requirements. Doing it right might require TWO
>  > new companion types for Klass*, a compact concrete klass ID, and a
>  > 32-bit klass ID (supertype to compact concrete klass ID). I think
>  > the larger one could be called narrowKlass (current name), and maybe
>  > the narrower concrete ID could be called narrowConcreteKlass or
>  > narrowestKlass or something like that.
> 
> I see, I think.
> 
> Simply keeping all of metadata in a single 32-bit range would be very
> useful. We could have instantiable Klasses in one region, followed by
> non-instantiable Klasses.
> 
>  > (Because of CDS, and maybe other factors, some compact concrete
>  > klass IDs will actually point to interfaces or abstract classes. So
>  > narrowConcreteKlass suggests a property of its referents that isn?t
>  > exactly true.)
> 
>  > The way I read this is to think about putting, not klass and
>  > non-klass, but concrete-klass and non-concrete-klass IDs in the same
>  > range. (By ID I mean a compressed Klass pointer, or alternatively an
>  > index into some sort of special table that we haven?t needed to
>  > invent.)
> 
> While I've now thought of a way to encode Klass pointers that doesn't
> need them all to be in the same 32-bit range, it may well be very
> useful in other contexts to ensure that they will be.
> 
> Maybe we could reduce the footprint of Klass instances. Right now,
> though, my invokeinterface prototypes *increase* the size of Klass
> instances, so I really want to have the possibility of using
> compressed metadata pointers.
> 
> For what it's worth, I'm relieved that we're not yet making Klass
> pointers a table index. Another chained load in the path of method
> dispatch, at a time when I'm trying to get rid of chained loads, would
> be a Bad Thing for me.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

> @theRealAph I do not know your idea regarding this matter but does compressing interface pointers independently from concrete class pointers help?

Of course that is possible, but it add complexity; and my goal is reducing complexity.

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402696292

From cnorrbin at openjdk.org  Wed Oct  9 15:59:25 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 9 Oct 2024 15:59:25 GMT
Subject: RFR: 8318127: align_up has potential overflow [v7]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <5IFuqMRNGfHDNTUL9BoNOsfk-QxtEHEuBmJ8L_fPD-Y=.f15320bd-963c-43d0-bfb0-3ad25c229149@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

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

  placed function within ifdef

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/a62a898a..67705973

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

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

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

From kbarrett at openjdk.org  Wed Oct  9 15:59:25 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Oct 2024 15:59:25 GMT
Subject: RFR: 8318127: align_up has potential overflow [v6]
In-Reply-To: <VjnE3N3KfR3acM3JPqAPqIr-1OJohmeBE7YadewUTC4=.ee0c8bce-1a8c-467e-847b-26a5631c3a57@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <VjnE3N3KfR3acM3JPqAPqIr-1OJohmeBE7YadewUTC4=.ee0c8bce-1a8c-467e-847b-26a5631c3a57@github.com>
Message-ID: <bLnZGn1KrCvPiu-z4rcUXtNbXEe5MJXh2z-FOFFA5fk=.4acf1389-628f-40fa-85b4-3fad7c70a0c0@github.com>

On Wed, 9 Oct 2024 14:19:38 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ifdef

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/utilities/test_align.cpp line 208:

> 206: }
> 207: 
> 208: #ifdef ASSERT

I forgot about the need for this. Glad you caught it.

But include test_fail_alignment under the conditional, to avoid possibility of "defined but unused" warnings.

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

PR Review: https://git.openjdk.org/jdk/pull/20808#pullrequestreview-2357556792
PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1793768593

From aph at openjdk.org  Wed Oct  9 16:10:11 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 16:10:11 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>
Message-ID: <j9uvo6mWz-7FcaaT1PD57iqUthx2SPo_94lg9kURbJ0=.7f9d6937-9af7-4a94-9809-6ae1eecb1472@github.com>

On Wed, 9 Oct 2024 06:07:13 GMT, John R Rose <jrose at openjdk.org> wrote:

> If the interfaces had a compact numbering, and there were a side table mapping the compact numbers to interface Klass* pointers, then I think Andrew's code would still work (with natural adjustments).

Probably, yes. I can pack klass ID+ [iv]table offset into a word to identify a method, or use a compressed metadata pointer. But I have a data dependency on a table load to get from a compressed Klass ID of some sort to a `Klass*`, that's a 3-to-5-cycle stall.

> But managing such a side table is at least as complicated as just doing the pointer compression stuff we do. (Hence my comment that we haven't had to invent side tables yet.)
> 
> Because of CDS I don't think we can treat concretes and abstracts (or even just classes and interfaces) as disjoint metadata types with separate independent compression tactics or representations. I think we need a subtype/supertype relation between the "narrowest" and merely "narrower" klass IDs.

I think that's right.

Notwithstanding any side tables etc., it would be nice to make sure that all metadata is reachable with a 4Gbyte offset from some base. It's not so hard to make sure that concrete and abstract `Klass*` (and all `Method*`s) can be in that range, simply(?) by allocating everything contiguously.

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402742912

From jrose at openjdk.org  Wed Oct  9 16:17:12 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 16:17:12 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <j9uvo6mWz-7FcaaT1PD57iqUthx2SPo_94lg9kURbJ0=.7f9d6937-9af7-4a94-9809-6ae1eecb1472@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>
 <j9uvo6mWz-7FcaaT1PD57iqUthx2SPo_94lg9kURbJ0=.7f9d6937-9af7-4a94-9809-6ae1eecb1472@github.com>
Message-ID: <G4vSyXihlBRXEpQZCXgzbm7O9yRnGNtTrzBtHe2TBSA=.0894e8ef-1ee5-4ba8-93f0-bbff82a14aa6@github.com>

On Wed, 9 Oct 2024 16:07:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> simply(?) by allocating everything contiguously

Suddenly I seem to hear Boromir and Yoda, in unison, saying, "One does not simply."

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402756530

From aph at openjdk.org  Wed Oct  9 16:17:12 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 16:17:12 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
 <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
 <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
Message-ID: <b4yptr1YEYxD1xi5VOg5aDumkt0sqf9W7ZHQbmnSzXs=.300548ab-d396-42ef-8a3d-2211e0eb2a4a@github.com>

On Tue, 3 Sep 2024 15:50:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>>> 
>>> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.
>> 
>> I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.
>
>> @tstuefe Do you have more comments on this PR?
> 
> Sorry, I was swamped the past days. I'll take a look tomorrow.

> AFAIK, @tstuefe (currently on vacation) has a working prototype of a Klass-lookup-table with good performance and reasonable ?management cost?. This would make make many things much simpler and also help solve this problem because it makes irrelevant where a Klass lives.

Yeah, I get that, and I'm sure @tstuefe has done a great job. But it goes to the fundamental theorem of software engineering (FTSE), Wheeler's statement that "We can solve any problem by introducing an extra level of indirection," often followed by "?except for the problem of too many levels of indirection."

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402757801

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 jrose at openjdk.org  Wed Oct  9 16:26:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 16:26:10 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <5tNL3Oxj8lsWwS08KfTBJMK-6r4CyX9j7m3r4UIOWCA=.abe50fe3-21c4-4624-a7cc-a30d6d16296b@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

Sometimes, if you are very clever and determined, you can do the very non-simple thing of putting some items at the least level of indirection, and other items at further levels of indirection.  You'd try to put stuff you need frequently closer to the root address.

Currently everything is equally close to the root address, except that IIRC we try to put a few really performance sensitive things on the earliest cache lines.

Splitting one Klass structure into a near and a far part is doable in principle, but the complexity adds up quickly, and there is also a problem deciding what to put in the near part.

Specifically, you probably want some v-table entries, but not all v-table entries, in the near part.  (Why not all?  Because near space is relatively scarce.  The near part might even be fixed in size, depending on design.)

The bottom line for me:  I like flatter data and shorter indirection chains.  The main exception is that I ALSO like to separate hot from cold data, when the opportunity arises, and cold data is often at the end of an unused indirection.

(I think there is relatively little cold data in metaspace, and it is probably already packed inside a pointer to an Array.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402774234

From sviswanathan at openjdk.org  Wed Oct  9 16:29:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 16:29:06 GMT
Subject: RFR: 8341832: Incorrect continuation address of synthetic SIGSEGV
 for APX in product builds
In-Reply-To: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
References: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
Message-ID: <HIvCCDTSO_7BjYoMkNpghvawlI84M7MRNZ2V1kN2d5g=.7d489e29-92d7-4e96-b5c3-5f8dae2a56d4@github.com>

On Wed, 9 Oct 2024 08:09:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Enable APX EGPRs state save restoration check which triggers synthetic SIGSEGV and verifies modified EGPRs state across OS signal handling for non-product builds to match with [corresponding logic in signal handlers.](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L251)
> 
> - Currently we haven't enabled APX support in product builds and intend to do so once entire planned support ([JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030)) is validated and checked into JDK-mainline, we are following incremental development approach for APX and hence don't want partial APX support to be enabled in intermediate releases.
> 
> Kindly review.
> 
> Best Regards,
> Jatin

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21419#pullrequestreview-2357643470

From iklam at openjdk.org  Wed Oct  9 16:31:06 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 16:31:06 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v2]
In-Reply-To: <WDcmugGg1Ho_cXfOrD11YeSKCvWaj-AsqJhBMHlo-zM=.04d842f5-a0d1-4617-88be-3a818170bb9e@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <WDcmugGg1Ho_cXfOrD11YeSKCvWaj-AsqJhBMHlo-zM=.04d842f5-a0d1-4617-88be-3a818170bb9e@github.com>
Message-ID: <duLzo2KxHiq07fAWcI7hO29sgxQZLJkOkBNBQcbwyjo=.bebe519f-6249-41f2-9809-a49395623cdb@github.com>

On Tue, 8 Oct 2024 17:18:46 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> Matias Saavedra Silva 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:
> 
>  - Removed test from problem list
>  - Merge branch 'master' into dumpRuntimeClassesTest_8341452
>  - 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java from JDK-8324259 is failing

The purpose of [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) is to optimize the execution of regular apps executed normally. Since -Xcomp is a testing flag, it's outside of the scope of JDK-8324259.

As -Xcomp may load classes that are not used in the normal execution path, it may load other classes if the implementation of the Manifest class changes, which would require similar whack-a-mole changes as in this PR.

In addition, adding JarVerifier will increase the footprint of the CDS archive.

I think it's better to exclude this test case when -Xcomp is selected.

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

PR Comment: https://git.openjdk.org/jdk/pull/21329#issuecomment-2402785360

From kvn at openjdk.org  Wed Oct  9 17:10:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 17:10:00 GMT
Subject: RFR: 8341832: Incorrect continuation address of synthetic SIGSEGV
 for APX in product builds
In-Reply-To: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
References: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
Message-ID: <owCuGLHFN-DvJgSpLV3TOv6fCW4GWOaBNQIoDwjzQec=.1be9f1f4-a786-4b7d-9fcc-4aedc8b8013b@github.com>

On Wed, 9 Oct 2024 08:09:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Enable APX EGPRs state save restoration check which triggers synthetic SIGSEGV and verifies modified EGPRs state across OS signal handling for non-product builds to match with [corresponding logic in signal handlers.](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L251)
> 
> - Currently we haven't enabled APX support in product builds and intend to do so once entire planned support ([JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030)) is validated and checked into JDK-mainline, we are following incremental development approach for APX and hence don't want partial APX support to be enabled in intermediate releases.
> 
> Kindly review.
> 
> Best Regards,
> Jatin

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21419#pullrequestreview-2357732186

From kvn at openjdk.org  Wed Oct  9 17:36:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 17:36:05 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
 <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
Message-ID: <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>

On Wed, 9 Oct 2024 14:59:08 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> The behavior remains unchanged when replacing the NOP with an ADD x1,x1,x1 instruction. That said, I fully agree with you that the benchmark is peculiar, and the result doesn't necessarily indicate whether the platform is sensitive to code entry alignment. Additionally, I'd like to point out that on the same N1 platform, EEMBC's CoreMark benchmark runs 0.07% faster (a small difference, I know) on G2 when built with -falign-functions=64 compared to -falign-functions=16, with the result for -falign-functions=32 falling in between. This makes me doubt that CodeEntryAlignment=16/32 is reasonable for N1.
>> 
>> Let me ask Vladimir if it is possible to check the performance with CodeEntryAlignment=32 setting.
>
> Dear @vnkozlov,
> Sorry for bothering you. Is it possible to check if CodeEntryAlignment=32 setting causes the regression on Ampere system with the internal benchmark?

Okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793906804

From matsaave at openjdk.org  Wed Oct  9 17:41:31 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 9 Oct 2024 17:41:31 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS [v2]
In-Reply-To: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
Message-ID: <ZoouDiiIbjmyLeUc7nTyB57K8Z0Lz5FtndZydMgZMm0=.1a1b665a-ff19-4328-8397-5f14c64d203e@github.com>

> 8341444: Unnecessary check for JSRs in CDS

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed fatal()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21330/files
  - new: https://git.openjdk.org/jdk/pull/21330/files/9268ef48..8b599317

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

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

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

From kvn at openjdk.org  Wed Oct  9 17:44:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 17:44:01 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
 <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
 <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>
Message-ID: <Qo4M7_tYzOi3ooO0apIjQiq2wQXZ888U-vKiIhuyVWA=.a729c7c7-eacb-446f-a488-1a371a723279@github.com>

On Wed, 9 Oct 2024 17:32:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Dear @vnkozlov,
>> Sorry for bothering you. Is it possible to check if CodeEntryAlignment=32 setting causes the regression on Ampere system with the internal benchmark?
>
> Okay

We pushed into OpenJDK JMH benchmark which is similar to what we use internally:
test/micro/org/openjdk/bench/vm/compiler/CodeCacheStress.java

You can try it while we are running our testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793917488

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 jbhateja at openjdk.org  Wed Oct  9 17:47:07 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 9 Oct 2024 17:47:07 GMT
Subject: Integrated: 8341832: Incorrect continuation address of synthetic
 SIGSEGV for APX in product builds
In-Reply-To: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
References: <fxJD56vO3l8xUc9jXQWnaYdgkuKAJp3I5O0k5oK4PJU=.52350179-926d-4028-9f5d-1f375c05ed34@github.com>
Message-ID: <3LlcLPjSu70smZz7MpxZw4TGI9F7N3qWfarmBBA5ET8=.2bd0f976-836d-415c-ae2b-38357629db27@github.com>

On Wed, 9 Oct 2024 08:09:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Enable APX EGPRs state save restoration check which triggers synthetic SIGSEGV and verifies modified EGPRs state across OS signal handling for non-product builds to match with [corresponding logic in signal handlers.](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp#L251)
> 
> - Currently we haven't enabled APX support in product builds and intend to do so once entire planned support ([JDK-8329030](https://bugs.openjdk.org/browse/JDK-8329030)) is validated and checked into JDK-mainline, we are following incremental development approach for APX and hence don't want partial APX support to be enabled in intermediate releases.
> 
> Kindly review.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 3180aaa3
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3180aaa370de16eb1835e1f57664b9fb15a6bb01
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8341832: Incorrect continuation address of synthetic SIGSEGV for APX in product builds

Reviewed-by: thartmann, sviswanathan, kvn

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

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

From kvn at openjdk.org  Wed Oct  9 18:20:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 18:20:04 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <Qo4M7_tYzOi3ooO0apIjQiq2wQXZ888U-vKiIhuyVWA=.a729c7c7-eacb-446f-a488-1a371a723279@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
 <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
 <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>
 <Qo4M7_tYzOi3ooO0apIjQiq2wQXZ888U-vK
 iIhuyVWA=.a729c7c7-eacb-446f-a488-1a371a723279@github.com>
Message-ID: <O0BKeqYSxYhQgZ8uBjwm1Y0u3HPYUgi1tWcojaFXekQ=.bdacbab1-d958-478b-a8f4-dff680ce0fc6@github.com>

On Wed, 9 Oct 2024 17:41:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Okay
>
> We pushed into OpenJDK JMH benchmark which is similar to what we use internally:
> test/micro/org/openjdk/bench/vm/compiler/CodeCacheStress.java
> 
> You can try it while we are running our testing.

CodeEntryAlignment=32 has the same regression as CodeEntryAlignment=12.
And CodeEntryAlignment=64 has no regression

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793958767

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 kvn at openjdk.org  Wed Oct  9 18:28:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Oct 2024 18:28:04 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <O0BKeqYSxYhQgZ8uBjwm1Y0u3HPYUgi1tWcojaFXekQ=.bdacbab1-d958-478b-a8f4-dff680ce0fc6@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
 <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
 <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>
 <Qo4M7_tYzOi3ooO0apIjQiq2wQXZ888U-vK
 iIhuyVWA=.a729c7c7-eacb-446f-a488-1a371a723279@github.com>
 <O0BKeqYSxYhQgZ8uBjwm1Y0u3HPYUgi1tWcojaFXekQ=.bdacbab1-d958-478b-a8f4-dff680ce0fc6@github.com>
Message-ID: <t5ZOJKmv9Vhxx4TK0aHf35kB-ifoaHhORLhwdLcjeBk=.d59ed1fd-7730-45f7-b698-08e6b7f70e9e@github.com>

On Wed, 9 Oct 2024 18:17:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> We pushed into OpenJDK JMH benchmark which is similar to what we use internally:
>> test/micro/org/openjdk/bench/vm/compiler/CodeCacheStress.java
>> 
>> You can try it while we are running our testing.
>
> CodeEntryAlignment=32 has the same regression as CodeEntryAlignment=12.
> And CodeEntryAlignment=64 has no regression

All runs with CodeCacheSegmentSize=64

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793967494

From svkamath at openjdk.org  Wed Oct  9 18:31:41 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 9 Oct 2024 18:31:41 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>

> 8341052: SHA-512 implementation using SHA-NI

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

  Addressed a review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20633/files
  - new: https://git.openjdk.org/jdk/pull/20633/files/afeb5028..85c1aea9

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

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

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

From kbarrett at openjdk.org  Wed Oct  9 19:12:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Oct 2024 19:12:52 GMT
Subject: RFR: 8318127: align_up has potential overflow [v7]
In-Reply-To: <5IFuqMRNGfHDNTUL9BoNOsfk-QxtEHEuBmJ8L_fPD-Y=.f15320bd-963c-43d0-bfb0-3ad25c229149@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <5IFuqMRNGfHDNTUL9BoNOsfk-QxtEHEuBmJ8L_fPD-Y=.f15320bd-963c-43d0-bfb0-3ad25c229149@github.com>
Message-ID: <gIQrLQ5S6oxGQyrH_NOx-YgeEJZzFmDDzfWdqNYquek=.601a937c-ed49-467f-8544-873d25a7b134@github.com>

On Wed, 9 Oct 2024 15:59:25 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   placed function within ifdef

test/hotspot/gtest/utilities/test_align.cpp line 228:

> 226:   test_fail_alignment<uint64_t, uint8_t>();
> 227: }
> 228: #endif // ASSERT

github is showing a warning icon here, like maybe there isn't a newline at the end of the last line?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1794078883

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 sviswanathan at openjdk.org  Wed Oct  9 20:16:13 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 20:16:13 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
Message-ID: <QufJyrENCBORm9HRZoIbdZYi-9YQSfEfYgJKp835OO8=.c28970eb-1f01-4068-ae0b-139a55c0d45e@github.com>

On Wed, 9 Oct 2024 18:31:41 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed a review comment

Marked as reviewed by sviswanathan (Reviewer).

Looks good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/20633#pullrequestreview-2358219543
PR Comment: https://git.openjdk.org/jdk/pull/20633#issuecomment-2403346825

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 dlong at openjdk.org  Wed Oct  9 21:07:19 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Oct 2024 21:07:19 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <T_vPGIfLyQFxp2baeG1HaWR2D1MU6GsKETcc-8LFIkM=.52de8792-fe8a-4768-a34e-84551895813b@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1446:

> 1444:   sub(rscratch1, super_check_offset, in_bytes(Klass::secondary_super_cache_offset()));
> 1445:   if (L_failure == &L_fallthrough) {
> 1446:     cbz(rscratch1, *L_slow_path);

What's the reason for changing to cbz/cbnz from subs and branching on condition codes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794228192

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 dlong at openjdk.org  Wed Oct  9 23:13:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Oct 2024 23:13:21 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <Lu1HQosgahPFlb5FKAOC75eM1pTJerjBfntt1kFReu4=.7ef529bb-a760-43f4-9bf5-ba5e0638ca48@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1820:

> 1818:   // mov(r_array_index, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
> 1819:   // sub(slot, r_array_index, slot);
> 1820:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));

Should we assert SECONDARY_SUPERS_TABLE_SIZE is a power of 2 here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794362398

From dlong at openjdk.org  Wed Oct  9 23:53:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Oct 2024 23:53:23 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lu1HQosgahPFlb5FKAOC75eM1pTJerjBfntt1kFReu4=.7ef529bb-a760-43f4-9bf5-ba5e0638ca48@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <Lu1HQosgahPFlb5FKAOC75eM1pTJerjBfntt1kFReu4=.7ef529bb-a760-43f4-9bf5-ba5e0638ca48@github.com>
Message-ID: <_onhoDXAMscNN5-gIBgSbix1yv0jLtEAMjB1GK821_4=.a4e40492-6108-4af6-acbf-4265934d3fb0@github.com>

On Wed, 9 Oct 2024 23:10:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1820:
> 
>> 1818:   // mov(r_array_index, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>> 1819:   // sub(slot, r_array_index, slot);
>> 1820:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
> 
> Should we assert SECONDARY_SUPERS_TABLE_SIZE is a power of 2 here?

If we used temp2 to store (Klass::SECONDARY_SUPERS_TABLE_SIZE - 1 - slot), then I think we could avoid the XOR at line 1863.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794399552

From dlong at openjdk.org  Wed Oct  9 23:53:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 9 Oct 2024 23:53:24 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <VQXM5iZCfbwdKW-A1edSS-ZSSPQa2JK-TPScgu8l5Mk=.fb8a701a-7d4e-4e6a-9840-807c7b944f90@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1863:

> 1861: 
> 1862:   // Is there another entry to check? Consult the bitmap.
> 1863:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));

Can we remove this XOR if we don't destroy the original value at line 1820?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794400204

From dlong at openjdk.org  Thu Oct 10 00:06:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Oct 2024 00:06:22 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <_onhoDXAMscNN5-gIBgSbix1yv0jLtEAMjB1GK821_4=.a4e40492-6108-4af6-acbf-4265934d3fb0@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <Lu1HQosgahPFlb5FKAOC75eM1pTJerjBfntt1kFReu4=.7ef529bb-a760-43f4-9bf5-ba5e0638ca48@github.com>
 <_onhoDXAMscNN5-gIBgSbix1yv0jLtEAMjB1GK821_4=.a4e40492-6108-4af6-acbf-4265934d3fb0@github.com>
Message-ID: <mxaRwxuXFlNeYcpnVUBxkTc6NgV7Zv02vY_Ryz3E6As=.eeaf8199-233e-4943-a77e-4cd37d1937ca@github.com>

On Wed, 9 Oct 2024 23:49:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1820:
>> 
>>> 1818:   // mov(r_array_index, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>>> 1819:   // sub(slot, r_array_index, slot);
>>> 1820:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>> 
>> Should we assert SECONDARY_SUPERS_TABLE_SIZE is a power of 2 here?
>
> If we used temp2 to store (Klass::SECONDARY_SUPERS_TABLE_SIZE - 1 - slot), then I think we could avoid the XOR at line 1863.

Or even better, can't we rotate right and then TBZ on bit 0?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794406475

From dlong at openjdk.org  Thu Oct 10 01:12:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Oct 2024 01:12:21 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <ROFm36wK0n1EuBe5kl3abMrv_0D9wTh90x3uFsD3ukg=.c0e445ae-075c-45aa-a828-63f259491215@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

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

> 182: // search for k.
> 183: bool Klass::fallback_search_secondary_supers(const Klass* k, int index, uintx rotated_bitmap) const {
> 184:   if (secondary_supers()->length() > SECONDARY_SUPERS_TABLE_SIZE - 2) {

This could use a comment, especially the "-2".

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

> 191: 
> 192:   // The check at the start of this function guarantees there are 0s
> 193:   // in the bitmap, so this loop eventually terminates.

I don't see the check that this comment is referring to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794438466
PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794437411

From dlong at openjdk.org  Thu Oct 10 01:19:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Oct 2024 01:19:20 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <ROFm36wK0n1EuBe5kl3abMrv_0D9wTh90x3uFsD3ukg=.c0e445ae-075c-45aa-a828-63f259491215@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <ROFm36wK0n1EuBe5kl3abMrv_0D9wTh90x3uFsD3ukg=.c0e445ae-075c-45aa-a828-63f259491215@github.com>
Message-ID: <GBLNpymjxGLEDXHMGLycMX4uaaSulTZ4a8H7An6j4N8=.753547f8-20a7-4c11-b09d-ce85ec2f295c@github.com>

On Thu, 10 Oct 2024 01:07:01 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/share/oops/klass.cpp line 193:
> 
>> 191: 
>> 192:   // The check at the start of this function guarantees there are 0s
>> 193:   // in the bitmap, so this loop eventually terminates.
> 
> I don't see the check that this comment is referring to.

I guess it means the check at line 184, which on the surface doesn't involve the bitmap at all, but I guess there is a directly relationship between secondary_supers()->length() and the bitmap.  It wouldn't hurt to spell this out more clearly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794441800

From dlong at openjdk.org  Thu Oct 10 01:27:16 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Oct 2024 01:27:16 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <17V-l0RJUN63KcA4-EqW1f2FB2kANddpw05gd_Au1BI=.6ab37d9d-7300-47c0-86df-4d2fc0099e3d@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

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

> 404:     }
> 405:     assert(i == secondaries->length(), "mismatch");
> 406:     postcond((int)population_count(bitmap) <= secondaries->length());

This helps explain my confusion reading fallback_search_secondary_supers().  Could we refer to this invariant there?  And could this be strengthened to :
`population_count(bitmap) == secondaries->length() || (population_count(bitmap) == SECONDARY_SUPERS_TABLE_SIZE && secondaries->length() > SECONDARY_SUPERS_TABLE_SIZE)`
?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794445824

From dlong at openjdk.org  Thu Oct 10 02:28:14 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Oct 2024 02:28:14 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <fLaUeJ_Eb-NWtFEYlKAz4SyeKyCn5Kqpkszwohfuk-Y=.c0a88b06-7293-49c3-b00b-351a81c6a064@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

src/hotspot/share/oops/klass.inline.hpp line 96:

> 94:   uintx bitmap = _secondary_supers_bitmap;
> 95: 
> 96:   constexpr int highest_bit_number = SECONDARY_SUPERS_TABLE_SIZE - 1;

It looks like this needs to be the number of bits in a uintx in order to shift out the high bits, which matches the current definition of SECONDARY_SUPERS_TABLE_SIZE.  But I'm wondering if we should separate the two, so that we could, for example, temporarily reduce SECONDARY_SUPERS_TABLE_SIZE to a smaller size for stress testing without the algorithm breaking.  So highest_bit_number here and in the assembly code would be something like sizeof(uintx) * BitsPerByte - 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794505000

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 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 shade at openjdk.org  Thu Oct 10 09:35:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Oct 2024 09:35:20 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
Message-ID: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>

See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.

Additional testing:
 - [ ] Linux AArch64 server fastdebug, `tier{1,2,3}`

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

Commit messages:
 - Fix

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

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

From aph at openjdk.org  Thu Oct 10 09:52:11 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 09:52:11 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
Message-ID: <QaAUDZdv5yvUk_XohnOVROKHU-8TfVIbivMKUMFn72k=.9948356d-ca1e-4b2c-b154-11f21db86e2b@github.com>

On Thu, 10 Oct 2024 07:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `tier{1,2,3}`

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5017:

> 5015:       lsl(d, s, CompressedOops::shift());
> 5016:     } else if (d != s) {
> 5017:       mov(d, s);

I think `MacroAssembler::mov` already does the `d != s` optimization, but perhaps it's clearer to do it here as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21443#discussion_r1795086391

From shade at openjdk.org  Thu Oct 10 09:55:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Oct 2024 09:55:10 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <QaAUDZdv5yvUk_XohnOVROKHU-8TfVIbivMKUMFn72k=.9948356d-ca1e-4b2c-b154-11f21db86e2b@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
 <QaAUDZdv5yvUk_XohnOVROKHU-8TfVIbivMKUMFn72k=.9948356d-ca1e-4b2c-b154-11f21db86e2b@github.com>
Message-ID: <ij2i_KaPXlU_CxJE-4b4Kmx0JNU9jnUNE_2eUzhjGDo=.38f764c6-849b-4438-b17e-6f807e4fa944@github.com>

On Thu, 10 Oct 2024 09:49:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
>> 
>> Additional testing:
>>  - [ ] Linux AArch64 server fastdebug, `tier{1,2,3}`
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5017:
> 
>> 5015:       lsl(d, s, CompressedOops::shift());
>> 5016:     } else if (d != s) {
>> 5017:       mov(d, s);
> 
> I think `MacroAssembler::mov` already does the `d != s` optimization, but perhaps it's clearer to do it here as well.

Yes, `mov` does the `d != s` optimization. I have no preference whether we do check here or rely on downstream check. Just peeling the `d != s` test from the original if-expression seems marginally easier to think about the patch impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21443#discussion_r1795091052

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 aph at openjdk.org  Thu Oct 10 11:03:17 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 11:03:17 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <T_vPGIfLyQFxp2baeG1HaWR2D1MU6GsKETcc-8LFIkM=.52de8792-fe8a-4768-a34e-84551895813b@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <T_vPGIfLyQFxp2baeG1HaWR2D1MU6GsKETcc-8LFIkM=.52de8792-fe8a-4768-a34e-84551895813b@github.com>
Message-ID: <TtlAWATBF_AtLxtbw3nohi5Z008CcVMeNzC9r-PuaIo=.a8990cb9-bce6-435d-8d2c-993c4b0089d1@github.com>

On Wed, 9 Oct 2024 21:04:07 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1446:
> 
>> 1444:   sub(rscratch1, super_check_offset, in_bytes(Klass::secondary_super_cache_offset()));
>> 1445:   if (L_failure == &L_fallthrough) {
>> 1446:     cbz(rscratch1, *L_slow_path);
> 
> What's the reason for changing to cbz/cbnz from subs and branching on condition codes?

When I was porting this code to AArch64, I mostly used x86_64 as my reference. In order to minimize the number of errors, I avoided AArch64 instructions such as `cbz`. That's no longer an issue, so we can use AArch64 idioms like this, which avoid the x86 problem of accidentally clobbering flags by not using flags except where necessary. I don't think there's a performance difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1795204086

From aph at openjdk.org  Thu Oct 10 11:03:17 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 11:03:17 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <mxaRwxuXFlNeYcpnVUBxkTc6NgV7Zv02vY_Ryz3E6As=.eeaf8199-233e-4943-a77e-4cd37d1937ca@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <Lu1HQosgahPFlb5FKAOC75eM1pTJerjBfntt1kFReu4=.7ef529bb-a760-43f4-9bf5-ba5e0638ca48@github.com>
 <_onhoDXAMscNN5-gIBgSbix1yv0jLtEAMjB1GK821_4=.a4e40492-6108-4af6-acbf-4265934d3fb0@github.com>
 <mxaRwxuXFlNeYcpnVUBxkTc6NgV7Zv02vY_Ryz3E6As=.eeaf8199-233e-4943-a77e-4cd37d1937ca@github.com>
Message-ID: <lIVXHnwcKhmp4z-pu27R9iDgPSnC2TEJVEg7GoMIVek=.70665e0b-4753-48d0-9cf1-34ccb6cc82b5@github.com>

On Thu, 10 Oct 2024 00:03:33 GMT, Dean Long <dlong at openjdk.org> wrote:

> Or even better, can't we rotate right and then TBZ on bit 0?

No, because we need to count the bits in the shifted value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1795207113

From aph at openjdk.org  Thu Oct 10 11:09:15 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 11:09:15 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <lIVXHnwcKhmp4z-pu27R9iDgPSnC2TEJVEg7GoMIVek=.70665e0b-4753-48d0-9cf1-34ccb6cc82b5@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <Lu1HQosgahPFlb5FKAOC75eM1pTJerjBfntt1kFReu4=.7ef529bb-a760-43f4-9bf5-ba5e0638ca48@github.com>
 <_onhoDXAMscNN5-gIBgSbix1yv0jLtEAMjB1GK821_4=.a4e40492-6108-4af6-acbf-4265934d3fb0@github.com>
 <mxaRwxuXFlNeYcpnVUBxkTc6NgV7Zv02vY_Ryz3E6As=.eeaf8199-233e-4943-a77e-4cd37d1937ca@github.com>
 <lIVXHnwcKhmp4z-pu27R9iDgPSnC2TEJVEg7GoMIVek=.70665e0b-4753-48d0-9cf1-34ccb6cc82b5@github.com>
Message-ID: <9f-t947wOVh76r4uIrQBtFX8IpjUrJy4OLMgwC9UvRE=.b44a10b9-908a-4586-9751-a93ba3b36981@github.com>

On Thu, 10 Oct 2024 11:00:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Or even better, can't we rotate right and then TBZ on bit 0?
>
>> Or even better, can't we rotate right and then TBZ on bit 0?
> 
> No, because we need to count the bits in the shifted value.

> If we used temp2 to store (Klass::SECONDARY_SUPERS_TABLE_SIZE - 1 - slot), then I think we could avoid the XOR at line 1863.

Yes, but temp2 is in use later on. XORing twice avoids the need for more complex register allocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1795219434

From aph at openjdk.org  Thu Oct 10 11:25:16 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 11:25:16 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <o_FXvFuZFuLWzeJIQeEBtqAPx8FAl4jYd0w3I-9i5hs=.551302a5-6f7e-4d0a-825b-a61ca291bd3f@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <o_FXvFuZFuLWzeJIQeEBtqAPx8FAl4jYd0w3I-9i5hs=.551302a5-6f7e-4d0a-825b-a61ca291bd3f@github.com>
Message-ID: <yCyK_m4gj_kJdeUmd0LTRhseW_MswK4z-myj2BQucu4=.03b9a4ab-ca4d-4865-8a83-8611ca3cef49@github.com>

On Wed, 9 Oct 2024 12:43:36 GMT, Gui Cao <gcao at openjdk.org> wrote:

> Hi, I ran some jmh tests on the arm64 platform and the performance `SecondarySupersLookup.testPositive` seems to have decreased, is this as expected? before this patch:

Yes.

The amazingly fast positive test results you're seeing are something of an illusion. After this patch, the single-entry `_secondary_super_cache` field, shared among all threads, is no longer in use. The use of this field led to catastrophic scaling problems.

What you're seeing in your test reult is a hangover from the "old" way of doing things. Even though C2-compiled code does not update `_secondary_super_cache`, that field just happens to contain the result of a previous lookup, either from C1 or the interpreter.

After this patch, the positive lookup time is still very fast in all reasonable cases, and it's near to the best that can be done while avoiding extreme slowdowns.

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

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2404823759

From jbhateja at openjdk.org  Thu Oct 10 12:22:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 10 Oct 2024 12:22:20 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
Message-ID: <CjSoOnUjY_Hwq-hUnOHW1PXWgYvVaj95ByvwP5HlhM4=.2a3a473d-94fd-4fbc-9656-65202026aa15@github.com>

On Wed, 9 Oct 2024 18:31:41 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed a review comment

src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 1522:

> 1520: }
> 1521: 
> 1522: void MacroAssembler::sha512_update_ni_x1(Register arg_hash, Register arg_msg, Register ofs, Register limit, bool multi_block) {

Please add a comment on this mentioning the source of algorithm.
https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t4/sha512_x1_ni_avx2.asm

src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 1602:

> 1600:       vpermq(xmm8, xmm4, 0x1b, Assembler::AVX_256bit);//ymm8 = W[20] W[21] W[22] W[23]
> 1601:       vpermq(xmm9, xmm3, 0x39, Assembler::AVX_256bit);//ymm9 = W[16] W[19] W[18] W[17]
> 1602:       vpblendd(xmm7, xmm8, xmm9, 0x3f, Assembler::AVX_256bit);//ymm7 = W[20] W[19] W[18] W[17]

[Algorithm](https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t4/sha512_x1_ni_avx2.asm) is specifically crafted for 256 bit vectors and with 512 bit extension we modify it. Do you think we should factor out following pattern and add an alternative implementation for it ?

  ```
      vpermq(xmm8, xmm4, 0x1b, Assembler::AVX_256bit);//ymm8 = W[20] W[21] W[22] W[23]
      vpermq(xmm9, xmm3, 0x39, Assembler::AVX_256bit);//ymm9 = W[16] W[19] W[18] W[17]
      vpblendd(xmm7, xmm8, xmm9, 0x3f, Assembler::AVX_256bit);//ymm7 = W[20] W[19] W[18] W[17]


This is a fixed pattern seen 4 times within computation loop and once outside the loop.
We are permuting two vectors with constant paramutation mask and blending them using immediate mask.
This is a very valid use case for two table permutation instruction VPERMI2Q (available for AVX512VL targets) 
We can store permutation pattern outside the loop into a vector and then re-use it within the loop.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1587:

> 1585:       __ sha512_AVX2(msg, state0, state1, msgtmp0, msgtmp1, msgtmp2, msgtmp3, msgtmp4,
> 1586:           buf, state, ofs, limit, rsp, multi_block, shuf_mask);
> 1587:   }

Suggestion:

    const XMMRegister msg = xmm0;
    const XMMRegister state0 = xmm1;
    const XMMRegister state1 = xmm2;
    const XMMRegister msgtmp0 = xmm3;
    const XMMRegister msgtmp1 = xmm4;
    const XMMRegister msgtmp2 = xmm5;
    const XMMRegister msgtmp3 = xmm6;
    const XMMRegister msgtmp4 = xmm7;

    const XMMRegister shuf_mask = xmm8;
     __ sha512_AVX2(msg, state0, state1, msgtmp0, msgtmp1, msgtmp2, msgtmp3, msgtmp4,
                           buf, state, ofs, limit, rsp, multi_block, shuf_mask);
  }

src/hotspot/cpu/x86/stubRoutines_x86.cpp line 446:

> 444:     0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
> 445: };
> 446: 

Remove this newline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1795316551
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1795279620
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1785638858
PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1785638760

From aph at openjdk.org  Thu Oct 10 13:16:18 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 13:16:18 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <fLaUeJ_Eb-NWtFEYlKAz4SyeKyCn5Kqpkszwohfuk-Y=.c0a88b06-7293-49c3-b00b-351a81c6a064@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <fLaUeJ_Eb-NWtFEYlKAz4SyeKyCn5Kqpkszwohfuk-Y=.c0a88b06-7293-49c3-b00b-351a81c6a064@github.com>
Message-ID: <WPBdvdmT98TDtaeUxQZLgEYYnNhqSir2W-R047nezlc=.6f6e6b7c-4f37-43dc-8070-d33c1114fab7@github.com>

On Thu, 10 Oct 2024 02:25:10 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/share/oops/klass.inline.hpp line 96:
> 
>> 94:   uintx bitmap = _secondary_supers_bitmap;
>> 95: 
>> 96:   constexpr int highest_bit_number = SECONDARY_SUPERS_TABLE_SIZE - 1;
> 
> It looks like this needs to be the number of bits in a uintx in order to shift out the high bits, which matches the current definition of SECONDARY_SUPERS_TABLE_SIZE.  But I'm wondering if we should separate the two, so that we could, for example, temporarily reduce SECONDARY_SUPERS_TABLE_SIZE to a smaller size for stress testing without the algorithm breaking.  So highest_bit_number here and in the assembly code would be something like sizeof(uintx) * BitsPerByte - 1.

Yes, it is the number of bits in the bitmap. Always 64 up 'til now. The fundamental nature of the algorithm is such that there is an occupancy bit for each possible slot. I could assert that here.

Severe stress testing is supported by `StressSecondarySupers`, which uses a terrible hash function. I think that option tests all of the code paths.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1795401743

From shade at openjdk.org  Thu Oct 10 13:22:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Oct 2024 13:22:12 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <ij2i_KaPXlU_CxJE-4b4Kmx0JNU9jnUNE_2eUzhjGDo=.38f764c6-849b-4438-b17e-6f807e4fa944@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
 <QaAUDZdv5yvUk_XohnOVROKHU-8TfVIbivMKUMFn72k=.9948356d-ca1e-4b2c-b154-11f21db86e2b@github.com>
 <ij2i_KaPXlU_CxJE-4b4Kmx0JNU9jnUNE_2eUzhjGDo=.38f764c6-849b-4438-b17e-6f807e4fa944@github.com>
Message-ID: <BxS65ZYaACLMMnEVame6hXp2jF-BuKKngyFlmp3jqmw=.5bd85c34-ca9c-49e7-b1bc-051a34605320@github.com>

On Thu, 10 Oct 2024 09:52:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5017:
>> 
>>> 5015:       lsl(d, s, CompressedOops::shift());
>>> 5016:     } else if (d != s) {
>>> 5017:       mov(d, s);
>> 
>> I think `MacroAssembler::mov` already does the `d != s` optimization, but perhaps it's clearer to do it here as well.
>
> Yes, `mov` does the `d != s` optimization. I have no preference whether we do check here or rely on downstream check. Just peeling the `d != s` test from the original if-expression seems marginally easier when thinking about the patch impact.

It is not very clear if you fine with this patch, @aph, or you want me to skip `d != s` check here. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21443#discussion_r1795417461

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 aph at openjdk.org  Thu Oct 10 13:29:15 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 13:29:15 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <WPBdvdmT98TDtaeUxQZLgEYYnNhqSir2W-R047nezlc=.6f6e6b7c-4f37-43dc-8070-d33c1114fab7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <fLaUeJ_Eb-NWtFEYlKAz4SyeKyCn5Kqpkszwohfuk-Y=.c0a88b06-7293-49c3-b00b-351a81c6a064@github.com>
 <WPBdvdmT98TDtaeUxQZLgEYYnNhqSir2W-R047nezlc=.6f6e6b7c-4f37-43dc-8070-d33c1114fab7@github.com>
Message-ID: <hXnEWerYAbbsFo6Robda9Evb-jUL8Ew90dlUTECUiuA=.2a3f2d04-dc07-4175-bdd2-ef17de69aaff@github.com>

On Thu, 10 Oct 2024 13:13:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/oops/klass.inline.hpp line 96:
>> 
>>> 94:   uintx bitmap = _secondary_supers_bitmap;
>>> 95: 
>>> 96:   constexpr int highest_bit_number = SECONDARY_SUPERS_TABLE_SIZE - 1;
>> 
>> It looks like this needs to be the number of bits in a uintx in order to shift out the high bits, which matches the current definition of SECONDARY_SUPERS_TABLE_SIZE.  But I'm wondering if we should separate the two, so that we could, for example, temporarily reduce SECONDARY_SUPERS_TABLE_SIZE to a smaller size for stress testing without the algorithm breaking.  So highest_bit_number here and in the assembly code would be something like sizeof(uintx) * BitsPerByte - 1.
>
> Yes, it is the number of bits in the bitmap. Always 64 up 'til now. The fundamental nature of the algorithm is such that there is an occupancy bit for each possible slot. I could assert that here.
> 
> Severe stress testing is supported by `StressSecondarySupers`, which uses a terrible hash function. I think that option tests all of the code paths.

And, a serious problem ensues if `SECONDARY_SUPERS_TABLE_SIZE` is smaller than the bits in the bitmap: we would have an error case for a bit set in the bitmap which is not in range. This would complexify the program and add a possible new source of error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1795428819

From aph at openjdk.org  Thu Oct 10 13:31:10 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 13:31:10 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <BxS65ZYaACLMMnEVame6hXp2jF-BuKKngyFlmp3jqmw=.5bd85c34-ca9c-49e7-b1bc-051a34605320@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
 <QaAUDZdv5yvUk_XohnOVROKHU-8TfVIbivMKUMFn72k=.9948356d-ca1e-4b2c-b154-11f21db86e2b@github.com>
 <ij2i_KaPXlU_CxJE-4b4Kmx0JNU9jnUNE_2eUzhjGDo=.38f764c6-849b-4438-b17e-6f807e4fa944@github.com>
 <BxS65ZYaACLMMnEVame6hXp2jF-BuKKngyFlmp3jqmw=.5bd85c34-ca9c-49e7-b1bc-051a34605320@github.com>
Message-ID: <9NylKNthNiMkabmKSkMzwM8g6jM8RrOSIYPPfqWFRsw=.c83f44df-4670-45a0-9f74-dd0c62f23cea@github.com>

On Thu, 10 Oct 2024 13:19:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes, `mov` does the `d != s` optimization. I have no preference whether we do check here or rely on downstream check. Just peeling the `d != s` test from the original if-expression seems marginally easier when thinking about the patch impact.
>
> It is not very clear if you fine with this patch, @aph, or you want me to skip `d != s` check here. :)

Sorry, I can't make up my mind. So leave this as it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21443#discussion_r1795433139

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 thartmann at openjdk.org  Thu Oct 10 14:28:14 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Oct 2024 14:28:14 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <1hqzRjRFI8wC_c65Nc0rDAni6sxkuSqMdMeGEDZLcXo=.30446bbb-0646-4830-b840-82c0a7d882b6@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
 <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>
 <1hqzRjRFI8wC_c65Nc0rDAni6sxkuSqMdMeGEDZLcXo=.30446bbb-0646-4830-b840-82c0a7d882b6@github.com>
Message-ID: <gxfsCnxgk6WgNY0MsC9n6x81mmgPTTQg2GwKGzAaCvU=.29d9b6f8-91b2-4ceb-a3a7-de34bc52d0c9@github.com>

On Wed, 9 Oct 2024 11:05:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> You've probably seen this but the new test is failing IR verification:
>> 
>> 
>> Failed IR Rules (4) of Methods (4)
>> ----------------------------------
>> 1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, app...
>
>> You've probably seen this but the new test is failing IR verification:
>> 
>> ```
>> Failed IR Rules (4) of Methods (4)
>> ----------------------------------
>> 1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, ...

@galderz The failure happened on x86_64, we (Oracle) don't build/test on 32-bit.

(The 32-bit build is currently broken due to [JDK-8341871](https://bugs.openjdk.org/browse/JDK-8341871))

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2405239334

From thartmann at openjdk.org  Thu Oct 10 14:28:15 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Oct 2024 14:28:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <Ywh4SAGnd9BWFTYu397rWnWiW6T0gKO_rK_m30jgsuM=.712eff81-8c99-4c94-b6e0-bd47fa43d392@github.com>

On Fri, 27 Sep 2024 14:21:57 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

The failure happens with `-XX:UseAVX=0`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2405244635

From cnorrbin at openjdk.org  Thu Oct 10 15:12:57 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 10 Oct 2024 15:12:57 GMT
Subject: RFR: 8318127: align_up has potential overflow [v8]
In-Reply-To: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
Message-ID: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com>

> Hi everyone,
> 
> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
> 
> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.

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

  newline at eof

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20808/files
  - new: https://git.openjdk.org/jdk/pull/20808/files/67705973..0b418a4c

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

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

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

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 shade at openjdk.org  Thu Oct 10 16:06:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Oct 2024 16:06:12 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <9NylKNthNiMkabmKSkMzwM8g6jM8RrOSIYPPfqWFRsw=.c83f44df-4670-45a0-9f74-dd0c62f23cea@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
 <QaAUDZdv5yvUk_XohnOVROKHU-8TfVIbivMKUMFn72k=.9948356d-ca1e-4b2c-b154-11f21db86e2b@github.com>
 <ij2i_KaPXlU_CxJE-4b4Kmx0JNU9jnUNE_2eUzhjGDo=.38f764c6-849b-4438-b17e-6f807e4fa944@github.com>
 <BxS65ZYaACLMMnEVame6hXp2jF-BuKKngyFlmp3jqmw=.5bd85c34-ca9c-49e7-b1bc-051a34605320@github.com>
 <9NylKNthNiMkabmKSkMzwM8g6jM8RrOSIYPPfqWFRsw=.c83f44df-4670-45a0-9f74-dd0c62f23cea@github.com>
Message-ID: <FX8nyuN8izNL8Cw1qAcJ-gY19GPmMRnz0yLsC4DGbow=.c93caee9-19f4-47c1-9df9-76a5d7808127@github.com>

On Thu, 10 Oct 2024 13:28:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> It is not very clear if you fine with this patch, @aph, or you want me to skip `d != s` check here. :)
>
> Sorry, I can't make up my mind. So leave this as it is.

OK, no problem. Want to formally approve the PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21443#discussion_r1795730076

From jbhateja at openjdk.org  Thu Oct 10 16:27:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 10 Oct 2024 16:27:25 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
Message-ID: <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>

On Tue, 8 Oct 2024 19:25:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
>  - Update VectorMath.java
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Typographical error fixups
>  - Doc fixups
>  - Typographic error
>  - Merge stashing and re-commit
>  - Tuning extra spaces.
>  - Tests for newly added VectorMath.* operations
>  - Test cleanups.
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/7312eea3...ce76c3e5

Hi @vnkozlov , Can you kindly run this through your test infrastructure. We have two review approvals for Java and x86 backend code.

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

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2405554905

From duke at openjdk.org  Thu Oct 10 17:00:24 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Oct 2024 17:00:24 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
Message-ID: <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>

On Sat, 5 Oct 2024 16:47:12 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
>  - fix windows build
>  - fix debug build
>  - 8341527: AVX-512 intrinsic for SHA3

Confirmed performance on my dev machine. Looks good!

Instruction selection: no complaints. `vperm*` instructions tend to be slower on AVX2, but work great here. Clean, compact and easy-to-read implementation

I don't know enough about SHA3 to do a line-by-line asm review, but that leads me to 'experimentally confirm correctness': testing.

I am wondering how you verified your code. I did spot the existing SHA3 KAT tests from the NIST PDF. The problem with those is that unless you run tests with `-Xcomp -XX:-TieredCompilation`, the test will finish before the code is even compiled. I've done that before, running test twice with either options; its 'better then nothing' (unless I am not seeing some more tests?). I much prefer some sort of fuzzing; one great thing about working on JCE intrinsics is having a ready-made 'reference implementation' to verify things against.

Except I am not sure how one would implement fuzzing for SHA3, perhaps you have some thoughts. It seems impossible to have both intrinsic and java/interpreter running concurrently. For Poly1305IntrinsicFuzzTest, I used the fact that single-block digest is not intrinsified. For MontgomeryPolynomialFuzzTest, I used the fact that we have a residue-domain implementation to compare against.

For SHA3, all roads lead to the intrinsic (which is a good thing.. except for testing). No DirectByteBuffer, nor single-block bypass.. The only potential thought is the fact that single-block intrinsic appears unreachable. Looking at `DigestBase.implCompressMultiBlock`, it will always call the multi-block intrinsic (unless I am missing some fancy predicate-generation by the JIT).

If `DigestBase.implCompressMultiBlock` were 'fixed' to require at least 2 full blocks, before calling the multiblock intrinsic, then one could implement fuzzing by alternatively disabling one of the non-/multi-block intrinsics.

src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1579:

> 1577:     }
> 1578:   }
> 1579:   void evpsrad(XMMRegister dst, KRegister mask, XMMRegister src, int shift, bool merge, int vector_len) {

more compact way to 'unhide' function from Assembler.hpp is the `using` C++ feature : `using Assembler::evpsrad;`. (You can see it being used bit further below, line 1589)

Comment repeats in (several) changes in this file.

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 85:

> 83: void StubGenerator::generate_sha3_stubs() {
> 84:   if (UseSHA3Intrinsics) {
> 85:     if (VM_Version::supports_evex()) {

This really should be an assert. i.e. All cpu-flag checks should be done in vm_version_x86.cpp and by this point if `UseSHA3Intrinsics` is on, "we are good to go"

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 148:

> 146:   __ addl(rax, 8);
> 147:   __ kmovbl(k4, rax);
> 148:   __ addl(rax, 16);

Since you need k5 soonest, you could save a few cycles by removing the propagation dependency on rax and loading the immediate directly..

(If you really want to get clever, 

  KRegister masks[] = {k1,k2,k3,k4,k5};
  for (long i=2; i<=32; i*=2) {
    __ mov64(rax, i-1);
    __ kmovbl(masks[i], rax);
  }
  ```
  Highly debatable if its actually any more readable.. so up to you)

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 152:

> 150: 
> 151:   // load the state
> 152:   __ evmovdquq(xmm0, k5, Address(state, 0), false, Assembler::AVX_512bit);

There is a potential issue with masked loads, but I confirmed (I believe) that it is not an issue here.

Background and what I tried. See [Optimization Reference Manual Vol. Chap 17.4](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html)

When using masked store and load, consider the following:
- When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation from the 
same address is blocked, until the data is written to the cache.

(I was hit by this in the Montgomery ECC intrinsic. The solution there was to break masked load into full loads/stores. That is a 5-element 512 load/store becomes a 64bit mov and 256-bit mov)

I ran JMH with this PR enabled and  collected perfasm. Didn't see any ticks on the loads(entry)/stores(exit). I believe this is because  of the `implCompressMultiBlock`. The only reason for the processor to use store-forwarding is if a store is followed immediately by a load. i.e. if `implCompress` was being called in a loop (it is), the first intrinsic would be fine, but all the subsequent ones would get stalled on entry, loading what the previous iteration only just saved.

With `implCompressMultiBlock`, the next iteration comes 'much later', and doesnt need store-forwarding.

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 178:

> 176: 
> 177:   // there will be 24 keccak rounds
> 178:   __ movl(roundsLeft, 24);

Since `roundsLeft` is a constant, you can use a C++ loop here instead. I believe the only loop variable is `constant2use`, used for memory address access.. slightly more constant access?

Not sure if this will give you any performance benefit, but its a 'relatively easy' experiment. (ie. 23 extra copies of the loop, worth the extra cache pressure?)

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

> 1314:   }
> 1315: 
> 1316:   if (UseAVX > 2) {

Should be `#ifdef _LP64`. (Similar format from above). Need to look up the cpu features required for the instructions in the intrinsic..

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

PR Review: https://git.openjdk.org/jdk/pull/21352#pullrequestreview-2352787214
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1790783146
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1790777522
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1792630210
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1792517204
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1792534573
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1790776557

From duke at openjdk.org  Thu Oct 10 17:00:24 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 10 Oct 2024 17:00:24 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
Message-ID: <ClLNLGz5sGp1pZU1jcGOo06J3zNLXk6qgmP8m6uAmdo=.875cfb7b-f686-4e17-844d-1fe4e5f15c88@github.com>

On Tue, 8 Oct 2024 23:57:15 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
>>  - fix windows build
>>  - fix debug build
>>  - 8341527: AVX-512 intrinsic for SHA3
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 148:
> 
>> 146:   __ addl(rax, 8);
>> 147:   __ kmovbl(k4, rax);
>> 148:   __ addl(rax, 16);
> 
> Since you need k5 soonest, you could save a few cycles by removing the propagation dependency on rax and loading the immediate directly..
> 
> (If you really want to get clever, 
> 
>   KRegister masks[] = {k1,k2,k3,k4,k5};
>   for (long i=2; i<=32; i*=2) {
>     __ mov64(rax, i-1);
>     __ kmovbl(masks[i], rax);
>   }
>   ```
>   Highly debatable if its actually any more readable.. so up to you)

Another alternative that is closer to the structure of your code (And uses smaller instructions..). 

- Start from the end, with `k5`, load `0x1f` constant
- Shift constant down by one and load into next KRegister
- (still could be done with a loop. but you decide what you find more readable..)

This way k5 is available immediately for the `evmovdquq`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1795735893

From aph at openjdk.org  Thu Oct 10 17:34:11 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 17:34:11 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
Message-ID: <e3B1yhRAtcvYZf4ZOYzaLUTZ56INfm7GUicjTlY_ZMc=.b4fe2982-1005-4cf6-9586-67d2aa88c715@github.com>

On Thu, 10 Oct 2024 07:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}`

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21443#pullrequestreview-2361007920

From matsaave at openjdk.org  Thu Oct 10 17:39:44 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 10 Oct 2024 17:39:44 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v3]
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <_coh4_grEN3RUrg21D-VnaKF9_N_rGbngoW02KJ5Tv8=.bbc40217-10c9-4195-961a-dc7c766ada47@github.com>

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Changed method name and added helper
 - Ioi comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21329/files
  - new: https://git.openjdk.org/jdk/pull/21329/files/fad43ec3..11a5499f

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

  Stats: 44 lines in 7 files changed: 13 ins; 26 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21329/head:pull/21329

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

From kbarrett at openjdk.org  Thu Oct 10 17:53:13 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 10 Oct 2024 17:53:13 GMT
Subject: RFR: 8318127: align_up has potential overflow [v8]
In-Reply-To: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com>
References: <MlXeEVxC-ffQFPqqdntnk7auLocY6G7-4NwlJ0ZtSXw=.1bf22a8d-fd30-4e3c-a02a-a4bd8e245c21@github.com>
 <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com>
Message-ID: <F35GdxY-YNN85IJpCWcDY9avPGwi8ZWM_kMqe9NhrnE=.09ed4120-9718-4ddb-ac5a-f96f74fffa1f@github.com>

On Thu, 10 Oct 2024 15:12:57 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such.
>> 
>> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline at eof

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20808#pullrequestreview-2361044111

From svkamath at openjdk.org  Thu Oct 10 18:52:30 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 10 Oct 2024 18:52:30 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v4]
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <IxDdXfa_-DBjVXq2AHcnmymtYOdDuj4MDwXb9n3MYmk=.f395cb1b-9840-4894-aab4-4adfa552fd7a@github.com>

> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.

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

  Updated code as per review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20633/files
  - new: https://git.openjdk.org/jdk/pull/20633/files/85c1aea9..3cb9175a

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

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

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

From svkamath at openjdk.org  Thu Oct 10 18:52:31 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Thu, 10 Oct 2024 18:52:31 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <CjSoOnUjY_Hwq-hUnOHW1PXWgYvVaj95ByvwP5HlhM4=.2a3a473d-94fd-4fbc-9656-65202026aa15@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
 <CjSoOnUjY_Hwq-hUnOHW1PXWgYvVaj95ByvwP5HlhM4=.2a3a473d-94fd-4fbc-9656-65202026aa15@github.com>
Message-ID: <PoOs0Bj-KerXafz-xKvt4LywFfyxb56BWcCvB8lLuCE=.18cacf79-21e6-428f-8664-c5a4624178aa@github.com>

On Thu, 10 Oct 2024 11:52:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed a review comment
>
> src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 1602:
> 
>> 1600:       vpermq(xmm8, xmm4, 0x1b, Assembler::AVX_256bit);//ymm8 = W[20] W[21] W[22] W[23]
>> 1601:       vpermq(xmm9, xmm3, 0x39, Assembler::AVX_256bit);//ymm9 = W[16] W[19] W[18] W[17]
>> 1602:       vpblendd(xmm7, xmm8, xmm9, 0x3f, Assembler::AVX_256bit);//ymm7 = W[20] W[19] W[18] W[17]
> 
> I assume [Algorithm](https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t4/sha512_x1_ni_avx2.asm) is specifically crafted for 256 bit vectors and with 512 bit extension we modify it. Do you think we should factor out following pattern and add an alternative implementation for it ?
> 
>   ```
>       vpermq(xmm8, xmm4, 0x1b, Assembler::AVX_256bit);//ymm8 = W[20] W[21] W[22] W[23]
>       vpermq(xmm9, xmm3, 0x39, Assembler::AVX_256bit);//ymm9 = W[16] W[19] W[18] W[17]
>       vpblendd(xmm7, xmm8, xmm9, 0x3f, Assembler::AVX_256bit);//ymm7 = W[20] W[19] W[18] W[17]
> 
> 
> This is a fixed pattern seen 4 times within computation loop and once outside the loop.
> We are permuting two vectors with constant paramutation mask and blending them using immediate mask.
> This is a very valid use case for two table permutation instruction VPERMI2Q (available for AVX512VL targets) 
> We can store permutation pattern outside the loop into a vector and then re-use it within the loop.

We can do this change in a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1795938470

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 dlong at openjdk.org  Thu Oct 10 20:33:15 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 10 Oct 2024 20:33:15 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <aehO4muIPAegueW0bDe_GEQTfGoO3cgbLUD_aqqrDqM=.73886e4e-a278-489f-bf4b-0402ef28d1e4@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

This looks good.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2361363132

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 duke at openjdk.org  Thu Oct 10 23:04:10 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 10 Oct 2024 23:04:10 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
Message-ID: <wg8cxzFq9TAavW9orMeXd36QNVleGNq6yj0H1ZuvwBk=.3c08a4dd-3c09-46ea-b178-b7dbfb21de9b@github.com>

On Wed, 9 Oct 2024 18:31:41 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed a review comment

This implementation looks good to me. 

I went through the implementation of `sha512_update_ni_x1`. Looked at it line by line and compared it to the ipsec [implementation](https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t4/sha512_x1_ni_avx2.asm). 

Thanks,
Srinivas Vamsi Parasa (Intel)

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

Marked as reviewed by vamsi-parasa at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/20633#pullrequestreview-2361568171

From duke at openjdk.org  Thu Oct 10 23:16:11 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 10 Oct 2024 23:16:11 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <PoOs0Bj-KerXafz-xKvt4LywFfyxb56BWcCvB8lLuCE=.18cacf79-21e6-428f-8664-c5a4624178aa@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
 <CjSoOnUjY_Hwq-hUnOHW1PXWgYvVaj95ByvwP5HlhM4=.2a3a473d-94fd-4fbc-9656-65202026aa15@github.com>
 <PoOs0Bj-KerXafz-xKvt4LywFfyxb56BWcCvB8lLuCE=.18cacf79-21e6-428f-8664-c5a4624178aa@github.com>
Message-ID: <0EVgFAWZ9O9e_dlRj4Na8Xf7QEC6FGU03wAs1bwVq5c=.ff19b62d-3b2c-4320-8be2-c7dee7cafdae@github.com>

On Thu, 10 Oct 2024 18:49:38 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86_sha.cpp line 1602:
>> 
>>> 1600:       vpermq(xmm8, xmm4, 0x1b, Assembler::AVX_256bit);//ymm8 = W[20] W[21] W[22] W[23]
>>> 1601:       vpermq(xmm9, xmm3, 0x39, Assembler::AVX_256bit);//ymm9 = W[16] W[19] W[18] W[17]
>>> 1602:       vpblendd(xmm7, xmm8, xmm9, 0x3f, Assembler::AVX_256bit);//ymm7 = W[20] W[19] W[18] W[17]
>> 
>> I assume [Algorithm](https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx2_t4/sha512_x1_ni_avx2.asm) is specifically crafted for 256 bit vectors and with 512 bit extension we modify it. Do you think we should factor out following pattern and add an alternative implementation for it ?
>> 
>>   ```
>>       vpermq(xmm8, xmm4, 0x1b, Assembler::AVX_256bit);//ymm8 = W[20] W[21] W[22] W[23]
>>       vpermq(xmm9, xmm3, 0x39, Assembler::AVX_256bit);//ymm9 = W[16] W[19] W[18] W[17]
>>       vpblendd(xmm7, xmm8, xmm9, 0x3f, Assembler::AVX_256bit);//ymm7 = W[20] W[19] W[18] W[17]
>> 
>> 
>> This is a fixed pattern seen 4 times within computation loop and once outside the loop.
>> We are permuting two vectors with constant paramutation mask and blending them using immediate mask.
>> This is a very valid use case for two table permutation instruction VPERMI2Q (available for AVX512VL targets) 
>> We can store permutation pattern outside the loop into a vector and then re-use it within the loop.
>
> We can do this change in a separate PR.

I agree with Smita. The current implementation has a one-to-one correspondence with the ipsec implementation. Any new changes or refactoring will require a new round of exhaustive testing and could be implemented as a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1796204440

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 iklam at openjdk.org  Fri Oct 11 01:37:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Oct 2024 01:37:19 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v3]
In-Reply-To: <_coh4_grEN3RUrg21D-VnaKF9_N_rGbngoW02KJ5Tv8=.bbc40217-10c9-4195-961a-dc7c766ada47@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <_coh4_grEN3RUrg21D-VnaKF9_N_rGbngoW02KJ5Tv8=.bbc40217-10c9-4195-961a-dc7c766ada47@github.com>
Message-ID: <IKVw3BewTdrdEyrE0r5m8VKZ92tnnIDBBi_vkU3cZmI=.5b6a7e48-9e02-4e58-aaaf-ba8cfe4a5deb@github.com>

On Thu, 10 Oct 2024 17:39:44 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed method name and added helper
>  - Ioi comment

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/cdsProtectionDomain.cpp line 221:

> 219:                          path_string, CHECK);
> 220: }
> 221: 

JavaValue is used only when calling Java with JavaCalls::call_static. It's better to change the API to:


oop CDSProtectionDomain::get_shared_jar_url_helper(const char* path, Handle url_h, TRAPS) {
  JavaValue result, 
  Handle path_string = java_lang_String::create_from_str(path, CHECK);
  JavaCalls::call_static(&result, ...);
  return result.get_oop();
}

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

PR Review: https://git.openjdk.org/jdk/pull/21329#pullrequestreview-2361748483
PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1796301032

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 iklam at openjdk.org  Fri Oct 11 06:48:32 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Oct 2024 06:48:32 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v3]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <D09TNJDwgd8OVBTt_488SYoevx1arDB0mewIGcd7HNE=.bf5135ba-56d1-4e44-b7f8-48379caba007@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

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

  8341600: [premain] Automatic aot-init of classes used by java.lang.invoke

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/ebfbb238..e9995ea7

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

  Stats: 477 lines in 14 files changed: 344 ins; 63 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

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

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 fyang at openjdk.org  Fri Oct 11 08:01:17 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 11 Oct 2024 08:01:17 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>

On Tue, 8 Oct 2024 12:54:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Hi, I witnessed performance improvement on other vendor's hardware too. Minor comments after a cursory look. Will take a more closer look. Thanks.

src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp line 97:

> 95:   // t0 and t1 are used as args in generate_exception_throw?
> 96:   // so use x18 as the tmp register for rt_call.
> 97:   __ rt_call(Runtime1::entry_for(stub_id), x18);

Can we use `x9` instead here? It's the first callee-save register in numbering.

src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 299:

> 297:   }
> 298:   if (entry_point != nullptr) {
> 299:     __ mv(t1, continuation);

I see `continuation` will be changed into `x9` for some switch cases, so maybe we can let `continuation` be `x9` and unconditionallly move `ra` into `x9` on entry. That would save the update of `continuation` and avoid use of `t1`, which I think will be cleaner.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 722:

> 720:   __ mv(x13, array);
> 721:   __ mv(t1, Interpreter::_throw_ArrayIndexOutOfBoundsException_entry);
> 722:   __ jr(t1);

Please also update preceding code comment: `// destroys x11, t0, t1`

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

PR Review: https://git.openjdk.org/jdk/pull/21406#pullrequestreview-2362130148
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1796575024
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1796548679
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1796537523

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 fyang at openjdk.org  Fri Oct 11 11:17:10 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 11 Oct 2024 11:17:10 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <x6_mRBxZpbv3RTV8V1q1ZENJUDRHziY3tGPe-lFk5tg=.12daf778-5438-4116-94e4-b476d83e0026@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <4LWBxQY9CotXHdSuIxJJxnO3FnhasE_L-IdiqlypeDA=.08e02e97-7025-4dd1-8f18-0961322ddc4d@github.com>
 <x6_mRBxZpbv3RTV8V1q1ZENJUDRHziY3tGPe-lFk5tg=.12daf778-5438-4116-94e4-b476d83e0026@github.com>
Message-ID: <CQVK1lu5VHsSFrVl1nKFvBhN_VEbhpBsI1v-_98o8Q0=.6ffd8b67-6c9b-41e8-be90-5e80822ff8e3@github.com>

On Wed, 9 Oct 2024 15:12:12 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > Great finding. Apparently, we didn't realize such an impact of this prediction hints before. Let me try this on hardwares from other vendors to see. BTW: Does this have anything to do with the use of x6(/t1) as flag register in C2? Seems to me it's all about encoding of x1 and x5 in jalr.
> 
> Thanks! The issue in C2 is that you now know need to kill CR if your code in any scenario may execute a JALR (assuming the code do return), and that is not obvious.

Ah. Now I see what you mean. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2407189035

From rehn at openjdk.org  Fri Oct 11 11:32:10 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 11 Oct 2024 11:32:10 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
Message-ID: <rmjxU0FgyMJe9wosu1XxaI2vqEbPUBYQ0x3UWgeYu-w=.2bf96e45-6534-41e2-89de-a2819fbfc106@github.com>

On Fri, 11 Oct 2024 07:58:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, I witnessed performance improvement on other vendor's hardware too. Minor comments after a cursory look. Will take a more closer look. Thanks.

Awesome, thanks !

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

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2407215907

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 jsjolen at openjdk.org  Fri Oct 11 13:56:58 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 11 Oct 2024 13:56:58 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <Rl4_InhrC70nZ6xfWfXUYbB1NY5_t_Ks41-uZhc7FTI=.50edb56e-6064-4f0c-b795-7aac927dc2af@github.com>

On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

Some style comments.

Some more comments. The general outline looks good and I like how we avoid an allocation. We do now take the cost of a virtual call, but I think that's negligible. If we can have some sort of micro benchmark for this, just something simple, that showcases the difference, that would be great.

I'm not sure, but when I look at the code it seems like the `virtual equals` method is unnecessary and can just be removed and we will regain static calls in the `ConcurrentHashTable`.

src/hotspot/share/classfile/javaClasses.cpp line 765:

> 763: }
> 764: 
> 765: bool java_lang_String::equals(oop java_string, const char* utf8_string, int len) {

I find it super confusing to use generic `len` here and would very much appreciate it if we called this `nr_unicode_points` or something like that. You could even add a comment. Honestly, I think that maybe we should change all of these functions for additional clarity.

src/hotspot/share/classfile/javaClasses.cpp line 775:

> 773:   bool is_latin1 = java_lang_String::is_latin1(java_string);
> 774:   jchar c;
> 775:   const char *ptr = utf8_string;

No need for the `ptr`, just use `utf8_str` directly.

src/hotspot/share/classfile/javaClasses.hpp line 184:

> 182:   }
> 183: 
> 184:   static unsigned int hash_code(const char *utf8_str, int num_chars) {

`num_unicode_points`

src/hotspot/share/classfile/javaClasses.hpp line 185:

> 183: 
> 184:   static unsigned int hash_code(const char *utf8_str, int num_chars) {
> 185:     const char *ptr = utf8_str;

No need for the `ptr`, just use `utf8_str` directly.

src/hotspot/share/classfile/javaClasses.hpp line 200:

> 198: 
> 199:   static bool equals(oop java_string, const jchar* chars, int len);
> 200:   static bool equals(oop java_string, const char* chars, int len);

`num_unicode_points`

src/hotspot/share/classfile/stringTable.cpp line 143:

> 141:     return java_lang_String::hash_code(wrapped_str.utf8_str, len);
> 142:   }
> 143:   return 0;

Add `ShouldNotReachHere();`

src/hotspot/share/classfile/stringTable.cpp line 156:

> 154:   case StringType::utf8_str:
> 155:     return java_lang_String::equals(java_string, wrapped_str.utf8_str, len);
> 156:   }

Add `ShouldNotReachHere();`

src/hotspot/share/classfile/stringTable.cpp line 212:

> 210: };
> 211: 
> 212: class StringTableLookupJchar : public StringTableLookup {

`StringTableLookupUnicode`?

src/hotspot/share/classfile/stringTable.cpp line 236:

> 234: };
> 235: 
> 236: class StringTableLookupChar : public StringTableLookup {

Maybe call `StringTableLookupUtf8` instead?

src/hotspot/share/classfile/stringTable.cpp line 438:

> 436:     return java_lang_String::create_from_str(wrapped_str.utf8_str, THREAD);
> 437:   }
> 438:   return Handle();

`ShouldNotReachHere`

src/hotspot/share/classfile/stringTable.hpp line 59:

> 57:   static double get_dead_factor(size_t num_dead);
> 58: 
> 59:   typedef enum { obj_str, unicode_str, symbol_str, utf8_str } StringType;

Style:

```c++
enum class StringType {
  OopStr, UnicodeStr, SymbolStr, Utf8Str
};


You can also add a short comment for each case to differentiate them further. Note: `OopStr`, not `Objstr`, I think that makes the most sense.

src/hotspot/share/classfile/stringTable.hpp line 73:

> 71:     StringWrapperInternal(const jchar* unicodeStr) : unicode_str(unicodeStr), type(StringType::unicode_str) {}
> 72:     StringWrapperInternal(const Symbol* symbolStr) : symbol_str(symbolStr),   type(StringType::symbol_str)  {}
> 73:     StringWrapperInternal(const char* utf8Str)     : utf8_str(utf8Str),       type(StringType::utf8_str)    {}

Style: Use `snake_case` for names which aren't types.

src/hotspot/share/oops/symbol.hpp line 262:

> 260: 
> 261:   // Returns the non-null-terminated utf8 string stored in the symbol
> 262:   const char* get_utf8() const { return (char*)bytes(); }

I'd prefer to see `static_cast<char*>(bytes)`

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

PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2347681196
PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2347998553
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787677952
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787688260
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787684958
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787687909
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787688754
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787690968
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787691668
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787701230
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787700656
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787707958
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787512169
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787501944
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787493537

From cnorrbin at openjdk.org  Fri Oct 11 13:56:57 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 11 Oct 2024 13:56:57 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
Message-ID: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>

Hi everyone,

String interning can be done on 4 different types of strings:
- oop-strings (unicode)
- oop-strings (latin1)
- Symbols (non-null-terminated utf8)
- null-terminated utf8 char arrays

Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.

This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.

This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.

Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)

2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
Also tested and passes tiers 1-3.

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

Commit messages:
 - feedback from johan
 - string conversion + intern tests
 - multi-type string interning

Changes: https://git.openjdk.org/jdk/pull/21325/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327156
  Stats: 558 lines in 7 files changed: 474 ins; 29 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/21325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325

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

From cnorrbin at openjdk.org  Fri Oct 11 13:56:58 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 11 Oct 2024 13:56:58 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <-8djC882NmaKdfFFgAOyxZd5T7DItSTD_qdpV5MyOLE=.c9f2afaa-0a07-43ba-bf95-7c34e1d2b9b3@github.com>

On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

Thank you for the early comments! All your points have been adressed

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

PR Comment: https://git.openjdk.org/jdk/pull/21325#issuecomment-2407463606

From jsjolen at openjdk.org  Fri Oct 11 13:56:58 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 11 Oct 2024 13:56:58 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <Rl4_InhrC70nZ6xfWfXUYbB1NY5_t_Ks41-uZhc7FTI=.50edb56e-6064-4f0c-b795-7aac927dc2af@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <Rl4_InhrC70nZ6xfWfXUYbB1NY5_t_Ks41-uZhc7FTI=.50edb56e-6064-4f0c-b795-7aac927dc2af@github.com>
Message-ID: <XutDWLchpO-tlle-Q0hROa39Y4HubuBKh4dqpSTsZ8U=.77197362-014e-49e7-864d-80e759fb8a6b@github.com>

On Fri, 4 Oct 2024 12:56:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> src/hotspot/share/classfile/javaClasses.cpp line 765:
> 
>> 763: }
>> 764: 
>> 765: bool java_lang_String::equals(oop java_string, const char* utf8_string, int len) {
> 
> I find it super confusing to use generic `len` here and would very much appreciate it if we called this `nr_unicode_points` or something like that. You could even add a comment. Honestly, I think that maybe we should change all of these functions for additional clarity.

The last suggestion can be done in a followup RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1787683536

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 fyang at openjdk.org  Fri Oct 11 15:26:10 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 11 Oct 2024 15:26:10 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
Message-ID: <kRd7CHwuxzChtljtn0CkFo-dXwkBdPF9b1c703xauMg=.a351dac7-317b-4c68-9786-5f615ae78992@github.com>

On Fri, 11 Oct 2024 07:36:07 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 299:
> 
>> 297:   }
>> 298:   if (entry_point != nullptr) {
>> 299:     __ mv(t1, continuation);
> 
> I see `continuation` will be changed into `x9` for some switch cases, so maybe we can let `continuation` alias `x9` and unconditionallly move `ra` into `x9` on entry. That would save the update of `continuation`  for these cases and avoid use of `t1`, which I think will be cleaner.

Hmm ... I don't understand why we would prefer `t1` here. It's actually a RET here, right? So I think that we should prefer `ra` for `jr` instead which indicates a RAS Pop. I mean something like this: 

if (continuation != ra) {
  __ mv(ra, continuation);
}
__ jr(ra);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1797111706

From matsaave at openjdk.org  Fri Oct 11 15:32:48 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 11 Oct 2024 15:32:48 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v4]
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <RZ7oEhxaLNco4oUtzBUky-kyQPLIgbUGM__i5oKQPbE=.c82c8b55-74cc-4fc5-a7fe-25725db57f11@github.com>

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Cleanup
 - Ioi suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21329/files
  - new: https://git.openjdk.org/jdk/pull/21329/files/11a5499f..eee9df2b

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

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

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

From liach at openjdk.org  Fri Oct 11 18:02:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 18:02:40 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v3]
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <zGJMKOsVbOGhJN4EHEjFKEZ_dkfJdnW86TeuPK9qWlI=.2c0b6aa0-6b88-45f6-9139-92c35ac6bb3a@github.com>

> Please review this change that adds a new dynamic proxies implementation as hidden classes.
> 
> Summary:
> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

Chen Liang 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 branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Flip flags, hidden is enabled only by choice
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - Missing changes to commit
 - Condense legacy and modern impl
 - Clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Cleanup...
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/7276a1be...2cc88f2b

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

Changes: https://git.openjdk.org/jdk/pull/19356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19356&range=02
  Stats: 81 lines in 6 files changed: 53 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/19356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19356/head:pull/19356

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

From liach at openjdk.org  Fri Oct 11 18:10:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 18:10:14 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v3]
In-Reply-To: <zGJMKOsVbOGhJN4EHEjFKEZ_dkfJdnW86TeuPK9qWlI=.2c0b6aa0-6b88-45f6-9139-92c35ac6bb3a@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <zGJMKOsVbOGhJN4EHEjFKEZ_dkfJdnW86TeuPK9qWlI=.2c0b6aa0-6b88-45f6-9139-92c35ac6bb3a@github.com>
Message-ID: <BZrY0l2Zu8u7uGs2PXmPQeqaOTh5o4UrxixJqPqd-_w=.a2a15ae3-ee30-4f14-9eff-a61449d98be3@github.com>

On Fri, 11 Oct 2024 18:02:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this change that adds a new dynamic proxies implementation as hidden classes.
>> 
>> Summary:
>> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
>> 
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.
>
> Chen Liang 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 branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>  - Flip flags, hidden is enabled only by choice
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - Missing changes to commit
>  - Condense legacy and modern impl
>  - Clean up
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>  - Cleanup...
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7276a1be...2cc88f2b

Updated to merge latest master. It seems the hidden class implementation passes existing serialization tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2407902076

From kvn at openjdk.org  Fri Oct 11 18:35:21 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 11 Oct 2024 18:35:21 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
Message-ID: <pOv0CNHsfalUViWLGzHzDNrPLdIfTsmKyVZ-Qiwke2U=.a9783227-72a4-4bf4-b13a-8db7febdb0d3@github.com>

On Mon, 9 Sep 2024 13:32:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
> 
>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>  - Fix s390
>  - Use post-incrememnt RegSet operator.
>  - Merge branch 'clean' into JDK-8331658-work
>  - Fix merge
>  - Merge branch 'clean' into JDK-8331658-work
>  - Merge from JDK head.
>  - Cleanup
>  - Fix shared code
>  - Fix shared code
>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2363371843

From kvn at openjdk.org  Fri Oct 11 18:40:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 11 Oct 2024 18:40:19 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <vGjmPl73Jq54k8FJpF2LgCLjf7wahlG98nYF_lucoY0=.61e1d4fd-f8ca-4265-a777-6ee40475eb06@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <vGjmPl73Jq54k8FJpF2LgCLjf7wahlG98nYF_lucoY0=.61e1d4fd-f8ca-4265-a777-6ee40475eb06@github.com>
Message-ID: <jl80PUL21kpXfrczXVY6kqBNCsyyfIXpXpfU53-gAZI=.55c0c75e-8df4-46c5-b942-082acd09a8ec@github.com>

On Tue, 8 Oct 2024 23:36:11 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/share/asm/register.hpp line 204:
> 
>> 202:     return r;
>> 203:   }
>> 204: 
> 
> Is this related change?

Used in `lookup_secondary_supers_table_var()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1797306708

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 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 iklam at openjdk.org  Fri Oct 11 23:32:34 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Oct 2024 23:32:34 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v4]
In-Reply-To: <RZ7oEhxaLNco4oUtzBUky-kyQPLIgbUGM__i5oKQPbE=.c82c8b55-74cc-4fc5-a7fe-25725db57f11@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <RZ7oEhxaLNco4oUtzBUky-kyQPLIgbUGM__i5oKQPbE=.c82c8b55-74cc-4fc5-a7fe-25725db57f11@github.com>
Message-ID: <ni2OCX0WA-ofGl5QHZEPnJnGADke1ASCno0c25sS5PY=.16b081df-8707-4760-8722-30caf6e52482@github.com>

On Fri, 11 Oct 2024 15:32:48 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup
>  - Ioi suggestion

LGTM. One small nit.

src/hotspot/share/cds/metaspaceShared.cpp line 66:

> 64: #include "memory/metaspace.hpp"
> 65: #include "memory/metaspaceClosure.hpp"
> 66: #include "memory/oopFactory.hpp"

This include is no longer needed.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21329#pullrequestreview-2363671539
PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1797493351

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 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 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 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 jbhateja at openjdk.org  Sun Oct 13 09:57:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 13 Oct 2024 09:57:00 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Update adlc changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/ce76c3e5..506ae299

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=22-23

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

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

From jbhateja at openjdk.org  Sun Oct 13 11:18:01 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 13 Oct 2024 11:18:01 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

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

  Updating tests to use floorMod

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/1cca8e24..79ee29c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=15-16

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

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

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 jbhateja at openjdk.org  Sun Oct 13 17:12:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 13 Oct 2024 17:12:11 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v4]
In-Reply-To: <IxDdXfa_-DBjVXq2AHcnmymtYOdDuj4MDwXb9n3MYmk=.f395cb1b-9840-4894-aab4-4adfa552fd7a@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <IxDdXfa_-DBjVXq2AHcnmymtYOdDuj4MDwXb9n3MYmk=.f395cb1b-9840-4894-aab4-4adfa552fd7a@github.com>
Message-ID: <onlgS4sllZ3zYu6H50XdGEWiYKlnrq3RSkAqKprjQG8=.314383bf-dd20-4338-8fdd-9e0ce3be55d4@github.com>

On Thu, 10 Oct 2024 18:52:30 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code as per review comments

Marked as reviewed by jbhateja (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20633#pullrequestreview-2364957828

From jbhateja at openjdk.org  Sun Oct 13 17:12:12 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 13 Oct 2024 17:12:12 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v3]
In-Reply-To: <0EVgFAWZ9O9e_dlRj4Na8Xf7QEC6FGU03wAs1bwVq5c=.ff19b62d-3b2c-4320-8be2-c7dee7cafdae@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <suTh6FGWjQxIoyxtGDN5ZVrtwtlOe5E6NbPTGv34bRY=.d1c40107-aa99-47d6-a10b-bb14c4bb4a20@github.com>
 <CjSoOnUjY_Hwq-hUnOHW1PXWgYvVaj95ByvwP5HlhM4=.2a3a473d-94fd-4fbc-9656-65202026aa15@github.com>
 <PoOs0Bj-KerXafz-xKvt4LywFfyxb56BWcCvB8lLuCE=.18cacf79-21e6-428f-8664-c5a4624178aa@github.com>
 <0EVgFAWZ9O9e_dlRj4Na8Xf7QEC6FGU03wAs1bwVq5c=.ff19b62d-3b2c-4320-8be2-c7dee7cafdae@github.com>
Message-ID: <LEFvc3g47PBN7IviLJbaE82wZFE9HbgDGCE0NR05UP4=.c1127c4d-97bf-47fe-b09f-a4a7c8d951bb@github.com>

On Thu, 10 Oct 2024 23:13:11 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> We can do this change in a separate PR.
>
> I agree with Smita. The current implementation has a one-to-one correspondence with the ipsec implementation. Any new changes or refactoring could be implemented as a separate PR.

I agree, in principle, any optimization crafted to AVX2 is also applicable to AVX512 target, in future with AVX10.2 (converged ISA) we will have a 256bits flavors of two table permute for non-AVX512 targets, for now AVX-SHA512 is only available on client parts (upcoming Lunar lake) and its ok to follow the IPsec algorithm in toto.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20633#discussion_r1798463742

From eosterlund at openjdk.org  Sun Oct 13 18:24:13 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Sun, 13 Oct 2024 18:24:13 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <UbOLixLd3_OTxnT5Ff2vXnLGBj71Xr_kAqbavGNXS6M=.5f3d56d9-c880-47a2-93a9-9770f3074b8c@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2364968158

From iklam at openjdk.org  Sun Oct 13 21:07:51 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 13 Oct 2024 21:07:51 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

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

  Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/e9995ea7..039fb65d

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

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

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

From fyang at openjdk.org  Mon Oct 14 02:59:12 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 02:59:12 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <QoZoysj7OmFmhvQoJTQSMX1w_QMVoHVThnNxqxIthhU=.99cd79b9-5dff-43cb-8683-b6b8bf19e917@github.com>

On Tue, 8 Oct 2024 12:54:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp line 729:

> 727:     __ mv(t1, stub->slow_path());
> 728:     __ jalr(t1);
> 729:   }

Bad news is that I do notice problems with use of t1 register for C2 rflags. Similar issue already exists for JDK head.
See this PR for more details: https://github.com/openjdk/jdk/pull/21485. I think we should get this resolved before this one.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1192:

> 1190:     Label L_continue;
> 1191:     __ bltu(t0, t1, L_continue);
> 1192:     __ j(nooverlap_target, t1);

Can we make use of the default param `t1`?

  void j(const address dest, Register temp = t1);
  void j(const Address &adr, Register temp = t1);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1798698844
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1797692181

From fyang at openjdk.org  Mon Oct 14 03:02:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 03:02:41 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
Message-ID: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>

`ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746

Testing on linux-riscv64:
- [ ] hs-tier1 - hs-tier3

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

Commit messages:
 - 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags

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

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

From iklam at openjdk.org  Mon Oct 14 05:34:06 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Oct 2024 05:34:06 GMT
Subject: RFR: 8338018: Rename ClassPrelinker to AOTConstantPoolResolver
 [v5]
In-Reply-To: <qwgqFcAWa8zm8bUF9TwQTebN2Y5InxciePCsvOWgDUU=.283c8bdc-b858-46d9-97c7-aeceece253ff@github.com>
References: <qwgqFcAWa8zm8bUF9TwQTebN2Y5InxciePCsvOWgDUU=.283c8bdc-b858-46d9-97c7-aeceece253ff@github.com>
Message-ID: <iqdCIJySbVmf2ODYnEyxZRPmwnzPlN7GPLm11myGWjU=.9e0a9408-8cdf-42c1-8b07-76da3779b912@github.com>

> This is the 2nd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> A simple renaming of the `ClassPrelinker` class to `AOTConstantPoolLinker`, so that the name is consistent with new classes that will be introduced in subsequent PRs for JEP 483 (`AOTClassLinker`, `AOTLinkedClassTable`, and `AOTLinkedClassBulkLoader`).
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

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

 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - 8338018: Rename ClassPrelinker to AOTConstantPoolResolver

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20517/files
  - new: https://git.openjdk.org/jdk/pull/20517/files/0859631f..c068db8e

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

  Stats: 57582 lines in 924 files changed: 46849 ins; 5815 del; 4918 mod
  Patch: https://git.openjdk.org/jdk/pull/20517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20517/head:pull/20517

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

From rehn at openjdk.org  Mon Oct 14 05:47:14 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 05:47:14 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <T4-Az4_P7r2AO0bgcQZDitk4Y9FnLKdQ0SqGy8UpPKM=.e889b22e-c428-487a-ab55-828701b80f3b@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [ ] hs-tier1 - hs-tier3

Thank you, looks good, great!

I don't believe this effects performance.

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21485#pullrequestreview-2365347524

From shade at openjdk.org  Mon Oct 14 06:19:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 06:19:09 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
Message-ID: <BZPykN6Os5QixFLFuhICG4ZEP1tiyk_SdrKKlqnH9k4=.2f7be086-16d6-43af-85dc-5a7c9930d7e1@github.com>

On Thu, 10 Oct 2024 07:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}`

Thanks! 

I think I need another Reviewer for this Hotspot patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21443#issuecomment-2410114736

From shade at openjdk.org  Mon Oct 14 06:21:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 06:21:13 GMT
Subject: RFR: 8336103: Clean up confusing Method::is_initializer [v2]
In-Reply-To: <t3K5QhtFrCpM4EoXc_pskncDv72bSfKgUKfguzjVI0Q=.4e5b01d1-9cad-45ec-8d70-656615bee374@github.com>
References: <bCys51DaXKl64gEdV10WAKffH5KEwwHZH3oIYBHmL38=.0568b7d5-1b38-40bd-8932-07050c69bd8d@github.com>
 <WSVnDVWEq7cIaiEd2-pdWW4Il8Qi4wwvjF2yyveKcgM=.613045d7-a827-4f3d-bcf4-ba9200a2c8f4@github.com>
 <t3K5QhtFrCpM4EoXc_pskncDv72bSfKgUKfguzjVI0Q=.4e5b01d1-9cad-45ec-8d70-656615bee374@github.com>
Message-ID: <nK2QFxtTmq-0XZzLGRdtTDzLXR8ZvYQj9mMIAbSXZEs=.4e299c95-0008-4468-b5dd-cfe3525994cf@github.com>

On Fri, 12 Jul 2024 04:12:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> It is evident that people have been unfamiliar/sloppy with this API. This change should help prevent that in future. I have a concern about one change.
> 
> Thanks

@dholmes-ora -- maybe you want to sanity check this again?

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

PR Comment: https://git.openjdk.org/jdk/pull/20120#issuecomment-2410118012

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 iklam at openjdk.org  Mon Oct 14 07:20:58 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Oct 2024 07:20:58 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v14]
In-Reply-To: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
Message-ID: <RgPqSo6M8KlEqAMOYG31rHZC3cigBEesuu46TSpaw1w=.59c51988-c29a-41c3-9d6c-905bfb95bbc5@github.com>

> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Problem:**
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
> 
> **Solution:**
> 
> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
> 
> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
> 
> **Review Notes:**
> 
> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
> 
> **Caveats:**
> 
> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the environment:
> 
> 
> enum Foo {
>     [....]
>     static fin...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - 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
 - 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
 - Adjust TEST.groups after merge with mainline
 - For aot-inited classes, require the <clinit> of all supertypes to be executed in assembly phase as well
 - changed dumptime_xxx to dump_time_xxx to be consistent with other fields in heapShared.hpp
 - comments from @adinn and @ashu-mehra
 - 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
 - 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
 - Fixed typo
 - erge 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
 - ... and 15 more: https://git.openjdk.org/jdk/compare/22c47d33...249489e3

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

Changes: https://git.openjdk.org/jdk/pull/20958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20958&range=13
  Stats: 990 lines in 20 files changed: 878 ins; 25 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/20958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20958/head:pull/20958

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

From iklam at openjdk.org  Mon Oct 14 07:21:51 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Oct 2024 07:21:51 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v9]
In-Reply-To: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
Message-ID: <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>

> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
> 
> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 16 additional commits since the last revision:

 - 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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @coleenp comments
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @vnkozlov comment - added NOT_CDS_RETURN
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - ... and 6 more: https://git.openjdk.org/jdk/compare/777b2c40...84777aa4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20959/files
  - new: https://git.openjdk.org/jdk/pull/20959/files/9b787423..84777aa4

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

  Stats: 57582 lines in 924 files changed: 46849 ins; 5815 del; 4918 mod
  Patch: https://git.openjdk.org/jdk/pull/20959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20959/head:pull/20959

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

From fyang at openjdk.org  Mon Oct 14 07:35:09 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 07:35:09 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
Message-ID: <hRmpaLhILZofPI6ktTKxB_O2Z1GtnKvmkp3cuP5WTXo=.f2e8965d-a5cb-4a05-878b-7f51caf529ea@github.com>

On Thu, 10 Oct 2024 07:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}`

LGTM. Seems riscv bears a similar issue. Will check and propose a seperate fix.

LGTM. Seems riscv bears a similar issue. Will check and propose a seperate fix.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21443#pullrequestreview-2365619704
PR Review: https://git.openjdk.org/jdk/pull/21443#pullrequestreview-2365621037

From aboldtch at openjdk.org  Mon Oct 14 07:58:13 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 14 Oct 2024 07:58:13 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <N10xT2Yi8DMfL-RLhYLBkjbkOUBwOlKCzRZoOWe5Wao=.ab9ed445-42dc-4497-80c2-ffc15704b651@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [x] hs-tier1 - hs-tier3

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21485#pullrequestreview-2365682175

From shade at openjdk.org  Mon Oct 14 07:58:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 07:58:16 GMT
Subject: RFR: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
Message-ID: <8kIbBsgLuagE1uOVElbnQdJcGopdMil-dxEN-AtC2_M=.1015faf3-88d1-4dfd-969b-b90175483c8c@github.com>

On Thu, 10 Oct 2024 07:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}`

Thanks! Yes, I think RISC-V would enjoy a similar fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/21443#issuecomment-2410342635

From shade at openjdk.org  Mon Oct 14 07:58:16 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 07:58:16 GMT
Subject: Integrated: 8341893: AArch64: Micro-optimize compressed ptr decoding
In-Reply-To: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
References: <YtJnXNanxP8Y2Jh7kK7FVAJmjUHcyfT7CTgGoJMzd1E=.4228ae51-d39f-41ae-8681-1864a4c5b2a7@github.com>
Message-ID: <yE7YAXZ-4cE0BtWND9097KMHR3l90UWfJBr0RGims2c=.13deb986-6614-4d66-825b-a14c46032d23@github.com>

On Thu, 10 Oct 2024 07:57:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for full description. I think there is an accidental inefficiency in decoding: we don't have to shift when shift is zero, but we are tripped by `d != s` check. Other architectures seem to do this right. This fix surgically fixes the decoding. I have a variant of a more comprehensive MacroAssembler fix that could cover this shift-to-mov translation wholesale, but that fix is riskier.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}`

This pull request has now been integrated.

Changeset: e3f65039
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3f650393744790e24820b2d6d99dd1da1a44de6
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8341893: AArch64: Micro-optimize compressed ptr decoding

Reviewed-by: aph, fyang

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

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

From mli at openjdk.org  Mon Oct 14 08:01:11 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Oct 2024 08:01:11 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <rqmsfcdgMEhVn51yGBI_jP7Xk_QnM4CIQvoi7uTGatM=.b6820b3f-0ed6-424a-ac17-a5afbc345c92@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [x] hs-tier1 - hs-tier3

found another one, not sure if it's safe to make the change either.

src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:

> 167:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
> 168:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
> 169:   effect(TEMP res, TEMP tmp1, TEMP tmp2);

should the effect of `res` be changed from `TEMP` to `DEF_TEMP`?
And other similar usage places.

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

PR Review: https://git.openjdk.org/jdk/pull/21485#pullrequestreview-2365685832
PR Review Comment: https://git.openjdk.org/jdk/pull/21485#discussion_r1798939069

From fgao at openjdk.org  Mon Oct 14 08:57:16 2024
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 14 Oct 2024 08:57:16 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v3]
In-Reply-To: <Mu_bFpgAUt2TWIfs-HaW4-6PKC-8NoKUebX1lYSBE1c=.73f8b74c-2f46-4210-a581-67f9bb05aac1@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
 <Mu_bFpgAUt2TWIfs-HaW4-6PKC-8NoKUebX1lYSBE1c=.73f8b74c-2f46-4210-a581-67f9bb05aac1@github.com>
Message-ID: <ihRVhYtGbwYT1RgNM7lwnk5A9r53cT8VRO2M7xZ9g4w=.080379d0-d109-4ab4-ac3d-758bef7142c4@github.com>

On Tue, 3 Sep 2024 09:25:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Fei Gao 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:
>> 
>>  - Fix indentation
>>  - Merge branch 'master' into enable-bti-runtime
>>  - Clean up makefile
>>  - Merge branch 'master' into enable-bti-runtime
>>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>>    
>>    This patch enables BTI branch protection for runtime part on
>>    Linux/aarch64 platform.
>>    
>>    Motivation
>>    
>>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>>    User-level packages can gain additional hardening by compiling with the
>>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>>    
>>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>>    one VM configure flag, which would pass `-mbranch-protection=standard`
>>    compilation flags to all c/c++ files. Note that `standard` turns on both
>>    `pac-ret` and `bti` branch protections. For more details about code
>>    reuse attacks and hardware-assisted branch protections on AArch64, see
>>    [3].
>>    
>>    However, we checked the `.note.gnu.property` section of all the shared
>>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>>    didn't set these two target feature bits:
>>    
>>    ```
>>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>>    ```
>>    
>>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>>    libjvm.so is not BTI-enabled.
>>    
>>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>>    `.got.plt` table. It's independent of whether the relocatable objects
>>    use PAC or not.
>>    
>>    Goal
>>    
>>    Hence, this patch aims to set PAC/BTI feature bits of the
>>    `.note.gnu.property` section for libjvm.so.
>>    
>>    Implementation
>>    
>>    Task-1: find out the problematic input objects
>>    
>>    From [5], "Static linkers processing ELF relocatable objects must set
>>    the feature bit in the output object or image only if all the input
>>    objects have the corresponding feature bit set." Hence we suspect that
>>    the root cause is probably that the PAC/BTI feature bits are not set
>>    only for some input objects of libjvm.so.
>>    
>>    In order to find out these inputs, we passed `--force-bti` linker flag
>>    [4] in my local test. This linker flag would...
>
> What is the effect on JNI? Is there full interworking with non-branch-protected libraries?

Hi @theRealAph , would you mind reviewing this PR once again? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2410496113

From fyang at openjdk.org  Mon Oct 14 08:59:10 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 08:59:10 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <rqmsfcdgMEhVn51yGBI_jP7Xk_QnM4CIQvoi7uTGatM=.b6820b3f-0ed6-424a-ac17-a5afbc345c92@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
 <rqmsfcdgMEhVn51yGBI_jP7Xk_QnM4CIQvoi7uTGatM=.b6820b3f-0ed6-424a-ac17-a5afbc345c92@github.com>
Message-ID: <oOLCCWG1CmJO_LQ-3dUvLyynhxmlRGm9s78bRBWIisc=.f3b71987-b32d-4b99-a396-e5cede86d71a@github.com>

On Mon, 14 Oct 2024 07:57:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
>> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
>> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
>> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
>> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
>> 
>> Testing on linux-riscv64:
>> - [x] hs-tier1 - hs-tier3
>
> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
> 
>> 167:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
>> 168:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
>> 169:   effect(TEMP res, TEMP tmp1, TEMP tmp2);
> 
> should the effect of `res` be changed from `TEMP` to `DEF_TEMP`?
> And other similar usage places.

Ah, that looks like a refactoring change to me. Maybe go with a separate change if it's necessary? Seems not strongly related to this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21485#discussion_r1799023251

From sjayagond at openjdk.org  Mon Oct 14 09:07:53 2024
From: sjayagond at openjdk.org (Sidraya Jayagond)
Date: Mon, 14 Oct 2024 09:07:53 GMT
Subject: RFR: 8327652: S390x: Implements SLP support [v12]
In-Reply-To: <xTrycoPw1Ati71ZzYe6cEUQyY-28KMxp93PC9_JuvYM=.5a3da904-b552-4e2f-9199-d3644271298d@github.com>
References: <xTrycoPw1Ati71ZzYe6cEUQyY-28KMxp93PC9_JuvYM=.5a3da904-b552-4e2f-9199-d3644271298d@github.com>
Message-ID: <GaVov03ySoub-GYM4q-2Kw7rp5iatjzjVMNfUJ0LyRU=.a59c6187-dac2-4313-89a5-537f78de6805@github.com>

> This PR Adds SIMD support on s390x.

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

  Disable vector instructions from string intrinsics
  
  Address Lutz's comments.
  Disable vector instructions from string intrinsics will be
  enabled once PR to JDK-8336356 gets integrates.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18162/files
  - new: https://git.openjdk.org/jdk/pull/18162/files/34341aed..8a96bf73

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

  Stats: 52 lines in 4 files changed: 21 ins; 22 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18162/head:pull/18162

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

From shade at openjdk.org  Mon Oct 14 09:32:22 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 09:32:22 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <i3s36Xix8ynmLxcCLP07q7e6BJXcmNnxRHMEQVl8WCE=.b985901d-4184-4d43-b2e8-eee8722049dc@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

Thanks! I see Kim reviewed JDK parts, so we need another Reviewer for Hotspot parts.

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2410579109

From mli at openjdk.org  Mon Oct 14 09:37:13 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Oct 2024 09:37:13 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <VWNCeNHe8roFDAizirIMVCfUxsC0ZRKo3UNLCF32uXU=.d58c4383-a9a2-4a57-964a-50c8052848d0@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [x] hs-tier1 - hs-tier3

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21485#pullrequestreview-2365947967

From mli at openjdk.org  Mon Oct 14 09:37:14 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 14 Oct 2024 09:37:14 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <oOLCCWG1CmJO_LQ-3dUvLyynhxmlRGm9s78bRBWIisc=.f3b71987-b32d-4b99-a396-e5cede86d71a@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
 <rqmsfcdgMEhVn51yGBI_jP7Xk_QnM4CIQvoi7uTGatM=.b6820b3f-0ed6-424a-ac17-a5afbc345c92@github.com>
 <oOLCCWG1CmJO_LQ-3dUvLyynhxmlRGm9s78bRBWIisc=.f3b71987-b32d-4b99-a396-e5cede86d71a@github.com>
Message-ID: <JfNn4KbJ3lf8FeE1Zr6ccnG8TCq_bEaqdf9hfiEfb0c=.abe3047b-c66d-48e3-9a33-81b22746209d@github.com>

On Mon, 14 Oct 2024 08:56:46 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/gc/g1/g1_riscv.ad line 169:
>> 
>>> 167:   predicate(UseG1GC && n->as_LoadStore()->barrier_data() != 0);
>>> 168:   match(Set res (CompareAndExchangeP mem (Binary oldval newval)));
>>> 169:   effect(TEMP res, TEMP tmp1, TEMP tmp2);
>> 
>> should the effect of `res` be changed from `TEMP` to `DEF_TEMP`?
>> And other similar usage places.
>
> Ah, that looks like a refactoring change to me. Maybe go with a separate change if it's necessary? Seems not strongly related to this PR.

Yes, make sense to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21485#discussion_r1799081784

From rehn at openjdk.org  Mon Oct 14 10:12:53 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 10:12:53 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v2]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <Y2IJHih3L4_-gRtH7SZPIIaL5-KqSlt1F6dB-hzlWEk=.5f7c9510-cc8b-483d-b90b-4b64f1cf1d6f@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

  Fixed return should be done with RA by using RET mnemonic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/d81501a4..1bfd40cf

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

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

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

From aph at openjdk.org  Mon Oct 14 10:14:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 10:14:01 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v24]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <ULpmLXaKtKISGfu3K1ZCcy5MwlpNJX8BtQZ11_Mcp1E=.21b05f7d-c61b-496c-b276-fef00e7bdaf0@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

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

  Update src/hotspot/cpu/aarch64/aarch64.ad
  
  Co-authored-by: Amit Kumar <amitlocham09 at icloud.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19989/files
  - new: https://git.openjdk.org/jdk/pull/19989/files/a7612674..934b47fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=22-23

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

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

From aph at openjdk.org  Mon Oct 14 10:14:03 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 10:14:03 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <VQXM5iZCfbwdKW-A1edSS-ZSSPQa2JK-TPScgu8l5Mk=.fb8a701a-7d4e-4e6a-9840-807c7b944f90@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <VQXM5iZCfbwdKW-A1edSS-ZSSPQa2JK-TPScgu8l5Mk=.fb8a701a-7d4e-4e6a-9840-807c7b944f90@github.com>
Message-ID: <Otc0T8fZ7pKkBOYSlRVeugNuxWSIJ9AN-LKd6wN1eoM=.f3baf000-e88d-4bcc-bf88-74572182c5cd@github.com>

On Wed, 9 Oct 2024 23:50:34 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1863:
> 
>> 1861: 
>> 1862:   // Is there another entry to check? Consult the bitmap.
>> 1863:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
> 
> Can we remove this XOR if we don't destroy the original value at line 1820?

I don't think we have a spare register,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1799131716

From aph at openjdk.org  Mon Oct 14 10:14:04 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 10:14:04 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <jl80PUL21kpXfrczXVY6kqBNCsyyfIXpXpfU53-gAZI=.55c0c75e-8df4-46c5-b942-082acd09a8ec@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <vGjmPl73Jq54k8FJpF2LgCLjf7wahlG98nYF_lucoY0=.61e1d4fd-f8ca-4265-a777-6ee40475eb06@github.com>
 <jl80PUL21kpXfrczXVY6kqBNCsyyfIXpXpfU53-gAZI=.55c0c75e-8df4-46c5-b942-082acd09a8ec@github.com>
Message-ID: <fBoOeZJp4j4c3gt189PIJTDNU2aWUniAdj7PcGBR5vs=.637991c8-7817-4794-b438-238384da1d74@github.com>

On Fri, 11 Oct 2024 18:37:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/asm/register.hpp line 204:
>> 
>>> 202:     return r;
>>> 203:   }
>>> 204: 
>> 
>> Is this related change?
>
> Used in `lookup_secondary_supers_table_var()`

Yes, exactly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1799133447

From rehn at openjdk.org  Mon Oct 14 10:17:11 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 10:17:11 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v2]
In-Reply-To: <QoZoysj7OmFmhvQoJTQSMX1w_QMVoHVThnNxqxIthhU=.99cd79b9-5dff-43cb-8683-b6b8bf19e917@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <QoZoysj7OmFmhvQoJTQSMX1w_QMVoHVThnNxqxIthhU=.99cd79b9-5dff-43cb-8683-b6b8bf19e917@github.com>
Message-ID: <RecQyRFD47jIJmm6JI2detO37VnDSvpYsIaMku21WnY=.671ab8b7-b749-46c8-a5df-46332c62a30e@github.com>

On Mon, 14 Oct 2024 02:51:56 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed return should be done with RA by using RET mnemonic
>
> src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp line 729:
> 
>> 727:     __ mv(t1, stub->slow_path());
>> 728:     __ jalr(t1);
>> 729:   }
> 
> Bad news is that I do notice problems with use of t1 register for C2 rflags. Similar issue already exists for JDK head.
> See this PR for more details: https://github.com/openjdk/jdk/pull/21485. I think we should get this resolved before this one.

Yes, thanks!

> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1192:
> 
>> 1190:     Label L_continue;
>> 1191:     __ bltu(t0, t1, L_continue);
>> 1192:     __ j(nooverlap_target, t1);
> 
> Can we make use of the default param `t1`?
> 
>   void j(const address dest, Register temp = t1);
>   void j(const Address &adr, Register temp = t1);

Yes, we can, but in some cases the use of t1 is not obvious therefore I was unsure if I should make t1 default or not.
I'll change then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799137215
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799138389

From rehn at openjdk.org  Mon Oct 14 10:17:12 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 10:17:12 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v2]
In-Reply-To: <kRd7CHwuxzChtljtn0CkFo-dXwkBdPF9b1c703xauMg=.a351dac7-317b-4c68-9786-5f615ae78992@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
 <kRd7CHwuxzChtljtn0CkFo-dXwkBdPF9b1c703xauMg=.a351dac7-317b-4c68-9786-5f615ae78992@github.com>
Message-ID: <cGFby-8TSGvt52UhjMzRd-d5pS5vxdgStBTYyBug0Xg=.8701944d-6b10-4b9d-8ca8-f55ac93cf750@github.com>

On Fri, 11 Oct 2024 15:23:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp line 299:
>> 
>>> 297:   }
>>> 298:   if (entry_point != nullptr) {
>>> 299:     __ mv(t1, continuation);
>> 
>> I see `continuation` will be changed into `x9` for some switch cases, so maybe we can let `continuation` alias `x9` and unconditionallly move `ra` into `x9` on entry. That would save the update of `continuation`  for these cases and avoid use of `t1`, which I think will be cleaner.
>
> Hmm ... I don't understand why we would prefer `t1` here. It's actually a RET here, right? So I think that we should prefer `ra` for `jr` instead which indicates a RAS Pop. I mean something like this: 
> 
> if (continuation != ra) {
>   __ mv(ra, continuation);
> }
> __ jr(ra);

I was fooled by the use of Jump Register mnemonic, which is a **jump** and cannot be used with **ra**.
So yes this is a return and should use the **ret** mnemonic.
Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799135868

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 rehn at openjdk.org  Mon Oct 14 10:37:44 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 10:37:44 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v3]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <Mv2RVyba9CYRLUOdvT03MSBiPwaVYghfJ0TrjeZac_0=.9b438aff-6368-450a-b6d2-5e0daf6f9ce9@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

  No need for explicit use of default t1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/1bfd40cf..c8d8fdc8

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

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

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

From rehn at openjdk.org  Mon Oct 14 10:51:47 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 10:51:47 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v4]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <OpohfAG0I6cYLmKODB0T7o3mAAW0FvGQe4ZePIaZuw0=.46914114-aa71-4f59-8d77-edc3db52f70d@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

  Use x9, comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/c8d8fdc8..1bab8119

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

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

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

From rehn at openjdk.org  Mon Oct 14 10:51:48 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 10:51:48 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v4]
In-Reply-To: <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <oRSbJPmcm0FJny0LrGB4pUeKXaAkgckBkoZCEK_DAMs=.6a6507a2-39fb-4894-b836-3d8bf2cd9311@github.com>
Message-ID: <h92-6I_iO7W9_KmTten9G7FSLbhf5pDxEJBeVNlfJ-0=.46e7a58d-58aa-4ac1-9ec9-b91e6babeccd@github.com>

On Fri, 11 Oct 2024 07:57:08 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use x9, comment update
>
> src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp line 97:
> 
>> 95:   // t0 and t1 are used as args in generate_exception_throw?
>> 96:   // so use x18 as the tmp register for rt_call.
>> 97:   __ rt_call(Runtime1::entry_for(stub_id), x18);
> 
> Can we use `x9` instead here? It's the first callee-save register in numbering.

Fixed

> src/hotspot/cpu/riscv/templateTable_riscv.cpp line 722:
> 
>> 720:   __ mv(x13, array);
>> 721:   __ mv(t1, Interpreter::_throw_ArrayIndexOutOfBoundsException_entry);
>> 722:   __ jr(t1);
> 
> Please also update preceding code comment: `// destroys x11, t0, t1`

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799254007
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799254177

From fyang at openjdk.org  Mon Oct 14 10:55:12 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 10:55:12 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v4]
In-Reply-To: <RecQyRFD47jIJmm6JI2detO37VnDSvpYsIaMku21WnY=.671ab8b7-b749-46c8-a5df-46332c62a30e@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <QoZoysj7OmFmhvQoJTQSMX1w_QMVoHVThnNxqxIthhU=.99cd79b9-5dff-43cb-8683-b6b8bf19e917@github.com>
 <RecQyRFD47jIJmm6JI2detO37VnDSvpYsIaMku21WnY=.671ab8b7-b749-46c8-a5df-46332c62a30e@github.com>
Message-ID: <9lkoBlLqfwu513X1lc3BVMNZ8l0n_-GfdTSec_TMAfE=.d5fa9929-8cad-4f11-b6aa-221d4619be28@github.com>

On Mon, 14 Oct 2024 10:14:30 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1192:
>> 
>>> 1190:     Label L_continue;
>>> 1191:     __ bltu(t0, t1, L_continue);
>>> 1192:     __ j(nooverlap_target, t1);
>> 
>> Can we make use of the default param `t1`?
>> 
>>   void j(const address dest, Register temp = t1);
>>   void j(const Address &adr, Register temp = t1);
>
> Yes, we can, but in some cases the use of t1 is not obvious therefore I was unsure if I should make t1 default or not.
> I'll change then.

Sorry I didn't mention that there are some other occurrences like changes made in file src/hotspot/cpu/riscv/stubGenerator_riscv.cpp. I would prefer to use the default param where possible just for consistency with other callsites. As I remembered, it's very rare that `t0` / `t1` is alive at the jump target.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799257769

From aph at openjdk.org  Mon Oct 14 11:04:29 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 11:04:29 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <17V-l0RJUN63KcA4-EqW1f2FB2kANddpw05gd_Au1BI=.6ab37d9d-7300-47c0-86df-4d2fc0099e3d@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <17V-l0RJUN63KcA4-EqW1f2FB2kANddpw05gd_Au1BI=.6ab37d9d-7300-47c0-86df-4d2fc0099e3d@github.com>
Message-ID: <i7tW7SXjYULkEjIQTd3yNdR5EK9kfFvbmQu2E3juZkk=.6d45b9c8-5dea-42ea-83ce-72f572e2a27e@github.com>

On Thu, 10 Oct 2024 01:24:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/share/oops/klass.cpp line 406:
> 
>> 404:     }
>> 405:     assert(i == secondaries->length(), "mismatch");
>> 406:     postcond((int)population_count(bitmap) <= secondaries->length());
> 
> This helps explain my confusion reading fallback_search_secondary_supers().  Could we refer to this invariant there?  And could this be strengthened to :
> `population_count(bitmap) == secondaries->length() || (population_count(bitmap) == SECONDARY_SUPERS_TABLE_SIZE && secondaries->length() > SECONDARY_SUPERS_TABLE_SIZE)`
> ?

We can't assert that here, because at this point we know `length <= SECONDARY_SUPERS_TABLE_SIZE - 2`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1799273074

From aph at openjdk.org  Mon Oct 14 11:19:28 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 11:19:28 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v25]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <Lbgc7MJxPhtzA2g8_HqcVG9ytkGrJghbs0GB8RnRFUM=.e8059c1c-9b3c-414b-bffc-8e0aff0d25e4@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Merge branch 'clean' into JDK-8331658-work
 - Comment change only
 - Update src/hotspot/cpu/aarch64/aarch64.ad
   
   Co-authored-by: Amit Kumar <amitlocham09 at icloud.com>
 - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
 - Fix s390
 - Use post-incrememnt RegSet operator.
 - Merge branch 'clean' into JDK-8331658-work
 - Fix merge
 - Merge branch 'clean' into JDK-8331658-work
 - Merge from JDK head.
 - ... and 54 more: https://git.openjdk.org/jdk/compare/15815089...0408b685

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

Changes: https://git.openjdk.org/jdk/pull/19989/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=24
  Stats: 1059 lines in 22 files changed: 783 ins; 140 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/19989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989

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

From rehn at openjdk.org  Mon Oct 14 11:28:45 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:28:45 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v5]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <cz6nmMunIoZCWaqD3fNxaWoFCPKJkhtgwNgb_fiGoxw=.8365ee76-6413-457b-836a-6da3792191f9@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

  Updated asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/1bab8119..b60789e5

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

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

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

From rehn at openjdk.org  Mon Oct 14 11:28:46 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:28:46 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v5]
In-Reply-To: <qhmukXdJ8yepuv_-KslX-GEnnFT5prihr3sBPFFQd3w=.d3a946de-9fa9-403e-ac3e-c0c2026a33e7@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <qhmukXdJ8yepuv_-KslX-GEnnFT5prihr3sBPFFQd3w=.d3a946de-9fa9-403e-ac3e-c0c2026a33e7@github.com>
Message-ID: <htQNFGNgPr3FbTHKGH2LyZ12463YauVv8h5JMH02Z8I=.436f7090-1e7b-46df-830c-3f12bfa62c5d@github.com>

On Wed, 9 Oct 2024 08:31:10 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated asserts
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 2895:
> 
>> 2893:   // All calls and jumps must go via MASM.
>> 2894:   void jalr(Register Rd, Register Rs, const int32_t offset) {
>> 2895:     assert(Rd != x5 && Rs != x5, "Register x5 not used for calls/jumps.");
> 
> Suggestion:
> 
>     assert(Rd != x5 && Rs != x5, "Register x5 should not be used for calls/jumps.");

Updated

> src/hotspot/cpu/riscv/assembler_riscv.hpp line 2910:
> 
>> 2908: 
>> 2909:   void jal(Register Rd, const int32_t offset) {
>> 2910:     assert(Rd != x5, "Register x5 not used for calls/jumps.");
> 
> Suggestion:
> 
>     assert(Rd != x5, "Register x5 should not be used for calls/jumps.");

Updated

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 944:
> 
>> 942: void MacroAssembler::load_link_jump(const address source, Register temp) {
>> 943:   assert(temp != noreg && temp != x0, "expecting a register");
>> 944:   assert(temp != x5, "Register x5 not used for calls.");
> 
> Suggestion:
> 
>   assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

Updated

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1012:
> 
>> 1010: void MacroAssembler::jr(Register Rd, int32_t offset) {
>> 1011:   assert(Rd != noreg, "expecting a register");
>> 1012:   assert(Rd != x5, "Register x5 not used for jumps.");
> 
> Same as above:
> Suggestion:
> 
>   assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

Updated

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1020:
> 
>> 1018:   assert_cond(dest != nullptr);
>> 1019:   assert(temp != noreg, "expecting a register");
>> 1020:   assert(temp != x5, "Register x5 not used for jumps.");
> 
> Same as above:
> Suggestion:
> 
>   assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

Updated

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1029:
> 
>> 1027: void MacroAssembler::jalr(Register Rs, int32_t offset) {
>> 1028:   assert(Rs != noreg, "expecting a register");
>> 1029:   assert(Rs != x1, "expecting a register");
> 
> Same as above:
> Suggestion:
> 
>   assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

Updated

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1035:
> 
>> 1033: 
>> 1034: void MacroAssembler::rt_call(address dest, Register tmp) {
>> 1035:   assert(tmp != x5, "Register x5 not used for jumps.");
> 
> Same as above:
> Suggestion:
> 
>   assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799308200
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799308324
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799308581
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799308686
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799308782
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799309066
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799308879

From rehn at openjdk.org  Mon Oct 14 11:31:26 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:31:26 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v6]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <fqIyD7TPVVKvMmQBaceNOBXWk3KJuS117jz7i3rU3pE=.a43cf22a-46ea-46f4-ae6e-e12df173719e@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

  Updated assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/b60789e5..135686b0

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

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

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

From rehn at openjdk.org  Mon Oct 14 11:31:27 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:31:27 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v6]
In-Reply-To: <qhmukXdJ8yepuv_-KslX-GEnnFT5prihr3sBPFFQd3w=.d3a946de-9fa9-403e-ac3e-c0c2026a33e7@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <qhmukXdJ8yepuv_-KslX-GEnnFT5prihr3sBPFFQd3w=.d3a946de-9fa9-403e-ac3e-c0c2026a33e7@github.com>
Message-ID: <LCT5SWy_TJMHh3l4p7iHWrHNYjfNbsEvm_wMALczZdE=.75516017-2171-4b87-8eca-9f57fe2a0640@github.com>

On Wed, 9 Oct 2024 08:35:30 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated assert
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 973:
> 
>> 971:     Assembler::jal(x0, distance);
>> 972:   } else {
>> 973:     assert(temp != x5 && temp != x1, "Register x5/x1 not used for jumps.");
> 
> Suggestion:
> 
>     assert(temp != noreg && temp != x0, "expecting a register");
>     assert(temp != x5 && temp != x1, "Register x5/x1 should not be used for jumps.");
> 
> To keep the order consistent with https://github.com/openjdk/jdk/pull/21406/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR943

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799313055

From rehn at openjdk.org  Mon Oct 14 11:42:31 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:42:31 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v7]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <vzDt0h75TWr6k2f8VYXC0DbsdEC96TzLzUV0afc2f3Q=.1a0ed2c8-1c9b-48f0-b741-4b267a14c924@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

  Another one removing explicit use of default t1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/135686b0..f5783d9e

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

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

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

From rehn at openjdk.org  Mon Oct 14 11:42:31 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:42:31 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v7]
In-Reply-To: <9lkoBlLqfwu513X1lc3BVMNZ8l0n_-GfdTSec_TMAfE=.d5fa9929-8cad-4f11-b6aa-221d4619be28@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <QoZoysj7OmFmhvQoJTQSMX1w_QMVoHVThnNxqxIthhU=.99cd79b9-5dff-43cb-8683-b6b8bf19e917@github.com>
 <RecQyRFD47jIJmm6JI2detO37VnDSvpYsIaMku21WnY=.671ab8b7-b749-46c8-a5df-46332c62a30e@github.com>
 <9lkoBlLqfwu513X1lc3BVMNZ8l0n_-GfdTSec_TMAfE=.d5fa9929-8cad-4f11-b6aa-221d4619be28@github.com>
Message-ID: <fGby1jyjh2t1fxcB_DtTf-w3SV4rOdvPzaKe6j6IV_8=.1b04a59d-a889-466d-9f7b-0108ecc51dfd@github.com>

On Mon, 14 Oct 2024 10:51:30 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Yes, we can, but in some cases the use of t1 is not obvious therefore I was unsure if I should make t1 default or not.
>> I'll change then.
>
> Sorry I didn't mention that there are some other occurrences like changes made in file src/hotspot/cpu/riscv/stubGenerator_riscv.cpp. I would prefer to use the default param where possible just for consistency with other callsites. As I remembered, it's very rare that `t0` / `t1` is alive at the jump target.

Fixed more

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799333536

From aph at openjdk.org  Mon Oct 14 11:43:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 11:43:57 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v26]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <WYlt9AQS2sHptF_uWqaj1vm622Lqg-ZNSG_QeAt59bw=.3c0d02ef-b10d-41ed-9265-9985286162e0@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

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

  Comment change only

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19989/files
  - new: https://git.openjdk.org/jdk/pull/19989/files/0408b685..d5a29592

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=24-25

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

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

From rehn at openjdk.org  Mon Oct 14 11:55:28 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 11:55:28 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v8]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <vylzB8YDumElesap9g4rRb5tyxZQtJs-Ya1bNQ67nHo=.7f1bdbba-e6f9-4ea4-bf9e-c5ecfa547359@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

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

 - Merge branch 'master' into remove_t0
 - Another one removing explicit use of default t1
 - Updated assert
 - Updated asserts
 - Use x9, comment update
 - No need for explicit use of default t1
 - Fixed return should be done with RA by using RET mnemonic
 - Draft

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/f5783d9e..4e974db8

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

  Stats: 15024 lines in 282 files changed: 12464 ins; 1061 del; 1499 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

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

From fyang at openjdk.org  Mon Oct 14 13:20:19 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 13:20:19 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v4]
In-Reply-To: <OpohfAG0I6cYLmKODB0T7o3mAAW0FvGQe4ZePIaZuw0=.46914114-aa71-4f59-8d77-edc3db52f70d@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OpohfAG0I6cYLmKODB0T7o3mAAW0FvGQe4ZePIaZuw0=.46914114-aa71-4f59-8d77-edc3db52f70d@github.com>
Message-ID: <Mxabs9frOgzvj_PAZOZrUJUH0C7dgugOORkY4BW-UC4=.72c03cb3-195a-4852-bf89-6e8ea777fd34@github.com>

On Mon, 14 Oct 2024 10:51:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use x9, comment update

src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp line 96:

> 94:   }
> 95:   // t0 and t1 are used as args in generate_exception_throw?
> 96:   // so use x18 as the tmp register for rt_call.

Code comment needs update as well: x18 -> x9

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799262581

From fyang at openjdk.org  Mon Oct 14 13:20:22 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 13:20:22 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v8]
In-Reply-To: <vylzB8YDumElesap9g4rRb5tyxZQtJs-Ya1bNQ67nHo=.7f1bdbba-e6f9-4ea4-bf9e-c5ecfa547359@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <vylzB8YDumElesap9g4rRb5tyxZQtJs-Ya1bNQ67nHo=.7f1bdbba-e6f9-4ea4-bf9e-c5ecfa547359@github.com>
Message-ID: <Oe7fPWZ0k5ZZubJvEvsyNSynEt1GAI9jrNTxsiDYQCU=.a3d930d5-4c07-4c13-b107-5d1b7e67a18f@github.com>

On Mon, 14 Oct 2024 11:55:28 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_t0
>  - Another one removing explicit use of default t1
>  - Updated assert
>  - Updated asserts
>  - Use x9, comment update
>  - No need for explicit use of default t1
>  - Fixed return should be done with RA by using RET mnemonic
>  - Draft

src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1475:

> 1473:     Label L_skip_barrier;
> 1474:     __ mov_metadata(t0, method->method_holder()); // InstanceKlass*
> 1475:     __ clinit_barrier(t0, t1, &L_skip_barrier);

What is this change for?

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 1088:

> 1086:   // Come here on failure
> 1087:   // object is at TOS
> 1088:   __ j(Interpreter::_throw_ArrayStoreException_entry, t1);

Use default param.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 3675:

> 3673:   __ push_reg(x13);
> 3674:   // object is at TOS
> 3675:   __ j(Interpreter::_throw_ClassCastException_entry, t1);

Use default param.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799493865
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799410995
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799411273

From rehn at openjdk.org  Mon Oct 14 13:26:15 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 13:26:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v8]
In-Reply-To: <Oe7fPWZ0k5ZZubJvEvsyNSynEt1GAI9jrNTxsiDYQCU=.a3d930d5-4c07-4c13-b107-5d1b7e67a18f@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <vylzB8YDumElesap9g4rRb5tyxZQtJs-Ya1bNQ67nHo=.7f1bdbba-e6f9-4ea4-bf9e-c5ecfa547359@github.com>
 <Oe7fPWZ0k5ZZubJvEvsyNSynEt1GAI9jrNTxsiDYQCU=.a3d930d5-4c07-4c13-b107-5d1b7e67a18f@github.com>
Message-ID: <gbiKFGg8QIs87_Kg8q6ChDTQqqQIZbMIsmTAmzJAOG4=.2a630944-ca7d-4718-b085-b33cec12d6d1@github.com>

On Mon, 14 Oct 2024 13:16:07 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into remove_t0
>>  - Another one removing explicit use of default t1
>>  - Updated assert
>>  - Updated asserts
>>  - Use x9, comment update
>>  - No need for explicit use of default t1
>>  - Fixed return should be done with RA by using RET mnemonic
>>  - Draft
>
> src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1475:
> 
>> 1473:     Label L_skip_barrier;
>> 1474:     __ mov_metadata(t0, method->method_holder()); // InstanceKlass*
>> 1475:     __ clinit_barrier(t0, t1, &L_skip_barrier);
> 
> What is this change for?

Some clinit_barrier used "t0, t1" and some "t1,t0" I was just annoyed that they were different.

> src/hotspot/cpu/riscv/templateTable_riscv.cpp line 3675:
> 
>> 3673:   __ push_reg(x13);
>> 3674:   // object is at TOS
>> 3675:   __ j(Interpreter::_throw_ClassCastException_entry, t1);
> 
> Use default param.

Not sure why my language server didn't show me this one... fixing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799507326
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799506620

From rehn at openjdk.org  Mon Oct 14 13:31:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 13:31:13 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v8]
In-Reply-To: <gbiKFGg8QIs87_Kg8q6ChDTQqqQIZbMIsmTAmzJAOG4=.2a630944-ca7d-4718-b085-b33cec12d6d1@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <vylzB8YDumElesap9g4rRb5tyxZQtJs-Ya1bNQ67nHo=.7f1bdbba-e6f9-4ea4-bf9e-c5ecfa547359@github.com>
 <Oe7fPWZ0k5ZZubJvEvsyNSynEt1GAI9jrNTxsiDYQCU=.a3d930d5-4c07-4c13-b107-5d1b7e67a18f@github.com>
 <gbiKFGg8QIs87_Kg8q6ChDTQqqQIZbMIsmTAmzJAOG4=.2a630944-ca7d-4718-b085-b33cec12d6d1@github.com>
Message-ID: <Q8qzXY_zdJbSVday-OPR5ir4xvMo_FsPL5SFnewULbk=.2330371d-28d8-49e0-b018-5eae87c4c232@github.com>

On Mon, 14 Oct 2024 13:23:59 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1475:
>> 
>>> 1473:     Label L_skip_barrier;
>>> 1474:     __ mov_metadata(t0, method->method_holder()); // InstanceKlass*
>>> 1475:     __ clinit_barrier(t0, t1, &L_skip_barrier);
>> 
>> What is this change for?
>
> Some clinit_barrier used "t0, t1" and some "t1,t0" I was just annoyed that they were different.

See there is still one odd one here, sharedRuntime_riscv.cpp L2849.
I can revert or change that one also ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799514753

From fyang at openjdk.org  Mon Oct 14 13:53:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 14 Oct 2024 13:53:18 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v8]
In-Reply-To: <Q8qzXY_zdJbSVday-OPR5ir4xvMo_FsPL5SFnewULbk=.2330371d-28d8-49e0-b018-5eae87c4c232@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <vylzB8YDumElesap9g4rRb5tyxZQtJs-Ya1bNQ67nHo=.7f1bdbba-e6f9-4ea4-bf9e-c5ecfa547359@github.com>
 <Oe7fPWZ0k5ZZubJvEvsyNSynEt1GAI9jrNTxsiDYQCU=.a3d930d5-4c07-4c13-b107-5d1b7e67a18f@github.com>
 <gbiKFGg8QIs87_Kg8q6ChDTQqqQIZbMIsmTAmzJAOG4=.2a630944-ca7d-4718-b085-b33cec12d6d1@github.com>
 <Q8qzXY_zdJbSVday-OPR5ir4xvMo_FsPL5SFnewULbk=.2330371d-28d8-49e0-b018-5eae87c4c232@github.com>
Message-ID: <wND96Lx_wImH0rN1jre2kVvwkiXwDVqegu3Ol77ytUI=.2b03f639-ebb5-4947-bdaf-9c9913e4a156@github.com>

On Mon, 14 Oct 2024 13:28:50 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Some clinit_barrier used "t0, t1" and some "t1,t0" I was just annoyed that they were different.
>
> See there is still one odd one here, sharedRuntime_riscv.cpp L2849.
> I can revert or change that one also ?

Ah, I see. I would prefer to keep the original shape. As you see, the first param for `MacroAssembler::clinit_barrier` is `klass` which is supposed to be alive for quite a range (used across the routine). I think `t1` is safer here because `t0` is implictly clobbered by various assember routines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1799550960

From rehn at openjdk.org  Mon Oct 14 14:02:51 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 14:02:51 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v9]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <BZlFnuM7jg5u8CgflQP1OnvAaRrYgKedtjROXzVa_9U=.45f19a9c-b6c0-4d40-afbe-346f85e26c57@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:

 - Upstream comment
 - Fixed no explicit use of default t1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/4e974db8..1ef98a26

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

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

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

From mbaesken at openjdk.org  Mon Oct 14 14:13:45 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Oct 2024 14:13:45 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
Message-ID: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>

When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.

java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
 
/jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
    #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
    #1 0x7fff8b8fc8e8 (<unknown module>)
 
test
java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
 
/jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
    #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
    #1 0x7fff6b8fc768 (<unknown module>)
 
test
java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
 
/jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
    #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
    #1 0x7fff7701c8ec (<unknown module>)

The coding does intentional division by zero. 
We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

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

Commit messages:
 - JDK-8338449

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

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

From rehn at openjdk.org  Mon Oct 14 14:16:33 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 14 Oct 2024 14:16:33 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed no explicit use of default t1
 - Revert clinit_barrier t1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/1ef98a26..ec28fe35

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

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

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

From bulasevich at openjdk.org  Mon Oct 14 14:33:14 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Mon, 14 Oct 2024 14:33:14 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <t5ZOJKmv9Vhxx4TK0aHf35kB-ifoaHhORLhwdLcjeBk=.d59ed1fd-7730-45f7-b698-08e6b7f70e9e@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
 <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
 <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>
 <Qo4M7_tYzOi3ooO0apIjQiq2wQXZ888U-vK
 iIhuyVWA=.a729c7c7-eacb-446f-a488-1a371a723279@github.com>
 <O0BKeqYSxYhQgZ8uBjwm1Y0u3HPYUgi1tWcojaFXekQ=.bdacbab1-d958-478b-a8f4-dff680ce0fc6@github.com>
 <t5ZOJKmv9Vhxx4TK0aHf35kB-ifoaHhORLhwdLcjeBk=.d59ed1fd-7730-45f7-b698-08e6b7f70e9e@github.com>
Message-ID: <YCrV6alBV83FtzBbBOuX1AB4DIHOILyZzmcM318YFcY=.9e42e7cc-8b64-4457-8b77-f14acf46ef2c@github.com>

On Wed, 9 Oct 2024 18:23:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> CodeEntryAlignment=32 has the same regression as CodeEntryAlignment=12.
>> And CodeEntryAlignment=64 has no regression
>
> All runs with CodeCacheSegmentSize=64

Thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1799620945

From bulasevich at openjdk.org  Mon Oct 14 14:33:15 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Mon, 14 Oct 2024 14:33:15 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <YCrV6alBV83FtzBbBOuX1AB4DIHOILyZzmcM318YFcY=.9e42e7cc-8b64-4457-8b77-f14acf46ef2c@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
 <Z_2GAIXI6xfHyC9PH338gUgxmahicaPSGiPD2WAGVzg=.1c7192de-19cf-43ab-8df3-5928fbbdbc68@github.com>
 <9cyRxwiPTEHGztHy8GzhafJo3xBuge2Xa7UZTiLUams=.0c60d42c-7b14-4032-8112-48c96971cf46@github.com>
 <rnsLIMj9xZdQzQ5I5J0G6LJp8VoU2rDwtqXO8A-dFII=.c5795944-0fdd-4db9-8856-c73995f8ddcd@github.com>
 <5ygpNs9BaoU3IItjjFi8ZQNOv7mkRjVQcNd-XZMF5pY=.b268dc1e-ecba-4287-a088-332732d9a425@github.com>
 <odN42OMwHuhteMX4LfhHRHwokaSwRHILJStQRIdvhOY=.bd85f2d0-520a-43aa-be99-ddc4b7b24296@github.com>
 <IV2sPi9HR9ydyGSxoT0HhVf5oInK6wDUFfj5dwaWuds=.2a5c5e99-7735-439e-ae10-a3430ab0e22e@github.com>
 <PCIf66Dcy3NkzBY-zko_XfDaBALhOqu5VhY4Jmu-LuY=.167772d9-d9d5-4517-9fe2-34bf1d54755b@github.com>
 <RWfUDig973fFTYAVyy_J1B7i9div10lvdLK10MkgTcM=.be0e0883-5dc3-460a-a4e9-7567dfcc96e4@github.com>
 <Qo4M7_tYzOi3ooO0apIjQiq2wQXZ888U-vK
 iIhuyVWA=.a729c7c7-eacb-446f-a488-1a371a723279@github.com>
 <O0BKeqYSxYhQgZ8uBjwm1Y0u3HPYUgi1tWcojaFXekQ=.bdacbab1-d958-478b-a8f4-dff680ce0fc6@github.com>
 <t5ZOJKmv9Vhxx4TK0aHf35kB-ifoaHhORLhwdLcjeBk=.d59ed1fd-7730-45f7-b698-08e6b7f70e9e@github.com>
 <YCrV6alBV83FtzBbBOuX1AB4DIHOILyZzmcM318YFcY=.9e42e7cc-8b64-4457-8b77-f14acf46ef2c@github.com>
Message-ID: <xMcdpVPufc_an-CF98yYRSU1s-S2xPbXlHbzu7k8sgU=.4a712040-f491-4d63-95d8-4c437d29c2cb@github.com>

On Mon, 14 Oct 2024 14:29:41 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> All runs with CodeCacheSegmentSize=64
>
> Thank you!

The public CodeCacheStress benchmark is very noisy, easily giving +-10% on subsequent runs. On longer runs, CodeEntryAlignment=16 give ~1% regression on Neoverse N1 (Graviton2 and Ampere Altra), but CodeEntryAlignment=32 is OK. My measurements:
- Graviton2 (Neoverse N1) results:
    - CodeEntryAlignment=16: 93.33 ? 0.60 us/op
    - CodeEntryAlignment=32: 92.10 ? 0.69 us/op
    - CodeEntryAlignment=64: 92.67 ? 0.62 us/op
- Ampere Altra (Neoverse N1) results:
    - CodeEntryAlignment=16: 85.50 ? 0.88 us/op
    - CodeEntryAlignment=32: 83.79 ? 0.97 us/op
    - CodeEntryAlignment=64: 84.10 ? 0.82 us/op
- Graviton4 (Neoverse V2) results:
    - CodeEntryAlignment=16: 34.60 ? 0.41 us/op
    - CodeEntryAlignment=32: 34.30 ? 0.35 us/op
    - CodeEntryAlignment=64: 34.38 ? 0.40 us/op

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1799621570

From matsaave at openjdk.org  Mon Oct 14 14:57:26 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 14 Oct 2024 14:57:26 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v5]
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <DWAfC5RTULIbufLGZRxHqg_mcMtImDrplsUz8UdCvRM=.03051ace-3ab7-46c5-9072-092b257b1a36@github.com>

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21329/files
  - new: https://git.openjdk.org/jdk/pull/21329/files/eee9df2b..40f07064

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

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

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

From heidinga at openjdk.org  Mon Oct 14 15:12:19 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 14 Oct 2024 15:12:19 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v9]
In-Reply-To: <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>
Message-ID: <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>

On Mon, 14 Oct 2024 07:21:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
>> 
>> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 16 additional commits since the last revision:
> 
>  - 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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @coleenp comments
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @vnkozlov comment - added NOT_CDS_RETURN
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/20599b63...84777aa4

src/hotspot/share/classfile/systemDictionary.cpp line 2097:

> 2095:     }
> 2096: 
> 2097:     MutexLocker ml(InvokeMethodIntrinsicTable_lock);

Should we take this lock once outside the loop and hold it for the duration rather than taking it just again and again before each add operation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20959#discussion_r1799694921

From psandoz at openjdk.org  Mon Oct 14 15:37:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 14 Oct 2024 15:37:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <UsqqMNHzM7w57ZAtry8JImA2Ol3i749xdBlNinxA9_Y=.7602385d-b323-4fab-bfdc-70e5ded2bdd0@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2367019017

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 duke at openjdk.org  Mon Oct 14 18:13:14 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Mon, 14 Oct 2024 18:13:14 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <u6gHtcQHTf08AF8qcjBkwJfZDD5oCdPe7TnkwCH_kMc=.8dd026cb-54eb-495a-89a9-3f4a4b073017@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [x] hs-tier1 - hs-tier3

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/21485#pullrequestreview-2367336415

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 dlong at openjdk.org  Mon Oct 14 19:23:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 14 Oct 2024 19:23:17 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <Otc0T8fZ7pKkBOYSlRVeugNuxWSIJ9AN-LKd6wN1eoM=.f3baf000-e88d-4bcc-bf88-74572182c5cd@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <VQXM5iZCfbwdKW-A1edSS-ZSSPQa2JK-TPScgu8l5Mk=.fb8a701a-7d4e-4e6a-9840-807c7b944f90@github.com>
 <Otc0T8fZ7pKkBOYSlRVeugNuxWSIJ9AN-LKd6wN1eoM=.f3baf000-e88d-4bcc-bf88-74572182c5cd@github.com>
Message-ID: <mDDnFYM2uPovS6WhXG1OudHVwm-2FKOhEuCdoQElrt4=.2b671e8d-9444-470f-b689-a2391639a1d6@github.com>

On Mon, 14 Oct 2024 10:08:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1863:
>> 
>>> 1861: 
>>> 1862:   // Is there another entry to check? Consult the bitmap.
>>> 1863:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>> 
>> Can we remove this XOR if we don't destroy the original value at line 1820?
>
> I don't think we have a spare register,

What if you changed lines 1820-1821 like so:

eor(temp2, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
lslv(temp2, r_bitmap, temp2);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1799974941

From kvn at openjdk.org  Mon Oct 14 19:23:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 14 Oct 2024 19:23:17 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v26]
In-Reply-To: <WYlt9AQS2sHptF_uWqaj1vm622Lqg-ZNSG_QeAt59bw=.3c0d02ef-b10d-41ed-9265-9985286162e0@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <WYlt9AQS2sHptF_uWqaj1vm622Lqg-ZNSG_QeAt59bw=.3c0d02ef-b10d-41ed-9265-9985286162e0@github.com>
Message-ID: <LgYaYkSbgEkO3Er-NxsvGPA1wXzFKOyDNTlS3sEjYN4=.83100721-baff-4b8f-b69f-595be9c11ddb@github.com>

On Mon, 14 Oct 2024 11:43:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment change only

Re-approve.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2367439171

From dlong at openjdk.org  Mon Oct 14 19:28:14 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 14 Oct 2024 19:28:14 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <i7tW7SXjYULkEjIQTd3yNdR5EK9kfFvbmQu2E3juZkk=.6d45b9c8-5dea-42ea-83ce-72f572e2a27e@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <17V-l0RJUN63KcA4-EqW1f2FB2kANddpw05gd_Au1BI=.6ab37d9d-7300-47c0-86df-4d2fc0099e3d@github.com>
 <i7tW7SXjYULkEjIQTd3yNdR5EK9kfFvbmQu2E3juZkk=.6d45b9c8-5dea-42ea-83ce-72f572e2a27e@github.com>
Message-ID: <sD_gvylurw3zZ5XTXBrQLA61gEKY4Aeu8EIcdPwfF_0=.68af734c-4526-4678-9c0e-e78561a77f43@github.com>

On Mon, 14 Oct 2024 11:01:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/oops/klass.cpp line 406:
>> 
>>> 404:     }
>>> 405:     assert(i == secondaries->length(), "mismatch");
>>> 406:     postcond((int)population_count(bitmap) <= secondaries->length());
>> 
>> This helps explain my confusion reading fallback_search_secondary_supers().  Could we refer to this invariant there?  And could this be strengthened to :
>> `population_count(bitmap) == secondaries->length() || (population_count(bitmap) == SECONDARY_SUPERS_TABLE_SIZE && secondaries->length() > SECONDARY_SUPERS_TABLE_SIZE)`
>> ?
>
> We can't assert that here, because at this point we know `length <= SECONDARY_SUPERS_TABLE_SIZE - 2`.

Doesn't that mean `population_count(bitmap) == secondaries->length()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1799980535

From patrick at reini.net  Mon Oct 14 19:41:45 2024
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 14 Oct 2024 21:41:45 +0200
Subject: JVM Crash when Jacoco and JFR are active
Message-ID: <92c12154-424d-49a1-a6f3-ed1c5fa8b18d@reini.net>

Hi everybody,

I'm lately tried to run our Gradle build and test environment on JDK 22 
and 23 to fix future problems on our code base and have experienced JVM 
Crashes seeming to be related with the enabled JFR and Jacoco code 
coverage.

While running a set of around 14'000 JUnit tests, 8 Tests cause the JVM 
to crash when both Jacoco and JFR is running with the crash at the end 
of the message. Unfortunately I could not boil it down further and write 
a simple test to reproduce it :-(

Also I searched the JBS for a potential existing issue, but did not find 
one matching the first thread frames. If anyone has a pointer to an 
existing issue I could at least provide the hs_err* log and jfr files 
for this.

Best regards

-Patrick


#
# A fatal error has been detected by the Java Runtime Environment:
#
#? SIGSEGV (0xb) at pc=0x00007f0605749ef0, pid=128840, tid=128846
#
# JRE version: OpenJDK Runtime Environment Temurin-23+37 (23.0+37) 
(build 23+37)
# Java VM: OpenJDK 64-Bit Server VM Temurin-23+37 (23+37, mixed mode, 
sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V? [libjvm.so+0x949ef0] 
JfrMethodData::mark_deprecated_call_site(Method*, int, JavaThread*)+0x70
#
# Core dump will be written. Default location: Core dumps may be 
processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" 
(or dumping to /workspace/base2/Frame/CH.obj.Core/core.128840)
#
# JFR recording file will be written. Location: 
/workspace/base2/Frame/CH.obj.Core/hs_err_pid128840.jfr
#
# If you would like to submit a bug report, please visit:
#?? https://github.com/adoptium/adoptium-support/issues
#

---------------? S U M M A R Y ------------

Command Line: -Dbisonfunctions.pedantic=true 
-Djunit.jupiter.extensions.autodetection.enabled=true -Dline.separator=
 ?-Dorg.gradle.internal.worker.tmpdir=/workspace/base2/Frame/CH.obj.Core/build/tmp/test/work 
-Duser.timezone=Europe/Berlin -XX:StartFlightRecording 
--add-opens=java.base/java.lang=ALL-UNNAMED 
--add-opens=java.base/java.lang.ref=ALL-UNNAMED 
--add-opens=java.base/java.io=ALL-UNNAMED 
-javaagent:/workspace/base2/Frame/CH.obj.Core/build/tmp/.cache/expanded/zip_ff7bf8f04f99dc306508d1c81e47a68b/jacocoagent.jar=destfile=build/jacoco/test.exec,append=true,excludes=java.*:javax.*:mockit.*,inclnolocationclasses=false,dumponexit=true,output=file,jmx=false 
-Xmx512m -Dfile.encoding=ISO-8859-1 -Duser.country=CH -Duser.language=de 
-Duser.variant -ea 
worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test 
Executor 246'

Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 62G, Fedora 
release 40 (Forty)
Time: Mon Oct 14 09:04:48 2024 CEST elapsed time: 1.709756 seconds (0d 
0h 0m 1s)

---------------? T H R E A D? ---------------

Current thread (0x00007f0600037ed0):? JavaThread "Test worker"??????? 
[_thread_in_vm, id=128846, stack(0x00007f0604d00000,0x00007f0604e00000) 
(1024K)]

Stack: [0x00007f0604d00000,0x00007f0604e00000], sp=0x00007f0604dfa130,? 
free space=1000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V? [libjvm.so+0x949ef0] 
JfrMethodData::mark_deprecated_call_site(Method*, int, JavaThread*)+0x70
V? [libjvm.so+0x930c6e]? JfrDeprecationManager::on_link(Method const*, 
Method*, int, unsigned char, JavaThread*)+0x2e
V? [libjvm.so+0x96d84b] JfrResolution::on_runtime_resolution(CallInfo 
const&, JavaThread*)+0x15b
V? [libjvm.so+0xc8e34d]? MethodHandles::resolve_MemberName(Handle, 
Klass*, int, bool, JavaThread*)+0x8fd
V? [libjvm.so+0xf23dac] 
SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, 
Symbol*, Symbol*, JavaThread*)+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241014/0ba9df4c/OpenPGP_signature-0001.asc>

From kvn at openjdk.org  Mon Oct 14 19:51:15 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 14 Oct 2024 19:51:15 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <k6adkbs4u0vM0qV_wucCPj971XDScEfvRZbOIVCP4Gw=.aace15a9-9720-44c0-a295-61915f42cae4@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

C2 change (intrinsics code) is fine.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2367483219

From svkamath at openjdk.org  Mon Oct 14 20:54:12 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 14 Oct 2024 20:54:12 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v4]
In-Reply-To: <IxDdXfa_-DBjVXq2AHcnmymtYOdDuj4MDwXb9n3MYmk=.f395cb1b-9840-4894-aab4-4adfa552fd7a@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <IxDdXfa_-DBjVXq2AHcnmymtYOdDuj4MDwXb9n3MYmk=.f395cb1b-9840-4894-aab4-4adfa552fd7a@github.com>
Message-ID: <q1RLImVNiWYeFP3Ag0D0BZITM3H8aLFoUDqfLD8XRds=.53067749-2337-4123-bae8-7352d6fff574@github.com>

On Thu, 10 Oct 2024 18:52:30 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code as per review comments

@ascarpino, I have approvals for this PR. Would it be possible for you to run tests and let me know the results? I appreciate your help. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20633#issuecomment-2412323595

From coleenp at openjdk.org  Mon Oct 14 21:09:18 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 14 Oct 2024 21:09:18 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS [v2]
In-Reply-To: <ZoouDiiIbjmyLeUc7nTyB57K8Z0Lz5FtndZydMgZMm0=.1a1b665a-ff19-4328-8397-5f14c64d203e@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
 <ZoouDiiIbjmyLeUc7nTyB57K8Z0Lz5FtndZydMgZMm0=.1a1b665a-ff19-4328-8397-5f14c64d203e@github.com>
Message-ID: <2NMUgenKxqRzo1OMPUp6gWduVv5PsScPmUyIXNz667I=.408aa230-3aac-43f4-a837-3c8b4465dc5c@github.com>

On Wed, 9 Oct 2024 17:41:31 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> 8341444: Unnecessary check for JSRs in CDS
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed fatal()

This looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21330#pullrequestreview-2367662374

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 coleen.phillimore at oracle.com  Mon Oct 14 21:55:06 2024
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 14 Oct 2024 17:55:06 -0400
Subject: [openjdk/jdk] 8338526: Don't store abstract and interface Klasses
 in class metaspace (PR #19157)
In-Reply-To: <fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com>
References: <openjdk/jdk/pull/19157@github.com>
 <openjdk/jdk/pull/19157/c2340431106@github.com>
 <b5b4ce8b-fda4-49ab-a5d0-cb0fdf34c8e1@littlepinkcloud.com>
 <F2151D7D-447C-4BE3-A5B5-211258FAFC10@oracle.com>
 <fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com>
Message-ID: <5b4f0623-1e48-4fbe-9201-27bab3957e3b@oracle.com>


Hi Andrew, I was on vacation and this isn't a complete answer but some 
points.

On 10/9/24 5:00 AM, Andrew Haley wrote:
> On 10/9/24 06:53, John Rose wrote:
>
> > It looks like the compression needs to be partial, down to about 32 
> bits.
>
> Yes, that's true. Slightly fewer bits would be nice, for tags.
>
> > So it looks like (a) having ALL klass IDs fit in 32 bits, and (b)
> > having all CONCRETE klass IDs fit into a smaller part of the same
> > range, would meet all requirements. Doing it right might require TWO
> > new companion types for Klass*, a compact concrete klass ID, and a
> > 32-bit klass ID (supertype to compact concrete klass ID). I think
> > the larger one could be called narrowKlass (current name), and maybe
> > the narrower concrete ID could be called narrowConcreteKlass or
> > narrowestKlass or something like that.
>
> I see, I think.
>
> Simply keeping all of metadata in a single 32-bit range would be very
> useful. We could have instantiable Klasses in one region, followed by
> non-instantiable Klasses.

The important aspect of class metaspace area is that it's a fixed size 
and this is also its problem. It's not location in the area, it's that 
the area is fixed.? There's piles of code and math to map the class 
metaspace and deal with its interaction with CDS (and there's also bug 
JDK-8340212 <https://bugs.openjdk.org/browse/JDK-8340212> affecting 
Lilliput).? This idea would add more code to that. Also, adding more 
code to metaspace to direct placement location in the class metaspace is 
code I don't wish to imagine.

>
> > (Because of CDS, and maybe other factors, some compact concrete
> > klass IDs will actually point to interfaces or abstract classes. So
> > narrowConcreteKlass suggests a property of its referents that isn?t
> > exactly true.)
>
> > The way I read this is to think about putting, not klass and
> > non-klass, but concrete-klass and non-concrete-klass IDs in the same
> > range. (By ID I mean a compressed Klass pointer, or alternatively an
> > index into some sort of special table that we haven?t needed to
> > invent.)
>
> While I've now thought of a way to encode Klass pointers that doesn't
> need them all to be in the same 32-bit range, it may well be very
> useful in other contexts to ensure that they will be.

I suppose that's good you don't need the interface pointers to be in the 
same memory area as the klass pointers.? There may be a performance bug 
with moving them so we might have to undo part of this change.? The goal 
was to have the generated classes not be in class metaspace and 
interfaces came for the ride.? But it was never a design to have 
Metaspace pointers in Metaspace be compressed and a lot of CDS and code 
throughout the JVM expects to just be able to use pointers without 
adjustment.

>
> Maybe we could reduce the footprint of Klass instances. Right now,
> though, my invokeinterface prototypes *increase* the size of Klass
> instances, so I really want to have the possibility of using
> compressed metadata pointers.

Increasing the size of Klass instances is painful.? Make your new thing 
something that Klass points to. It doesn't matter how much memory you 
use in non-class metaspace.

>
> For what it's worth, I'm relieved that we're not yet making Klass
> pointers a table index. Another chained load in the path of method
> dispatch, at a time when I'm trying to get rid of chained loads, would
> be a Bad Thing for me.
>

Sorry about this Bad Thing but we are investigating exactly how to do 
this and not lose performance.? We haven't given up on this idea because 
of aforementioned piles of code we don't like to maintain, and the 
allure of not having the special "Class Metaspace" for each 
ClassLoaderData anymore.

Coleen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241014/4f08c4d5/attachment.htm>

From dholmes at openjdk.org  Mon Oct 14 22:18:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 14 Oct 2024 22:18:10 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS [v2]
In-Reply-To: <E3oc2kBWPHWSRRpIbyXcWWc6qOFutvTm93l3JGYAvFY=.bf1764e3-9b30-4dc4-9ab4-2bf2c9a34a83@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
 <HgJHowiCeGe2KVSTypys61MQ-tk3rioujwxTP0um7dA=.42b4a606-609e-49b4-92b4-7866f9edccf5@github.com>
 <E3oc2kBWPHWSRRpIbyXcWWc6qOFutvTm93l3JGYAvFY=.bf1764e3-9b30-4dc4-9ab4-2bf2c9a34a83@github.com>
Message-ID: <J4V1PpwJWpgU67WZBf4Q12eiolEVIaCZzFdeg5NDeNI=.5c29a62b-ddf9-4285-876b-fcac4ca250a8@github.com>

On Fri, 4 Oct 2024 17:33:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 2459:
>> 
>>> 2457:   // don't have any methods share the Universe::_the_empty_method_array which is in the RO region.
>>> 2458:   if (_methods != nullptr && _methods->length() > 0 && !can_be_verified_at_dumptime()) {
>>> 2459:     // To handle jsr bytecode, new Method* maybe stored into _methods
>> 
>> Based on the comment we only need to do this if the method does contain a JSR bytecode - now we will do it for all cases where verification can't be done at dumptime. ??
>
> Yes, we will put these in RW space the time.  Using the BytecodeStream to look for JSRs in unverified code is risky, so we avoid doing this optimization.

So shouldn't the comment be updated to indicate that we cannot safely check if the jsr bytecode exists and so all methods that can't be verified are made writeable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21330#discussion_r1800185967

From fyang at openjdk.org  Tue Oct 15 02:56:15 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Oct 2024 02:56:15 GMT
Subject: RFR: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <3hI0OqzagCSMgHraPqj2gNSTnjk4yJK2zYiTvHrh3IU=.be9e590a-4d13-42ff-905b-f57adedf1c69@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [x] hs-tier1 - hs-tier3

Thanks all for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/21485#issuecomment-2412702842

From fyang at openjdk.org  Tue Oct 15 02:56:15 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Oct 2024 02:56:15 GMT
Subject: Integrated: 8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags
In-Reply-To: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
References: <lM3T8UD36nfBGwn25D4UajJ4tgKKkF8c3qFFFv4ITN4=.1c08ea80-4a29-46c7-afc0-fe92538204ff@github.com>
Message-ID: <BcNyQ9qpYXTk6xvy2FFVYaQheT9V-uG7YMvT7omFmRA=.1dafc17f-a526-4192-95cb-7285da454f84@github.com>

On Mon, 14 Oct 2024 02:45:35 GMT, Fei Yang <fyang at openjdk.org> wrote:

> `ZStoreBarrierStubC2` (`ZBarriersetAssembler::generate_c2_store_barrier_stub`) clobbers rflags (the `t1` register) on riscv [1].
> And `ZStoreBarrierStubC2` is used by `z_store_barrier` in file gc/z/z_riscv.ad. But the calling instructs in the same ad file
> didn't list the rflags as being killed. As the call chain is not simple, this kind of problem could go silently unnoticed.
> I would suggest we add clobbering of rflags for all gc-related C2 instructs. No obvious impact witnessed on performance.
> This would help reduce the risk of another PR: https://github.com/openjdk/jdk/pull/21406 which touches g1/x/z prefering `t1` for performance reasons. Tagging @robehn 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp#L746
> 
> Testing on linux-riscv64:
> - [x] hs-tier1 - hs-tier3

This pull request has now been integrated.

Changeset: a601cd2e
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a601cd2e100958e3f37ae65e32e4b3cac246c079
Stats:     64 lines in 3 files changed: 0 ins; 0 del; 64 mod

8342014: RISC-V: ZStoreBarrierStubC2 clobbers rflags

Reviewed-by: rehn, aboldtch, mli

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

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

From iklam at openjdk.org  Tue Oct 15 05:21:53 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 05:21:53 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
 - 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
 - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
 - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
 - @adinn comments
 - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
 - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
 - 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
 - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
 - Limit the use of AOTHolder
 - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

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

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=04
  Stats: 2172 lines in 64 files changed: 1928 ins; 103 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

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

From fyang at openjdk.org  Tue Oct 15 05:47:11 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Oct 2024 05:47:11 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
Message-ID: <PGkgXmPdaF4xgcXi959cgAUYBfuPgB50QC3ljkgzwo8=.9d29a634-43d0-4009-a6ea-ab4946aa66ce@github.com>

On Mon, 14 Oct 2024 14:16:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1

src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 100:

> 98: 
> 99:   __ mov_metadata(t0, method->holder()->constant_encoding());
> 100:   __ clinit_barrier(t0, t1, &L_skip_barrier /* L_fast_path */);

Can we revert this as well? Missed?

src/hotspot/cpu/riscv/riscv.ad line 1422:

> 1420: 
> 1421:     __ mov_metadata(t0, C->method()->holder()->constant_encoding());
> 1422:     __ clinit_barrier(t0, t1, &L_skip_barrier);

Similar here. Missed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800321043
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800321216

From fyang at openjdk.org  Tue Oct 15 06:24:13 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Oct 2024 06:24:13 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
Message-ID: <93M5tjIpFPkwHH0FysirF94SCeDsv92r-ZVe0W7WVh4=.a5504a9b-5247-479a-846f-e89859ccd879@github.com>

On Mon, 14 Oct 2024 14:16:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1

src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 614:

> 612:   const Register receiver = j_rarg0;
> 613:   const Register data = t0;
> 614:   const Register tmp = t2;  // A call-clobbered register not used for arg passing

Can you remove following line at L614 while you are on it? Seems a left-over which is now not used anywhere.


const Register tmp = t2;  // A call-clobbered register not used for arg passing

src/hotspot/cpu/riscv/vtableStubs_riscv.cpp line 184:

> 182:   const Register temp_reg           = x28;
> 183:   const Register temp_reg2          = x29;
> 184:   const Register icdata_reg         = t0;

It seems to me quite risky to let `t0` hold CompiledICData. Here for this case, the `__ increment(Address(x18));` at L166 would clobber `t0` implicitly. I am wondering if we have another choice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800505517
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800522084

From david.holmes at oracle.com  Tue Oct 15 06:53:31 2024
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Oct 2024 16:53:31 +1000
Subject: JVM Crash when Jacoco and JFR are active
In-Reply-To: <92c12154-424d-49a1-a6f3-ed1c5fa8b18d@reini.net>
References: <92c12154-424d-49a1-a6f3-ed1c5fa8b18d@reini.net>
Message-ID: <72274759-733f-4ba4-829c-bcabb24f8be0@oracle.com>

Hi Patrick,

On 15/10/2024 5:41 am, Patrick Reinhart wrote:
> Hi everybody,
> 
> I'm lately tried to run our Gradle build and test environment on JDK 22 
> and 23 to fix future problems on our code base and have experienced JVM 
> Crashes seeming to be related with the enabled JFR and Jacoco code 
> coverage.
> 
> While running a set of around 14'000 JUnit tests, 8 Tests cause the JVM 
> to crash when both Jacoco and JFR is running with the crash at the end 
> of the message. Unfortunately I could not boil it down further and write 
> a simple test to reproduce it :-(
> 
> Also I searched the JBS for a potential existing issue, but did not find 
> one matching the first thread frames. If anyone has a pointer to an 
> existing issue I could at least provide the hs_err* log and jfr files 
> for this.

I haven't seen this before. The crash is in the code to generate JFR 
events for use of Deprecated (forRemoval?) methods. Do you know how 
Jacoco bytecode instrumentation might interact with things here? Can you 
run with a debug VM and see if any assertions fail?

David
-----

> Best regards
> 
> -Patrick
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #? SIGSEGV (0xb) at pc=0x00007f0605749ef0, pid=128840, tid=128846
> #
> # JRE version: OpenJDK Runtime Environment Temurin-23+37 (23.0+37) 
> (build 23+37)
> # Java VM: OpenJDK 64-Bit Server VM Temurin-23+37 (23+37, mixed mode, 
> sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux- 
> amd64)
> # Problematic frame:
> # V? [libjvm.so+0x949ef0] 
> JfrMethodData::mark_deprecated_call_site(Method*, int, JavaThread*)+0x70
> #
> # Core dump will be written. Default location: Core dumps may be 
> processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c 
> %h" (or dumping to /workspace/base2/Frame/CH.obj.Core/core.128840)
> #
> # JFR recording file will be written. Location: /workspace/base2/Frame/ 
> CH.obj.Core/hs_err_pid128840.jfr
> #
> # If you would like to submit a bug report, please visit:
> #?? https://github.com/adoptium/adoptium-support/issues
> #
> 
> ---------------? S U M M A R Y ------------
> 
> Command Line: -Dbisonfunctions.pedantic=true - 
> Djunit.jupiter.extensions.autodetection.enabled=true -Dline.separator=
>  ?-Dorg.gradle.internal.worker.tmpdir=/workspace/base2/Frame/ 
> CH.obj.Core/build/tmp/test/work -Duser.timezone=Europe/Berlin - 
> XX:StartFlightRecording --add-opens=java.base/java.lang=ALL-UNNAMED -- 
> add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/ 
> java.io=ALL-UNNAMED -javaagent:/workspace/base2/Frame/CH.obj.Core/build/ 
> tmp/.cache/expanded/zip_ff7bf8f04f99dc306508d1c81e47a68b/ 
> jacocoagent.jar=destfile=build/jacoco/ 
> test.exec,append=true,excludes=java.*:javax.*:mockit.*,inclnolocationclasses=false,dumponexit=true,output=file,jmx=false -Xmx512m -Dfile.encoding=ISO-8859-1 -Duser.country=CH -Duser.language=de -Duser.variant -ea worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 246'
> 
> Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 62G, Fedora 
> release 40 (Forty)
> Time: Mon Oct 14 09:04:48 2024 CEST elapsed time: 1.709756 seconds (0d 
> 0h 0m 1s)
> 
> ---------------? T H R E A D? ---------------
> 
> Current thread (0x00007f0600037ed0):? JavaThread "Test 
> worker" [_thread_in_vm, id=128846, 
> stack(0x00007f0604d00000,0x00007f0604e00000) (1024K)]
> 
> Stack: [0x00007f0604d00000,0x00007f0604e00000], sp=0x00007f0604dfa130, 
> free space=1000k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> V? [libjvm.so+0x949ef0] 
> JfrMethodData::mark_deprecated_call_site(Method*, int, JavaThread*)+0x70
> V? [libjvm.so+0x930c6e]? JfrDeprecationManager::on_link(Method const*, 
> Method*, int, unsigned char, JavaThread*)+0x2e
> V? [libjvm.so+0x96d84b] JfrResolution::on_runtime_resolution(CallInfo 
> const&, JavaThread*)+0x15b
> V? [libjvm.so+0xc8e34d]? MethodHandles::resolve_MemberName(Handle, 
> Klass*, int, bool, JavaThread*)+0x8fd
> V? [libjvm.so+0xf23dac] 
> SystemDictionary::link_method_handle_constant(Klass*, int, Klass*, 
> Symbol*, Symbol*, JavaThread*)+
> 


From rehn at openjdk.org  Tue Oct 15 07:09:11 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 07:09:11 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <93M5tjIpFPkwHH0FysirF94SCeDsv92r-ZVe0W7WVh4=.a5504a9b-5247-479a-846f-e89859ccd879@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
 <93M5tjIpFPkwHH0FysirF94SCeDsv92r-ZVe0W7WVh4=.a5504a9b-5247-479a-846f-e89859ccd879@github.com>
Message-ID: <hyF90zboZPO7NyoVCDYd3muVpce9JW41rntgIlh-9jA=.ca6d8996-552d-419e-831f-eb99a04931fd@github.com>

On Tue, 15 Oct 2024 06:20:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed no explicit use of default t1
>>  - Revert clinit_barrier t1
>
> src/hotspot/cpu/riscv/vtableStubs_riscv.cpp line 184:
> 
>> 182:   const Register temp_reg           = x28;
>> 183:   const Register temp_reg2          = x29;
>> 184:   const Register icdata_reg         = t0;
> 
> It seems to me quite risky to let `t0` hold CompiledICData. Here for this case, the `__ increment(Address(x18));` at L166 would clobber `t0` implicitly. I am wondering if we have another choice.
> 
> (Or maybe we can move `t0` which holds CompiledICData to `t1` on entry and use `t1` afterwards like before?)

Yes, I think I like that, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800574247

From johannes.bechberger at sap.com  Tue Oct 15 07:24:43 2024
From: johannes.bechberger at sap.com (Bechberger, Johannes)
Date: Tue, 15 Oct 2024 07:24:43 +0000
Subject: JVM Crash when Jacoco and JFR are active
In-Reply-To: <72274759-733f-4ba4-829c-bcabb24f8be0@oracle.com>
References: <92c12154-424d-49a1-a6f3-ed1c5fa8b18d@reini.net>
 <72274759-733f-4ba4-829c-bcabb24f8be0@oracle.com>
Message-ID: <DB5PR02MB10263A9B18D93E242BE013E92EA452@DB5PR02MB10263.eurprd02.prod.outlook.com>

Hi Patrick,

As a second idea: Could you disable the `DeprecatedInvocation` event by passing  `DeprecatedInvocation#enabled=false`in the JFR options on the command line?

Regards
Johannes

From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of David Holmes <david.holmes at oracle.com>
Date: Tuesday, 15. October 2024 at 08:54
To: hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: Re: JVM Crash when Jacoco and JFR are active
Hi Patrick,

On 15/10/2024 5:41 am, Patrick Reinhart wrote:
> Hi everybody,
>
> I'm lately tried to run our Gradle build and test environment on JDK 22
> and 23 to fix future problems on our code base and have experienced JVM
> Crashes seeming to be related with the enabled JFR and Jacoco code
> coverage.
>
> While running a set of around 14'000 JUnit tests, 8 Tests cause the JVM
> to crash when both Jacoco and JFR is running with the crash at the end
> of the message. Unfortunately I could not boil it down further and write
> a simple test to reproduce it :-(
>
> Also I searched the JBS for a potential existing issue, but did not find
> one matching the first thread frames. If anyone has a pointer to an
> existing issue I could at least provide the hs_err* log and jfr files
> for this.

I haven't seen this before. The crash is in the code to generate JFR
events for use of Deprecated (forRemoval?) methods. Do you know how
Jacoco bytecode instrumentation might interact with things here? Can you
run with a debug VM and see if any assertions fail?

David
-----

> Best regards
>
> -Patrick
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f0605749ef0, pid=128840, tid=128846
> #
> # JRE version: OpenJDK Runtime Environment Temurin-23+37 (23.0+37)
> (build 23+37)
> # Java VM: OpenJDK 64-Bit Server VM Temurin-23+37 (23+37, mixed mode,
> sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-
> amd64)
> # Problematic frame:
> # V  [libjvm.so+0x949ef0]
> JfrMethodData::mark_deprecated_call_site(Method*, int, JavaThread*)+0x70
> #
> # Core dump will be written. Default location: Core dumps may be
> processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c
> %h" (or dumping to /workspace/base2/Frame/CH.obj.Core/core.128840)
> #
> # JFR recording file will be written. Location: /workspace/base2/Frame/
> CH.obj.Core/hs_err_pid128840.jfr
> #
> # If you would like to submit a bug report, please visit:
> #   https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadoptium%2Fadoptium-support%2Fissues&data=05%7C02%7Cjohannes.bechberger%40sap.com%7Ca89a9747b902473f1ef208dcece6246a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638645720404812245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=82LJIuFyN0tt4Yo1KKhgtBFQEE5se737SXqvXjNwctY%3D&reserved=0<https://github.com/adoptium/adoptium-support/issues>
> #
>
> ---------------  S U M M A R Y ------------
>
> Command Line: -Dbisonfunctions.pedantic=true -
> Djunit.jupiter.extensions.autodetection.enabled=true -Dline.separator=
>   -Dorg.gradle.internal.worker.tmpdir=/workspace/base2/Frame/
> CH.obj.Core/build/tmp/test/work -Duser.timezone=Europe/Berlin -
> XX:StartFlightRecording --add-opens=java.base/java.lang=ALL-UNNAMED --
> add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/
> java.io=ALL-UNNAMED -javaagent:/workspace/base2/Frame/CH.obj.Core/build/
> tmp/.cache/expanded/zip_ff7bf8f04f99dc306508d1c81e47a68b/
> jacocoagent.jar=destfile=build/jacoco/
> test.exec,append=true,excludes=java.*:javax.*:mockit.*,inclnolocationclasses=false,dumponexit=true,output=file,jmx=false -Xmx512m -Dfile.encoding=ISO-8859-1 -Duser.country=CH -Duser.language=de -Duser.variant -ea worker.org.gradle.process.internal.worker.GradleWorkerMain 'Gradle Test Executor 246'
>
> Host: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 8 cores, 62G, Fedora
> release 40 (Forty)
> Time: Mon Oct 14 09:04:48 2024 CEST elapsed time: 1.709756 seconds (0d
> 0h 0m 1s)
>
> ---------------  T H R E A D  ---------------
>
> Current thread (0x00007f0600037ed0):  JavaThread "Test
> worker" [_thread_in_vm, id=128846,
> stack(0x00007f0604d00000,0x00007f0604e00000) (1024K)]
>
> Stack: [0x00007f0604d00000,0x00007f0604e00000], sp=0x00007f0604dfa130,
> free space=1000k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V  [libjvm.so+0x949ef0]
> JfrMethodData::mark_deprecated_call_site(Method*, int, JavaThread*)+0x70
> V  [libjvm.so+0x930c6e]  JfrDeprecationManager::on_link(Method const*,
> Method*, int, unsigned char, JavaThread*)+0x2e
> V  [libjvm.so+0x96d84b] JfrResolution::on_runtime_resolution(CallInfo
> const&, JavaThread*)+0x15b
> V  [libjvm.so+0xc8e34d]  MethodHandles::resolve_MemberName(Handle,
> Klass*, int, bool, JavaThread*)+0x8fd
> V  [libjvm.so+0xf23dac]
> SystemDictionary::link_method_handle_constant(Klass*, int, Klass*,
> Symbol*, Symbol*, JavaThread*)+
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241015/9be518b8/attachment.htm>

From dholmes at openjdk.org  Tue Oct 15 07:36:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 07:36:10 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <XutDWLchpO-tlle-Q0hROa39Y4HubuBKh4dqpSTsZ8U=.77197362-014e-49e7-864d-80e759fb8a6b@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <Rl4_InhrC70nZ6xfWfXUYbB1NY5_t_Ks41-uZhc7FTI=.50edb56e-6064-4f0c-b795-7aac927dc2af@github.com>
 <XutDWLchpO-tlle-Q0hROa39Y4HubuBKh4dqpSTsZ8U=.77197362-014e-49e7-864d-80e759fb8a6b@github.com>
Message-ID: <t8yavt9NEIMiSXVHLhBhyICGh-SzYuMck9Rhi-USn8c=.542cf5d7-49d5-4b9a-ac53-62cd06bdadec@github.com>

On Fri, 4 Oct 2024 13:01:04 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 765:
>> 
>>> 763: }
>>> 764: 
>>> 765: bool java_lang_String::equals(oop java_string, const char* utf8_string, int len) {
>> 
>> I find it super confusing to use generic `len` here and would very much appreciate it if we called this `nr_unicode_points` or something like that. You could even add a comment. Honestly, I think that maybe we should change all of these functions for additional clarity.
>
> The last suggestion can be done in a followup RFE.

If the `char*` is a sequence of 8-bit UTF8 values, and the `len` is the number of such 8-bit values, then "unicode points" would not be at all appropriate as they are something quite different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1800609604

From dholmes at openjdk.org  Tue Oct 15 07:36:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 07:36:11 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <Rl4_InhrC70nZ6xfWfXUYbB1NY5_t_Ks41-uZhc7FTI=.50edb56e-6064-4f0c-b795-7aac927dc2af@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <Rl4_InhrC70nZ6xfWfXUYbB1NY5_t_Ks41-uZhc7FTI=.50edb56e-6064-4f0c-b795-7aac927dc2af@github.com>
Message-ID: <--9m9iSNfVfGHtgT31fn9ETwGgEnFE9z1rFxIELABos=.b33e13e3-8d5c-4c34-8f79-fa8b814cc61e@github.com>

On Fri, 4 Oct 2024 13:02:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> src/hotspot/share/classfile/javaClasses.hpp line 184:
> 
>> 182:   }
>> 183: 
>> 184:   static unsigned int hash_code(const char *utf8_str, int num_chars) {
> 
> `num_unicode_points`

Nope - this is the number of 8-bit chars in `utf8_str`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1800610609

From dholmes at openjdk.org  Tue Oct 15 07:43:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 07:43:12 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>

On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

I've started looking at this but can't quite get my head around it yet. But some initial responses to Johan's comments.

src/hotspot/share/classfile/javaClasses.cpp line 393:

> 391: #ifdef ASSERT
> 392:   // This check is too strict when the symbol does not contain valid UTF8.
> 393:   if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, utf8_len, false)) {

But a successfully created Symbol should only ever be valid UTF8. ??

src/hotspot/share/classfile/javaClasses.cpp line 740:

> 738: }
> 739: 
> 740: bool java_lang_String::equals(oop java_string, const jchar* chars, int num_unicode_points) {

Please undo these changes - these are not "unicode points".

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2368423135
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1800615356
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1800616132

From patrick at reini.net  Tue Oct 15 07:45:50 2024
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 15 Oct 2024 09:45:50 +0200
Subject: JVM Crash when Jacoco and JFR are active
In-Reply-To: <DB5PR02MB10263A9B18D93E242BE013E92EA452@DB5PR02MB10263.eurprd02.prod.outlook.com>
References: <DB5PR02MB10263A9B18D93E242BE013E92EA452@DB5PR02MB10263.eurprd02.prod.outlook.com>
Message-ID: <FDB24746-1B05-4D91-B56B-655852C26669@reini.net>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241015/0296dfd7/attachment-0001.htm>

From mli at openjdk.org  Tue Oct 15 08:05:29 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 15 Oct 2024 08:05:29 GMT
Subject: Withdrawn: 8312425: [vectorapi] AArch64: Optimize vector math
 operations with SLEEF
In-Reply-To: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com>
References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com>
Message-ID: <0XMmMQPmuNWxSQt9INDulzZddodcx7SgN3grxuDUGVc=.fccc05f9-f710-42d2-8f97-bfe45bd7f63c@github.com>

On Wed, 3 Apr 2024 14:40:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294).
> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers.
> 
> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time.
> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk.
> 
> Besides of the code changes, one important task is to handle the legal process.
> 
> Thanks!
> 
> ## Test
> tests:
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
> 
> options:
> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs
> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs
> * -XX:+EnableVectorSupport -XX:-UseVectorStubs
> 
> ## Performance
> 
> ### Options
> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs'
> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs'
> 
> ### Float
> data
> <google-sheets-html-origin style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0)
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408
> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876
> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936
> Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 | ops/ms | 135.088 | 32.449 | 4.163 | 135.72...

This pull request has been closed without being integrated.

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

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

From patrick at reini.net  Tue Oct 15 08:08:08 2024
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 15 Oct 2024 10:08:08 +0200
Subject: JVM Crash when Jacoco and JFR are active
In-Reply-To: <72274759-733f-4ba4-829c-bcabb24f8be0@oracle.com>
References: <72274759-733f-4ba4-829c-bcabb24f8be0@oracle.com>
Message-ID: <72161626-B11D-44E6-BE4D-8133571D0C5D@reini.net>

> 
> I haven't seen this before. The crash is in the code to generate JFR events for use of Deprecated (forRemoval?) methods. Do you know how Jacoco bytecode instrumentation might interact with things here? Can you run with a debug VM and see if any assertions fail?
> 
> David
> -----
> 

What would be the JVM argument I should use, that give you the needed Information?

-Patrick 



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 johannes.bechberger at sap.com  Tue Oct 15 08:20:28 2024
From: johannes.bechberger at sap.com (Bechberger, Johannes)
Date: Tue, 15 Oct 2024 08:20:28 +0000
Subject: JVM Crash when Jacoco and JFR are active
In-Reply-To: <72161626-B11D-44E6-BE4D-8133571D0C5D@reini.net>
References: <72274759-733f-4ba4-829c-bcabb24f8be0@oracle.com>
 <72161626-B11D-44E6-BE4D-8133571D0C5D@reini.net>
Message-ID: <DB5PR02MB102634BB387CF257EF79B221DEA452@DB5PR02MB10263.eurprd02.prod.outlook.com>

You can get a debug JVM (fastdebug and slowdebug) from https://builds.shipilev.net/openjdk-jdk23/ if you don?t want to build them yourself. Please run your tests with at least fastdebug and give us the error output.

Regards
Johannes

From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Patrick Reinhart <patrick at reini.net>
Date: Tuesday, 15. October 2024 at 10:08
To: David Holmes <david.holmes at oracle.com>, hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
Subject: Re: JVM Crash when Jacoco and JFR are active
[You don't often get email from patrick at reini.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

>
> I haven't seen this before. The crash is in the code to generate JFR events for use of Deprecated (forRemoval?) methods. Do you know how Jacoco bytecode instrumentation might interact with things here? Can you run with a debug VM and see if any assertions fail?
>
> David
> -----
>

What would be the JVM argument I should use, that give you the needed Information?

-Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241015/80fc5fe0/attachment.htm>

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 patrick at reini.net  Tue Oct 15 09:02:00 2024
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 15 Oct 2024 11:02:00 +0200
Subject: JVM Crash when Jacoco and JFR are active
In-Reply-To: <DB5PR02MB102634BB387CF257EF79B221DEA452@DB5PR02MB10263.eurprd02.prod.outlook.com>
References: <DB5PR02MB102634BB387CF257EF79B221DEA452@DB5PR02MB10263.eurprd02.prod.outlook.com>
Message-ID: <9F83E9E6-9DDA-4180-BAF3-398F76C8657C@reini.net>

Rerun the test with slow debug and attached results to https://bugs.openjdk.org/browse/JDK-8342105

-Patrick 
> Am 15.10.2024 um 10:20 schrieb Bechberger, Johannes <johannes.bechberger at sap.com>:
> 
> ?
> You can get a debug JVM (fastdebug and slowdebug) from https://builds.shipilev.net/openjdk-jdk23/ if you don?t want to build them yourself. Please run your tests with at least fastdebug and give us the error output.
>  
> Regards
> Johannes
>  
> From: hotspot-dev <hotspot-dev-retn at openjdk.org> on behalf of Patrick Reinhart <patrick at reini.net>
> Date: Tuesday, 15. October 2024 at 10:08
> To: David Holmes <david.holmes at oracle.com>, hotspot-dev at openjdk.org <hotspot-dev at openjdk.org>
> Subject: Re: JVM Crash when Jacoco and JFR are active
> 
> [You don't often get email from patrick at reini.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> >
> > I haven't seen this before. The crash is in the code to generate JFR events for use of Deprecated (forRemoval?) methods. Do you know how Jacoco bytecode instrumentation might interact with things here? Can you run with a debug VM and see if any assertions fail?
> >
> > David
> > -----
> >
> 
> What would be the JVM argument I should use, that give you the needed Information?
> 
> -Patrick
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241015/dca65597/attachment-0001.htm>

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 shade at openjdk.org  Tue Oct 15 09:21:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 09:21:18 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

Thanks for review, folks. I am re-running testing locally here. Would appreciate if you can give this patch a spin through your CIs as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2413348085

From rcastanedalo at openjdk.org  Tue Oct 15 09:27:12 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 15 Oct 2024 09:27:12 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
 <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>
Message-ID: <MX2iRPfi5jOwWg7t9Nrg204dQ3QBVGgIXjJ_bYhm9Zk=.ef3f8b90-1717-4f00-8128-b12567b5df4d@github.com>

On Tue, 15 Oct 2024 09:18:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thanks for review, folks. I am re-running testing locally here. Would appreciate if you can give this patch a spin through your CIs as well.

I will run some internal CI testing and report back in one or two days.

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2413362811

From epeter at openjdk.org  Tue Oct 15 09:38:22 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 15 Oct 2024 09:38:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

I gave it a quick scan, and I have no further comments. LGTM.

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2368730929

From rehn at openjdk.org  Tue Oct 15 09:41:54 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 09:41:54 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v11]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <F4ZGHIXaR-yloKWEl8aDNUfQ-Z6_bNZpHD7xj1X0I5E=.c613ba42-407b-4bc4-a76d-f502e8237320@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:

 - ICData move to t1, removed dead code
 - Revert clinit_barrier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/ec28fe35..5cc487aa

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

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

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

From rehn at openjdk.org  Tue Oct 15 09:41:55 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 09:41:55 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <PGkgXmPdaF4xgcXi959cgAUYBfuPgB50QC3ljkgzwo8=.9d29a634-43d0-4009-a6ea-ab4946aa66ce@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
 <PGkgXmPdaF4xgcXi959cgAUYBfuPgB50QC3ljkgzwo8=.9d29a634-43d0-4009-a6ea-ab4946aa66ce@github.com>
Message-ID: <WUFgOztCMSDwbnnsLpb-KX1-wz60IOVY8HtTTOZeDmY=.aa8a6b9c-dbb0-420e-bfd9-11ba2deb07ee@github.com>

On Tue, 15 Oct 2024 02:13:19 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed no explicit use of default t1
>>  - Revert clinit_barrier t1
>
> src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 100:
> 
>> 98: 
>> 99:   __ mov_metadata(t0, method->holder()->constant_encoding());
>> 100:   __ clinit_barrier(t0, t1, &L_skip_barrier /* L_fast_path */);
> 
> Can we revert this as well? Missed?

Yes

> src/hotspot/cpu/riscv/riscv.ad line 1422:
> 
>> 1420: 
>> 1421:     __ mov_metadata(t0, C->method()->holder()->constant_encoding());
>> 1422:     __ clinit_barrier(t0, t1, &L_skip_barrier);
> 
> Similar here. Missed?

Yes

> src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 614:
> 
>> 612:   const Register receiver = j_rarg0;
>> 613:   const Register data = t0;
>> 614:   const Register tmp = t2;  // A call-clobbered register not used for arg passing
> 
> Can you remove following line at L614 while you are on it? Seems a left-over which is now not used anywhere.
> 
> 
> const Register tmp = t2;  // A call-clobbered register not used for arg passing

Yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800809015
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800809177
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800809363

From rehn at openjdk.org  Tue Oct 15 09:41:55 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 09:41:55 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <hyF90zboZPO7NyoVCDYd3muVpce9JW41rntgIlh-9jA=.ca6d8996-552d-419e-831f-eb99a04931fd@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
 <93M5tjIpFPkwHH0FysirF94SCeDsv92r-ZVe0W7WVh4=.a5504a9b-5247-479a-846f-e89859ccd879@github.com>
 <hyF90zboZPO7NyoVCDYd3muVpce9JW41rntgIlh-9jA=.ca6d8996-552d-419e-831f-eb99a04931fd@github.com>
Message-ID: <6GMuqlYtZ1UZng0vGwMLvgneC5cMDR6t5ZgEHt0z7o0=.61e7e2a6-facb-48ff-9553-7786ed34906b@github.com>

On Tue, 15 Oct 2024 07:06:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vtableStubs_riscv.cpp line 184:
>> 
>>> 182:   const Register temp_reg           = x28;
>>> 183:   const Register temp_reg2          = x29;
>>> 184:   const Register icdata_reg         = t0;
>> 
>> It seems to me quite risky to let `t0` hold CompiledICData. Here for this case, the `__ increment(Address(x18))` at L166 would clobber `t0` implicitly. I am wondering if we have another choice.
>> 
>> (Or maybe we can move `t0` which holds CompiledICData to `t1` on entry and use `t1` afterwards like before?)
>
> Yes, I think I like that, thanks.

Fixed, take another look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800809706

From rehn at openjdk.org  Tue Oct 15 09:52:53 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 09:52:53 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn 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 15 additional commits since the last revision:

 - Merge branch 'master' into remove_t0
 - ICData move to t1, removed dead code
 - Revert clinit_barrier
 - Fixed no explicit use of default t1
 - Revert clinit_barrier t1
 - Upstream comment
 - Fixed no explicit use of default t1
 - Merge branch 'master' into remove_t0
 - Another one removing explicit use of default t1
 - Updated assert
 - ... and 5 more: https://git.openjdk.org/jdk/compare/bb1a7aee...c95c9601

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/5cc487aa..c95c9601

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

  Stats: 1311 lines in 69 files changed: 1007 ins; 77 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

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

From yzheng at openjdk.org  Tue Oct 15 10:05:16 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 15 Oct 2024 10:05:16 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <_jxZbWC74sQnUsT7Pher9IhyI2zWos38DYNsnB6azSo=.e90cf5e6-d008-4022-a752-61c26505b560@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

src/hotspot/share/gc/z/zBarrierSetRuntime.hpp line 43:

> 41:   static void store_barrier_on_oop_field_with_healing(oop* p);
> 42:   static void store_barrier_on_oop_field_without_healing(oop* p);
> 43:   static void no_keepalive_store_barrier_on_oop_field_without_healing(oop* p);

Could you please export this to JVMCI? I.e.,

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 5452cca96b8..46aeb996c56 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -847,6 +847,7 @@
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::load_barrier_on_oop_field_preloaded_store_good))           \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_weak_oop_field_preloaded))    \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_phantom_oop_field_preloaded)) \
+  ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing)   \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_native_oop_field_without_healing))        \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_with_healing))                  \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_without_healing))               \

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1800848130

From epeter at openjdk.org  Tue Oct 15 10:22:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 15 Oct 2024 10:22:21 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
Message-ID: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>

On Sun, 13 Oct 2024 09:57:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update adlc changes.

Are there any IR rules that verify that the correct C2 nodes are used? Is that a thing you generally do with the VectorAPI, just to make sure things get correctly intrinsified?

src/hotspot/share/opto/vectornode.hpp line 161:

> 159:   // Needed for proper cloning.
> 160:   virtual uint size_of() const { return sizeof(*this); }
> 161:   bool is_unsigned() { return _is_unsigned; }

Can you put this in the `print_spec`, so the IR dump shows if it is unsigned?

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

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2368845862
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1800870852

From aph at openjdk.org  Tue Oct 15 10:25:57 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 10:25:57 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v27]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <uNU9-qgIa7ylgYlvBRP0xvmuLZTQyfVS-S6Y_XJAyGg=.3bc5a8f4-b55e-411b-b319-d7bfcd457ae3@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

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

  Save an instruction in lookup_secondary_supers_table_var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19989/files
  - new: https://git.openjdk.org/jdk/pull/19989/files/d5a29592..2134f63d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=25-26

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

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

From aph at openjdk.org  Tue Oct 15 10:27:14 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 10:27:14 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v3]
In-Reply-To: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
Message-ID: <JWS04Q8ZGVpaoDRMeyrd_-6FD3kXdHTi29lyiwAApuU=.b9d57792-bd29-4607-8d21-6b02b813e097@github.com>

On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
>> 
>> Motivation
>> 
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
>> 
>> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
>> 
>> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
>> 
>> 
>>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>> 
>> 
>> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
>> 
>> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
>> 
>> Goal
>> 
>> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
>> 
>> Implementation
>> 
>> Task-1: find out the problematic input objects
>> 
>> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
>> 
>> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
>> 
>> 
>>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
>> 
>> 
>> Task-2: add `.note.gnu.property` section for these assembly files
>> 
>> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
>> 
>> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i...
>
> Fei Gao 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:
> 
>  - Fix indentation
>  - Merge branch 'master' into enable-bti-runtime
>  - Clean up makefile
>  - Merge branch 'master' into enable-bti-runtime
>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>    
>    This patch enables BTI branch protection for runtime part on
>    Linux/aarch64 platform.
>    
>    Motivation
>    
>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>    User-level packages can gain additional hardening by compiling with the
>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>    
>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>    one VM configure flag, which would pass `-mbranch-protection=standard`
>    compilation flags to all c/c++ files. Note that `standard` turns on both
>    `pac-ret` and `bti` branch protections. For more details about code
>    reuse attacks and hardware-assisted branch protections on AArch64, see
>    [3].
>    
>    However, we checked the `.note.gnu.property` section of all the shared
>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>    didn't set these two target feature bits:
>    
>    ```
>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>    ```
>    
>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>    libjvm.so is not BTI-enabled.
>    
>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>    `.got.plt` table. It's independent of whether the relocatable objects
>    use PAC or not.
>    
>    Goal
>    
>    Hence, this patch aims to set PAC/BTI feature bits of the
>    `.note.gnu.property` section for libjvm.so.
>    
>    Implementation
>    
>    Task-1: find out the problematic input objects
>    
>    From [5], "Static linkers processing ELF relocatable objects must set
>    the feature bit in the output object or image only if all the input
>    objects have the corresponding feature bit set." Hence we suspect that
>    the root cause is probably that the PAC/BTI feature bits are not set
>    only for some input objects of libjvm.so.
>    
>    In order to find out these inputs, we passed `--force-bti` linker flag
>    [4] in my local test. This linker flag would warn if any input object
>    does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
>    list:
>    
>  ...

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20491#pullrequestreview-2368859314

From aph at openjdk.org  Tue Oct 15 10:31:16 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 10:31:16 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <mDDnFYM2uPovS6WhXG1OudHVwm-2FKOhEuCdoQElrt4=.2b671e8d-9444-470f-b689-a2391639a1d6@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <VQXM5iZCfbwdKW-A1edSS-ZSSPQa2JK-TPScgu8l5Mk=.fb8a701a-7d4e-4e6a-9840-807c7b944f90@github.com>
 <Otc0T8fZ7pKkBOYSlRVeugNuxWSIJ9AN-LKd6wN1eoM=.f3baf000-e88d-4bcc-bf88-74572182c5cd@github.com>
 <mDDnFYM2uPovS6WhXG1OudHVwm-2FKOhEuCdoQElrt4=.2b671e8d-9444-470f-b689-a2391639a1d6@github.com>
Message-ID: <n1uGWI5zK3M9smyn_F3ywYrHXO6FzK1Qt7c07ZYaSbE=.8bce05bf-992f-480f-84bc-e91013eac9ef@github.com>

On Mon, 14 Oct 2024 19:18:56 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I don't think we have a spare register,
>
> What if you changed lines 1820-1821 like so:
> 
> eor(temp2, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
> lslv(temp2, r_bitmap, temp2);

Yes, you're right. Please look at it now.

@iwanowww , do you think this needs a full re-test? This is a local change, and I think it's self-contained.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1800887071

From aph at openjdk.org  Tue Oct 15 10:35:50 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 10:35:50 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v28]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <hNhLOoNftDPqrcLvGnc3924MmDMlSi25DtOU-RIaZgA=.74e2d44c-da0e-469d-b074-a492220a4302@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

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

  Strengthen assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19989/files
  - new: https://git.openjdk.org/jdk/pull/19989/files/2134f63d..67ca29ff

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

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

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

From aph at openjdk.org  Tue Oct 15 10:44:18 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 10:44:18 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v28]
In-Reply-To: <hNhLOoNftDPqrcLvGnc3924MmDMlSi25DtOU-RIaZgA=.74e2d44c-da0e-469d-b074-a492220a4302@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <hNhLOoNftDPqrcLvGnc3924MmDMlSi25DtOU-RIaZgA=.74e2d44c-da0e-469d-b074-a492220a4302@github.com>
Message-ID: <YNm_tUXXGIDIxWb7UJTp4Fjgvg51KIIpZnhbfPHk4kU=.329c561f-6de7-43eb-80bc-e7bb1f0243c2@github.com>

On Tue, 15 Oct 2024 10:35:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen assertion

By the way, to see the performance benefit of this patch run the test case SecondarySuperCacheInterContention.java, like so:

`/build/macosx-aarch64-server-fastdebug/jdk/bin/java -XX:-UseSecondarySupersTable -XX:+UseSecondarySupersCache -jar build/macosx-aarch64-server-fastdebug/images/test/micro/benchmarks.jar SecondarySuperCacheInterContention`

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

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2413532757

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 shade at openjdk.org  Tue Oct 15 11:07:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 11:07:32 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v10]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

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

  Export in JVMCI too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/9f7ad7ab..479781df

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

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

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

From shade at openjdk.org  Tue Oct 15 11:07:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 11:07:34 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <_jxZbWC74sQnUsT7Pher9IhyI2zWos38DYNsnB6azSo=.e90cf5e6-d008-4022-a752-61c26505b560@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
 <_jxZbWC74sQnUsT7Pher9IhyI2zWos38DYNsnB6azSo=.e90cf5e6-d008-4022-a752-61c26505b560@github.com>
Message-ID: <ASHyXEP0mr5bgz9zwh0OeUOn3qdO6jB10Qt7lHLVF8s=.5f85dc2c-f2ba-4e47-a334-a0e9ddaeabc1@github.com>

On Tue, 15 Oct 2024 10:02:15 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Simplify: just do keep alive checks
>>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>>  - More precise bit-unmasks
>>  - Reconcile with late barrier expansion in G1
>>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>>  - Review comments
>>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>>  - Also dispatch to slow-path on other arches
>>  - Fix other arches
>>  - Tighten up comments in Reference javadoc
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab
>
> src/hotspot/share/gc/z/zBarrierSetRuntime.hpp line 43:
> 
>> 41:   static void store_barrier_on_oop_field_with_healing(oop* p);
>> 42:   static void store_barrier_on_oop_field_without_healing(oop* p);
>> 43:   static void no_keepalive_store_barrier_on_oop_field_without_healing(oop* p);
> 
> Could you please export this to JVMCI? I.e.,
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 5452cca96b8..46aeb996c56 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -847,6 +847,7 @@
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::load_barrier_on_oop_field_preloaded_store_good))           \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_weak_oop_field_preloaded))    \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_phantom_oop_field_preloaded)) \
> +  ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing)   \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_native_oop_field_without_healing))        \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_with_healing))                  \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_without_healing))               \
> 
> Thanks!

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1800937787

From aph at openjdk.org  Tue Oct 15 11:08:59 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 11:08:59 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v29]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

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

  Strengthen assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19989/files
  - new: https://git.openjdk.org/jdk/pull/19989/files/67ca29ff..cf71c835

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

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

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

From ihse at openjdk.org  Tue Oct 15 11:11:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 11:11:14 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v3]
In-Reply-To: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
Message-ID: <ZYk4dKAE45GJo_VYlqoOi75_Uk-0MhjMllflO2Uzdlg=.ff2704b4-e5fe-47e8-9f36-1f7f0c01b848@github.com>

On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
>> 
>> Motivation
>> 
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
>> 
>> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
>> 
>> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
>> 
>> 
>>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>> 
>> 
>> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
>> 
>> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
>> 
>> Goal
>> 
>> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
>> 
>> Implementation
>> 
>> Task-1: find out the problematic input objects
>> 
>> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
>> 
>> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
>> 
>> 
>>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
>> 
>> 
>> Task-2: add `.note.gnu.property` section for these assembly files
>> 
>> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
>> 
>> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i...
>
> Fei Gao 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:
> 
>  - Fix indentation
>  - Merge branch 'master' into enable-bti-runtime
>  - Clean up makefile
>  - Merge branch 'master' into enable-bti-runtime
>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>    
>    This patch enables BTI branch protection for runtime part on
>    Linux/aarch64 platform.
>    
>    Motivation
>    
>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>    User-level packages can gain additional hardening by compiling with the
>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>    
>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>    one VM configure flag, which would pass `-mbranch-protection=standard`
>    compilation flags to all c/c++ files. Note that `standard` turns on both
>    `pac-ret` and `bti` branch protections. For more details about code
>    reuse attacks and hardware-assisted branch protections on AArch64, see
>    [3].
>    
>    However, we checked the `.note.gnu.property` section of all the shared
>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>    didn't set these two target feature bits:
>    
>    ```
>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>    ```
>    
>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>    libjvm.so is not BTI-enabled.
>    
>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>    `.got.plt` table. It's independent of whether the relocatable objects
>    use PAC or not.
>    
>    Goal
>    
>    Hence, this patch aims to set PAC/BTI feature bits of the
>    `.note.gnu.property` section for libjvm.so.
>    
>    Implementation
>    
>    Task-1: find out the problematic input objects
>    
>    From [5], "Static linkers processing ELF relocatable objects must set
>    the feature bit in the output object or image only if all the input
>    objects have the corresponding feature bit set." Hence we suspect that
>    the root cause is probably that the PAC/BTI feature bits are not set
>    only for some input objects of libjvm.so.
>    
>    In order to find out these inputs, we passed `--force-bti` linker flag
>    [4] in my local test. This linker flag would warn if any input object
>    does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
>    list:
>    
>  ...

Build changes still look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20491#pullrequestreview-2368988641

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 fyang at openjdk.org  Tue Oct 15 11:29:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Oct 2024 11:29:18 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
Message-ID: <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>

On Tue, 15 Oct 2024 09:52:53 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_t0
>  - ICData move to t1, removed dead code
>  - Revert clinit_barrier
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1
>  - Upstream comment
>  - Fixed no explicit use of default t1
>  - Merge branch 'master' into remove_t0
>  - Another one removing explicit use of default t1
>  - Updated assert
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/5b00f636...c95c9601

src/hotspot/cpu/riscv/assembler_riscv.hpp line 2895:

> 2893: // --------------------------
> 2894:  protected:
> 2895:   // All calls and jumps must go via MASM.

Better to add some extra code comment here about the link register usage. Say:

// All calls and jumps must go via MASM. Only use x1 (aka ra) as link register for now.

src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp line 97:

> 95:   // t0 and t1 are used as args in generate_exception_throw?
> 96:   // so use x9 as the tmp register for rt_call.
> 97:   __ rt_call(Runtime1::entry_for(stub_id), x9);

Not sure if `x9` is usable for us here after another look. Seems all registers must be preserved from the code comment [1]. We need to double check.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp#L130

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800916361
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800984655

From fyang at openjdk.org  Tue Oct 15 11:29:19 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 15 Oct 2024 11:29:19 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
Message-ID: <GilEOcItfdsuRSrGe7SnTUuAoudrTPn6nvQhcLnuCds=.09a27366-b7d7-40df-bdc6-6b3730f32bc6@github.com>

On Mon, 14 Oct 2024 14:16:33 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 771:

> 769:                                        Label *retaddr) {
> 770:   int32_t offset = 0;
> 771:   push_reg(RegSet::of(t1, xmethod), sp);   // push << t0 & xmethod >> to sp

Code comment needs update.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 777:

> 775:     bind(*retaddr);
> 776:   }
> 777:   pop_reg(RegSet::of(t1, xmethod), sp);   // pop << t0 & xmethod >> from sp

Code comment needs update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800529244
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1800529332

From dholmes at openjdk.org  Tue Oct 15 12:13:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 12:13:11 GMT
Subject: RFR: 8336103: Clean up confusing Method::is_initializer [v4]
In-Reply-To: <ZkX0GJUUXe-unxZGENazMqmH7xXv7wtavvH1YagJSiM=.6d6dc39e-4cb3-4f77-92e1-13858a27d19d@github.com>
References: <bCys51DaXKl64gEdV10WAKffH5KEwwHZH3oIYBHmL38=.0568b7d5-1b38-40bd-8932-07050c69bd8d@github.com>
 <ZkX0GJUUXe-unxZGENazMqmH7xXv7wtavvH1YagJSiM=.6d6dc39e-4cb3-4f77-92e1-13858a27d19d@github.com>
Message-ID: <y32sDMOUTfY4M0Ui1cWXOisJknt8UEHKF6OK51bnjz0=.9cfa7f4a-dcb3-402e-8a23-50e383131f79@github.com>

On Fri, 27 Sep 2024 09:57:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> All around Hotspot, we have calls to `method->is_initializer()`. That method tests for both instance and static initializers. In many cases, the uses imply we actually want to test for constructor, not static initializer. Sometimes we filter explicitly for `!m->is_static()`, sometimes we don't.  At this point, I think the best way to prevent future accidents is to remove the confusing `is_initializer`.
>> 
>> The behavioral changes have been handled by already integrated PRs, see the links in JBS. The changes left here are not (supposed to be) changing the behavior.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fix

Simplified version looks good. Sorry I didn't spot this had been updated.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20120#pullrequestreview-2369143119

From shade at openjdk.org  Tue Oct 15 12:19:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 12:19:20 GMT
Subject: RFR: 8336103: Clean up confusing Method::is_initializer [v4]
In-Reply-To: <ZkX0GJUUXe-unxZGENazMqmH7xXv7wtavvH1YagJSiM=.6d6dc39e-4cb3-4f77-92e1-13858a27d19d@github.com>
References: <bCys51DaXKl64gEdV10WAKffH5KEwwHZH3oIYBHmL38=.0568b7d5-1b38-40bd-8932-07050c69bd8d@github.com>
 <ZkX0GJUUXe-unxZGENazMqmH7xXv7wtavvH1YagJSiM=.6d6dc39e-4cb3-4f77-92e1-13858a27d19d@github.com>
Message-ID: <Vnm9jJzEoudjzYgco0CRV-dzQuxFxMa6BaNfuE5f-Mc=.e030c451-1e47-47ed-83e2-f5ac82f6bbb5@github.com>

On Fri, 27 Sep 2024 09:57:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> All around Hotspot, we have calls to `method->is_initializer()`. That method tests for both instance and static initializers. In many cases, the uses imply we actually want to test for constructor, not static initializer. Sometimes we filter explicitly for `!m->is_static()`, sometimes we don't.  At this point, I think the best way to prevent future accidents is to remove the confusing `is_initializer`.
>> 
>> The behavioral changes have been handled by already integrated PRs, see the links in JBS. The changes left here are not (supposed to be) changing the behavior.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fix

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/20120#issuecomment-2413749698

From shade at openjdk.org  Tue Oct 15 12:19:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 12:19:20 GMT
Subject: Integrated: 8336103: Clean up confusing Method::is_initializer
In-Reply-To: <bCys51DaXKl64gEdV10WAKffH5KEwwHZH3oIYBHmL38=.0568b7d5-1b38-40bd-8932-07050c69bd8d@github.com>
References: <bCys51DaXKl64gEdV10WAKffH5KEwwHZH3oIYBHmL38=.0568b7d5-1b38-40bd-8932-07050c69bd8d@github.com>
Message-ID: <dqxjNgdpUpTzIKf4_41tHd8M3J67kD63m2RKMnQsNUs=.9e896ef1-68cf-417b-8aa9-ed3918425546@github.com>

On Wed, 10 Jul 2024 17:15:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> All around Hotspot, we have calls to `method->is_initializer()`. That method tests for both instance and static initializers. In many cases, the uses imply we actually want to test for constructor, not static initializer. Sometimes we filter explicitly for `!m->is_static()`, sometimes we don't.  At this point, I think the best way to prevent future accidents is to remove the confusing `is_initializer`.
> 
> The behavioral changes have been handled by already integrated PRs, see the links in JBS. The changes left here are not (supposed to be) changing the behavior.

This pull request has now been integrated.

Changeset: 54c9348c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54c9348c8c0f5b363d1ef31166179fe9ac61ab9c
Stats:     24 lines in 7 files changed: 4 ins; 13 del; 7 mod

8336103: Clean up confusing Method::is_initializer

Reviewed-by: dholmes, coleenp

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

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

From dholmes at openjdk.org  Tue Oct 15 12:21:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 12:21:11 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

src/hotspot/share/runtime/sharedRuntimeTrans.cpp line 122:

> 120:   unsigned lx;
> 121: 
> 122:   static_assert(std::numeric_limits<double>::is_iec559, "IEEE 754 required");

I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1801055026

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 jsjolen at openjdk.org  Tue Oct 15 13:10:13 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 15 Oct 2024 13:10:13 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
Message-ID: <ro_IqT0f44DSnB562DhDSySQrGUNggGp1-p-O2M04C0=.74bd45a0-51e2-417e-a8ae-e1a7eca42e96@github.com>

On Tue, 15 Oct 2024 07:37:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> src/hotspot/share/classfile/javaClasses.cpp line 740:
> 
>> 738: }
>> 739: 
>> 740: bool java_lang_String::equals(oop java_string, const jchar* chars, int num_unicode_points) {
> 
> Please undo these changes - these are not "unicode points".

I don't think that you're correct here, David. As far as I understand, the length `len` does not represent the length of the `chars` array but the number of unicode code points in the array. The same is true for the other overloads, such as the UTF8 string. I'd appreciate it if you could explain why what I'm saying is incorrect here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1801134097

From aph-open at littlepinkcloud.com  Tue Oct 15 14:02:42 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 15 Oct 2024 15:02:42 +0100
Subject: [openjdk/jdk] 8338526: Don't store abstract and interface Klasses
 in class metaspace (PR #19157)
In-Reply-To: <5b4f0623-1e48-4fbe-9201-27bab3957e3b@oracle.com>
References: <openjdk/jdk/pull/19157@github.com>
 <openjdk/jdk/pull/19157/c2340431106@github.com>
 <b5b4ce8b-fda4-49ab-a5d0-cb0fdf34c8e1@littlepinkcloud.com>
 <F2151D7D-447C-4BE3-A5B5-211258FAFC10@oracle.com>
 <fed8d8ba-a814-448e-a230-b8a5c3e2fabe@littlepinkcloud.com>
 <5b4f0623-1e48-4fbe-9201-27bab3957e3b@oracle.com>
Message-ID: <c65144bd-81ee-4881-9e04-1f4628a1b2e9@littlepinkcloud.com>

On 10/14/24 22:55, coleen.phillimore at oracle.com wrote:
 >
 > Hi Andrew, I was on vacation and this isn't a complete answer but some points.

Thanks.

 > The important aspect of class metaspace area is that it's a fixed
 > size and this is also its problem. It's not location in the area,
 > it's that the area is fixed. There's piles of code and math to map
 > the class metaspace and deal with its interaction with CDS (and
 > there's also bug JDK-8340212
 > <https://bugs.openjdk.org/browse/JDK-8340212> affecting Lilliput).
 > This idea would add more code to that. Also, adding more code to
 > metaspace to direct placement location in the class metaspace is
 > code I don't wish to imagine.

OK, got that.

 > I suppose that's good you don't need the interface pointers to be in
 > the same memory area as the klass pointers. There may be a
 > performance bug with moving them so we might have to undo part of
 > this change. The goal was to have the generated classes not be in
 > class metaspace and interfaces came for the ride. But it was never a
 > design to have Metaspace pointers in Metaspace be compressed and a
 > lot of CDS and code throughout the JVM expects to just be able to
 > use pointers without adjustment.

I see. I'll have a look at what I can do.

 >> Maybe we could reduce the footprint of Klass instances. Right now,
 >> though, my invokeinterface prototypes *increase* the size of Klass
 >> instances, so I really want to have the possibility of using
 >> compressed metadata pointers.
 >
 > Increasing the size of Klass instances is painful. Make your new
 > thing something that Klass points to. It doesn't matter how much
 > memory you use in non-class metaspace.

OK. I'll think on. Please bear in mind that I have the possibility of
shrinking the size of Klass instances, which I guess you'd like too.
We're not working in opposition.

Some background to what I'm trying to do:

The HotSpot tradition seems to have been to avoid megamorphic dispatch
wherever possible. I'm interested in improving the hard cases, not
just the average, but of course the average will improve as well.

IMO, the root of the problem with megamorphic dispatch is that it's a
bunch of chained loads. When CPU prediction works well, dispatch is
really fast. When it doesn't, dispatch is relatively slow.
(https://mail.openjdk.org/pipermail/hotspot-dev/2024-October/095211.html
is an example)

 > Sorry about this Bad Thing but we are investigating exactly how to
 > do this and not lose performance. We haven't given up on this idea
 > because of aforementioned piles of code we don't like to maintain,
 > and the allure of not having the special "Class Metaspace" for each
 > ClassLoaderData anymore.

Sure, got that.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


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:54:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Oct 2024 15:54:14 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
Message-ID: <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>

On Thu, 10 Oct 2024 16:57:36 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Confirmed performance on my dev machine. Looks good!
> 

Thanks for looking at it!

> Instruction selection: no complaints. `vperm*` instructions tend to be slower on AVX2, but work great here. Clean, compact and easy-to-read implementation
> 
> I don't know enough about SHA3 to do a line-by-line asm review, but that leads me to 'experimentally confirm correctness': testing.
> 
> I am wondering how you verified your code. I did spot the existing SHA3 KAT tests from the NIST PDF. The problem with those is that unless you run tests with `-Xcomp -XX:-TieredCompilation`, the test will finish before the code is even compiled. I've done that before, running test twice with either options; its 'better then nothing' (unless I am not seeing some more tests?). I much prefer some sort of fuzzing; one great thing about working on JCE intrinsics is having a ready-made 'reference implementation' to verify things against.

 I was developing this as part of the ML-KEM and ML-DSA implementations, and there SHA3 is called quite frequently, so the test for those will test the SHA3 intrinsics, too.

 The algorithms for the hash (digest) functions are designed so that any programming error would lead to erroneous output on any input, so if your implementation produces the correct result on a few randomly chosen inputs of sizes varying from 0 bytes to several blocks then you can claim with high confidence that it is correct. 
> 
> Except I am not sure how one would implement fuzzing for SHA3, perhaps you have some thoughts. It seems impossible to have both intrinsic and java/interpreter running concurrently. For Poly1305IntrinsicFuzzTest, I used the fact that single-block digest is not intrinsified. For MontgomeryPolynomialFuzzTest, I used the fact that we have a residue-domain implementation to compare against.
> 
> For SHA3, all roads lead to the intrinsic (which is a good thing.. except for testing). No DirectByteBuffer, nor single-block bypass.. The only potential thought is the fact that single-block intrinsic appears unreachable. Looking at `DigestBase.implCompressMultiBlock`, it will always call the multi-block intrinsic (unless I am missing some fancy predicate-generation by the JIT).
 
 In a test, you can always just copy the pure Java implementation into the test and compare the results. During development of the intrinsics I like to use methods that return 0 from the intrinsic and 1 from the pure Java implementation and at the call sites, if the method returns 0  I also call the pure Java version (with a clone of the original inputs) and compare the results. 

> 
> If `DigestBase.implCompressMultiBlock` were 'fixed' to require at least 2 full blocks, before calling the multiblock intrinsic, then one could implement fuzzing by alternatively disabling one of the non-/multi-block intrinsics.

> src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1579:
> 
>> 1577:     }
>> 1578:   }
>> 1579:   void evpsrad(XMMRegister dst, KRegister mask, XMMRegister src, int shift, bool merge, int vector_len) {
> 
> more compact way to 'unhide' function from Assembler.hpp is the `using` C++ feature : `using Assembler::evpsrad;`. (You can see it being used bit further below, line 1589)
> 
> Comment repeats in (several) changes in this file.

Changed as suggested.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 85:
> 
>> 83: void StubGenerator::generate_sha3_stubs() {
>> 84:   if (UseSHA3Intrinsics) {
>> 85:     if (VM_Version::supports_evex()) {
> 
> This really should be an assert. i.e. All cpu-flag checks should be done in vm_version_x86.cpp and by this point if `UseSHA3Intrinsics` is on, "we are good to go"

Changed as suggested.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 152:
> 
>> 150: 
>> 151:   // load the state
>> 152:   __ evmovdquq(xmm0, k5, Address(state, 0), false, Assembler::AVX_512bit);
> 
> There is a potential issue with masked loads, but I confirmed (I believe) that it is not an issue here.
> 
> Background and what I tried. See [Optimization Reference Manual Vol. Chap 17.4](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html)
> 
> When using masked store and load, consider the following:
> - When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation from the 
> same address is blocked, until the data is written to the cache.
> 
> (I was hit by this in the Montgomery ECC intrinsic. The solution there was to break masked load into full loads/stores. That is a 5-element 512 load/store becomes a 64bit mov and 256-bit mov)
> 
> I ran JMH with this PR enabled and  collected perfasm. Didn't see any ticks on the loads(entry)/stores(exit). I believe this is because  of the `implCompressMultiBlock`. The only reason for the processor to use store-forwarding is if a store is followed immediately by a load. i.e. if `implCompress` was being called in a loop (it is), the first intrinsic would be fine, but all the subsequent ones would get stalled on entry, loading what the previous iteration only just saved.
> 
> With `implCompressMultiBlock`, the next iteration comes 'much later', and doesnt need store-forwarding.

Based on your comment I kept it as is.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 178:
> 
>> 176: 
>> 177:   // there will be 24 keccak rounds
>> 178:   __ movl(roundsLeft, 24);
> 
> Since `roundsLeft` is a constant, you can use a C++ loop here instead. I believe the only loop variable is `constant2use`, used for memory address access.. slightly more constant access?
> 
> Not sure if this will give you any performance benefit, but its a 'relatively easy' experiment. (ie. 23 extra copies of the loop, worth the extra cache pressure?)

I rather keep the code compact.

> src/hotspot/cpu/x86/vm_version_x86.cpp line 1316:
> 
>> 1314:   }
>> 1315: 
>> 1316:   if (UseAVX > 2) {
> 
> Should be `#ifdef _LP64`. (Similar format from above). Need to look up the cpu features required for the instructions in the intrinsic..

Added the #ifdef.

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

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2414406442
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1801483332
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1801483262
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1801483419
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1801483537
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1801483204

From duke at openjdk.org  Tue Oct 15 15:54:15 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 15 Oct 2024 15:54:15 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <ClLNLGz5sGp1pZU1jcGOo06J3zNLXk6qgmP8m6uAmdo=.875cfb7b-f686-4e17-844d-1fe4e5f15c88@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <ClLNLGz5sGp1pZU1jcGOo06J3zNLXk6qgmP8m6uAmdo=.875cfb7b-f686-4e17-844d-1fe4e5f15c88@github.com>
Message-ID: <I15ZGrr6nfgsD-FIEQ7xchY6wDABj3Zck1aTJavJWZk=.7d13bdc1-b239-4ecb-b8e2-e136d138a248@github.com>

On Thu, 10 Oct 2024 16:08:01 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 148:
>> 
>>> 146:   __ addl(rax, 8);
>>> 147:   __ kmovbl(k4, rax);
>>> 148:   __ addl(rax, 16);
>> 
>> Since you need k5 soonest, you could save a few cycles by removing the propagation dependency on rax and loading the immediate directly..
>> 
>> (If you really want to get clever, 
>> 
>>   KRegister masks[] = {k1,k2,k3,k4,k5};
>>   for (long i=2; i<=32; i*=2) {
>>     __ mov64(rax, i-1);
>>     __ kmovbl(masks[i], rax);
>>   }
>>   ```
>>   Highly debatable if its actually any more readable.. so up to you)
>
> Another alternative that is closer to the structure of your code (And uses smaller instructions..). 
> 
> - Start from the end, with `k5`, load `0x1f` constant
> - Shift constant down by one and load into next KRegister
> - (still could be done with a loop. but you decide what you find more readable..)
> 
> This way k5 is available immediately for the `evmovdquq`

Changed to start loading the mask registers from k5.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1801483636

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 psandoz at openjdk.org  Tue Oct 15 16:06:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 16:06:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
 <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
Message-ID: <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>

On Tue, 15 Oct 2024 09:35:23 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I gave it a quick scan, and I have no further comments. LGTM.

Thank you, i will kick off an internal test.

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

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2414431367

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 epeter at openjdk.org  Tue Oct 15 16:32:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 15 Oct 2024 16:32:15 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
Message-ID: <qs41c2Vqu77-mu5jnDSdHoTxwgYjAWABrhFeesVjHHk=.ae084b95-cee2-41d3-a52e-f8e650bf67a4@github.com>

On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   [vectorapi] Refactor VectorShuffle implementation

src/hotspot/cpu/x86/x86.ad line 2172:

> 2170: 
> 2171: // Return true if Vector::rearrange needs preparation of the shuffle argument
> 2172: bool Matcher::vector_needs_load_shuffle(BasicType elem_bt, int vlen) {

I think the name needs to be more expressive. If I read it alone, then I would think that it is about all kinds of vectors ... and it is confusing because what is a "load shuffle"? Are we shuffling loads or loading shuffles?

src/hotspot/share/opto/vectornode.hpp line 1618:

> 1616:  public:
> 1617:   VectorLoadShuffleNode(Node* in, const TypeVect* vt)
> 1618:     : VectorNode(in, vt) {}

Can you add a comment above "class VectorLoadShuffleNode" to say what its semantics are?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1801531980
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1801536233

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 psandoz at openjdk.org  Tue Oct 15 16:42:18 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 16:42:18 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
 <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>
Message-ID: <jmWdAoq1BA3K6a_aoM8VLfW7SMyEzxtzUGWGFEJlvhE=.e83433ed-bfcb-40b1-b019-ddb36431b9a6@github.com>

On Thu, 10 Oct 2024 16:24:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi @vnkozlov , Can you kindly run this through your test infrastructure. We have two review approvals for Java and x86 backend code.

I have kicked off some internal tests (FYI @vnkozlov)

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

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2414510216

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 ihse at openjdk.org  Tue Oct 15 17:11:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 17:11:13 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <uoYKyyDsw2tlQmw7rFO41EnOTtmFBw-eKCTPSJaQbJA=.eed6143e-b09c-45b5-8b38-0491a875c114@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Bot, keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2414569170

From rehn at openjdk.org  Tue Oct 15 17:22:15 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 17:22:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
Message-ID: <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>

On Tue, 15 Oct 2024 11:26:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into remove_t0
>>  - ICData move to t1, removed dead code
>>  - Revert clinit_barrier
>>  - Fixed no explicit use of default t1
>>  - Revert clinit_barrier t1
>>  - Upstream comment
>>  - Fixed no explicit use of default t1
>>  - Merge branch 'master' into remove_t0
>>  - Another one removing explicit use of default t1
>>  - Updated assert
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/738fa89e...c95c9601
>
> src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp line 97:
> 
>> 95:   // t0 and t1 are used as args in generate_exception_throw?
>> 96:   // so use x9 as the tmp register for rt_call.
>> 97:   __ rt_call(Runtime1::entry_for(stub_id), x9);
> 
> Not sure if `x9` is usable for us here after another look. Seems all registers must be preserved from the code comment [1]. We need to double check.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp#L130

As we are throwing an exception we get away with it in this case. (as in no test failures)
I was expecting that maybe some test would see it, as it maybe observable in some cases, but no test fails due to it. And then forgot about it :) 

As C1 only have a subset of registers available to the allocator we could use maybe use on of those to not override a local value which may be in the oopmap?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1801616872

From rehn at openjdk.org  Tue Oct 15 17:22:15 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 17:22:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
 <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>
Message-ID: <NnGv0WZrXb2Yh3kSlyBm_Cy2WN9nKSi1Hb652kIKEN0=.d3459826-314a-4692-b489-5f188bbe5ff0@github.com>

On Tue, 15 Oct 2024 17:17:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp line 97:
>> 
>>> 95:   // t0 and t1 are used as args in generate_exception_throw?
>>> 96:   // so use x9 as the tmp register for rt_call.
>>> 97:   __ rt_call(Runtime1::entry_for(stub_id), x9);
>> 
>> Not sure if `x9` is usable for us here after another look. Seems all registers must be preserved from the code comment [1]. We need to double check.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp#L130
>
> As we are throwing an exception we get away with it in this case. (as in no test failures)
> I was expecting that maybe some test would see it, as it maybe observable in some cases, but no test fails due to it. And then forgot about it :) 
> 
> As C1 only have a subset of registers available to the allocator we could use maybe use on of those to not override a local value which may be in the oopmap?

Also note that this should be slow case, so here we can actually use **ra** as we are probably about to unwind the stack, which means all predictions will be wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1801619313

From ihse at openjdk.org  Tue Oct 15 17:32:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 17:32:02 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v2]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <96UITN520SU42GFjufedN6uOlfIrduNQYGHJeMId5G0=.abccf54c-2a62-4466-8ff5-563d67a8a4f2@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

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

 - Merge branch 'master' into static-jdk-image
 - Makefile changes needed for static-launcher and static-jdk-image targets
 - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/43f57b80..0717600c

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

  Stats: 239454 lines in 2229 files changed: 213080 ins; 14335 del; 12039 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

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

From ihse at openjdk.org  Tue Oct 15 17:37:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 17:37:57 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v3]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <hYc_xPXje4v8-iykzOcLLHFlCcPGNa_SH9wM7fiJxT4=.701818af-cc38-49c2-9ad3-c509d0c488e7@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

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

  Remove superfluous SRC.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/0717600c..fc42982f

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

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

PR: https://git.openjdk.org/jdk/pull/20837

From rehn at openjdk.org  Tue Oct 15 17:46:51 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 17:46:51 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v13]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <YkA5tG8RyoFgeq265JksvTzKs7sfEUeLFwKAPaTg8kE=.be196cb7-ce18-479e-abc5-68bcd9a71f37@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Comments fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/c95c9601..8ed7d3e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=11-12

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

From rehn at openjdk.org  Tue Oct 15 17:46:53 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 17:46:53 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
Message-ID: <eRyQSWOforWTgEk3euor8GlWI-4dhlb_Ym9FIJVxukE=.890fb20e-a74a-47e7-9f52-74cddf7fe780@github.com>

On Tue, 15 Oct 2024 10:49:15 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn 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 15 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into remove_t0
>>  - ICData move to t1, removed dead code
>>  - Revert clinit_barrier
>>  - Fixed no explicit use of default t1
>>  - Revert clinit_barrier t1
>>  - Upstream comment
>>  - Fixed no explicit use of default t1
>>  - Merge branch 'master' into remove_t0
>>  - Another one removing explicit use of default t1
>>  - Updated assert
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/c39b6f3c...c95c9601
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 2895:
> 
>> 2893: // --------------------------
>> 2894:  protected:
>> 2895:   // All calls and jumps must go via MASM.
> 
> Better to add some extra code comment here about the link register usage. Say:
> 
> // All calls and jumps must go via MASM. Only use x1 (aka ra) as link register for now.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1801654493

From rehn at openjdk.org  Tue Oct 15 17:46:54 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 17:46:54 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v10]
In-Reply-To: <GilEOcItfdsuRSrGe7SnTUuAoudrTPn6nvQhcLnuCds=.09a27366-b7d7-40df-bdc6-6b3730f32bc6@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <K2q9MfCUQRDVm8tjPAON_77dzhF5zF7yU4t4iDg0zFE=.da4a2295-8d69-4393-953e-a1e212669879@github.com>
 <GilEOcItfdsuRSrGe7SnTUuAoudrTPn6nvQhcLnuCds=.09a27366-b7d7-40df-bdc6-6b3730f32bc6@github.com>
Message-ID: <QCEp2dHqzlJl3OG2s1_ghMyRzinMxJ6sjvGBHxNmFxI=.9b280dcb-5140-4cc5-a958-d537089c8544@github.com>

On Tue, 15 Oct 2024 06:27:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed no explicit use of default t1
>>  - Revert clinit_barrier t1
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 771:
> 
>> 769:                                        Label *retaddr) {
>> 770:   int32_t offset = 0;
>> 771:   push_reg(RegSet::of(t1, xmethod), sp);   // push << t0 & xmethod >> to sp
> 
> Code comment needs update.

Fixed

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 777:
> 
>> 775:     bind(*retaddr);
>> 776:   }
>> 777:   pop_reg(RegSet::of(t1, xmethod), sp);   // pop << t0 & xmethod >> from sp
> 
> Code comment needs update.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1801654874
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1801654658

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 ihse at openjdk.org  Tue Oct 15 18:15:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:15:29 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v4]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <D3K3Urn2nt1Kyz2HbRNRa_Xx0aZqxalBcZ7HJhDyWdc=.cb71273f-7f11-42cd-830f-31587b3ec5b4@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add lookup asserts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/fc42982f..7fb1b409

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=02-03

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From rehn at openjdk.org  Tue Oct 15 18:20:12 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 15 Oct 2024 18:20:12 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <NnGv0WZrXb2Yh3kSlyBm_Cy2WN9nKSi1Hb652kIKEN0=.d3459826-314a-4692-b489-5f188bbe5ff0@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
 <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>
 <NnGv0WZrXb2Yh3kSlyBm_Cy2WN9nKSi1Hb652kIKEN0=.d3459826-314a-4692-b489-5f188bbe5ff0@github.com>
Message-ID: <sbCQcuScsRFG7yKmOeuTy-3iHeMTD1BIFEJec1J-9UQ=.8b570623-b2d1-4959-a21a-554d46f59a43@github.com>

On Tue, 15 Oct 2024 17:19:15 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As we are throwing an exception we get away with it in this case. (as in no test failures)
>> I was expecting that maybe some test would see it, as it maybe observable in some cases, but no test fails due to it. And then forgot about it :) 
>> 
>> As C1 only have a subset of registers available to the allocator we could use maybe use on of those to not override a local value which may be in the oopmap?
>
> Also note that this should be slow case, so here we can actually use **ra** as we are probably about to unwind the stack, which means all predictions will be wrong.

I'm thinking about x18.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1801700582

From ihse at openjdk.org  Tue Oct 15 18:42:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:42:28 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <WOVoDcj-l7xzbL3Pj7r6eTtboY3htPzKv119r6TU45M=.9891a72b-fe0a-44c5-aa92-d9233d69e147@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/7fb1b409..7286bff4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From ihse at openjdk.org  Tue Oct 15 18:42:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:42:28 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <WfweadNY7uFR6FfVedxH7wIXrPZvwgtIo9evDUkfwZc=.39943e16-32d8-43a1-b55a-f1f7eca540c6@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <WfweadNY7uFR6FfVedxH7wIXrPZvwgtIo9evDUkfwZc=.39943e16-32d8-43a1-b55a-f1f7eca540c6@github.com>
Message-ID: <7M4W1dnpgzpFBoFp6r6dTyvHBHVCQl79hfmiYyTPMJE=.40923564-7d2b-406c-b12b-810fa630698e@github.com>

On Thu, 5 Sep 2024 00:15:35 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>
> src/java.base/unix/native/libjli/java_md.c line 509:
> 
>> 507: 
>> 508:     if (GetApplicationHome(path, pathsize)) {
>> 509:         if (JLI_IsStaticallyLinked()) {
> 
> `GetJREPath()` does not need to be called for the static case. Any reason why this path is executed for static mode?

I guess this is parts of my initial attempt to get the static launcher to work on macOS. I agree that it should not be needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801727521

From ihse at openjdk.org  Tue Oct 15 18:42:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:42:28 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>
Message-ID: <romgauTwbdM86X19_lNqJml8YpKPsmkt4qxaYz8NuhE=.d780e443-ad16-4770-b270-e6b1f4d83cfe@github.com>

On Thu, 5 Sep 2024 10:17:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>
> src/java.base/unix/native/libjli/java_md.c line 509:
> 
>> 507: 
>> 508:     if (GetApplicationHome(path, pathsize)) {
>> 509:         if (JLI_IsStaticallyLinked()) {
> 
> In passing, GetJREPath's function description includes "or registry settings" which is confusing to see now.

I updated the description.

Also, the name "JRE" is severly outdated, but cleaning out technical debt in the JLI library will have to wait for another day.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801728335

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 ihse at openjdk.org  Tue Oct 15 18:53:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:53:15 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
 <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>
Message-ID: <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>

On Thu, 5 Sep 2024 20:41:35 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> You are right, this is dead code. Thanks for spotting this. 
>> 
>> During my experimentation, I tried passing along LDFLAGS from the individual libraries as well, but it turned out not to be a good idea -- the way we have used them were to modify some special properties on a single dynamic library, which did not apply to the static library as a whole.
>> 
>> However, there is a risk that we in the future need to add LDFLAGS to a library that also needs to be carried over to the static launcher. If this happens, I guess we need to separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING.
>
> +1 on "separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING"
> 
> I think we need to get the linker flags sorted out correctly in this initial PR and make sure the needed flags (most importantly the ones used in $JVM_LDFLAGS).

After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801756571

From jiangli at openjdk.org  Tue Oct 15 19:02:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 15 Oct 2024 19:02:11 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
 <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>
 <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>
Message-ID: <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@github.com>

On Tue, 15 Oct 2024 18:50:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.

@magicus, just to make it clear, do you plan to explicitly define the set of LDFLAGS for static linking as part of this PR? We need to make sure the JVM_LDFLAGS is properly included initially.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801767849

From heidinga at openjdk.org  Tue Oct 15 19:11:14 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 15 Oct 2024 19:11:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
Message-ID: <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>

On Sun, 13 Oct 2024 21:07:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:

> 233: }
> 234: 
> 235: // TODO -- is this really correct? Do we need a special ClassLoaderData for each hidden class?

There are multiple kinds of hidden classes: 
* default ones which can be unloaded immediately when no longer referenced
* MHs.Lookup.ClassOption::STRONG which are associated with their defining loader and can only be unloaded when that loader is unloaded.

I think we need special ClassLoaderData for the non-strong (default) hidden classes

src/hotspot/share/cds/archiveUtils.cpp line 377:

> 375:   if (SystemDictionaryShared::is_excluded_class(src_ik)) {
> 376:     return false;
> 377:   }

Do we want an assert here that `ArchiveBuilder::current()->get_buffered_addr(src_ik)->has_aot_initialized_mirror() == false`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1799752753
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1799755064

From heidinga at openjdk.org  Tue Oct 15 19:11:19 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 15 Oct 2024 19:11:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - 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
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - 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
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

src/hotspot/share/cds/heapShared.cpp line 457:

> 455:   if (HeapShared::is_archivable_hidden_klass(ik)) {
> 456:     // We can't rerun the <clinit> method of hidden classes as we don't save
> 457:     // the classData, so we must archive its mirror in initialized state.

Is this comment still accurate?  It looks like we do save the class_data on line 506

src/hotspot/share/cds/heapShared.cpp line 1140:

> 1138:       return false;
> 1139:     }
> 1140:   }

This is conservatively correct in that it checks all implemented interfaces.  We could be less conservative and only check interfaces that have a "non-abstract non-static" (aka default) method as those are the interfaces that will be initialized along with the class as per JVMS 5.5

src/hotspot/share/cds/metaspaceShared.cpp line 873:

> 871:       Symbol* method_sig = vmSymbols::void_method_signature();
> 872:       JavaCalls::call_static(&result, vmClasses::Class_klass(),
> 873:                              method_name, method_sig, CHECK);

Is this a good candidate for a `runtimeResolve` helper method?  Can we roll it into the same mechanism as the other `runtimeResolve` classes use?

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 599:

> 597: 
> 598:     /** Number of CPUS, to place bounds on some sizings */
> 599:     static @Stable int NCPU;

I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801391257
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801410321
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801597570
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801777860

From ihse at openjdk.org  Tue Oct 15 19:31:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 19:31:48 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v6]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <saXCPxxQ35xy2XiF3jMgKaF_akmhTOnTm3B2Oynj4DI=.458fbf88-f0d9-4046-b524-7e281c60a46e@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Setup LDFLAGS_STATIC_JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/7286bff4..53ae4779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=04-05

  Stats: 16 lines in 5 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From ihse at openjdk.org  Tue Oct 15 19:34:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 19:34:14 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v6]
In-Reply-To: <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
 <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>
 <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>
 <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@github.com>
Message-ID: <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@github.com>

On Tue, 15 Oct 2024 18:59:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.
>
>> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.
> 
> @magicus, just to make it clear, do you plan to explicitly define the set of LDFLAGS for static linking as part of this PR? We need to make sure the JVM_LDFLAGS is properly included initially.

Yes, I just pushed a commit that does that. I have manually inspected the values and it looks sane, but I need to verify it on our CI system as well. The reasoning for us setting some of the ld flags are less than clear, so it is a bit hard to tell if they should be included or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801804046

From iklam at openjdk.org  Tue Oct 15 19:35:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 19:35:16 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <pgNVGyhN6uSCgipzMJeUoJd0BMJnb9qa-7Hpn6EWz6M=.8d294031-08a7-4450-a7af-1f46bb159436@github.com>

On Tue, 15 Oct 2024 19:08:20 GMT, Dan Heidinga <heidinga 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 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 599:
> 
>> 597: 
>> 598:     /** Number of CPUS, to place bounds on some sizings */
>> 599:     static @Stable int NCPU;
> 
> I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.

We have been archiving `ConcurrentHashMap` objects for many JDK releases (to support archiving of modules) and `NCPU` would change between CDS archive dump time and program run time. We have not seen any problems, so I think it's safe to use the `@Stable` annotation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801804442

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 psandoz at openjdk.org  Tue Oct 15 19:43:24 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 19:43:24 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
Message-ID: <E_NmeXkYvphAUlV9ab5g0NGuFkkW0FyyYRIgV-X8zuo=.e729a2bf-e5c9-4cec-92b7-539125e2eb67@github.com>

On Sun, 13 Oct 2024 09:57:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update adlc changes.

The compiler test `test/hotspot/jtreg/compiler/vectorapi/VectorCompareWithZeroTest.java` fails to compile and needs to update to use the renamed constants (`UNSIGNED_GT` -> `UGT` and `UNSIGNED_GE` -> `UGE`). This test is only compiled and run on aarch64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2414859793

From liach at openjdk.org  Tue Oct 15 19:45:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 19:45:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <XVzsnY9pNVOn-p6DILd10hZz5_kA0kGfyMJRGD-k6qQ=.087aba1f-6291-422c-ae1c-84da9d90495e@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - 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
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - 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
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

I recommend adding javadoc or block comments indicating that `runtimeSetup`, `resetArchivedStates`, etc. are called by VM CDS code so people don't accidentally rename this and have unintended impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2414863856

From stefank at openjdk.org  Tue Oct 15 19:45:15 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Oct 2024 19:45:15 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - 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
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - 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
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

src/hotspot/share/memory/iterator.inline.hpp line 53:

> 51:     // class has not yet been loaded by CDS.
> 52:     cld->oops_do(this, _claim);
> 53:   }

Could you show the stack trace for this? I want to understand better why we are iterating over objects that don't have a loaded class.

src/hotspot/share/oops/cpCache.cpp line 52:

> 50: #include "oops/objArrayOop.inline.hpp"
> 51: #include "oops/oop.inline.hpp"
> 52: #include "oops/method.inline.hpp"

Could you go over the entire patch and fix sort order of added includes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801811576
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801813265

From aph at openjdk.org  Tue Oct 15 19:49:11 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 15 Oct 2024 19:49:11 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
Message-ID: <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>

On Tue, 15 Oct 2024 12:18:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?

It needs to return -Inf. ubsan seems wrong here: this IEEE-754 arithmetic is well defined, and has been for a very long while.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1801820032

From liach at openjdk.org  Tue Oct 15 19:54:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 19:54:15 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <OtkZfudYN1NRi5p6PHHj53UcVz247butMciqvzKEjko=.09bace39-def8-4d56-9955-9ab97f81b4ce@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - 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
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - 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
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:

> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
> 403:         if (archivedMethodTypes != null) {
> 404:             MethodType mt = archivedMethodTypes.get(primordialMT);

The use of `HashMap` naturally feels alarming given this method is invoked in a concurrent context. I just want to make sure that:

1. `HashMap` will never have structural modifications when read access is performed (some data structures like treap do). Don't know if we have a test to verify such an intended usage, as we would hurt badly if this implied property suddenly no longer exist.
2. The `archivedMethodTypes` must be properly published so we won't read a partial `HashMap`. I've heard of talks about concurrent VM bootstraping so I need some help to understand how this is ensured in bootstrap.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801825750

From ihse at openjdk.org  Tue Oct 15 20:22:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 20:22:52 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Don't hardcode server variant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/53ae4779..03cd9171

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

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 psandoz at openjdk.org  Tue Oct 15 21:00:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 21:00:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
 <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
 <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>
Message-ID: <PeHpp7eJFyoOLEJuDfHPoZMJ3IsTtoAYvBrkAjHcnT4=.18a889e2-4bbf-4773-bda8-9027471ab79e@github.com>

On Tue, 15 Oct 2024 16:03:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > I gave it a quick scan, and I have no further comments. LGTM.
> 
> Thank you, i will kick off an internal test.

Tier 1 to 3 tests pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2415121395

From psandoz at openjdk.org  Tue Oct 15 21:00:25 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 21:00:25 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <jmWdAoq1BA3K6a_aoM8VLfW7SMyEzxtzUGWGFEJlvhE=.e83433ed-bfcb-40b1-b019-ddb36431b9a6@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
 <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>
 <jmWdAoq1BA3K6a_aoM8VLfW7SMyEzxtzUGWGFEJlvhE=.e83433ed-bfcb-40b1-b019-ddb36431b9a6@github.com>
Message-ID: <K7F0Rz8uY0YSYOJZW07k5Of9i6Ghqn3BfiYDtgWa2B0=.62b3a26e-2c71-4c60-a84d-2d5d03b643d3@github.com>

On Tue, 15 Oct 2024 16:39:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > Hi @vnkozlov , Can you kindly run this through your test infrastructure. We have two review approvals for Java and x86 backend code.
> 
> I have kicked off some internal tests (FYI @vnkozlov)

Tier 1 to 3 test past, except for the trivial source compilation error previously mentioned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2415124207

From dholmes at openjdk.org  Tue Oct 15 21:04:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 21:04:49 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <ro_IqT0f44DSnB562DhDSySQrGUNggGp1-p-O2M04C0=.74bd45a0-51e2-417e-a8ae-e1a7eca42e96@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
 <ro_IqT0f44DSnB562DhDSySQrGUNggGp1-p-O2M04C0=.74bd45a0-51e2-417e-a8ae-e1a7eca42e96@github.com>
Message-ID: <Ag74cYwNI-95cGZ8H3xy16Kru0fFYTGqzMM2L9mwsBQ=.ae473c3e-be7f-40b9-ba95-c6cb82ba7418@github.com>

On Tue, 15 Oct 2024 13:07:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 740:
>> 
>>> 738: }
>>> 739: 
>>> 740: bool java_lang_String::equals(oop java_string, const jchar* chars, int num_unicode_points) {
>> 
>> Please undo these changes - these are not "unicode points".
>
> I don't think that you're correct here, David. As far as I understand, the length `len` does not represent the length of the `chars` array but the number of unicode code points in the array. The same is true for the other overloads, such as the UTF8 string. I'd appreciate it if you could explain why what I'm saying is incorrect here.

The `len` parameter is just the length of the array. We use it to iterate through the array. e.g.

    for (int i = 0; i < len; i++) {
      if (value->char_at(i) != chars[i]) {
        return false;
      }
    }

But you are right that this is also the number of "code points" as defined by the Unicode standard - my apologies for that. I was mistakenly thinking that codepoints refer to actual characters, but it is a general term used for any numeric value in the unicode codespace, including non-characters and importantly surrogates. But while technically accurate I don't think using `num_unicode_points` adds any value here - quite the opposite as it obscures that this is simply the length of the array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802004224

From dholmes at openjdk.org  Tue Oct 15 21:15:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 21:15:12 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>

On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

src/hotspot/share/classfile/stringTable.hpp line 88:

> 86:   static const jchar *to_unicode(StringWrapper wrapped_str, int len, TRAPS);
> 87:   static Handle to_handle(StringWrapper wrapped_str, int len, TRAPS);
> 88:   static void print_string(StringWrapper wrapped_str, int len, TRAPS);

What is `len` supposed to represent in all of these methods? The code only makes sense to me if `len` here is actually "number of unicode characters" (which need not be the same as the length of any wrapped UTF8 sequence).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802026263

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 psandoz at openjdk.org  Tue Oct 15 21:40:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 21:40:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
 <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
Message-ID: <NOT5_LOX5SjoqP9LDMBfBRP3WAYKXaDekzBG88wJ0L4=.75dcd6ec-20e5-4fc3-bd80-cb9c4430d470@github.com>

On Tue, 15 Oct 2024 10:19:46 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Are there any IR rules that verify that the correct C2 nodes are used? Is that a thing you generally do with the VectorAPI, just to make sure things get correctly intrinsified?

Not systematically. We have some IR testing for more complex areas, located under `test/hotspot/jtreg/compiler/vectorapi/`. When we started out testing there was no IR testing framework so we relied on classic unit tests running a test N times for C2 to kick in. That is still the case for the majority of tests. It would be nice to have a better balance, and a way to systematically generate IR tests for the various vector operations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2415212261

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: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 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 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 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 dholmes at openjdk.org  Tue Oct 15 22:47:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 22:47:16 GMT
Subject: RFR: 8338018: Rename ClassPrelinker to AOTConstantPoolResolver
 [v5]
In-Reply-To: <iqdCIJySbVmf2ODYnEyxZRPmwnzPlN7GPLm11myGWjU=.9e0a9408-8cdf-42c1-8b07-76da3779b912@github.com>
References: <qwgqFcAWa8zm8bUF9TwQTebN2Y5InxciePCsvOWgDUU=.283c8bdc-b858-46d9-97c7-aeceece253ff@github.com>
 <iqdCIJySbVmf2ODYnEyxZRPmwnzPlN7GPLm11myGWjU=.9e0a9408-8cdf-42c1-8b07-76da3779b912@github.com>
Message-ID: <px93iOFhTyTDwgfvFvcg2V4HQNokGuN34bdNmjM5d5E=.e8c1d804-f260-41ba-aba1-14df09a2511f@github.com>

On Mon, 14 Oct 2024 05:34:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 2nd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> A simple renaming of the `ClassPrelinker` class to `AOTConstantPoolLinker`, so that the name is consistent with new classes that will be introduced in subsequent PRs for JEP 483 (`AOTClassLinker`, `AOTLinkedClassTable`, and `AOTLinkedClassBulkLoader`).
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
>  - 8338018: Rename ClassPrelinker to AOTConstantPoolResolver

Still good

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20517#pullrequestreview-2370822556

From duke at openjdk.org  Tue Oct 15 22:59:11 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Oct 2024 22:59:11 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
Message-ID: <E-sE4Tg1T-OXy_vKucyDoQuyMsIOHGx3CngdnC5Cguw=.86fd5e28-0e03-4691-9704-4d7def9083c1@github.com>

On Tue, 15 Oct 2024 15:51:59 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> I was developing this as part of the ML-KEM and ML-DSA implementations, and there SHA3 is called quite frequently, so the test for those will test the SHA3 intrinsics, too.

I suppose it works. When possible, I rather have a more granular unit test (and we don't have the code for those algorithms yet. erm, right?)

> In a test, you can always just copy the pure Java implementation into the test and compare the results. During development of the intrinsics I like to use methods that return 0 from the intrinsic and 1 from the pure Java implementation and at the call sites, if the method returns 0 I also call the pure Java version (with a clone of the original inputs) and compare the results.

If you still have it and it can be 'made clean'..  I would love to see some of that 'scaffolding test code' kept for the final commit. (I like to imagine the 'final code cleanup' as 'removing **scaffolding** from a construction site' :) ) This will be especially useful if (when?) we revisit the intrinsic. (I can already see us also needing an AVX2 version.. someone will need to re-learn how to verify that intrinsic too)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2415307895

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 kvn at openjdk.org  Tue Oct 15 23:04:09 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 15 Oct 2024 23:04:09 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
Message-ID: <ECHiww7tz-Qi7QB9wgj6TlUEYs4xDo0HDS0wxkRLjWE=.c83ffcc6-d142-42da-819e-c578efac984e@github.com>

On Tue, 15 Oct 2024 15:51:59 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> Confirmed performance on my dev machine. Looks good!
>> 
>> Instruction selection: no complaints. `vperm*` instructions tend to be slower on AVX2, but work great here. Clean, compact and easy-to-read implementation
>> 
>> I don't know enough about SHA3 to do a line-by-line asm review, but that leads me to 'experimentally confirm correctness': testing.
>> 
>> I am wondering how you verified your code. I did spot the existing SHA3 KAT tests from the NIST PDF. The problem with those is that unless you run tests with `-Xcomp -XX:-TieredCompilation`, the test will finish before the code is even compiled. I've done that before, running test twice with either options; its 'better then nothing' (unless I am not seeing some more tests?). I much prefer some sort of fuzzing; one great thing about working on JCE intrinsics is having a ready-made 'reference implementation' to verify things against.
>> 
>> Except I am not sure how one would implement fuzzing for SHA3, perhaps you have some thoughts. It seems impossible to have both intrinsic and java/interpreter running concurrently. For Poly1305IntrinsicFuzzTest, I used the fact that single-block digest is not intrinsified. For MontgomeryPolynomialFuzzTest, I used the fact that we have a residue-domain implementation to compare against.
>> 
>> For SHA3, all roads lead to the intrinsic (which is a good thing.. except for testing). No DirectByteBuffer, nor single-block bypass.. The only potential thought is the fact that single-block intrinsic appears unreachable. Looking at `DigestBase.implCompressMultiBlock`, it will always call the multi-block intrinsic (unless I am missing some fancy predicate-generation by the JIT).
>> 
>> If `DigestBase.implCompressMultiBlock` were 'fixed' to require at least 2 full blocks, before calling the multiblock intrinsic, then one could implement fuzzing by alternatively disabling one of the non-/multi-block intrinsics.
>
>> Confirmed performance on my dev machine. Looks good!
>> 
> 
> Thanks for looking at it!
> 
>> Instruction selection: no complaints. `vperm*` instructions tend to be slower on AVX2, but work great here. Clean, compact and easy-to-read implementation
>> 
>> I don't know enough about SHA3 to do a line-by-line asm review, but that leads me to 'experimentally confirm correctness': testing.
>> 
>> I am wondering how you verified your code. I did spot the existing SHA3 KAT tests from the NIST PDF. The problem with those is that unless you run tests with `-Xcomp -XX:-TieredCompilation`, the test will finish before the code is even compiled. I've done that before, running test twice with either options; its 'better then nothing' (unless I am not seeing some more tests?). I much prefer some sort of fuzzing; one great thing about working on JCE intrinsics is having a ready-made 'reference implementation' to verify things against.
> 
>  I was developing this as part of the ML-KEM and ML-DSA implementations, and there SHA3 is called quite frequently, so the test for those will test the SHA3 intrinsics, too.
> 
>  The algorithms for the hash (digest) functions are designed so that any programming error would lead to erroneous output on any input, so if your implementation produces the correct result on a few randomly chosen inputs of sizes varying from 0 bytes to several blocks then you can claim with high confidence that it is correct. 
>> 
>> Except I am not sure how one would implement fuzzing for SHA3, perhaps you have some thoughts. It seems impossible to have both intrinsic and java/interpreter running concurrently. For Poly1305IntrinsicFuzzTest, I used the fact that single-block digest is not intrinsified. For MontgomeryPolynomialFuzzTest, I used the fact that we have a residue-domain implementation to compare against.
>> 
>> For SHA3, all roads lead to the intrinsic (which is a good thing.. except for testing). No DirectByteBuffer, nor single-block bypass.. The only potential thought is the fact that single-block intrinsic appears unreachable. Looking at `DigestBase.implCompressMultiBlock`, it will always call the multi-block intrinsic (unless I am missing some fancy predicate-generation by the JIT).
>  
>  In a test, you can always just copy the pure Java implementation into the test and compare the results. During development of the intrinsics I like to use methods that return 0 from the intrinsic and 1 from the pure Java implementation and at the call sites, if the method returns 0  I...

@ferakocz I thank you need to enble SHA3 testing in jtreg tests we have by modifying:
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L106

[JDK-8252204](https://bugs.openjdk.org/browse/JDK-8252204) added several C2 tests for SHA3 intrinsics in `test/hotspot/jtreg/compiler/intrinsics/sha`. Please make sure your changes passed those tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2415313075

From duke at openjdk.org  Tue Oct 15 23:04:10 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Oct 2024 23:04:10 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
Message-ID: <8F-WvJYHaXUKjOVezAkCU4PabjWQpMhzSB_GHor7wc8=.b8ccfebd-cff6-4147-a5f6-75458e156bcc@github.com>

On Tue, 15 Oct 2024 15:51:47 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> I rather keep the code compact.

Just to make sure we were on the same page. I was suggesting an experiment that would not have substantially changed the C++ line count, but replaced the runtime asm loop with compile time C++ loop (at cost of _generated code_ size, which is perhaps what you meant?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1802109976

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 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:42:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 23:42:55 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v15]
In-Reply-To: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
Message-ID: <Ww5mF-FP13it3zYeuKWeqPcVdYWv9nUCQGl0fhSmzYY=.372d012b-fc84-4dd2-8a1b-3b43abbd650d@github.com>

> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Problem:**
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
> 
> **Solution:**
> 
> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
> 
> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
> 
> **Review Notes:**
> 
> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
> 
> **Caveats:**
> 
> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the environment:
> 
> 
> enum Foo {
>     [....]
>     static fin...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - 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
 - 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
 - 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
 - Adjust TEST.groups after merge with mainline
 - For aot-inited classes, require the <clinit> of all supertypes to be executed in assembly phase as well
 - changed dumptime_xxx to dump_time_xxx to be consistent with other fields in heapShared.hpp
 - comments from @adinn and @ashu-mehra
 - 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
 - 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
 - Fixed typo
 - ... and 16 more: https://git.openjdk.org/jdk/compare/6bb38cb9...dd4f0c99

-------------

Changes: https://git.openjdk.org/jdk/pull/20958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20958&range=14
  Stats: 990 lines in 20 files changed: 878 ins; 25 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/20958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20958/head:pull/20958

PR: https://git.openjdk.org/jdk/pull/20958

From iklam at openjdk.org  Tue Oct 15 23:53:52 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 23:53:52 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v10]
In-Reply-To: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
Message-ID: <QP44k2BV6NZs4Bx95dHEVyAMRlatYtDtwsj7KQJS2pA=.a9c291b7-faee-44a2-9ebc-761e43895b8c@github.com>

> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
> 
> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge 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-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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @coleenp comments
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @vnkozlov comment - added NOT_CDS_RETURN
 - 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
 - ... and 7 more: https://git.openjdk.org/jdk/compare/6aa442c7...a9356279

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20959/files
  - new: https://git.openjdk.org/jdk/pull/20959/files/84777aa4..a9356279

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20959&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20959&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20959/head:pull/20959

PR: https://git.openjdk.org/jdk/pull/20959

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 iklam at openjdk.org  Tue Oct 15 23:59:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 23:59:12 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v9]
In-Reply-To: <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>
 <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>
Message-ID: <Y-vvhT_uwJsZWl6YZtnoD9UTP19uc8vXRXIhZYHPUKM=.7dec13ef-0610-4f87-b482-c01215e04d57@github.com>

On Mon, 14 Oct 2024 15:09:19 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam 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 16 additional commits since the last revision:
>> 
>>  - 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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - @coleenp comments
>>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - @vnkozlov comment - added NOT_CDS_RETURN
>>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/65d49dcc...84777aa4
>
> src/hotspot/share/classfile/systemDictionary.cpp line 2097:
> 
>> 2095:     }
>> 2096: 
>> 2097:     MutexLocker ml(InvokeMethodIntrinsicTable_lock);
> 
> Should we take this lock once outside the loop and hold it for the duration rather than taking it just again and again before each add operation?

The lock cannot be held while calling `AdapterHandlerLibrary::create_native_wrapper()` -- a few lines above. Otherwise  you'd see an error like

> assert(false) failed: Attempting to acquire lock AdapterHandlerLibrary_lock/safepoint out of order with lock InvokeMethodIntrinsicTable_lock/safepoint -- possible deadlock

You can see the same pattern with the existing code

https://github.com/openjdk/jdk/blob/b9cabbecdac27ae8b93df88660a4a0f3f60e6828/src/hotspot/share/classfile/systemDictionary.cpp#L2008-L2022

Most of the work is done inside `AdapterHandlerLibrary::create_native_wrapper()`, which generates native code. Also, this loop happens while the JVM is still in single-threaded mode, so there's no contention on the lock. The cost of taking this lock is negligible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20959#discussion_r1802140753

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 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 dholmes at openjdk.org  Wed Oct 16 00:17:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 00:17:11 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
Message-ID: <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>

On Tue, 15 Oct 2024 21:12:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> src/hotspot/share/classfile/stringTable.hpp line 88:
> 
>> 86:   static const jchar *to_unicode(StringWrapper wrapped_str, int len, TRAPS);
>> 87:   static Handle to_handle(StringWrapper wrapped_str, int len, TRAPS);
>> 88:   static void print_string(StringWrapper wrapped_str, int len, TRAPS);
> 
> What is `len` supposed to represent in all of these methods? The code only makes sense to me if `len` here is actually "number of unicode characters" (which need not be the same as the length of any wrapped UTF8 sequence).

Actually that in itself is not enough to make the code correct AFAICS. Consider this example from Table 2-11, page 71, in https://www.unicode.org/versions/Unicode16.0.0/UnicodeStandard-16.0.pdf The Unicode character 00010384 in UTF-32, consists of the surrogate pair D800, DF84 in UTF-16, and the four byte sequence F0, 90, 8E, 84 in UTF-8. So if we have a java.lang.String that represents this single unicode character, the String will consist of an array of 2 char values, and the UTF8 representation would consist of 4 byte values. So if you were doing an equals comparison between the String's value array and the utf_str, what length would you pass to the equals method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802150535

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 iklam at openjdk.org  Wed Oct 16 01:26:45 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 01:26:45 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v6]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
 - 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
 - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
 - 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
 - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
 - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
 - @adinn comments
 - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
 - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
 - 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
 - ... and 21 more: https://git.openjdk.org/jdk/compare/11391c39...a6ad908f

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=05
  Stats: 2216 lines in 64 files changed: 1972 ins; 103 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

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 iklam at openjdk.org  Wed Oct 16 01:29:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 01:29:12 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
Message-ID: <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>

On Mon, 14 Oct 2024 15:52:07 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:
> 
>> 233: }
>> 234: 
>> 235: // TODO -- is this really correct? Do we need a special ClassLoaderData for each hidden class?
> 
> There are multiple kinds of hidden classes: 
> * default ones which can be unloaded immediately when no longer referenced
> * MHs.Lookup.ClassOption::STRONG which are associated with their defining loader and can only be unloaded when that loader is unloaded.
> 
> I think we need special ClassLoaderData for the non-strong (default) hidden classes

We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've added a comment and tightened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802208841

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 dlong at openjdk.org  Wed Oct 16 01:56:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 16 Oct 2024 01:56:21 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v29]
In-Reply-To: <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
Message-ID: <uwMyIdGaqXv-NNzqIXOlRjyOASxKBAqoerp9AlaM8rA=.40bc9ab5-1be2-40f2-b8da-c87081a3b08c@github.com>

On Tue, 15 Oct 2024 11:08:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen assertion

Latest version looks good.

-------------

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2371013844

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 jbhateja at openjdk.org  Wed Oct 16 01:59:18 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 01:59:18 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <PeHpp7eJFyoOLEJuDfHPoZMJ3IsTtoAYvBrkAjHcnT4=.18a889e2-4bbf-4773-bda8-9027471ab79e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
 <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
 <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>
 <PeHpp7eJFyoOLEJuDfHPoZMJ3IsTtoAYvBrkAjHcnT4=.18a889e2-4bbf-4773-bda8-9027471ab79e@github.com>
Message-ID: <ApQGwv8Y0spGjlOYX8tVAsELt-mln6n-cAU3E3koPnw=.52f1f93a-f2c2-4dea-9beb-789ff4707c75@github.com>

On Tue, 15 Oct 2024 20:57:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> I gave it a quick scan, and I have no further comments. LGTM.
>> 
>> Thank you, i will kick off an internal test.
>
>> > I gave it a quick scan, and I have no further comments. LGTM.
>> 
>> Thank you, i will kick off an internal test.
> 
> Tier 1 to 3 tests pass.

Thanks @PaulSandoz , @sviswa7 and @eme64 for review suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2415566209

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 fyang at openjdk.org  Wed Oct 16 02:10:14 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Oct 2024 02:10:14 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <sbCQcuScsRFG7yKmOeuTy-3iHeMTD1BIFEJec1J-9UQ=.8b570623-b2d1-4959-a21a-554d46f59a43@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
 <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>
 <NnGv0WZrXb2Yh3kSlyBm_Cy2WN9nKSi1Hb652kIKEN0=.d3459826-314a-4692-b489-5f188bbe5ff0@github.com>
 <sbCQcuScsRFG7yKmOeuTy-3iHeMTD1BIFEJec1J-9UQ=.8b570623-b2d1-4959-a21a-554d46f59a43@github.com>
Message-ID: <yVT_yLxON0RjrHAlR_c0qjBM_49BGgvMfKafSxpFRTI=.525fd04e-adcb-4f98-8ea2-0f1f47b45b6d@github.com>

On Tue, 15 Oct 2024 18:17:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Also note that this should be slow case, so here we can actually use **ra** as we are probably about to unwind the stack, which means all predictions will be wrong.
>
> I'm thinking about x18.

So you want a RAS push action when you change to different register from `ra`. But seems to me that the original code with `ra` also achieves the same purpose from the spec. RAS push action is supposed to happen when rd=rs1=ra, which enable macro-op fusion of the sequence `auipc ra, imm20; jalr ra, imm12(ra)`. So I think we can simply revert this change. Anyway, this should be a slow case as you mentioned.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1802232487

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 iklam at openjdk.org  Wed Oct 16 02:42:52 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 02:42:52 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typo in last commit; fixed header inclusion order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/a6ad908f..4be6a255

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=05-06

  Stats: 38 lines in 15 files changed: 17 ins; 20 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Wed Oct 16 02:42:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 02:42:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
Message-ID: <A7SLv__ysUzcQBnxEXOqCyqXz-3-6hXSoCi5706VnxA=.17365c73-7f14-4886-bb27-2503e97ec5c9@github.com>

On Tue, 15 Oct 2024 19:40:15 GMT, Stefan Karlsson <stefank 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 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/oops/cpCache.cpp line 52:
> 
>> 50: #include "oops/objArrayOop.inline.hpp"
>> 51: #include "oops/oop.inline.hpp"
>> 52: #include "oops/method.inline.hpp"
> 
> Could you go over the entire patch and fix sort order of added includes.

I fixed the include problems found by my script. I'll make sure to run the script again before the final push.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802252522

From iklam at openjdk.org  Wed Oct 16 03:32:14 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 03:32:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
Message-ID: <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>

On Tue, 15 Oct 2024 19:38:43 GMT, Stefan Karlsson <stefank 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 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/memory/iterator.inline.hpp line 53:
> 
>> 51:     // class has not yet been loaded by CDS.
>> 52:     cld->oops_do(this, _claim);
>> 53:   }
> 
> Could you show the stack trace for this? I want to understand better why we are iterating over objects that don't have a loaded class.

Here's the call stack if I remove the "if" check on line 49. It can be reproduced with test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java from the PR repo.


10 javaSignalHandler (sig=11, info=0x7ffff428fdb0, context=0x7ffff428fc80)
12 Atomic::PlatformLoad::operator() (this=0x7ffff429097f, dest=0x28)
13 Atomic::LoadImpl, void>::operator() (this=0x7ffff42909af, dest=0x28)
14 Atomic::load (dest=0x28)
15 ClassLoaderData::try_claim (this=0x0, claim=4)
16 ClassLoaderData::oops_do (this=0x0, f=0x7fff6c014c88, claim_value=4, clear_mod_oops=false)
17 ClaimMetadataVisitingOopIterateClosure::do_cld (this=0x7fff6c014c88, cld=0x0)
18 ClaimMetadataVisitingOopIterateClosure::do_klass (this=0x7fff6c014c88, k=0x7fff763655d8)
19 call_do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
20 Devirtualizer::do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
21 InstanceKlass::oop_oop_iterate (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
22 OopOopIterateDispatch::Table::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, k=0x7fff763655d8)
23 OopIteratorClosureDispatch::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, klass=0x7fff763655d8)
24 oopDesc::oop_iterate (this=0xfffd72a0, cl=0x7fff6c014c88)
25 G1FullGCMarker::follow_object (this=0x7fff6c014630, obj=0xfffd72a0)
26 G1FullGCMarker::publish_and_drain_oop_tasks (this=0x7fff6c014630)
27 G1FullGCMarker::follow_marking_stacks (this=0x7fff6c014630)
28 G1FullGCMarker::complete_marking (this=0x7fff6c014630, oop_stacks=0x7fffd445c6b8, array_stacks=0x7fffd445c6d0, terminator=0x7fffd445c190)
29 G1FullGCMarkTask::work (this=0x7fffd445c030, worker_id=0)
30 WorkerTaskDispatcher::worker_run_task (this=0x7ffff008b9b8)
31 WorkerThread::run (this=0x7ffff008bac0)


This is in a GC triggered by here (with -XX:VerifyArchivedFields=2).


void HeapShared::init_archived_fields_for(Klass* k, 
     const ArchivedKlassSubGraphInfoRecord* record) {
  verify_the_heap(k, "before");


At frame 18:


#18 0x00007ffff58505d1 in ClaimMetadataVisitingOopIterateClosure::do_klass 
    (this=0x7fff6c014c88, k=0x7fff763655d8)
    at src/hotspot/share/memory/iterator.inline.hpp:58
58	  ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
(gdb) psym k->_name
$1 = 0x7fff765430be "BulkLoaderTestApp$$Lambda+0x800000013"
(gdb) p k->_class_loader_data
$2 = (ClassLoaderData *) 0x0
(gdb) p SystemDictionary::_java_system_loader 
$3 = {_obj = 0x0}


At frame 21:


#21 0x00007ffff6132f6f in InstanceKlass::oop_oop_iterate<narrowOop, G1MarkAndPushClosure> 
    (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
    at src/hotspot/share/oops/instanceKlass.inline.hpp:164
164	    Devirtualizer::do_klass(closure, this);
(gdb) call pp(obj)
"Executing pp"
BulkLoaderTestApp$$Lambda/0x800000013 
{0x00000000fffd72a0} - klass: 'BulkLoaderTestApp$$Lambda+0x800000013' - flags: is_hidden_class 


The root cause is:

- A lambda has been aot-resolved for a class loaded by the app loader
- There is an instance (`0xfffd72a0`) of the lambda proxy class (`BulkLoaderTestApp$$Lambda+0x800000013`) that represents this call site 
- At the point of failure, all archived heap objects, including `0xfffd72a0`, are reachable (through `HeapShared::_root_segments`).
- However, we are still early in VM bootstrap. The `_java_system_loader` isn't available yet, so we are not yet able to load the lambda proxy class.

Before JEP 483, all archived objects are from java.base, and the `VerifyArchivedFields` code was careful to not trigger a GC until `is_init_completed()` becomes true.

However, with JEP 483, it's possible to have an archived object from the app class loader, and it's legally possible for a GC to happen before the app loader is available. Thus we come into this situation.

(Ping @fisk @coleenp in case you're curious)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802291536

From jpai at openjdk.org  Wed Oct 16 03:59:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 03:59:14 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <romgauTwbdM86X19_lNqJml8YpKPsmkt4qxaYz8NuhE=.d780e443-ad16-4770-b270-e6b1f4d83cfe@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>
 <romgauTwbdM86X19_lNqJml8YpKPsmkt4qxaYz8NuhE=.d780e443-ad16-4770-b270-e6b1f4d83cfe@github.com>
Message-ID: <AGiQVfr2GLhFDHwfvhfCgDhye46Kk6BDTzZ6wwFdQM8=.deddaa24-e3b6-4523-af3e-6d7802f53a64@github.com>

On Tue, 15 Oct 2024 18:39:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/unix/native/libjli/java_md.c line 509:
>> 
>>> 507: 
>>> 508:     if (GetApplicationHome(path, pathsize)) {
>>> 509:         if (JLI_IsStaticallyLinked()) {
>> 
>> In passing, GetJREPath's function description includes "or registry settings" which is confusing to see now.
>
> I updated the description.
> 
> Also, the name "JRE" is severly outdated, but cleaning out technical debt in the JLI library will have to wait for another day.

Hello Magnus,

> Also, the name "JRE" is severly outdated, but cleaning out technical debt in the JLI library will have to wait for another day.

I have some changes in this launcher area (for clean up) that will show up as PRs in the coming days.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1802309882

From dholmes at openjdk.org  Wed Oct 16 05:08:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 05:08:11 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v5]
In-Reply-To: <DWAfC5RTULIbufLGZRxHqg_mcMtImDrplsUz8UdCvRM=.03051ace-3ab7-46c5-9072-092b257b1a36@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <DWAfC5RTULIbufLGZRxHqg_mcMtImDrplsUz8UdCvRM=.03051ace-3ab7-46c5-9072-092b257b1a36@github.com>
Message-ID: <2T8YMFdoCbebmZHIdaWWM7N14SMYIV0-NFxQb-hu3Wo=.5e7740eb-30a7-4f1c-83d3-46c525624b02@github.com>

On Mon, 14 Oct 2024 14:57:26 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused include

One renaming suggestion but otherwise seems fine. Thanks.

src/hotspot/share/cds/cdsProtectionDomain.cpp line 212:

> 210: }
> 211: 
> 212: oop CDSProtectionDomain::get_shared_jar_url_helper(const char* path, Handle url_h, TRAPS) {

Suggestion:

oop CDSProtectionDomain::get_file_URL(const char* path, Handle url_h, TRAPS) {

It looks odd to have a "helper" method as part of the public API, especially when called directly.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21329#pullrequestreview-2371203175
PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1802356129

From liach at openjdk.org  Wed Oct 16 05:16:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 05:16:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v6]
In-Reply-To: <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>
Message-ID: <DB_AbfZbFKp1UoN9RQE0mQzKc6VufflWanWJSqO2v8I=.4b41450e-79af-44f1-9bc6-4e50d927b17c@github.com>

On Wed, 16 Oct 2024 01:26:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
>  - 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
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - 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
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - 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
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/11391c39...a6ad908f

src/hotspot/share/cds/heapShared.cpp line 447:

> 445: 
> 446: bool HeapShared::is_string_concat_klass(InstanceKlass* ik) {
> 447:   return ik->is_hidden() && ik->name()->starts_with("java/lang/String$$StringConcat");

Can you add a comment in `StringConcatFactory`'s place where this name is defined, so others who change the generated class name will remember to update references here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802362899

From fyang at openjdk.org  Wed Oct 16 05:17:15 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Oct 2024 05:17:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v13]
In-Reply-To: <YkA5tG8RyoFgeq265JksvTzKs7sfEUeLFwKAPaTg8kE=.be196cb7-ce18-479e-abc5-68bcd9a71f37@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <YkA5tG8RyoFgeq265JksvTzKs7sfEUeLFwKAPaTg8kE=.be196cb7-ce18-479e-abc5-68bcd9a71f37@github.com>
Message-ID: <7T7iX5F49go6KE5i9JKnHHl2rzzdst0QfW2oBFE681I=.21431799-2671-4e6d-bec3-800f0f1fcc46@github.com>

On Tue, 15 Oct 2024 17:46:51 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments fixes

BTW: Would you mind apply following small addon change? I think it cleans up the related code making it a bit more consistent. Thanks.

[21406-addon-change.diff.txt](https://github.com/user-attachments/files/17389440/21406-addon-change.diff.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2415750009

From iklam at openjdk.org  Wed Oct 16 05:32:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 05:32:12 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v5]
In-Reply-To: <2T8YMFdoCbebmZHIdaWWM7N14SMYIV0-NFxQb-hu3Wo=.5e7740eb-30a7-4f1c-83d3-46c525624b02@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <DWAfC5RTULIbufLGZRxHqg_mcMtImDrplsUz8UdCvRM=.03051ace-3ab7-46c5-9072-092b257b1a36@github.com>
 <2T8YMFdoCbebmZHIdaWWM7N14SMYIV0-NFxQb-hu3Wo=.5e7740eb-30a7-4f1c-83d3-46c525624b02@github.com>
Message-ID: <X7ykW70lxzsUTlEKoR9rMKFbNk0w4Qe6ulm6gavziPo=.91950e9e-e190-4e43-a7b5-03762aca90ac@github.com>

On Wed, 16 Oct 2024 05:04:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused include
>
> src/hotspot/share/cds/cdsProtectionDomain.cpp line 212:
> 
>> 210: }
>> 211: 
>> 212: oop CDSProtectionDomain::get_shared_jar_url_helper(const char* path, Handle url_h, TRAPS) {
> 
> Suggestion:
> 
> oop CDSProtectionDomain::get_file_URL(const char* path, Handle url_h, TRAPS) {
> 
> It looks odd to have a "helper" method as part of the public API, especially when called directly.

I think both function can use the same name, since they have overloaded parameter types:


Handle CDSProtectionDomain::get_shared_jar_url(int shared_path_index, TRAPS);
oop CDSProtectionDomain::get_shared_jar_url(const char* path, Handle url_h, TRAPS);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1802377534

From jbhateja at openjdk.org  Wed Oct 16 05:36:19 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 05:36:19 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
 <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
Message-ID: <FD2LLtVOCY6Qdeanv6WCxoXYx0EOlOxRE5NFgdu-hUw=.0d770cab-f0fe-49e9-8202-9fcbffd7922c@github.com>

On Tue, 15 Oct 2024 10:17:40 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update adlc changes.
>
> src/hotspot/share/opto/vectornode.hpp line 161:
> 
>> 159:   // Needed for proper cloning.
>> 160:   virtual uint size_of() const { return sizeof(*this); }
>> 161:   bool is_unsigned() { return _is_unsigned; }
> 
> Can you put this in the `print_spec`, so the IR dump shows if it is unsigned?

Hi @eme64 , I see print_spec is mainly used for dumping information about VTransformVectorNode,  please note newly added situating operations are not being auto-vectorized and are are emitted through VectorAPI based explicit vectorization flow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1802382779

From vlivanov at openjdk.org  Wed Oct 16 05:46:15 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Oct 2024 05:46:15 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v29]
In-Reply-To: <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
Message-ID: <YWJVHgdhwdvT_NLl0Nv5-J6EiflsAcB68JL6YoU4vd8=.4c47071a-948d-49f3-a6cd-05526c59d655@github.com>

On Tue, 15 Oct 2024 11:08:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen assertion

Testing results (hs-tier1 - hs-tier4) for latest version look good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2371255403

From vlivanov at openjdk.org  Wed Oct 16 05:46:16 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 16 Oct 2024 05:46:16 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v23]
In-Reply-To: <n1uGWI5zK3M9smyn_F3ywYrHXO6FzK1Qt7c07ZYaSbE=.8bce05bf-992f-480f-84bc-e91013eac9ef@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <Lv0Nl6QzPHsusYOEBlYvXu2Ng-QjTskLLUR7PO5vxqg=.55a02ff5-3b8b-41e9-a77f-6a785c9183f7@github.com>
 <VQXM5iZCfbwdKW-A1edSS-ZSSPQa2JK-TPScgu8l5Mk=.fb8a701a-7d4e-4e6a-9840-807c7b944f90@github.com>
 <Otc0T8fZ7pKkBOYSlRVeugNuxWSIJ9AN-LKd6wN1eoM=.f3baf000-e88d-4bcc-bf88-74572182c5cd@github.com>
 <mDDnFYM2uPovS6WhXG1OudHVwm-2FKOhEuCdoQElrt4=.2b671e8d-9444-470f-b689-a2391639a1d6@github.com>
 <n1uGWI5zK3M9smyn_F3ywYrHXO6FzK1Qt7c07ZYaSbE=.8bce05bf-992f-480f-84bc-e91013eac9ef@github.com>
Message-ID: <qfhdr3H3kunYXrgukghomdJCuDBu7vqpB-KaiBRZkkM=.a28cdd16-d5c2-4932-9480-3ebc7d65ea5f@github.com>

On Tue, 15 Oct 2024 10:29:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> What if you changed lines 1820-1821 like so:
>> 
>> eor(temp2, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>> lslv(temp2, r_bitmap, temp2);
>
> Yes, you're right. Please look at it now.
> 
> @iwanowww , do you think this needs a full re-test? This is a local change, and I think it's self-contained.

I agree that a full retest would be an overkill. I submitted limited testing with the latest patch and results look good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1802391440

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 rehn at openjdk.org  Wed Oct 16 06:54:14 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 06:54:14 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <yVT_yLxON0RjrHAlR_c0qjBM_49BGgvMfKafSxpFRTI=.525fd04e-adcb-4f98-8ea2-0f1f47b45b6d@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
 <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>
 <NnGv0WZrXb2Yh3kSlyBm_Cy2WN9nKSi1Hb652kIKEN0=.d3459826-314a-4692-b489-5f188bbe5ff0@github.com>
 <sbCQcuScsRFG7yKmOeuTy-3iHeMTD1BIFEJec1J-9UQ=.8b570623-b2d1-4959-a21a-554d46f59a43@github.com>
 <yVT_yLxON0RjrHAlR_c0qjBM_49BGgvMfKafSxpFRTI=.525fd04e-adcb-4f98-8ea2-0f1f47b45b6d@github.com>
Message-ID: <u-GogS_5H7m_51QugMDuyVpXqdrMNcxDqUI5GVqOC1Q=.35b2e1ec-37e9-43ee-b220-31f3aa291e15@github.com>

On Wed, 16 Oct 2024 02:08:02 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I'm thinking about x18.
>
> So you want a RAS push action when you change to different register from `ra`. But seems to me that the original code with `ra` also achieves the same purpose from the spec. RAS push action is supposed to happen when rd=rs1=ra for `jalr`, which enables macro-op fusion of the sequence `auipc ra, imm20; jalr ra, imm12(ra)`. So I think we can simply revert this change. Anyway, this should be a slow case as you mentioned.

Yes, but I didn't want exceptions to the rules, as the asserts don't make sense without seing the RAS table.

I'll do some re-work and make the asserts according the table, but without the alternative calling convetion using x5. So using **ra** works and anyone can see why we can.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1802463705

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 jsjolen at openjdk.org  Wed Oct 16 07:11:11 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 16 Oct 2024 07:11:11 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <AbkrVrNc47azm4sYS_RmbmpDLcQEUrhZWDtLSmKiE-E=.4003ff0b-da65-4844-841c-b1f793519c42@github.com>

On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

src/hotspot/share/classfile/stringTable.cpp line 244:

> 242: 
> 243: public:
> 244:   StringTableLookupUTF8(Thread* thread, uintx hash, const char* key, int len)

Should `_len` also be `_num_unicode_points`? Please wait with this change until you, me and David understand and agree with each other :).

src/hotspot/share/classfile/stringTable.cpp line 247:

> 245:       : StringTableLookup(thread, hash), _str(key), _len(len) {}
> 246: 
> 247:   bool equals(WeakHandle* value) {

This can be a `const WeakHandle*` or maybe even a `const WeakHandle&`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1801137071
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1801139191

From jsjolen at openjdk.org  Wed Oct 16 07:17:16 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 16 Oct 2024 07:17:16 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <Ag74cYwNI-95cGZ8H3xy16Kru0fFYTGqzMM2L9mwsBQ=.ae473c3e-be7f-40b9-ba95-c6cb82ba7418@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
 <ro_IqT0f44DSnB562DhDSySQrGUNggGp1-p-O2M04C0=.74bd45a0-51e2-417e-a8ae-e1a7eca42e96@github.com>
 <Ag74cYwNI-95cGZ8H3xy16Kru0fFYTGqzMM2L9mwsBQ=.ae473c3e-be7f-40b9-ba95-c6cb82ba7418@github.com>
Message-ID: <mxcJSi3blbwDnwhqlt_QD129J9kFoiIz4Fo1-kOOQjo=.544fa732-1c2a-4815-b29b-b71579538226@github.com>

On Tue, 15 Oct 2024 21:01:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>The len parameter is just the length of the array. We use it to iterate through the array. e.g.

Oops.

>But while technically accurate I don't think using num_unicode_points adds any value here - quite the opposite as it obscures that this is simply the length of the array.

Alright, I think it brings consistency with the fact that in the other methods we are actually passing in the number of unicode code points (like for the utf-8 case). In this case it happens to *also* be the length of the array. I think a comment in the code would help out a lot, regardless of the name chosen for the parameter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802487661

From rehn at openjdk.org  Wed Oct 16 07:23:27 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 07:23:27 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v13]
In-Reply-To: <7T7iX5F49go6KE5i9JKnHHl2rzzdst0QfW2oBFE681I=.21431799-2671-4e6d-bec3-800f0f1fcc46@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <YkA5tG8RyoFgeq265JksvTzKs7sfEUeLFwKAPaTg8kE=.be196cb7-ce18-479e-abc5-68bcd9a71f37@github.com>
 <7T7iX5F49go6KE5i9JKnHHl2rzzdst0QfW2oBFE681I=.21431799-2671-4e6d-bec3-800f0f1fcc46@github.com>
Message-ID: <GrrUKh0q3lHVGK-ENfF-upXLx-vjxWSv0GrCU1C2ogI=.edef1d65-6698-40a8-a130-63913b88187d@github.com>

On Wed, 16 Oct 2024 05:14:02 GMT, Fei Yang <fyang at openjdk.org> wrote:

> BTW: Would you mind apply following small addon change? I think it cleans up the related code making it a bit more consistent. Thanks.
> 
> [21406-addon-change.diff.txt](https://github.com/user-attachments/files/17389440/21406-addon-change.diff.txt)

Sorry this is not correct, as this is missing relocations in some cases.
Hence we generate a plain `JAL`, which means when we relocate the code, the JAL imm is to large.
Thus we hit:
`assert(Assembler::is_simm21(offset) && ((offset % 2) == 0)) failed: offset (121960514) is too large to be patched in one jal instruction!`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2415933840

From mbaesken at openjdk.org  Wed Oct 16 07:25:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Oct 2024 07:25:15 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
 <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
Message-ID: <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>

On Tue, 15 Oct 2024 19:46:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntimeTrans.cpp line 122:
>> 
>>> 120:   unsigned lx;
>>> 121: 
>>> 122:   static_assert(std::numeric_limits<double>::is_iec559, "IEEE 754 required");
>> 
>> I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?
>
>> I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?
> 
> It needs to return -Inf. ubsan seems wrong here: this IEEE-754 arithmetic is well defined, and has been for a very long while.

Ubsan is just following the C++ standard 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
5.6 Multiplicative operators  
 ....
'The binary / operator yields the quotient, and the binary % operator yields the remainder from the division
of the first expression by the second. If the second operand of / or % is zero the behavior is undefined.'

See also https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero .

However on our set of platforms in OpenJDK we probably get away with the expected results when dividing by 0  (because they all seem to follow IEEE-754).
That's why I just added the static_assert.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1802501457

From jsjolen at openjdk.org  Wed Oct 16 07:27:13 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 16 Oct 2024 07:27:13 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
Message-ID: <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>

On Wed, 16 Oct 2024 00:14:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/stringTable.hpp line 88:
>> 
>>> 86:   static const jchar *to_unicode(StringWrapper wrapped_str, int len, TRAPS);
>>> 87:   static Handle to_handle(StringWrapper wrapped_str, int len, TRAPS);
>>> 88:   static void print_string(StringWrapper wrapped_str, int len, TRAPS);
>> 
>> What is `len` supposed to represent in all of these methods? The code only makes sense to me if `len` here is actually "number of unicode characters" (which need not be the same as the length of any wrapped UTF8 sequence).
>
> Actually that in itself is not enough to make the code correct AFAICS. Consider this example from Table 2-11, page 71, in https://www.unicode.org/versions/Unicode16.0.0/UnicodeStandard-16.0.pdf The Unicode character 00010384 in UTF-32, consists of the surrogate pair D800, DF84 in UTF-16, and the four byte sequence F0, 90, 8E, 84 in UTF-8. So if we have a java.lang.String that represents this single unicode character, the String will consist of an array of 2 char values, and the UTF8 representation would consist of 4 byte values. So if you were doing an equals comparison between the String's value array and the utf_str, what length would you pass to the equals method?

I'd hope that the answer is 4, but I suspect that the answer is 5 (UTF-16). When the class `UTF8` talks about "unicode", it seems to be talking about whatever encoding Java's strings are, which AFAIK is basically UTF-16 with some special cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802502642

From jsjolen at openjdk.org  Wed Oct 16 07:27:13 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 16 Oct 2024 07:27:13 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
 <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
Message-ID: <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>

On Wed, 16 Oct 2024 07:23:35 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Actually that in itself is not enough to make the code correct AFAICS. Consider this example from Table 2-11, page 71, in https://www.unicode.org/versions/Unicode16.0.0/UnicodeStandard-16.0.pdf The Unicode character 00010384 in UTF-32, consists of the surrogate pair D800, DF84 in UTF-16, and the four byte sequence F0, 90, 8E, 84 in UTF-8. So if we have a java.lang.String that represents this single unicode character, the String will consist of an array of 2 char values, and the UTF8 representation would consist of 4 byte values. So if you were doing an equals comparison between the String's value array and the utf_str, what length would you pass to the equals method?
>
> I'd hope that the answer is 4, but I suspect that the answer is 5 (UTF-16). When the class `UTF8` talks about "unicode", it seems to be talking about whatever encoding Java's strings are, which AFAIK is basically UTF-16 with some special cases.

See for example this snippet from `java_lang_String::create_from_str(const char* utf8_str, T/
```c++
  int length = UTF8::unicode_length(utf8_str, is_latin1, has_multibyte);
  if (!CompactStrings) {
    has_multibyte = true;
    is_latin1 = false;
  }

  Handle h_obj = basic_create(length, is_latin1, CHECK_NH);
  if (length > 0) {
    if (!has_multibyte) {
      const jbyte* src = reinterpret_cast<const jbyte*>(utf8_str);
      ArrayAccess<>::arraycopy_from_native(src, value(h_obj()), typeArrayOopDesc::element_offset<jbyte>(0), length);
    } else if (is_latin1) {
      UTF8::convert_to_unicode(utf8_str, value(h_obj())->byte_at_addr(0), length);
    } else {
      UTF8::convert_to_unicode(utf8_str, value(h_obj())->char_at_addr(0), length);
    }
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802504344

From thartmann at openjdk.org  Wed Oct 16 07:30:13 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 16 Oct 2024 07:30:13 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
Message-ID: <pnP6nskvCr6dLbn7KG003eRC9vLIR70lpICIJkHQCmo=.e7afefc0-b58f-4f34-9568-6b3c7a3cf82d@github.com>

On Sat, 5 Oct 2024 16:47:12 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
>  - fix windows build
>  - fix debug build
>  - 8341527: AVX-512 intrinsic for SHA3

src/hotspot/cpu/x86/assembler_x86.cpp line 8581:

> 8579:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 8580:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_evex()), "");
> 8581:   // TODO check what legacy_mode needs to be set to

Drive-by comment: There's a TODO left in here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1802507743

From fyang at openjdk.org  Wed Oct 16 07:40:20 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Oct 2024 07:40:20 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v13]
In-Reply-To: <GrrUKh0q3lHVGK-ENfF-upXLx-vjxWSv0GrCU1C2ogI=.edef1d65-6698-40a8-a130-63913b88187d@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <YkA5tG8RyoFgeq265JksvTzKs7sfEUeLFwKAPaTg8kE=.be196cb7-ce18-479e-abc5-68bcd9a71f37@github.com>
 <7T7iX5F49go6KE5i9JKnHHl2rzzdst0QfW2oBFE681I=.21431799-2671-4e6d-bec3-800f0f1fcc46@github.com>
 <GrrUKh0q3lHVGK-ENfF-upXLx-vjxWSv0GrCU1C2ogI=.edef1d65-6698-40a8-a130-63913b88187d@github.com>
Message-ID: <oozMGgHsiNvEUIy8VF5-AUM8NtmkZADQqs0FsYxK0BM=.a0e3c899-7fda-44e4-b1b2-2554c2b75b03@github.com>

On Wed, 16 Oct 2024 07:20:36 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > BTW: Would you mind apply following small addon change? I think it cleans up the related code making it a bit more consistent. Thanks.
> > [21406-addon-change.diff.txt](https://github.com/user-attachments/files/17389440/21406-addon-change.diff.txt)
> 
> Sorry this is not correct, as this is missing relocations in some cases. Hence we generate a plain `JAL`, which means when we relocate the code, the JAL imm is to large. Thus we hit: `assert(Assembler::is_simm21(offset) && ((offset % 2) == 0)) failed: offset (121960514) is too large to be patched in one jal instruction!`

Oops ... I think I missed it. Just forget about it. I will take a look at it later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2415965656

From ihse at openjdk.org  Wed Oct 16 07:42:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Oct 2024 07:42:17 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
 <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>
 <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>
 <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@github.com>
 <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@github.com>
Message-ID: <2EQObSBYG9ZtB0qDRKvYjERfxkYKTlGAlQ9JVEj9zYg=.61c7c77a-746a-4c30-9c58-dfb564ecf24d@github.com>

On Tue, 15 Oct 2024 19:31:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.
>> 
>> @magicus, just to make it clear, do you plan to explicitly define the set of LDFLAGS for static linking as part of this PR? We need to make sure the JVM_LDFLAGS is properly included initially.
>
> Yes, I just pushed a commit that does that. I have manually inspected the values and it looks sane, but I need to verify it on our CI system as well. The reasoning for us setting some of the ld flags are less than clear, so it is a bit hard to tell if they should be included or not.

This change started to expose some other problems as well. I'll need to work a bit more on getting this right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1802525755

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 rcastanedalo at openjdk.org  Wed Oct 16 08:10:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 16 Oct 2024 08:10:15 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <MX2iRPfi5jOwWg7t9Nrg204dQ3QBVGgIXjJ_bYhm9Zk=.ef3f8b90-1717-4f00-8128-b12567b5df4d@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
 <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>
 <MX2iRPfi5jOwWg7t9Nrg204dQ3QBVGgIXjJ_bYhm9Zk=.ef3f8b90-1717-4f00-8128-b12567b5df4d@github.com>
Message-ID: <2OSj9HzqKzyTa1yy2Mg07zva9QEefe0fppmi-0CnLIk=.cc1ac084-a63f-4924-b7bd-35d1c2cae6ed@github.com>

On Tue, 15 Oct 2024 09:24:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> I will run some internal CI testing and report back in one or two days.

The test results look good. I tested the changes (up to commit 9f7ad7ab) on top of jdk-24+19 running tier1-tier5 on all Oracle-supported platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2416038769

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 cnorrbin at openjdk.org  Wed Oct 16 08:48:13 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 16 Oct 2024 08:48:13 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
 <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
 <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>
Message-ID: <m7ivLHEBzBJP3FLAH8_t2i6TUh__NJ52o9jg8EnCO1Y=.724de800-eb68-454e-9d74-dff62a5c170e@github.com>

On Wed, 16 Oct 2024 07:24:48 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> I'd hope that the answer is 4, but I suspect that the answer is 5 (UTF-16). When the class `UTF8` talks about "unicode", it seems to be talking about whatever encoding Java's strings are, which AFAIK is basically UTF-16 with some special cases.
>
> See for example this snippet from `java_lang_String::create_from_str(const char* utf8_str, T/
> ```c++
>   int length = UTF8::unicode_length(utf8_str, is_latin1, has_multibyte);
>   if (!CompactStrings) {
>     has_multibyte = true;
>     is_latin1 = false;
>   }
> 
>   Handle h_obj = basic_create(length, is_latin1, CHECK_NH);
>   if (length > 0) {
>     if (!has_multibyte) {
>       const jbyte* src = reinterpret_cast<const jbyte*>(utf8_str);
>       ArrayAccess<>::arraycopy_from_native(src, value(h_obj()), typeArrayOopDesc::element_offset<jbyte>(0), length);
>     } else if (is_latin1) {
>       UTF8::convert_to_unicode(utf8_str, value(h_obj())->byte_at_addr(0), length);
>     } else {
>       UTF8::convert_to_unicode(utf8_str, value(h_obj())->char_at_addr(0), length);
>     }
>   }

The `len` in all these methods is the number of unicode characters, which yes, could be less than the length of the UTF8 array.

---

`UTF8::convert_to_unicode` uses `UTF8::next`, like I also do in the new UTF8 equals/hash functions. Part of `UTF8::next` looks like this: 

```c++
  switch ((ch = ptr[0]) >> 4) {
    default:
    ... work ... /* 1-byte character */
    break;

  case 0x8: case 0x9: case 0xA: case 0xB: case 0xF:
    /* Shouldn't happen. */
    break;

  case 0xC: case 0xD:
    /* 110xxxxx  10xxxxxx */
    ... work ... /* 2-byte character */
    break;

  case 0xE:
    /* 1110xxxx 10xxxxxx 10xxxxxx */
    ... work ... /* 3-byte character */
    break;
  } /* end of switch */


In this code, 4-byte long UTF8 characters are not converted. This leads me to believe that we do not support this range of characters. With this restriction, we also do not have 2 wide (4 byte) UTF16 characters, as 3-byte UTF8 characters fit in a single (2 byte) UTF16 unit.

So for the question, I do not know what would happen. I believe it would be undefined behaviour as this character would not be supported. Just like if we would use `UTF8::convert_to_unicode` first to then compare two UTF16 strings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802636657

From cnorrbin at openjdk.org  Wed Oct 16 08:52:16 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 16 Oct 2024 08:52:16 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
Message-ID: <iHrPBSmtMPSVFgJAO_B9Zn1HqYtU9NlIgRhBwCgDx6c=.210bc07e-ec72-409a-bf0d-0ba11fdaa88c@github.com>

On Tue, 15 Oct 2024 07:36:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> src/hotspot/share/classfile/javaClasses.cpp line 393:
> 
>> 391: #ifdef ASSERT
>> 392:   // This check is too strict when the symbol does not contain valid UTF8.
>> 393:   if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, utf8_len, false)) {
> 
> But a successfully created Symbol should only ever be valid UTF8. ??

In theory, yes. However, there was a single test which somehow generated corrupted Symbols. I did not investigate this much further, and instead relaxed the check to look the same as in `java_lang_String::create_from_str`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1802643616

From rcastanedalo at openjdk.org  Wed Oct 16 08:52:18 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 16 Oct 2024 08:52:18 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v10]
In-Reply-To: <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
Message-ID: <G5co3PXZt5oFfLLIIQUpBa92YFqb9jxE2ytEoNmwdbI=.b14e9b01-5c81-49b0-8d01-0486d0e43d88@github.com>

On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export in JVMCI too

Marked as reviewed by rcastanedalo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2371670897

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 rehn at openjdk.org  Wed Oct 16 09:06:30 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 09:06:30 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v14]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <SWY1wozr62fFcIFm5VMDi19Br0bNAzEiDNZZV83PWoE=.a756ba1e-10cc-485f-879a-7146da8e231b@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Allow x1 as Rs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/8ed7d3e1..bcc6bc98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=12-13

  Stats: 32 lines in 3 files changed: 25 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

From rehn at openjdk.org  Wed Oct 16 09:06:31 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 09:06:31 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v12]
In-Reply-To: <u-GogS_5H7m_51QugMDuyVpXqdrMNcxDqUI5GVqOC1Q=.35b2e1ec-37e9-43ee-b220-31f3aa291e15@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <OqpCkRVI8aTMGXaEtRH8GyYg-mfXlzTLVozhAZ_vj48=.feb00d32-37de-433b-b941-237bbe272eae@github.com>
 <KtORAooPUmr-Q_HT2uF5m3n6r5iWef2nfkHHmKlFIjw=.bd9019c1-2340-4fe1-aa59-85cc8b03c802@github.com>
 <HdWznK190x3IhT13X7AS8Z5QDN-ZQZI3itk77shZfXI=.c46b1933-62b8-494f-9223-d25399d01adb@github.com>
 <NnGv0WZrXb2Yh3kSlyBm_Cy2WN9nKSi1Hb652kIKEN0=.d3459826-314a-4692-b489-5f188bbe5ff0@github.com>
 <sbCQcuScsRFG7yKmOeuTy-3iHeMTD1BIFEJec1J-9UQ=.8b570623-b2d1-4959-a21a-554d46f59a43@github.com>
 <yVT_yLxON0RjrHAlR_c0qjBM_49BGgvMfKafSxpFRTI=.525fd04e-adcb-4f98-8ea2-0f1f47b45b6d@github.com>
 <u-GogS_5H7m_51QugMDuyVpXqdrMNcxDqUI5GVqOC1Q=.35b2e1ec-37e9-43ee-b220-31f3aa291e15@github.com>
Message-ID: <WPQzWyDIg5wIEkwCaK8BvhsqvJuPsDyHhMsHdcrxI80=.6ba96c97-d079-47db-96fb-258a6e83e73f@github.com>

On Wed, 16 Oct 2024 06:51:37 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> So you want a RAS push action when you change to different register from `ra`. But seems to me that the original code with `ra` also achieves the same purpose from the spec. RAS push action is supposed to happen when rd=rs1=ra for `jalr`, which enables macro-op fusion of the sequence `auipc ra, imm20; jalr ra, imm12(ra)`. So I think we can simply revert this change. Anyway, this should be a slow case as you mentioned.
>
> Yes, but I didn't want exceptions to the rules, as the asserts don't make sense without seing the RAS table.
> 
> I'll do some re-work and make the asserts according the table, but without the alternative calling convetion using x5. So using **ra** works and anyone can see why we can.

I made an update. Let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1802668529

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 rehn at openjdk.org  Wed Oct 16 09:18:53 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 09:18:53 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn 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 18 additional commits since the last revision:

 - Merge branch 'master' into remove_t0
 - Allow x1 as Rs
 - Comments fixes
 - Merge branch 'master' into remove_t0
 - ICData move to t1, removed dead code
 - Revert clinit_barrier
 - Fixed no explicit use of default t1
 - Revert clinit_barrier t1
 - Upstream comment
 - Fixed no explicit use of default t1
 - ... and 8 more: https://git.openjdk.org/jdk/compare/a2661602...52b02cb8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/bcc6bc98..52b02cb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=13-14

  Stats: 4041 lines in 72 files changed: 2771 ins; 349 del; 921 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

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 jpai at openjdk.org  Wed Oct 16 10:35:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 10:35:15 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
Message-ID: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>

This brings in CPU24_10 changes into master branch.

-------------

Commit messages:
 - 8335713: Enhance vectorization analysis
 - 8332644: Improve graph optimizations
 - 8331446: Improve deserialization support
 - 8307383: Enhance DTLS connections
 - 8311208: Improve CDS Support
 - 8328544: Improve handling of vectorization
 - 8328286: Enhance HTTP client
 - 8328726: Better Kerberos support
 - 8302111: Serialization considerations

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/21533/files
  Stats: 3690 lines in 79 files changed: 2781 ins; 346 del; 563 mod
  Patch: https://git.openjdk.org/jdk/pull/21533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21533/head:pull/21533

PR: https://git.openjdk.org/jdk/pull/21533

From alanb at openjdk.org  Wed Oct 16 11:24:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 11:24:09 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <qwOQuVYagvGmmYX1Zr_IQui-YZKkIo0GzicRDl8pP18=.52835a32-507d-4bd4-8500-12194ee23468@github.com>

On Wed, 16 Oct 2024 10:31:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in CPU24_10 changes into master branch.

Discussed with Jai to confirm testing. All good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21533#pullrequestreview-2372116298

From jpai at openjdk.org  Wed Oct 16 11:39:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 11:39:54 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d [v2]
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <0HP5c8oQ1lFbLOjhg180ujsosHaV9REEAQMZ_O3bPx4=.ad6b6227-7ab8-4f9f-87e6-d13cea518c50@github.com>

> This brings in CPU24_10 changes into master branch.

Jaikiran Pai 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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21533/files
  - new: https://git.openjdk.org/jdk/pull/21533/files/490d099e..490d099e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21533&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21533/head:pull/21533

PR: https://git.openjdk.org/jdk/pull/21533

From dfuchs at openjdk.org  Wed Oct 16 11:39:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Oct 2024 11:39:54 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d [v2]
In-Reply-To: <0HP5c8oQ1lFbLOjhg180ujsosHaV9REEAQMZ_O3bPx4=.ad6b6227-7ab8-4f9f-87e6-d13cea518c50@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
 <0HP5c8oQ1lFbLOjhg180ujsosHaV9REEAQMZ_O3bPx4=.ad6b6227-7ab8-4f9f-87e6-d13cea518c50@github.com>
Message-ID: <Iu4lF5Whdn1hc4VukFGDSkuIRBMicjMBQP_aSg5rTYs=.166b4d6b-c252-4b61-9362-a823a7475ecc@github.com>

On Wed, 16 Oct 2024 11:36:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This brings in CPU24_10 changes into master branch.
>
> Jaikiran Pai 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.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21533#pullrequestreview-2372156477

From jpai at openjdk.org  Wed Oct 16 11:39:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 11:39:54 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <CxyqkRRZoAJPt_JPQpmGwuM8UUZ7A-jOqvN7BulGIwc=.305a6fb3-e030-4d99-abeb-647c15b3402e@github.com>

On Wed, 16 Oct 2024 10:31:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in CPU24_10 changes into master branch.

Thank you Alan and Daniel for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21533#issuecomment-2416550126

From jpai at openjdk.org  Wed Oct 16 11:39:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 11:39:56 GMT
Subject: Integrated: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <jN3QhL4Ba6UTfaf6im2ZPzCfVtL4l3EsD_pCuB3Ib_8=.82e5d718-d75e-435b-8cda-448b3d89376f@github.com>

On Wed, 16 Oct 2024 10:31:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in CPU24_10 changes into master branch.

This pull request has now been integrated.

Changeset: cf5bb127
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf5bb12731b0eefe53b99281453e40493ddafbe4
Stats:     3690 lines in 79 files changed: 2781 ins; 346 del; 563 mod

Merge

Reviewed-by: alanb, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/21533

From fyang at openjdk.org  Wed Oct 16 11:45:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Oct 2024 11:45:18 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
Message-ID: <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>

On Wed, 16 Oct 2024 09:18:53 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_t0
>  - Allow x1 as Rs
>  - Comments fixes
>  - Merge branch 'master' into remove_t0
>  - ICData move to t1, removed dead code
>  - Revert clinit_barrier
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1
>  - Upstream comment
>  - Fixed no explicit use of default t1
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/6268c04f...52b02cb8

Thanks for the update. Seems that we missed the jump in `MacroAssembler::trampoline_call` [1]? I also witnessed another place where we missed killing the rflags after this change. See comment for details.

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L4272

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4082:

> 4080:                                                    Register tmp2,
> 4081:                                                    Register tmp3) {
> 4082:   assert_different_registers(r_sub_klass, r_super_klass, tmp1, tmp2, tmp3, result, t0, t1);

This `MacroAssembler::verify_secondary_supers_table` is used by `MacroAssembler::lookup_secondary_supers_table` which is called by `instruct partialSubtypeCheckConstSuper` in riscv.ad. We should list the rflags as being killed for this instruct as well. As this is not obvious, we need to double check if there are other similar occurrences like this.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21406#pullrequestreview-2372155596
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1802929358

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 rehn at openjdk.org  Wed Oct 16 12:25:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 12:25:13 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
 <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>
Message-ID: <HnWiBs0HyWWs4-qvGv8RV1n8gOK2c0H7tgJX86AmAl8=.bfcf848d-de9e-4ab8-a5d3-420211806dbb@github.com>

On Wed, 16 Oct 2024 11:40:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks for the update. Seems that we missed the jump_link in `MacroAssembler::trampoline_call` [1]? I also witnessed another place where we missed killing the rflags after this change. See comment for details.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L4272
> 
> (PS: Ignore this as I just noticed that it's a `jal` instead of `jalr` by the `jump_link`)

For C2 calls, i.e. when compiler is doing a deliberate call, RFLAG is SOC.
Which means calls do not need to kill CR, it is implicitly killed AFIACT.
C2 should have saved RFLAG register before doing the call if it needs that value after the call.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4082:
> 
>> 4080:                                                    Register tmp2,
>> 4081:                                                    Register tmp3) {
>> 4082:   assert_different_registers(r_sub_klass, r_super_klass, tmp1, tmp2, tmp3, result, t0, t1);
> 
> This `MacroAssembler::verify_secondary_supers_table` is used by `MacroAssembler::lookup_secondary_supers_table` which is called by C2 `instruct partialSubtypeCheckConstSuper` in riscv.ad. We should list the rflags (aka t1) as being killed for this instruct as well. As this is not obvious, we need to double check if there are other similar occurrences like this.

Same anwser here actual call do not need to kill CR as RFLAG is SOC.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2416673932
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1803002374

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 fyang at openjdk.org  Wed Oct 16 12:41:12 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Oct 2024 12:41:12 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <HnWiBs0HyWWs4-qvGv8RV1n8gOK2c0H7tgJX86AmAl8=.bfcf848d-de9e-4ab8-a5d3-420211806dbb@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
 <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>
 <HnWiBs0HyWWs4-qvGv8RV1n8gOK2c0H7tgJX86AmAl8=.bfcf848d-de9e-4ab8-a5d3-420211806dbb@github.com>
Message-ID: <wqDEYDwnK5zW6IP0_LC2UofuGIwl1X44F75ST9IBjOU=.463c08e4-11cd-4e8d-9ef1-0f7ee6355385@github.com>

On Wed, 16 Oct 2024 12:22:23 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4082:
>> 
>>> 4080:                                                    Register tmp2,
>>> 4081:                                                    Register tmp3) {
>>> 4082:   assert_different_registers(r_sub_klass, r_super_klass, tmp1, tmp2, tmp3, result, t0, t1);
>> 
>> This `MacroAssembler::verify_secondary_supers_table` is used by `MacroAssembler::lookup_secondary_supers_table` which is called by C2 `instruct partialSubtypeCheckConstSuper` in riscv.ad. We should list the rflags (aka t1) as being killed for this instruct as well. As this is not obvious, we need to double check if there are other similar occurrences like this.
>
> Same anwser here actual call do not need to kill CR as RFLAG is SOC.

Note that C2 instruct `partialSubtypeCheckConstSuper` is not a call. So this issue is still there for this case I think. 
(Also `t0` and `t1` is reserved from C2, so I don't think they will save and restore them. That's why we add clobbering for `t1`/rflags for C2 calling instructs: CallRuntime/CallDynamicJava ...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1803018392

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 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 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 shade at openjdk.org  Wed Oct 16 14:11:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 14:11:21 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v10]
In-Reply-To: <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
Message-ID: <F_z8HalzrPdL7PtTgb0yrxayF-6zww1jVkc2HfrhLIc=.66cd3444-de84-491b-b230-919621178c09@github.com>

On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export in JVMCI too

Thank you for testing! Here goes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2416954569

From shade at openjdk.org  Wed Oct 16 14:11:22 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 14:11:22 GMT
Subject: Integrated: 8329597: C2: Intrinsify Reference.clear
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <1qO6cEgGDaDehUQfowHFCdggggj3dz-5QU7YIU3RwNM=.3ed8aff2-01aa-4f8a-a29c-d1137d879e06@github.com>

On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 7625b299
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7625b29920e95f9b754057fe0a2c4ab0afa5cb0c
Stats:     362 lines in 26 files changed: 341 ins; 0 del; 21 mod

8329597: C2: Intrinsify Reference.clear

Reviewed-by: rcastanedalo, eosterlund, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/20139

From rehn at openjdk.org  Wed Oct 16 14:12:15 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 16 Oct 2024 14:12:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <wqDEYDwnK5zW6IP0_LC2UofuGIwl1X44F75ST9IBjOU=.463c08e4-11cd-4e8d-9ef1-0f7ee6355385@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
 <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>
 <HnWiBs0HyWWs4-qvGv8RV1n8gOK2c0H7tgJX86AmAl8=.bfcf848d-de9e-4ab8-a5d3-420211806dbb@github.com>
 <wqDEYDwnK5zW6IP0_LC2UofuGIwl1X44F75ST9IBjOU=.463c08e4-11cd-4e8d-9ef1-0f7ee6355385@github.com>
Message-ID: <kxFNj4GXhcr2L1fNcQmIiAeBAcfmoDzBR_9p6rcs460=.3b93690f-f2f1-48d2-b0fb-8ac98cac2c07@github.com>

On Wed, 16 Oct 2024 12:32:56 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Same anwser here actual call do not need to kill CR as RFLAG is SOC.
>
> Note that C2 instruct `partialSubtypeCheckConstSuper` is not a call. So this issue is still there for this case I think. 
> 
> (Also `t0` and `t1` is reserved from C2, so I don't think they will save and restore them. That's why we add clobbering for `t1`/rflags for C2 calling instructs: CallRuntime/CallDynamicJava ... Redundant??? )

Note sure what you mean by "t0 and t1 is reserved from C2".
They are not allocatable by register allocator.
But C2 think there is RFLAG register (still not allocatable), which we have aliased with x6/t1.
This pseudo register will be SOC.
Any live SOC should be pushed before a call.

The clobbering we added for CallRuntime/CallDynamicJava is not needed AFAIK, check e.g. x86 it do not kill CR as RFLAG is also set to SOC on x86 (but here backed with a real register).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1803189043

From fyang at openjdk.org  Wed Oct 16 14:35:16 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 16 Oct 2024 14:35:16 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <kxFNj4GXhcr2L1fNcQmIiAeBAcfmoDzBR_9p6rcs460=.3b93690f-f2f1-48d2-b0fb-8ac98cac2c07@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
 <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>
 <HnWiBs0HyWWs4-qvGv8RV1n8gOK2c0H7tgJX86AmAl8=.bfcf848d-de9e-4ab8-a5d3-420211806dbb@github.com>
 <wqDEYDwnK5zW6IP0_LC2UofuGIwl1X44F75ST9IBjOU=.463c08e4-11cd-4e8d-9ef1-0f7ee6355385@github.com>
 <kxFNj4GXhcr2L1fNcQmIiAeBAcfmoDzBR_9p6rcs460=.3b93690f-f2f1-48d2-b0fb-8ac98cac2c07@github.com>
Message-ID: <wLMksCqRgPQo1f3pZL0RP5cIR7cfIYccv5nOSSR5Cos=.ebd9ce9d-a5c3-4317-b048-661d516e9748@github.com>

On Wed, 16 Oct 2024 14:10:00 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Note sure what you mean by "t0 and t1 is reserved from C2". They are not allocatable by register allocator. But C2 think there is RFLAG register (still not allocatable), which we have aliased with x6/t1. This pseudo register will be SOC. Any live SOC should be pushed before a call.

Yeah, they are not allocatable. That's what I mean by saying they are reserved :-)

> The clobbering we added for CallRuntime/CallDynamicJava is not needed AFAIK, check e.g. x86 it do not kill CR as RFLAG is also set to SOC on x86 (but here backed with a real register).

Yes, I also checked other CPU platforms and I think you are right in that these effect of killing CR are unnecessary. Maybe a separate PR to clean them up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1803232561

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 yzheng at openjdk.org  Wed Oct 16 15:15:26 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 16 Oct 2024 15:15:26 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
Message-ID: <zxi6t9MYavUM33xbiJjrTascpUcXWAg2ndDNtukJIbE=.779f0175-a304-4637-907f-6e462ff9f6f9@github.com>

On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change ifdef from x86 to AMD64

src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 74:

> 72: // Special cases:
> 73: //  tanh(NaN) = quiet NaN, and raise invalid exception
> 74: //  tanh(INF) = that INF

This should be

tanh(POSITIVE_INFINITY) = +1.0
tanh(NEGATIVE_INFINITY) = -1.0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1803316120

From chagedorn at openjdk.org  Wed Oct 16 15:18:20 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Oct 2024 15:18:20 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
Message-ID: <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>

On Sat, 5 Oct 2024 16:47:12 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
>  - fix windows build
>  - fix debug build
>  - 8341527: AVX-512 intrinsic for SHA3

This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:

#### Failure 1
Tests: 
- `testlibrary_tests/ir_framework/tests/TestCPUFeatureCheck.java`
  - Additional flags: `-XX:+UseParallelGC -XX:+UseNUMA`
- `compiler/loopopts/superword/TestDependencyOffsets.java`
  - Additional flags: `-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation`
```	
CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 106 stepping 6 microcode 0x1, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512cd, sha, fma, clflush, hv, rdtscp, rdpid, fsrm, f16c, pku, ospke
CPU Model and flags from /proc/cpuinfo:
model name	: Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves nt_good wbnoinvd arat vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid fsrm md_clear arch_capabilities


Failure:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/a4a7850a-7c35-410a-b879-d77fbb2f6087-S144302/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d6cec7c3-7401-41e9-aaad-f45b38c7a9e7/runs/9e85fc0d-9d6b-426f-b5d8-e84e2daa4c8c/workspace/open/src/hotspot/cpu/x86/assembler_x86.cpp:2979), pid=1550324, tid=1550336
#  Error: assert(VM_Version::supports_avx512dq()) failed
.....
Command Line: -Djava.library.path=/opt/mach5/mesos/work_dir/jib-master/install/2024-10-15-1659164.christian.hagedorn.jdk-test/linux-x64-debug.test/hotspot/jtreg/native -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/23/37/bundles/linux-x64/jdk-23_linux-x64_bin.tar.gz/jdk-23 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/a4a7850a-7c35-410a-b879-d77fbb2f6087-S151463/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b87f227c-12f2-4145-8d72-0ba96c4ef814/runs/6cf6b0a6-7bb2-4e1d-97a8-2ad532639bfd/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_misc/tmp -XX:+UseParallelGC -XX:+UseNUMA -Dir.framework.server.port=42709 -XX:+UseKNLSetting -XX:-BackgroundCompilation -XX:CompileCommand=quiet compiler.lib.ir_framework.test.TestVM ir_framework.tests.TestCPUFeatureCheck
.....
Stack: [0x00007f4c047e9000,0x00007f4c048e9000],  sp=0x00007f4c048e57e0,  free space=1009k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x63bd61]  Assembler::kmovbl(KRegister, Register)+0x181  (assembler_x86.cpp:2979)
V  [libjvm.so+0x17615d4]  StubGenerator::generate_sha3_implCompress(bool, char const*)+0x274  (stubGenerator_x86_64_sha3.cpp:141)
V  [libjvm.so+0x176339a]  StubGenerator::generate_sha3_stubs()+0x3a  (stubGenerator_x86_64_sha3.cpp:86)
V  [libjvm.so+0x1711217]  StubGenerator::generate_compiler_stubs()+0x387  (stubGenerator_x86_64.cpp:4033)
V  [libjvm.so+0x1712ff8]  StubGenerator_generate(CodeBuffer*, StubCodeGenerator::StubsKind)+0xd8  (stubGenerator_x86_64.cpp:4242)
V  [libjvm.so+0x176d5af]  initialize_stubs(StubCodeGenerator::StubsKind, int, int, char const*, char const*, char const*)+0xef  (stubRoutines.cpp:245)
V  [libjvm.so+0x176f791]  compiler_stubs_init(bool)+0xa1  (stubRoutines.cpp:282)
V  [libjvm.so+0x87e5ae]  C2Compiler::init_c2_runtime()+0xbe  (c2compiler.cpp:92)
V  [libjvm.so+0x87e795]  C2Compiler::initialize()+0x35  (c2compiler.cpp:112)
V  [libjvm.so+0xa39716]  CompileBroker::init_compiler_runtime()+0xd6  (compileBroker.cpp:1771)
V  [libjvm.so+0xa3ff01]  CompileBroker::compiler_thread_loop()+0x121  (compileBroker.cpp:1913)
V  [libjvm.so+0xef158c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:759)
V  [libjvm.so+0x18199f6]  Thread::call_run()+0xb6  (thread.cpp:234)
V  [libjvm.so+0x14fc288]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:858)


#### Failure 2
- `compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnUnsupportedCPU.java`
  - Additional flags: `-server -Xmixed`
  
Output:

stderr: [Java HotSpot(TM) 64-Bit Server VM warning: SHA3 intrinsics require AVX512 instructions
java version "24-internal" 2025-03-18
Java(TM) SE Runtime Environment (fastdebug build 24-internal-2024-10-15-1659164.christian.hagedorn.jdk-test)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 24-internal-2024-10-15-1659164.christian.hagedorn.jdk-test, mixed mode, sharing)
]
 exitValue = 0

java.lang.AssertionError: Expected message not found: 'Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU.'.
JVM should start with '-XX:-UseSHA3Intrinsics' flag without any warnings
	at jdk.test.lib.cli.CommandLineOptionTest.verifyOutput(CommandLineOptionTest.java:159)
	at jdk.test.lib.cli.CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.java:130)
	at jdk.test.lib.cli.CommandLineOptionTest.verifySameJVMStartup(CommandLineOptionTest.java:209)
	at compiler.intrinsics.sha.cli.testcases.GenericTestCaseForUnsupportedX86CPU.verifyWarnings(GenericTestCaseForUnsupportedX86CPU.java:70)
	at compiler.intrinsics.sha.cli.DigestOptionsBase$TestCase.test(DigestOptionsBase.java:162)
	at compiler.intrinsics.sha.cli.DigestOptionsBase.runTestCases(DigestOptionsBase.java:139)
	at jdk.test.lib.cli.CommandLineOptionTest.test(CommandLineOptionTest.java:537)
	at compiler.intrinsics.sha.cli.TestUseSHA3IntrinsicsOptionOnUnsupportedCPU.main(TestUseSHA3IntrinsicsOptionOnUnsupportedCPU.java:56)
	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.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1576)
Caused by: java.lang.RuntimeException: 'Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU.' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
	at jdk.test.lib.cli.CommandLineOptionTest.verifyOutput(CommandLineOptionTest.java:154)
	... 11 more

JavaTest Message: Test threw exception: java.lang.AssertionError: Expected message not found: 'Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU.'.
JVM should start with '-XX:-UseSHA3Intrinsics' flag without any warnings
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.AssertionError: Expected message not found: 'Intrinsics for SHA3-224, SHA3-256, SHA3-384 and SHA3-512 crypto hash functions not available on this CPU.'. JVM should start with '-XX:-UseSHA3Intrinsics' flag without any warnings

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2417134494

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 heidinga at openjdk.org  Wed Oct 16 15:35:25 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 16 Oct 2024 15:35:25 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v9]
In-Reply-To: <Y-vvhT_uwJsZWl6YZtnoD9UTP19uc8vXRXIhZYHPUKM=.7dec13ef-0610-4f87-b482-c01215e04d57@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>
 <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>
 <Y-vvhT_uwJsZWl6YZtnoD9UTP19uc8vXRXIhZYHPUKM=.7dec13ef-0610-4f87-b482-c01215e04d57@github.com>
Message-ID: <VXLJoaqCCKXF6z93GEzsmeLgiOm0Os6236XaqXSkc0k=.ff9904b5-0e52-4735-9f6f-465a55d18b89@github.com>

On Tue, 15 Oct 2024 23:56:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 2097:
>> 
>>> 2095:     }
>>> 2096: 
>>> 2097:     MutexLocker ml(InvokeMethodIntrinsicTable_lock);
>> 
>> Should we take this lock once outside the loop and hold it for the duration rather than taking it just again and again before each add operation?
>
> The lock cannot be held while calling `AdapterHandlerLibrary::create_native_wrapper()` -- a few lines above. Otherwise  you'd see an error like
> 
>> assert(false) failed: Attempting to acquire lock AdapterHandlerLibrary_lock/safepoint out of order with lock InvokeMethodIntrinsicTable_lock/safepoint -- possible deadlock
> 
> You can see the same pattern with the existing code
> 
> https://github.com/openjdk/jdk/blob/b9cabbecdac27ae8b93df88660a4a0f3f60e6828/src/hotspot/share/classfile/systemDictionary.cpp#L2008-L2022
> 
> Most of the work is done inside `AdapterHandlerLibrary::create_native_wrapper()`, which generates native code. Also, this loop happens while the JVM is still in single-threaded mode, so there's no contention on the lock. The cost of taking this lock is negligible.

Thanks for confirming.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20959#discussion_r1803354428

From duke at openjdk.org  Wed Oct 16 15:36:15 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 16 Oct 2024 15:36:15 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <pnP6nskvCr6dLbn7KG003eRC9vLIR70lpICIJkHQCmo=.e7afefc0-b58f-4f34-9568-6b3c7a3cf82d@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <pnP6nskvCr6dLbn7KG003eRC9vLIR70lpICIJkHQCmo=.e7afefc0-b58f-4f34-9568-6b3c7a3cf82d@github.com>
Message-ID: <OQ1eLxQPAg47Y-iDMSzEt_ctJnqsUeA2ZPkdUjeRrTI=.34317b0e-30fd-4f55-9f71-e43293d894b8@github.com>

On Wed, 16 Oct 2024 07:27:02 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
>>  - fix windows build
>>  - fix debug build
>>  - 8341527: AVX-512 intrinsic for SHA3
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 8581:
> 
>> 8579:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
>> 8580:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_evex()), "");
>> 8581:   // TODO check what legacy_mode needs to be set to
> 
> Drive-by comment: There's a TODO left in here.

Actually, I was hoping that I would learn that from a reviewer @vpaprotsk or @vnkozlov , do you know? I was not able to figure it out from the manual what it should be. (with the current setting "false" at least my code works on the test machines that I tried, but I never tried with "true")

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1803352201

From duke at openjdk.org  Wed Oct 16 15:42:15 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Oct 2024 15:42:15 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <OQ1eLxQPAg47Y-iDMSzEt_ctJnqsUeA2ZPkdUjeRrTI=.34317b0e-30fd-4f55-9f71-e43293d894b8@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <pnP6nskvCr6dLbn7KG003eRC9vLIR70lpICIJkHQCmo=.e7afefc0-b58f-4f34-9568-6b3c7a3cf82d@github.com>
 <OQ1eLxQPAg47Y-iDMSzEt_ctJnqsUeA2ZPkdUjeRrTI=.34317b0e-30fd-4f55-9f71-e43293d894b8@github.com>
Message-ID: <306KCfVKymOCH0a2mjiPVMHPwtYtCnauYfK7jln7epU=.81800571-d429-4087-9fc5-6e184516a257@github.com>

On Wed, 16 Oct 2024 15:31:35 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 8581:
>> 
>>> 8579:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
>>> 8580:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_evex()), "");
>>> 8581:   // TODO check what legacy_mode needs to be set to
>> 
>> Drive-by comment: There's a TODO left in here.
>
> Actually, I was hoping that I would learn that from a reviewer @vpaprotsk or @vnkozlov , do you know? I was not able to figure it out from the manual what it should be. (with the current setting "false" at least my code works on the test machines that I tried, but I never tried with "true")

I am looking it up.. gimme a bit? Though I was thinking about the UseSHA3Intrinsic flag.. missed this one..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1803366455

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 coleenp at openjdk.org  Wed Oct 16 15:47:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 15:47:13 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v10]
In-Reply-To: <QP44k2BV6NZs4Bx95dHEVyAMRlatYtDtwsj7KQJS2pA=.a9c291b7-faee-44a2-9ebc-761e43895b8c@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <QP44k2BV6NZs4Bx95dHEVyAMRlatYtDtwsj7KQJS2pA=.a9c291b7-faee-44a2-9ebc-761e43895b8c@github.com>
Message-ID: <3Yp0r3KGyBe4x9_bTqsta6Ei9_aR9pD3V3TKQkXwClg=.2d6bfa3b-74d8-48eb-840f-a47d1767a366@github.com>

On Tue, 15 Oct 2024 23:53:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
>> 
>> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge 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-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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @coleenp comments
>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - @vnkozlov comment - added NOT_CDS_RETURN
>  - 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
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/167af8fd...a9356279

I forgot to release my comment.  You could hold the lock for the duration if you want.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20959#pullrequestreview-2367385814

From coleenp at openjdk.org  Wed Oct 16 15:47:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 15:47:16 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v9]
In-Reply-To: <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>
 <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>
Message-ID: <YBbVi_5JIZnXDa4s_67Jt99GcPdw1nUNsbUkpeDBdDc=.1c7f440d-3e07-45bd-8784-6ea5ebb64280@github.com>

On Mon, 14 Oct 2024 15:09:19 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam 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 16 additional commits since the last revision:
>> 
>>  - 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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - @coleenp comments
>>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - @vnkozlov comment - added NOT_CDS_RETURN
>>  - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/b2f08170...84777aa4
>
> src/hotspot/share/classfile/systemDictionary.cpp line 2097:
> 
>> 2095:     }
>> 2096: 
>> 2097:     MutexLocker ml(InvokeMethodIntrinsicTable_lock);
> 
> Should we take this lock once outside the loop and hold it for the duration rather than taking it just again and again before each add operation?

Yes this might be possible because create_native_wrapper doesn't thrown an exception or otherwise call Java code, as far as I can tell.  Unlike the other places where we take this lock.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20959#discussion_r1799945409

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 iklam at openjdk.org  Wed Oct 16 16:01:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 16:01:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
 <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
Message-ID: <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>

On Wed, 16 Oct 2024 03:29:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/memory/iterator.inline.hpp line 53:
>> 
>>> 51:     // class has not yet been loaded by CDS.
>>> 52:     cld->oops_do(this, _claim);
>>> 53:   }
>> 
>> Could you show the stack trace for this? I want to understand better why we are iterating over objects that don't have a loaded class.
>
> Here's the call stack if I remove the "if" check on line 49. It can be reproduced with test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java from the PR repo.
> 
> 
> 10 javaSignalHandler (sig=11, info=0x7ffff428fdb0, context=0x7ffff428fc80)
> 12 Atomic::PlatformLoad::operator() (this=0x7ffff429097f, dest=0x28)
> 13 Atomic::LoadImpl, void>::operator() (this=0x7ffff42909af, dest=0x28)
> 14 Atomic::load (dest=0x28)
> 15 ClassLoaderData::try_claim (this=0x0, claim=4)
> 16 ClassLoaderData::oops_do (this=0x0, f=0x7fff6c014c88, claim_value=4, clear_mod_oops=false)
> 17 ClaimMetadataVisitingOopIterateClosure::do_cld (this=0x7fff6c014c88, cld=0x0)
> 18 ClaimMetadataVisitingOopIterateClosure::do_klass (this=0x7fff6c014c88, k=0x7fff763655d8)
> 19 call_do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
> 20 Devirtualizer::do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
> 21 InstanceKlass::oop_oop_iterate (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
> 22 OopOopIterateDispatch::Table::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, k=0x7fff763655d8)
> 23 OopIteratorClosureDispatch::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, klass=0x7fff763655d8)
> 24 oopDesc::oop_iterate (this=0xfffd72a0, cl=0x7fff6c014c88)
> 25 G1FullGCMarker::follow_object (this=0x7fff6c014630, obj=0xfffd72a0)
> 26 G1FullGCMarker::publish_and_drain_oop_tasks (this=0x7fff6c014630)
> 27 G1FullGCMarker::follow_marking_stacks (this=0x7fff6c014630)
> 28 G1FullGCMarker::complete_marking (this=0x7fff6c014630, oop_stacks=0x7fffd445c6b8, array_stacks=0x7fffd445c6d0, terminator=0x7fffd445c190)
> 29 G1FullGCMarkTask::work (this=0x7fffd445c030, worker_id=0)
> 30 WorkerTaskDispatcher::worker_run_task (this=0x7ffff008b9b8)
> 31 WorkerThread::run (this=0x7ffff008bac0)
> 
> 
> This is in a GC triggered by here (with -XX:VerifyArchivedFields=2).
> 
> 
> void HeapShared::init_archived_fields_for(Klass* k, 
>      const ArchivedKlassSubGraphInfoRecord* record) {
>   verify_the_heap(k, "before");
> 
> 
> At frame 18:
> 
> 
> #18 0x00007ffff58505d1 in ClaimMetadataVisitingOopIterateClosure::do_klass 
>     (this=0x7fff6c014c88, k=0x7fff763655d8)
>     at src/hotspot/share/memory/iterator.inline.hpp:58
> 58	  ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
> (gdb) psym k->_name
> $1 = 0x7fff765430be "BulkLoaderTestApp$$Lambda+0x800000013"
> (gdb) p k->_class_loader_data
> $2 = (ClassLoaderData *) 0x0
> (gdb) p SystemDictionary::_java_system_loader 
> $3 = {_obj = 0x0}
> 
> 
> At frame 21:
> 
> 
> #21 0x00007ffff6132f6f in InstanceKlass::oop_oop_iterate<narrowOop, G...

I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache classes in loaded state" to address this properly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803396788

From duke at openjdk.org  Wed Oct 16 16:09:14 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 16 Oct 2024 16:09:14 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <E-sE4Tg1T-OXy_vKucyDoQuyMsIOHGx3CngdnC5Cguw=.86fd5e28-0e03-4691-9704-4d7def9083c1@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
 <E-sE4Tg1T-OXy_vKucyDoQuyMsIOHGx3CngdnC5Cguw=.86fd5e28-0e03-4691-9704-4d7def9083c1@github.com>
Message-ID: <lX_PDv3sY80tU0wjx5DSIIXPbhWvfkPbdgUAlIj4Jwk=.18db8b61-865b-403c-b041-47676900bbf5@github.com>

On Tue, 15 Oct 2024 22:56:56 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> If you still have it and it can be 'made clean'.. I would love to see some of that 'scaffolding test code' kept for the final commit. (I like to imagine the 'final code cleanup' as 'removing **scaffolding** from a construction site' :) ) This will be especially useful if (when?) we revisit the intrinsic. (I can already see us also needing an AVX2 version.. someone will need to re-learn how to verify that intrinsic too)

The scaffolding is really simple: instead of e.g.

@IntrinsiCandidate
void foo(byte[] output, byte[] input) {
  // do some computation
}

you would have

void foo(byte[] output, byte[] input) {
   byte[] inputCopy = input.clone();
   int x = fooImpl(output, input);
   if (x==0) {
    // it was the intrinsic, so e.g. call fooImplJava() on imputCopy and compare the result
  }
}

@IntrinsicCandidate
int fooImpl(byte[] output, byte[] input) {
  fooImplJava(input, output);
  return 1;
}

void fooImplJava(byte[] output, byte[] input) {
  // do some computation
}

Just a bit more complicated for non-void methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2417277788

From sviswanathan at openjdk.org  Wed Oct 16 16:07:38 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 16 Oct 2024 16:07:38 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <SoNH5QFS4FBkfGbGmltCb4Nl1cYzfxjyy1EB2jsGuKk=.5516160f-092c-4a9d-b597-661cb0e74aae@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

Changes look good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2372983898

From jbhateja at openjdk.org  Wed Oct 16 16:11:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 16:11:26 GMT
Subject: Integrated: 8338023: Support two vector selectFrom API
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <AQXhq7FAv2OC5W6Ept1OJVR3Ijw2rm9hwvTPQMfbPbQ=.db35f716-65f6-492c-8c4f-99ef80833919@github.com>

On Thu, 8 Aug 2024 06:57:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

This pull request has now been integrated.

Changeset: 709914fc
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/709914fc92dd180c8f081ff70ef476554a04f4ce
Stats:     2805 lines in 89 files changed: 2786 ins; 18 del; 1 mod

8338023: Support two vector selectFrom API

Reviewed-by: psandoz, epeter, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/20508

From duke at openjdk.org  Wed Oct 16 17:01:19 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 16 Oct 2024 17:01:19 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
Message-ID: <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>

On Wed, 16 Oct 2024 15:15:07 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:
> 

@chhagedorn could you send me the mach5 command line (or other means) to run these tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2417404815

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 duke at openjdk.org  Wed Oct 16 17:05:15 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Oct 2024 17:05:15 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
Message-ID: <WKMp3fJIhL-8t19fmASLK94z99WnjrTMfxEfwO8X4-Q=.7f917d75-cf06-457d-b6ce-46ad00da09e1@github.com>

On Tue, 15 Oct 2024 15:51:34 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.cpp line 1316:
>> 
>>> 1314:   }
>>> 1315: 
>>> 1316:   if (UseAVX > 2) {
>> 
>> Should be `#ifdef _LP64`. (Similar format from above). Need to look up the cpu features required for the instructions in the intrinsic..
>
> Added the #ifdef.

The 'rest' of the comment I owed you.. need `AVX512F`, `AVX512DQ`, `AVX512BW`.
So you will need `supports_avx512bwdq()` here

"Showing my (math) work.."

grep '__ ' src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp | sed -e 's| *__ *||' -e 's|(.*||' | sort -u
(only using the full 512 versions, no need for VL)
evmovdquq  AVX512F
evmovdquw  AVX512BW
evpermt2q  AVX512F
evprolq    AVX512F
evprolvq   AVX512F
evpxorq    AVX512F
vpternlogq AVX512F
kmovbl     AVX512DQ
...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1803495632

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 jbhateja at openjdk.org  Wed Oct 16 17:29:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 17:29:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  New IR tests + additional IR transformations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/506ae299..c5650889

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=23-24

  Stats: 1010 lines in 7 files changed: 1007 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Wed Oct 16 17:29:05 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 17:29:05 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
 <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
Message-ID: <Rg-rMYpuDQfTSKxczEBiO_DHiTbwViV9kwHAKt2HI2Q=.3fd9f71f-a70c-4bb1-b0ae-713a1bb8239e@github.com>

On Tue, 15 Oct 2024 10:17:40 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update adlc changes.
>
> src/hotspot/share/opto/vectornode.hpp line 161:
> 
>> 159:   // Needed for proper cloning.
>> 160:   virtual uint size_of() const { return sizeof(*this); }
>> 161:   bool is_unsigned() { return _is_unsigned; }
> 
> Can you put this in the `print_spec`, so the IR dump shows if it is unsigned?

I think you meant Node::dump_spec. Its a good suggestions, addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1803527017

From duke at openjdk.org  Wed Oct 16 17:37:10 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 16 Oct 2024 17:37:10 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <WKMp3fJIhL-8t19fmASLK94z99WnjrTMfxEfwO8X4-Q=.7f917d75-cf06-457d-b6ce-46ad00da09e1@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <Kd3F3oyCbkY2njOo7RYfpcEntIdyd08Rs76YgbeaF5Q=.32de8ce0-333b-4fda-9371-bfb1454b5453@github.com>
 <W79LHR2j5TSND_Chwuwnl_SoU21cXYSfIENnoRTyyZM=.38123d2e-920a-4ffa-b44e-91c7a35eb604@github.com>
 <WKMp3fJIhL-8t19fmASLK94z99WnjrTMfxEfwO8X4-Q=.7f917d75-cf06-457d-b6ce-46ad00da09e1@github.com>
Message-ID: <VouaL-DuCoQPtKjidIDZt7OqMsTqn1RFbLtMQ06QpiI=.c57e3a19-9c70-4743-baea-5ac7453997ff@github.com>

On Wed, 16 Oct 2024 17:02:23 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Added the #ifdef.
>
> The 'rest' of the comment I owed you.. need `AVX512F`, `AVX512DQ`, `AVX512BW`.
> So you will need `supports_avx512bwdq()` here
> 
> "Showing my (math) work.."
> 
> grep '__ ' src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp | sed -e 's| *__ *||' -e 's|(.*||' | sort -u
> (only using the full 512 versions, no need for VL)
> evmovdquq  AVX512F
> evmovdquw  AVX512BW
> evpermt2q  AVX512F
> evprolq    AVX512F
> evprolvq   AVX512F
> evpxorq    AVX512F
> vpternlogq AVX512F
> kmovbl     AVX512DQ
> ...

Thanks! I will change the kmovbl()s to kmovwl() and then supports_avx512bw() will suffice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1803539650

From matsaave at openjdk.org  Wed Oct 16 17:53:13 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 16 Oct 2024 17:53:13 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v5]
In-Reply-To: <X7ykW70lxzsUTlEKoR9rMKFbNk0w4Qe6ulm6gavziPo=.91950e9e-e190-4e43-a7b5-03762aca90ac@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <DWAfC5RTULIbufLGZRxHqg_mcMtImDrplsUz8UdCvRM=.03051ace-3ab7-46c5-9072-092b257b1a36@github.com>
 <2T8YMFdoCbebmZHIdaWWM7N14SMYIV0-NFxQb-hu3Wo=.5e7740eb-30a7-4f1c-83d3-46c525624b02@github.com>
 <X7ykW70lxzsUTlEKoR9rMKFbNk0w4Qe6ulm6gavziPo=.91950e9e-e190-4e43-a7b5-03762aca90ac@github.com>
Message-ID: <TxCRUggQh6z4H8ftbxZGgXJS_OZwOVVkNysxE538CnY=.1f052670-75ca-4d8b-9a07-f2e04d2fb5ff@github.com>

On Wed, 16 Oct 2024 05:29:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsProtectionDomain.cpp line 212:
>> 
>>> 210: }
>>> 211: 
>>> 212: oop CDSProtectionDomain::get_shared_jar_url_helper(const char* path, Handle url_h, TRAPS) {
>> 
>> Suggestion:
>> 
>> oop CDSProtectionDomain::get_file_URL(const char* path, Handle url_h, TRAPS) {
>> 
>> It looks odd to have a "helper" method as part of the public API, especially when called directly.
>
> I think both function can use the same name, since they have overloaded parameter types:
> 
> 
> Handle CDSProtectionDomain::get_shared_jar_url(int shared_path_index, TRAPS);
> oop CDSProtectionDomain::get_shared_jar_url(const char* path, Handle url_h, TRAPS);

I think using the same name might be confusing here since they return totally different things. I prefer David's suggestion here since all the method is doing is calling `toFileURL`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21329#discussion_r1803559544

From liach at openjdk.org  Wed Oct 16 17:55:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 17:55:24 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <JJspV-KE7HNaA2kjhdTWfoNvi3k67o8y3ld3GNcdBx4=.6ccab320-64a5-4812-b6b2-060508181d6f@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

This patch failed on the lastest master. Another reason OpenJDK guide asks to merge master despite all these commit churns...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2417516748

From liach at openjdk.org  Wed Oct 16 17:59:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 17:59:44 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
Message-ID: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>

This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

-------------

Commit messages:
 - Revert "8338023: Support two vector selectFrom API"

Changes: https://git.openjdk.org/jdk/pull/21546/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342440
  Stats: 2805 lines in 89 files changed: 18 ins; 2786 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21546/head:pull/21546

PR: https://git.openjdk.org/jdk/pull/21546

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 matsaave at openjdk.org  Wed Oct 16 18:04:28 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 16 Oct 2024 18:04:28 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v6]
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <IRWjo2Dc5cHiSag8UedYjOiU3qyTwU1iid_YdXra_O0=.3cfffbe6-0f54-4019-8e46-99fe9323ceed@github.com>

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed copyright change and renamed method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21329/files
  - new: https://git.openjdk.org/jdk/pull/21329/files/40f07064..f15f24ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21329&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21329&range=04-05

  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21329.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21329/head:pull/21329

PR: https://git.openjdk.org/jdk/pull/21329

From kvn at openjdk.org  Wed Oct 16 18:06:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 16 Oct 2024 18:06:10 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <xpMxkk4rVHe-EYdkvgq-uO1vpiSga18esb7DlHeWRII=.839acb71-0bbd-424a-89df-45e90086663f@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21546#pullrequestreview-2373275510

From liach at openjdk.org  Wed Oct 16 18:06:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:06:10 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <cgijJg86n1G-4Uvxg_ynEgsgZ7eNWlwcrWU2jzZ2y5Y=.574fe06b-5678-4dc8-b6a1-8ea70f5ccd07@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

@jatin-bhateja The failure message is like:



/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp: In function 'Node* LowerSelectFromTwoVectorOperation(PhaseGVN&, Node*, Node*, Node*, const TypeVect*)':
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2876:110: error: cannot convert 'const Type*' to 'BasicType'
 2876 |                                                                                    Type::get_const_basic_type(T_BYTE), false));
      |                                                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                              |
      |                                                                                                              const Type*
In file included from /home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:30:
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2887:101: error: cannot convert 'const Type*' to 'BasicType'
 2887 |                                                                           Type::get_const_basic_type(T_BYTE), false));
      |                                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                     |
      |                                                                                                     const Type*
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp: In member function 'bool LibraryCallKit::inline_vector_select_from_two_vectors()':
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:3015:116: error: cannot convert 'const Type*' to 'BasicType'
 3015 |     Node* wrap_mask_vec = gvn().transform(VectorNode::scalar2vector(wrap_mask, num_elem, Type::get_const_basic_type(index_elem_bt), false));
      |                                                                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
      |                                                                                                                    |
      |                                                                                                                    const Type*
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
lib/CompileJvm.gmk:168: recipe for target '/home/liach/java/jdk-5/build/linux-x64/hotspot/variant-server/libjvm/objs/vectorIntrinsics.o' failed
make[3]: *** [/home/liach/java/jdk-5/build/linux-x64/hotspot/variant-server/libjvm/objs/vectorIntrinsics.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [hotspot-server-libs] Error 2
make/Main.gmk:245: recipe for target 'hotspot-server-libs' failed
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'images' in configuration 'linux-x64' (exit code 2) 
Stopping javac server

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_vectorIntrinsics.o:
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp: In function 'Node* LowerSelectFromTwoVectorOperation(PhaseGVN&, Node*, Node*, Node*, const TypeVect*)':
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2876:110: error: cannot convert 'const Type*' to 'BasicType'
 2876 |                                                                                    Type::get_const_basic_type(T_BYTE), false));
      |                                                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                              |
      |                                                                                                              const Type*
In file included from /home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:30:
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2887:101: error: cannot convert 'const Type*' to 'BasicType'
 2887 |                                                                           Type::get_const_basic_type(T_BYTE), false));
      |                                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                     |
      |                                                                                                     const Type*
   ... (rest of output omitted)

* All command lines available in /home/liach/java/jdk-5/build/linux-x64/make-support/failure-logs.



If you can give a hotfix under the redo issue, we can merge that redo too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417540448

From jbhateja at openjdk.org  Wed Oct 16 18:06:10 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 18:06:10 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <7RIC5hbesOliqF966YUuT2h0E0I-VCFSkb45gkjxg3M=.b488c944-845f-473a-949a-d4c05bc19d3b@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Let me fix it immediately if you can hold for few mins.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417541451

From liach at openjdk.org  Wed Oct 16 18:13:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:13:11 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <m-4AKc5MZBbASpEkFZvVLTIDdtfvhppZgvPVr6Wwcwg=.c79d162a-8b30-411f-b19d-33e97d819e86@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Sure. Please reuse https://bugs.openjdk.org/browse/JDK-8342439 (feel free to edit the title and description to indicate this is a hotfix) for your hotfix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417562207

From kvn at openjdk.org  Wed Oct 16 18:13:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 16 Oct 2024 18:13:10 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
 <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
Message-ID: <gyfqh-2nzwvnNwzfK7nxEJ6Her9GFwVSCaoflVOlSgw=.8264497f-7864-4b76-81c1-7412c4da1b33@github.com>

On Wed, 16 Oct 2024 16:58:07 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> > This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:
> 
> @chhagedorn could you send me the mach5 command line (or other means) to run these tests?

I think Christian missed additional important flag which limits avx512 features: -XX:+UseKNLSetting
I think you can run any test with it to trigger error because it happens during stub generation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2417568322

From jbhateja at openjdk.org  Wed Oct 16 18:13:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 18:13:11 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <m-4AKc5MZBbASpEkFZvVLTIDdtfvhppZgvPVr6Wwcwg=.c79d162a-8b30-411f-b19d-33e97d819e86@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
 <m-4AKc5MZBbASpEkFZvVLTIDdtfvhppZgvPVr6Wwcwg=.c79d162a-8b30-411f-b19d-33e97d819e86@github.com>
Message-ID: <PbpScMQTgaJwcVf0x9vHBAYLk349M6eI7SbFvG-7bXI=.94131d60-7213-41c8-9edc-bb33546ef69a@github.com>

On Wed, 16 Oct 2024 18:08:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sure. Please reuse https://bugs.openjdk.org/browse/JDK-8342439 (feel free to edit the title and description to indicate this is a hotfix) for your hotfix.

Ok, fix is ready, I will update the title and fix as a build issue.  Thanks!!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417568437

From jbhateja at openjdk.org  Wed Oct 16 18:17:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 18:17:11 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <9jBRhMABT7F6d5z9eSEQi9tTR351FaIlMaW29bJF6dw=.d8db4541-2600-464a-b159-cf71570e12ae@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Please approve.

https://github.com/openjdk/jdk/pull/21547

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417577012

From kvn at openjdk.org  Wed Oct 16 18:17:13 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 16 Oct 2024 18:17:13 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
Message-ID: <858QEXdJIs5az5q0QvddlngO7fRftSAOGW7C51fRQnM=.4d9c6d59-1d9c-4b8d-8979-d6454bda901b@github.com>

On Sat, 5 Oct 2024 16:47:12 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi 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 branch 'master' into sha3-avx512-intrinsic
>  - fix windows build
>  - fix debug build
>  - 8341527: AVX-512 intrinsic for SHA3

"Failure 2" is due to issue I pointed about [compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L10](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L106)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2417575985

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 liach at openjdk.org  Wed Oct 16 18:27:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:27:17 GMT
Subject: Withdrawn: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <W5uX9uZCg940s0oL3j6alcsNIr0GIPtBPz8VAH8EHWw=.faa1e875-8611-4c05-b127-b7ac3ee96bde@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21546

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 chagedorn at openjdk.org  Wed Oct 16 18:29:13 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 16 Oct 2024 18:29:13 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <gyfqh-2nzwvnNwzfK7nxEJ6Her9GFwVSCaoflVOlSgw=.8264497f-7864-4b76-81c1-7412c4da1b33@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
 <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
 <gyfqh-2nzwvnNwzfK7nxEJ6Her9GFwVSCaoflVOlSgw=.8264497f-7864-4b76-81c1-7412c4da1b33@github.com>
Message-ID: <m7Gd3G6m3_iYcCzJpuYtLTfazLKNCb2f-6GgO8Pn6r0=.29cade86-3607-4204-a04d-18431e499c09@github.com>

On Wed, 16 Oct 2024 18:10:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > > This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:
> > 
> > 
> > @chhagedorn could you send me the mach5 command line (or other means) to run these tests?
> 
> I think Christian missed additional important flag which limits avx512 features: -XX:+UseKNLSetting I think you can run any test with it to trigger error because it happens during stub generation.

Right, you need -XX:+UseKNLSetting, thanks Vladimir for jumping in! Missed to mention that separately and was hard to spot in the posted command line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2417596548

From psandoz at openjdk.org  Wed Oct 16 19:47:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Oct 2024 19:47:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
Message-ID: <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>

On Wed, 16 Oct 2024 17:29:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New IR tests + additional IR transformations

Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2417790144

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 iklam at openjdk.org  Wed Oct 16 20:46:11 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 20:46:11 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v6]
In-Reply-To: <IRWjo2Dc5cHiSag8UedYjOiU3qyTwU1iid_YdXra_O0=.3cfffbe6-0f54-4019-8e46-99fe9323ceed@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <IRWjo2Dc5cHiSag8UedYjOiU3qyTwU1iid_YdXra_O0=.3cfffbe6-0f54-4019-8e46-99fe9323ceed@github.com>
Message-ID: <VsAmqZ4VNtgRVQTFpGZjn6D6wC4uEAQ4tr-GapIIPKY=.85f2144b-a25c-4585-a1b9-e29d8054b1be@github.com>

On Wed, 16 Oct 2024 18:04:28 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed copyright change and renamed method

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21329#pullrequestreview-2373645682

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 dholmes at openjdk.org  Wed Oct 16 20:55:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 20:55:15 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <iHrPBSmtMPSVFgJAO_B9Zn1HqYtU9NlIgRhBwCgDx6c=.210bc07e-ec72-409a-bf0d-0ba11fdaa88c@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
 <iHrPBSmtMPSVFgJAO_B9Zn1HqYtU9NlIgRhBwCgDx6c=.210bc07e-ec72-409a-bf0d-0ba11fdaa88c@github.com>
Message-ID: <NfM-Wly3xA7eIyGAGxMXNpJeLSuN95VI4bkDimqf8is=.2842e09a-a8e8-4f4a-95b4-6a77eb585a3e@github.com>

On Wed, 16 Oct 2024 08:49:55 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 393:
>> 
>>> 391: #ifdef ASSERT
>>> 392:   // This check is too strict when the symbol does not contain valid UTF8.
>>> 393:   if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, utf8_len, false)) {
>> 
>> But a successfully created Symbol should only ever be valid UTF8. ??
>
> In theory, yes. However, there was a single test which somehow generated corrupted Symbols. I did not investigate this much further, and instead relaxed the check to look the same as in `java_lang_String::create_from_str`.

That seems a bug as it should not be possible. Please dig up the failing test case so I/we can examine it further - thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1803785617

From dholmes at openjdk.org  Wed Oct 16 21:19:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 21:19:26 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <9Xf2YdrTANxaq8K7K5OnTWdi7dSs6jd6dHkNvx85yg4=.0d752d93-2fef-4b28-8b01-6b7e6ba8b80e@github.com>

On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

src/hotspot/share/classfile/javaClasses.hpp line 199:

> 197: 
> 198:   static bool equals(oop java_string, const jchar* chars, int num_unicode_points);
> 199:   static bool equals(oop java_string, const char* chars, int num_unicode_points);

Suggestion:

  static bool equals(oop java_string, const char* utf8_str, int num_unicode_points);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1803808958

From dholmes at openjdk.org  Wed Oct 16 21:27:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 21:27:17 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <m7ivLHEBzBJP3FLAH8_t2i6TUh__NJ52o9jg8EnCO1Y=.724de800-eb68-454e-9d74-dff62a5c170e@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
 <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
 <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>
 <m7ivLHEBzBJP3FLAH8_t2i6TUh__NJ52o9jg8EnCO1Y=.724de800-eb68-454e-9d74-dff62a5c170e@github.com>
Message-ID: <nuqK3YSBCQ9vLOflaYTdPcA98XLWchv6qmz3UJWLcJE=.b248e733-4fe0-4131-ab38-3822a6b15ad9@github.com>

On Wed, 16 Oct 2024 08:45:47 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> See for example this snippet from `java_lang_String::create_from_str(const char* utf8_str, T/
>> ```c++
>>   int length = UTF8::unicode_length(utf8_str, is_latin1, has_multibyte);
>>   if (!CompactStrings) {
>>     has_multibyte = true;
>>     is_latin1 = false;
>>   }
>> 
>>   Handle h_obj = basic_create(length, is_latin1, CHECK_NH);
>>   if (length > 0) {
>>     if (!has_multibyte) {
>>       const jbyte* src = reinterpret_cast<const jbyte*>(utf8_str);
>>       ArrayAccess<>::arraycopy_from_native(src, value(h_obj()), typeArrayOopDesc::element_offset<jbyte>(0), length);
>>     } else if (is_latin1) {
>>       UTF8::convert_to_unicode(utf8_str, value(h_obj())->byte_at_addr(0), length);
>>     } else {
>>       UTF8::convert_to_unicode(utf8_str, value(h_obj())->char_at_addr(0), length);
>>     }
>>   }
>
> The `len` in all these methods is the number of unicode characters, which yes, could be less than the length of the UTF8 array.
> 
> ---
> 
> `UTF8::convert_to_unicode` uses `UTF8::next`, like I also do in the new UTF8 equals/hash functions. Part of `UTF8::next` looks like this: 
> 
> ```c++
>   switch ((ch = ptr[0]) >> 4) {
>     default:
>     ... work ... /* 1-byte character */
>     break;
> 
>   case 0x8: case 0x9: case 0xA: case 0xB: case 0xF:
>     /* Shouldn't happen. */
>     break;
> 
>   case 0xC: case 0xD:
>     /* 110xxxxx  10xxxxxx */
>     ... work ... /* 2-byte character */
>     break;
> 
>   case 0xE:
>     /* 1110xxxx 10xxxxxx 10xxxxxx */
>     ... work ... /* 3-byte character */
>     break;
>   } /* end of switch */
> 
> 
> In this code, 4-byte long UTF8 characters are not converted. This leads me to believe that we do not support this range of characters. Or that we at least do not support it encoded in UTF8. With this restriction, we also do not have 2 wide (4 byte) UTF16 characters, as 3-byte UTF8 characters fit in a single (2 byte) UTF16 unit.
> 
> So for the question, I do not know what would happen. I believe it would be undefined behaviour as this character would not be supported encoded in UTF8. Just like if we would use `UTF8::convert_to_unicode` first to then compare two UTF16 strings.

@caspernorrbin - Aarggh! Sorry I picked a bad example - the JVM uses modified-UTF8 which does not support 4-byte UTF8 encodings. Any UTF16 surrogate pair would be encoded as two three-byte modifed-UTF8 sequences.

> The len in all these methods is the number of unicode characters

Are you sure you meant "characters" there?

Let me try to back up a bit and go to the code that I have a problem with:

bool java_lang_String::equals(oop java_string, const char* utf8_string, int num_unicode_points) {
  assert(java_string->klass() == vmClasses::String_klass(),
         "must be java_string");
  typeArrayOop value = java_lang_String::value_no_keepalive(java_string);
  int length = java_lang_String::length(java_string, value);
  if (length != num_unicode_points) {
    return false;
  }

The incoming String represents a single unicode character encoded as a surrogate pair - so `length == 2`. Each element in the surrogate pairs encodes as a 3-byte modified-UTF8 sequence, so the length of `utf8_string` is 6. For the length check to pass the incoming value of `num_unicode_points` has to be 2. So for this to succeed the caller always has to pass in the number of UTF16 elements that comprise the `java_string`. As Johan noted in the utf8.cpp file when it refers to "unicode" it really means UTF16, so in that sense `num_unicode_points` is not incorrect.  But it means those `len` parameters should also be named the same way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1803816182

From dholmes at openjdk.org  Wed Oct 16 21:33:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 21:33:17 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <mxcJSi3blbwDnwhqlt_QD129J9kFoiIz4Fo1-kOOQjo=.544fa732-1c2a-4815-b29b-b71579538226@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <p6RnTApB9I03KbdNJ47XkSe9U2Znzt8HB5nj2Cx0Wyg=.3128cce8-21cf-4b02-aa17-3701ec6948ad@github.com>
 <ro_IqT0f44DSnB562DhDSySQrGUNggGp1-p-O2M04C0=.74bd45a0-51e2-417e-a8ae-e1a7eca42e96@github.com>
 <Ag74cYwNI-95cGZ8H3xy16Kru0fFYTGqzMM2L9mwsBQ=.ae473c3e-be7f-40b9-ba95-c6cb82ba7418@github.com>
 <mxcJSi3blbwDnwhqlt_QD129J9kFoiIz4Fo1-kOOQjo=.544fa732-1c2a-4815-b29b-b71579538226@github.com>
Message-ID: <kWhh4JwETJ3ZBj3AsqW43HT2UAUlIUqTZC2K4IBQpbA=.29d250be-abb4-4555-8573-233dba773e94@github.com>

On Wed, 16 Oct 2024 07:12:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The `len` parameter is just the length of the array. We use it to iterate through the array. e.g.
>> 
>>     for (int i = 0; i < len; i++) {
>>       if (value->char_at(i) != chars[i]) {
>>         return false;
>>       }
>>     }
>> 
>> But you are right that this is also the number of "code points" as defined by the Unicode standard - my apologies for that. I was mistakenly thinking that codepoints refer to actual characters, but it is a general term used for any numeric value in the unicode codespace, including non-characters and importantly surrogates. But while technically accurate I don't think using `num_unicode_points` adds any value here - quite the opposite as it obscures that this is simply the length of the array.
>
>>The len parameter is just the length of the array. We use it to iterate through the array. e.g.
> 
> Oops.
> 
>>But while technically accurate I don't think using num_unicode_points adds any value here - quite the opposite as it obscures that this is simply the length of the array.
> 
> Alright, I think it brings consistency with the fact that in the other methods we are actually passing in the number of unicode code points (like for the utf-8 case). In this case it happens to *also* be the length of the array. I think a comment in the code would help out a lot, regardless of the name chosen for the parameter.

I think we need to be very clear when we are passing in the expected length of an array as opposed to the number of characters/elements/points we intend to try to read from it. To that end just as we often use `void foo(char* buf, int buflen)` we should use e.g. `(char* utf8_str, int utf8_str_len)` if that is what we actually mean. (Though note we have an issue with using int instead of size_t for length!).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1803821741

From sviswanathan at openjdk.org  Wed Oct 16 21:33:18 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 16 Oct 2024 21:33:18 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <OQ1eLxQPAg47Y-iDMSzEt_ctJnqsUeA2ZPkdUjeRrTI=.34317b0e-30fd-4f55-9f71-e43293d894b8@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <pnP6nskvCr6dLbn7KG003eRC9vLIR70lpICIJkHQCmo=.e7afefc0-b58f-4f34-9568-6b3c7a3cf82d@github.com>
 <OQ1eLxQPAg47Y-iDMSzEt_ctJnqsUeA2ZPkdUjeRrTI=.34317b0e-30fd-4f55-9f71-e43293d894b8@github.com>
Message-ID: <2OzuDbul0X7nXrM5EBv8fEnSBEo9VWYjpop6MllPVmg=.f6b33d6c-85ed-4512-94b8-cef28975f8cd@github.com>

On Wed, 16 Oct 2024 15:31:35 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 8581:
>> 
>>> 8579:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
>>> 8580:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_evex()), "");
>>> 8581:   // TODO check what legacy_mode needs to be set to
>> 
>> Drive-by comment: There's a TODO left in here.
>
> Actually, I was hoping that I would learn that from a reviewer @vpaprotsk or @vnkozlov , do you know? I was not able to figure it out from the manual what it should be. (with the current setting "false" at least my code works on the test machines that I tried, but I never tried with "true")

legacy_mode should be false here. This instruction is promotable to evex encoding if higher bank registers (XMM16 and above) are used. It is not a legacy instruction so legacy_mode should be false. Examples of legacy instructions are vptest, vpblend*.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1803821984

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 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 asmehra at openjdk.org  Wed Oct 16 23:01:15 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 16 Oct 2024 23:01:15 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
Message-ID: <P2bNpw2Ke20lBr7tLUfXdnwjqmPiEFqBchB2naVSgJ4=.c42ea920-e67c-4312-ad82-e11944747168@github.com>

On Wed, 16 Oct 2024 02:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo in last commit; fixed header inclusion order

src/hotspot/share/cds/heapShared.cpp line 675:

> 673:     const char* klass_name = info->klass_name;
> 674:     for (; fields[i].valid(); i++) {
> 675:       ArchivableStaticFieldInfo* f = &fields[i];

It looks like the pattern of nested for-loops is copied from HeapShared::archive_object_subgraphs()
but this pattern doesn't seem to give any advantage here. If so can we replace it with just single for loop to make it easier to understand?

src/hotspot/share/cds/heapShared.cpp line 717:

> 715: };
> 716: 
> 717: void HeapShared::find_archivable_hidden_classes_in_object(oop root) {

If this function find archivable hidden classes, shouldn't there be a check for`is_hidden()` on the InstanceKlass being marked as `required`. Am I missing something?

src/hotspot/share/cds/heapShared.cpp line 790:

> 788: 
> 789:   init_seen_objects_table();
> 790:   {

Why was this scope introduced?

src/hotspot/share/classfile/systemDictionaryShared.cpp line 675:

> 673: 
> 674: // Returns true if the class should be excluded. This can be called before
> 675: // SystemDictionaryShared::check_excluded_classes().

There are a couple of references to check_excluded_classes() in the comments but this function no longer exists. Can you please update the comment accordingly.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 759:

> 757:       if (k->is_hidden() && should_hidden_class_be_archived(k)) {
> 758:         SystemDictionaryShared::check_for_exclusion(k, &info);
> 759:         if (info.is_excluded()) {

Is it possible that a hidden class for which `should_hidden_class_be_archived()` returns true is marked for exclusion by `SDS::check_for exclusion`? I guess only possibility is if for some reason its super or interface is excluded. Is that possible?

src/hotspot/share/classfile/systemDictionaryShared.cpp line 775:

> 773:   // Now, all hidden classes that have not yet been scanned must be marked as excluded
> 774:   auto exclude_remaining_hidden = [&] (InstanceKlass* k, DumpTimeClassInfo& info) {
> 775:     if (k->is_hidden() && !info.has_checked_exclusion()) {

Suggestion: Check for `has_checked_exclusion()` is not really required as the call to `SDS::check_for_exclusion()` does that. And the condition in `guarantee()` can be updated as `info.is_excluded() || info.is_required()`.

src/hotspot/share/oops/constantPool.cpp line 340:

> 338:     src_cp->iterate_archivable_resolved_references([&](int rr_index) {
> 339:       keep_resolved_refs.at_put(rr_index, true);
> 340:       });

Indentation seems off here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803888327
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887158
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887567
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887919
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887979
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803888011
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803889248

From svkamath at openjdk.org  Wed Oct 16 23:13:45 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Wed, 16 Oct 2024 23:13:45 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v5]
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <tCuaZFrrX71Rw1Xh03-1Q-yds_lqVkU0ZJ-RPLjGFoU=.3088d06c-4754-4b00-b9cb-c6b6b00850cc@github.com>

> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.

Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into sha-512
 - Updated code as per review comments
 - Addressed a review comment
 - Updated code as per review comment & updated test case
 - Updated AMD64.java
 - Merge master
 - SHA-512 implementation using SHA-NI instructions

-------------

Changes: https://git.openjdk.org/jdk/pull/20633/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20633&range=04
  Stats: 271 lines in 10 files changed: 252 ins; 11 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20633/head:pull/20633

PR: https://git.openjdk.org/jdk/pull/20633

From asmehra at openjdk.org  Wed Oct 16 23:18:14 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 16 Oct 2024 23:18:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
Message-ID: <vlnQGlbG7NDzWUc_gJWL6qO7pDIfmnww-JBHGiH-2zs=.3a3e0644-ea17-42aa-96de-d0d024e19f87@github.com>

On Wed, 16 Oct 2024 02:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo in last commit; fixed header inclusion order

@iklam Changes to move main module name from modules.cpp to elsewhere do not look related to AOT-linking of indy. If so, can they be done in a separate PR.

src/hotspot/share/cds/dumpTimeClassInfo.hpp line 45:

> 43:   bool                         _is_early_klass;
> 44:   bool                         _has_checked_exclusion;
> 45:   bool                         _is_required;

Is this flag only used for hidden classes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2418123427
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803900416

From iklam at openjdk.org  Wed Oct 16 23:34:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 23:34:50 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v11]
In-Reply-To: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
Message-ID: <O7JnEfjm-boQ_2BeE2Nwet09ioROEUX0w0fGv7vRR48=.72b6b3b4-c0f9-42b6-aaa2-11e42bab8a95@github.com>

> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
> 
> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @coleenp: No need to hold InvokeMethodIntrinsicTable_lock during bootstrap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20959/files
  - new: https://git.openjdk.org/jdk/pull/20959/files/a9356279..1e79b7e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20959&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20959&range=09-10

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20959/head:pull/20959

PR: https://git.openjdk.org/jdk/pull/20959

From iklam at openjdk.org  Wed Oct 16 23:34:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 23:34:50 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v9]
In-Reply-To: <VXLJoaqCCKXF6z93GEzsmeLgiOm0Os6236XaqXSkc0k=.ff9904b5-0e52-4735-9f6f-465a55d18b89@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O0uNYfDYpEGuoKjoVX32mUaAUAEQd9UBL48voWp-iD8=.431898e0-9af9-45e7-a6d5-75a2293f8586@github.com>
 <cXKkIHndqhn8ob7fT30oTGdqJ-mbbl75RVfcsH8EhTc=.e4b57e53-72a4-452e-a084-f9a71fdc5842@github.com>
 <Y-vvhT_uwJsZWl6YZtnoD9UTP19uc8vXRXIhZYHPUKM=.7dec13ef-0610-4f87-b482-c01215e04d57@github.com>
 <VXLJoaqCCKXF6z93GEzsmeLgiOm0Os6236XaqXSkc0k=.ff9904b5-0e52-4735-9f6f-465a55d18b89@github.com>
Message-ID: <D7XJk0MpgDuWv4WZEZV7kq77IUr8ABVPSwiEs79BImE=.fbf98afb-38ac-4bf1-909c-f78a6eb56f6e@github.com>

On Wed, 16 Oct 2024 15:32:55 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> The lock cannot be held while calling `AdapterHandlerLibrary::create_native_wrapper()` -- a few lines above. Otherwise  you'd see an error like
>> 
>>> assert(false) failed: Attempting to acquire lock AdapterHandlerLibrary_lock/safepoint out of order with lock InvokeMethodIntrinsicTable_lock/safepoint -- possible deadlock
>> 
>> You can see the same pattern with the existing code
>> 
>> https://github.com/openjdk/jdk/blob/b9cabbecdac27ae8b93df88660a4a0f3f60e6828/src/hotspot/share/classfile/systemDictionary.cpp#L2008-L2022
>> 
>> Most of the work is done inside `AdapterHandlerLibrary::create_native_wrapper()`, which generates native code. Also, this loop happens while the JVM is still in single-threaded mode, so there's no contention on the lock. The cost of taking this lock is negligible.
>
> Thanks for confirming.

After offline discussion with @coleep, we decided to not take this lock at all, as we will never have contention. I added a comment to explain why.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20959#discussion_r1803909285

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 dholmes at openjdk.org  Thu Oct 17 01:02:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Oct 2024 01:02:11 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing [v6]
In-Reply-To: <IRWjo2Dc5cHiSag8UedYjOiU3qyTwU1iid_YdXra_O0=.3cfffbe6-0f54-4019-8e46-99fe9323ceed@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <IRWjo2Dc5cHiSag8UedYjOiU3qyTwU1iid_YdXra_O0=.3cfffbe6-0f54-4019-8e46-99fe9323ceed@github.com>
Message-ID: <V_W6WaSP6wISfbyNmeqfccMRRF4WcIUlx7y9aMU4FRw=.ba5a2ddf-d77d-453b-aba9-6e0ba40b9b1f@github.com>

On Wed, 16 Oct 2024 18:04:28 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed copyright change and renamed method

LGTM2

Thanks for the rename.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21329#pullrequestreview-2373937615

From coleenp at openjdk.org  Thu Oct 17 01:02:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 17 Oct 2024 01:02:21 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v11]
In-Reply-To: <O7JnEfjm-boQ_2BeE2Nwet09ioROEUX0w0fGv7vRR48=.72b6b3b4-c0f9-42b6-aaa2-11e42bab8a95@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O7JnEfjm-boQ_2BeE2Nwet09ioROEUX0w0fGv7vRR48=.72b6b3b4-c0f9-42b6-aaa2-11e42bab8a95@github.com>
Message-ID: <k_P2Qgf7WQrbNXfcsHVacLPOiOx8W6pQy4tgahX21zw=.b970b31e-d1f0-4c09-b477-0cacc1141c8e@github.com>

On Wed, 16 Oct 2024 23:34:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
>> 
>> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp: No need to hold InvokeMethodIntrinsicTable_lock during bootstrap

This looks good. I've always wondered if CDS could share these.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20959#pullrequestreview-2373937358

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 fyang at openjdk.org  Thu Oct 17 04:08:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 17 Oct 2024 04:08:18 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
Message-ID: <fLnqu-DziblFbfJuWjf3yq9z15PViMlc9YatO4d9epA=.c5c6a949-3060-4a49-8ad7-4a5e70b8c41d@github.com>

On Wed, 16 Oct 2024 09:18:53 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_t0
>  - Allow x1 as Rs
>  - Comments fixes
>  - Merge branch 'master' into remove_t0
>  - ICData move to t1, removed dead code
>  - Revert clinit_barrier
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1
>  - Upstream comment
>  - Fixed no explicit use of default t1
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/10455b0f...52b02cb8

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5162:

> 5160:   assert(is_power_of_2(zero_words_block_size), "adjust this");
> 5161:   assert(ptr == x28 && cnt == x29, "mismatch in register usage");
> 5162:   assert_different_registers(cnt, t0, t1);

Here is another case. The call site of `MacroAssembler::zero_words` is `instruct clearArray_reg_reg` which is also missing a `KILL cr` effect after this change. This is similar with the previous reported `instruct partialSubtypeCheckConstSuper` case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1804067035

From iklam at openjdk.org  Thu Oct 17 04:19:27 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Oct 2024 04:19:27 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @liach comments -- added comments; added asserts for HashMap safety in MethodType.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/4be6a255..7bab10b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=06-07

  Stats: 18 lines in 5 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Thu Oct 17 04:23:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Oct 2024 04:23:12 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <XVzsnY9pNVOn-p6DILd10hZz5_kA0kGfyMJRGD-k6qQ=.087aba1f-6291-422c-ae1c-84da9d90495e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <XVzsnY9pNVOn-p6DILd10hZz5_kA0kGfyMJRGD-k6qQ=.087aba1f-6291-422c-ae1c-84da9d90495e@github.com>
Message-ID: <GbvbMQ8CGtpGftw4BEsgJp9ynxpbo1dxqpZE0EHRWNM=.9d7eb7b8-eb30-4c17-9b02-beb7d8488566@github.com>

On Tue, 15 Oct 2024 19:42:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> I recommend adding javadoc or block comments indicating that `runtimeSetup`, `resetArchivedStates`, etc. are called by VM CDS code so people don't accidentally rename this and have unintended impact.

Done.

> src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:
> 
>> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
>> 403:         if (archivedMethodTypes != null) {
>> 404:             MethodType mt = archivedMethodTypes.get(primordialMT);
> 
> The use of `HashMap` naturally feels alarming given this method is invoked in a concurrent context. I just want to make sure that:
> 
> 1. `HashMap` will never have structural modifications when read access is performed (some data structures like treap do). Don't know if we have a test to verify such an intended usage, as we would hurt badly if this implied property suddenly no longer exist.
> 2. The `archivedMethodTypes` must be properly published so we won't read a partial `HashMap`. I've heard of talks about concurrent VM bootstraping so I need some help to understand how this is ensured in bootstrap.

I added asserts to check that the HashMap is written only in the CDS dumping process, so at least we know it's not being modified when we read from it.

The CDS archived heap is either mmaped or read into memory while the VM is still in single threaded mode, so the entire content of the archived heap should be published for to all future threads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2418466360
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1804080520

From iklam at openjdk.org  Thu Oct 17 04:23:14 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Oct 2024 04:23:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v6]
In-Reply-To: <DB_AbfZbFKp1UoN9RQE0mQzKc6VufflWanWJSqO2v8I=.4b41450e-79af-44f1-9bc6-4e50d927b17c@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>
 <DB_AbfZbFKp1UoN9RQE0mQzKc6VufflWanWJSqO2v8I=.4b41450e-79af-44f1-9bc6-4e50d927b17c@github.com>
Message-ID: <7rLnzKl2xG-icT2_QHOW0vhBa4A-CB_gFI3P3vO_zsc=.69679147-a49b-409d-881a-36837c4f5c67@github.com>

On Wed, 16 Oct 2024 05:13:13 GMT, Chen Liang <liach 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 31 commits:
>> 
>>  - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
>>  - 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
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/11391c39...a6ad908f
>
> src/hotspot/share/cds/heapShared.cpp line 447:
> 
>> 445: 
>> 446: bool HeapShared::is_string_concat_klass(InstanceKlass* ik) {
>> 447:   return ik->is_hidden() && ik->name()->starts_with("java/lang/String$$StringConcat");
> 
> Can you add a comment in `StringConcatFactory`'s place where this name is defined, so others who change the generated class name will remember to update references here?

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1804080661

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 duke at openjdk.org  Thu Oct 17 08:09:15 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 17 Oct 2024 08:09:15 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <2OzuDbul0X7nXrM5EBv8fEnSBEo9VWYjpop6MllPVmg=.f6b33d6c-85ed-4512-94b8-cef28975f8cd@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <pnP6nskvCr6dLbn7KG003eRC9vLIR70lpICIJkHQCmo=.e7afefc0-b58f-4f34-9568-6b3c7a3cf82d@github.com>
 <OQ1eLxQPAg47Y-iDMSzEt_ctJnqsUeA2ZPkdUjeRrTI=.34317b0e-30fd-4f55-9f71-e43293d894b8@github.com>
 <2OzuDbul0X7nXrM5EBv8fEnSBEo9VWYjpop6MllPVmg=.f6b33d6c-85ed-4512-94b8-cef28975f8cd@github.com>
Message-ID: <8eX0sGecpJwH1hSf7gscPoaFwxkulpVy3qC3IB69jxI=.5b84dbee-1f00-4d91-827f-5e9859fca4b4@github.com>

On Wed, 16 Oct 2024 21:30:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Actually, I was hoping that I would learn that from a reviewer @vpaprotsk or @vnkozlov , do you know? I was not able to figure it out from the manual what it should be. (with the current setting "false" at least my code works on the test machines that I tried, but I never tried with "true")
>
> legacy_mode should be false here. This instruction is promotable to evex encoding if higher bank registers (XMM16 and above) are used. It is not a legacy instruction so legacy_mode should be false. Examples of legacy instructions are vptest, vpblend*.

Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1804305362

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 fyang at openjdk.org  Thu Oct 17 08:11:15 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 17 Oct 2024 08:11:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
Message-ID: <I40xINj6SuIvGM8Uh0BoQJjpFsXO9BzRsXdUfabyyfA=.16bfa87d-63e5-4d04-94be-850179012049@github.com>

On Wed, 16 Oct 2024 09:18:53 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_t0
>  - Allow x1 as Rs
>  - Comments fixes
>  - Merge branch 'master' into remove_t0
>  - ICData move to t1, removed dead code
>  - Revert clinit_barrier
>  - Fixed no explicit use of default t1
>  - Revert clinit_barrier t1
>  - Upstream comment
>  - Fixed no explicit use of default t1
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/753b7f9a...52b02cb8

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4333:

> 4331:   IncompressibleRegion ir(this);
> 4332:   Register receiver = j_rarg0;
> 4333:   Register data = t0;

As `ic_check` is used by `MachUEPNode::emit`, I think you need to update IC data register usage in `MachUEPNode::format` as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1804304934

From rehn at openjdk.org  Thu Oct 17 08:14:47 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 17 Oct 2024 08:14:47 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v16]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <nhn_2cr-Yu2pO0JRLg9hysOkhD5lJw64DKG115lVmoo=.c744a2bc-6bc5-4840-bc79-bcace58ea2c3@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  KILL cr

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/52b02cb8..030f45b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=14-15

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

From rehn at openjdk.org  Thu Oct 17 08:26:44 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 17 Oct 2024 08:26:44 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v17]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <RO4h8EOL8dy4CPjAqRC5bNx5pOe4J230LecdpLTog-A=.10da81ca-6cd5-4da9-82b2-3b096381ff03@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into remove_t0
 - KILL cr
 - Merge branch 'master' into remove_t0
 - Allow x1 as Rs
 - Comments fixes
 - Merge branch 'master' into remove_t0
 - ICData move to t1, removed dead code
 - Revert clinit_barrier
 - Fixed no explicit use of default t1
 - Revert clinit_barrier t1
 - ... and 10 more: https://git.openjdk.org/jdk/compare/7a64fbbb...14d77aef

-------------

Changes: https://git.openjdk.org/jdk/pull/21406/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=16
  Stats: 178 lines in 18 files changed: 51 ins; 12 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

From jrose at openjdk.org  Thu Oct 17 08:39:14 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 17 Oct 2024 08:39:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
Message-ID: <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>

On Thu, 17 Oct 2024 04:19:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @liach comments -- added comments; added asserts for HashMap safety in MethodType.java

I read through it fairly thoroughly.  I made a lot of suggestions.  Rather than edit comments into lots of spots in this PR, I made the following patch file.
[aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)

  The first lines of the patch file state which revision the patch applies to, which is 4be6a255cdd from Tuesday.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2418914733

From johan.sjolen at oracle.com  Thu Oct 17 08:57:58 2024
From: johan.sjolen at oracle.com (Johan Sjolen)
Date: Thu, 17 Oct 2024 08:57:58 +0000
Subject: Suggestion: Remove NMT header & footer canaries
Message-ID: <BL3PR10MB623377EFE4A0115ED7EF95A6FE472@BL3PR10MB6233.namprd10.prod.outlook.com>

Hi Hotspot-dev,

Today NMT has two canaries: A header and a footer canary. These enable mainly two things:

1. For NMT to aid in identifying and describing a pointer
2. A basic form of out-of-bounds protection

With the introduction of UBSan and Asan into OpenJDK we have gained stronger tools for out-of-bounds analysis, without requiring NMT to be activated. Therefore, I believe that point 2 is no longer something that NMT needs to support. For point 1, we will unfortunately be losing this ability for malloc:ed memory if the canaries are removed, only retaining it for mmaped memory.

I'd like to suggest that we remove these canaries. It would open up valuable real estate in the malloc headers, which we may or may not use for future NMT feature development. I am writing this e-mail as part of community outreach. I want to make sure that I am not missing valuable information which may lead me to re-evaluate the position on this matter.

I am looking forward to your replies.

All the best,
Johan Sj?l?n

From duke at openjdk.org  Thu Oct 17 09:12:23 2024
From: duke at openjdk.org (Andreas Schwab)
Date: Thu, 17 Oct 2024 09:12:23 GMT
Subject: RFR: 8296448: RISC-V: Fix temp usages of heapbase register killed
 by MacroAssembler::en/decode_klass_not_null [v2]
In-Reply-To: <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
References: <7NJqWAajnAuuq1Udf6GT8JeGZdNgBxWGASX0P8HhZE8=.9e7f7b23-3f6a-4954-91a0-d6a7ac123319@github.com>
 <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
Message-ID: <XMRWf9A3CpKk73DIEilmZ3qXvK2HQtU9sqWL0CdPhVM=.7eccbad2-2bc0-4026-906e-2152823aff0c@github.com>

On Tue, 8 Nov 2022 09:00:38 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Please see the JBS issue for more crash details.
>> 
>> To reproduce using a cross-compiled build:
>> 
>> # dump one cds-nocoops.jsa
>> <java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:dump -Xlog:cds* -version
>> 
>> # reproduce
>> <java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:on -XX:-TieredCompilation \
>>        -Xlog:cds* -Xlog:gc+metaspace=info -jar renaissance-gpl-0.14.1.jar -r 1 movie-lens
>> 
>> 
>> `MacroAssembler::en/decode_klass_not_null` uses the heapbase register as a temp register in the interpreter, which may kill the in-use value when enabling C2 compilation and `UseCompressedClassPointers` meanwhile disabling `UseCompressedOops`. C1 won't have this issue for the xheapbase is not its allocation candidate. When CDS is enabled, the narrow klass base is mapped to some address like `0x0000000800000000`, so `MacroAssembler::decode_klass_not_null`, which lacks registers, will use `xheapbase` as a temp to load the klass base and kill the register in the interpreter. So adding a `-XX:+DeoptimizeALot` can speedily reproduce the issue.
>> 
>> To solve this, we shall decouple the xheapbase used as a temp register in `MacroAssembler::en/decode_klass_not_null`. AArch64 has advanced instructions so one register is enough to handle the logic. But in RISC-V we require at least two.
>> 
>> This patch introduces another argument `tmp` to related functions to decouple and eliminate such heapbase usages. One thing that deserves noticing is the `cmp_klass` case, which usually gets used at the beginning of a method entry when `t1` is used as ic holder klass and `t0` is occupied there. These positions are special since nearly all registers are usable except ones used for arguments and special purposes (thread register, etc.). I propose to use a call-clobbered `t2` register here, to keep aligning the `i2c2i_adapter` logic[1].
>> 
>> Tested hotspot tier1~4 on QEMU; jdk tier1~tier2 and hotspot tier1~tier2 on my Hifive unmatched board, and the reproducible movie-lens benchmark.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp#L629
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

There is a potential conflict with the use of t0 in decode_klass_not_null:

    assert_different_registers(t0, xbase);

since tmp in load_klass defaults to t0.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11010#issuecomment-2418986543

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 galder at openjdk.org  Thu Oct 17 10:10:56 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 17 Oct 2024 10:10:56 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o 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 30 additional commits since the last revision:

 - Use same default size as in other vector reduction benchmarks
 - Renamed benchmark class
 - Double/Float tests only when avx enabled
 - Make state class non-final
 - Restore previous benchmark iterations and default param size
 - Add clipping range benchmark that uses min/max
 - Encapsulate benchmark state within an inner class
 - Avoid creating result array in benchmark method
 - Merge branch 'master' into topic.intrinsify-max-min-long
 - Revert "Implement cmovL as a jump+mov branch"
   
   This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
 - ... and 20 more: https://git.openjdk.org/jdk/compare/583c2fbe...0a8718e1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/16ae2a33..0a8718e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=02-03

  Stats: 298782 lines in 3654 files changed: 243667 ins; 34795 del; 20320 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From galder at openjdk.org  Thu Oct 17 10:15:25 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 17 Oct 2024 10:15:25 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
Message-ID: <QXs7uJ-a7WLEpftyElRZcGB_R_iKJpRrj8uQG6WD3h4=.13ee5ec0-871b-4f15-a162-368bb70b4f30@github.com>

On Thu, 17 Oct 2024 10:10:56 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o 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 30 additional commits since the last revision:
> 
>  - Use same default size as in other vector reduction benchmarks
>  - Renamed benchmark class
>  - Double/Float tests only when avx enabled
>  - Make state class non-final
>  - Restore previous benchmark iterations and default param size
>  - Add clipping range benchmark that uses min/max
>  - Encapsulate benchmark state within an inner class
>  - Avoid creating result array in benchmark method
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/52005a12...0a8718e1

I've re-run the benchmarks in non-AVX-512 and AVX-512 environments making sure no .ad changes were applied.
I've also added clipping range benchmarks suggested by @theRealAph.

Remember that the AVX512 and non-AVX512 results were obtained in different systems so they cannot be compared between them. AVX512 results can be compared between base and patched versions and same for non-AVX512 results.

The results for loop* and reduction* match the behaviour explained in https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872. The explanation in that comment applies here as well:


Benchmark                          (probability)  (range)  (seed)  (size)   Mode  Cnt    Score    Error   Units
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  107.441 ?  0.092  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  107.431 ?  0.057  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  213.200 ?  5.070  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  107.411 ?  0.088  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  107.425 ?  0.097  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  107.377 ?  0.075  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  414.214 ?  0.898  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  414.637 ?  0.074  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  239.570 ?  3.034  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  414.276 ?  0.399  ops/ms (AVX512, patch)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  414.284 ?  0.342  ops/ms (AVX512, patch)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  413.860 ?  1.831  ops/ms (AVX512, patch)


The clipping range results show big improvements:

Benchmark                          (probability)  (range)  (seed)  (size)   Mode  Cnt    Score    Error    Units
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8  108.503 ?  0.399   ops/ms (non-AVX512, base)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8  107.655 ?  1.759   ops/ms (non-AVX512, base)
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8  613.310 ?  1.140   ops/ms (non-AVX512, patch)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8  613.282 ?  0.744   ops/ms (non-AVX512, patch)
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8   64.343 ?  0.396   ops/ms (AVX512, base)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8   61.323 ?  6.059   ops/ms (AVX512, base)
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8  359.525 ?  0.570   ops/ms (AVX512, patch)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8  360.284 ?  1.408   ops/ms (AVX512, patch)


The improvements in clipping range are due to vector instructions being used:


   0.11%  ??  0x00007f5e000266c8:   vpcmpgtq		%ymm4, %ymm5, %ymm12
   0.56%  ??  0x00007f5e000266cd:   vblendvpd		%ymm12, %ymm5, %ymm4, %ymm12
   0.04%  ??  0x00007f5e000266d3:   vpcmpgtq		%ymm6, %ymm12, %ymm11
   1.10%  ??  0x00007f5e000266d8:   vblendvpd		%ymm11, %ymm6, %ymm12, %ymm11
   2.93%  ??  0x00007f5e000266de:   vmovdqu		%ymm11, 0xf0(%r9, %r10, 8)
          ??                                                            ;*lastore {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 35 (line 211)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


Whereas without the changes it uses scalar instructions:


   0.56%          ??    0x00007f9e98025e83:   cmpq		%r8, %rdx
   2.98%  ?       ??    0x00007f9e98025e86:   jle		0x7f9e98025e8b      ;*ifgt {reexecute=0 rethrow=0 return_oop=0}
          ?       ??                                                              ; - java.lang.Math::min at 3 (line 2132)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 32 (line 211)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   0.03%  ?       ??    0x00007f9e98025e88:   movq		%r8, %rdx           ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?       ??                                                              ; - java.lang.Math::min at 11 (line 2132)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 32 (line 211)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   0.04%  ?       ??    0x00007f9e98025e8b:   movq		%rdx, 0x28(%r13, %rcx, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
                  ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 35 (line 211)
                  ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
  19.79%          ??    0x00007f9e98025e90:   addl		$4, %ecx            ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                  ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 36 (line 210)
                  ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


Finally, I've fixed the float/double IR tests by adding conditionals to make sure they only run when UseAVX > 0.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2419120069

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 rehn at openjdk.org  Thu Oct 17 13:44:55 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 17 Oct 2024 13:44:55 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Updated UEP pretty print with t1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21406/files
  - new: https://git.openjdk.org/jdk/pull/21406/files/14d77aef..f1856830

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=16-17

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

From matsaave at openjdk.org  Thu Oct 17 13:59:15 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Oct 2024 13:59:15 GMT
Subject: RFR: 8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java
 from JDK-8324259 is failing
In-Reply-To: <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
 <4kq5v8ZKwvKTWNJ18qCH6B2IRxFS5_8lL1ooX0OQQJQ=.b6653c8c-ed67-402f-b0ad-c55cb01d37aa@github.com>
Message-ID: <uAnlWVIqgPQuDZ_S1GfHpn_-6JNpkAnjkgXkYdeQL_8=.6620b36b-299b-481c-9a1a-14e59b54a86d@github.com>

On Fri, 4 Oct 2024 02:18:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
>> 
>> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.
>
> P.S you also need to unProblemList the test.

Thanks for the discussion and reviews @dholmes-ora and @iklam!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21329#issuecomment-2419625381

From matsaave at openjdk.org  Thu Oct 17 13:59:16 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Oct 2024 13:59:16 GMT
Subject: Integrated: 8341452: Test
 runtime/cds/appcds/DumpRuntimeClassesTest.java from JDK-8324259 is failing
In-Reply-To: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
References: <V74bkhzmFQGcn5Zy0aaRgfKM6YzovweuaZgz2uJ33v8=.0462ef26-ced3-46d6-bd92-053bb758928f@github.com>
Message-ID: <1uvBJLwbb6DfGFG4wrHvArsInDzEKEfVSXALZ0v1j40=.405014fe-e813-4b24-a08f-e40639ae7b7a@github.com>

On Thu, 3 Oct 2024 17:43:50 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> DumpRuntimeClassesTest.java was added in [JDK-8324259](https://bugs.openjdk.org/browse/JDK-8324259) to verify that the newly added dummy call archived classes that are used at CDS runtime. This new test exposed a case where `JarVerifier` is used at CDS runtime while not being in the archive, so this patch performs a dummy call to `JarVerifier`. 
> 
> When using `-Xcomp`, the class `Manifest` is compiled which causes `JarVerifier` to be loaded. This does not occur in other modes since the constructor of `Manifest` doesn't create any instances of `JarVerifier`. The existing dummy call to `Manifest` doesn't load `JarVerifier` either, so a separate dummy call can be used to ensure it is loaded at dumptime. Now that there are multiple dummy calls, they are pulled out into a new method `make_dummy_calls()`. Verified with tier x-y tests.

This pull request has now been integrated.

Changeset: 363327e6
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/363327e68644b710b0fd549e088beb5c8838a973
Stats:     50 lines in 6 files changed: 25 ins; 20 del; 5 mod

8341452: Test runtime/cds/appcds/DumpRuntimeClassesTest.java from JDK-8324259 is failing

Reviewed-by: dholmes, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/21329

From rehn at openjdk.org  Thu Oct 17 14:05:25 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 17 Oct 2024 14:05:25 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <I40xINj6SuIvGM8Uh0BoQJjpFsXO9BzRsXdUfabyyfA=.16bfa87d-63e5-4d04-94be-850179012049@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
 <I40xINj6SuIvGM8Uh0BoQJjpFsXO9BzRsXdUfabyyfA=.16bfa87d-63e5-4d04-94be-850179012049@github.com>
Message-ID: <WN84V_uJpv6S-0CRx5jMMyXC1KlwkgEnhNRKyjgMd90=.1c55b4d1-c647-470b-9f8d-6a172764008d@github.com>

On Thu, 17 Oct 2024 08:06:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn 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 18 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into remove_t0
>>  - Allow x1 as Rs
>>  - Comments fixes
>>  - Merge branch 'master' into remove_t0
>>  - ICData move to t1, removed dead code
>>  - Revert clinit_barrier
>>  - Fixed no explicit use of default t1
>>  - Revert clinit_barrier t1
>>  - Upstream comment
>>  - Fixed no explicit use of default t1
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/9424a955...52b02cb8
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4333:
> 
>> 4331:   IncompressibleRegion ir(this);
>> 4332:   Register receiver = j_rarg0;
>> 4333:   Register data = t0;
> 
> As `ic_check` is used by `MachUEPNode::emit`, I think you need to update IC data register usage in `MachUEPNode::format` as well.

Yes, good, fixed the prints.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5162:
> 
>> 5160:   assert(is_power_of_2(zero_words_block_size), "adjust this");
>> 5161:   assert(ptr == x28 && cnt == x29, "mismatch in register usage");
>> 5162:   assert_different_registers(cnt, t0, t1);
> 
> Here is another case. The call site of `MacroAssembler::zero_words` is `instruct clearArray_reg_reg` which is also missing a `KILL cr` effect after this change (Also see https://bugs.openjdk.org/browse/JDK-8247979). This is similar with the previous reported `instruct partialSubtypeCheckConstSuper` case.
> 
> (PS: I haven't checked all the `rt_call` assembler routine call sites, not sure if they bear similar issues (clobber rflags or ICdata silently))

icdata only needs be present in the handful first assebmly lines in the entry, as ic_check is the first thing we do as long as that do not clobber t0 we are good to go.

Fixed the ones you found thanks!
I'll look tomorrow if there are anymore!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1804845802
PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1804849269

From fyang at openjdk.org  Thu Oct 17 14:10:15 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 17 Oct 2024 14:10:15 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
Message-ID: <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>

On Thu, 17 Oct 2024 13:44:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated UEP pretty print with t1

Thanks for the update. Hopefully, I think I can finish first round of review tomorrow. BTW: It will be good to know how this may affect other benchmark workloads, like specjbb2015, etc.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2419652358

From matsaave at openjdk.org  Thu Oct 17 14:10:52 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 17 Oct 2024 14:10:52 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS [v3]
In-Reply-To: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
Message-ID: <iXPc8xUf9J-hOLvnrTIVpPxp2uL8lAJtVzMTPr8nvCk=.a1bcef7e-737a-4483-8c07-bee36cbed00f@github.com>

> 8341444: Unnecessary check for JSRs in CDS

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Further changed comment
 - Updated comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21330/files
  - new: https://git.openjdk.org/jdk/pull/21330/files/8b599317..d7cdb705

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21330&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21330&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21330.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21330/head:pull/21330

PR: https://git.openjdk.org/jdk/pull/21330

From rehn at openjdk.org  Thu Oct 17 14:40:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 17 Oct 2024 14:40:13 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
 <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>
Message-ID: <vMsuRfr8iItgy8Y5uh3YbjRJnDBtdubQdVP3fvPjQPI=.b4e20854-54d5-444b-a1c8-7cdc781e2eb0@github.com>

On Thu, 17 Oct 2024 14:06:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks for the update. Hopefully, I think I can finish first round of review tomorrow. BTW: It will be good to know how this may affect other benchmark workloads, like specjbb2015, etc.

Thank you for the in-depth review! Maybe @Hamlin-Li can take it for spin?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2419734595

From tanksherman27 at gmail.com  Thu Oct 17 15:28:14 2024
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 17 Oct 2024 23:28:14 +0800
Subject: Seemingly contradictory code in sharedRuntime.cpp
Message-ID: <CAP2b4GOhMHxWFGAar=DtVM9xW7odeM1gHOn=-L7JZPTWjoOU3g@mail.gmail.com>

Hi all,

Recently while compiling the Windows JDK, gcc caught a very strange
case in sharedRuntime.cpp. The SharedRuntime::frem and
SharedRuntime::drem methods both contain code that is only compiled if
_WIN64 is defined. The problem is this is then surrounded by an ifndef
check for X86. HotSpot defines X86 if AMD64 or IA32 is defined. Since
IA32 is not a supported architecture, only AMD64 is of interest to us
here. But AMD64 and _WIN64 will always both be defined at the same
time, as _WIN64 is an AMD64 platform. So by extension, X86 and _WIN64
will always be defined together. But remember that the Windows
specific code in frem and drem will only be compiled if X86 is not
defined and _WIN64 is defined. This means the block of code that is
guarded by the _WIN64 define is never ever compiled. To add to that,
sharedRuntime_x86.cpp also contains alternate method definitions for
SharedRuntime::frem and SharedRuntime::drem. This all leads me to
believe it is a bug where the code meant for Windows x64 was
erroneously added to the implementation for non x86 platforms instead
of the correct one inside sharedRuntime_x86.cpp. I just thought I'd
give everyone a heads up, and also to confirm that this is indeed a
bug, before I start working on a fix

The code in question:

#if !defined(X86) // <----- This will always be defined if _WIN64 is defined!
JRT_LEAF(jfloat, SharedRuntime::frem(jfloat x, jfloat y))
#ifdef _WIN64 // <----- This will always be defined if X86 is defined!
  // 64-bit Windows on amd64 returns the wrong values for
  // infinity operands.
  juint xbits = PrimitiveConversions::cast<juint>(x);
  juint ybits = PrimitiveConversions::cast<juint>(y);
  // x Mod Infinity == x unless x is infinity
  if (((xbits & float_sign_mask) != float_infinity) &&
       ((ybits & float_sign_mask) == float_infinity) ) {
    return x;
  }
  return ((jfloat)fmod_winx64((double)x, (double)y));
#else
  return ((jfloat)fmod((double)x,(double)y));
#endif
JRT_END

JRT_LEAF(jdouble, SharedRuntime::drem(jdouble x, jdouble y))
#ifdef _WIN64 <----- This will always be defined if X86 is defined!
  julong xbits = PrimitiveConversions::cast<julong>(x);
  julong ybits = PrimitiveConversions::cast<julong>(y);
  // x Mod Infinity == x unless x is infinity
  if (((xbits & double_sign_mask) != double_infinity) &&
       ((ybits & double_sign_mask) == double_infinity) ) {
    return x;
  }
  return ((jdouble)fmod_winx64((double)x, (double)y));
#else
  return ((jdouble)fmod((double)x,(double)y));
#endif
JRT_END
#endif // !X86

best regards,
Julian

From jbhateja at openjdk.org  Thu Oct 17 15:33:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 15:33:38 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v26]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <Sjy8msqKoDsvOZPP6tiYVBBnihejr0oU1wLqhnP3veY=.a8a82548-9767-4e7a-b548-1a8c67c788ae@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - New IR tests + additional IR transformations
 - Update adlc changes.
 - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
 - Update VectorMath.java
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Typographical error fixups
 - Doc fixups
 - Typographic error
 - Merge stashing and re-commit
 - ... and 19 more: https://git.openjdk.org/jdk/compare/44151f47...c92084d9

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=25
  Stats: 10221 lines in 55 files changed: 9784 ins; 27 del; 410 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

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 jbhateja at openjdk.org  Thu Oct 17 15:45:19 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 15:45:19 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
Message-ID: <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>

On Wed, 16 Oct 2024 19:44:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.

Agree, I am thinking of developing an automated IR validation infrastructure for all vector API operations, till then and for the sake of completeness of this patch we can let newly created IR based tests be part of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2419895522

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 sviswanathan at openjdk.org  Thu Oct 17 16:19:22 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 17 Oct 2024 16:19:22 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
Message-ID: <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>

On Thu, 17 Oct 2024 15:41:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.
> 
> Agree, I am thinking of developing an automated IR validation infrastructure for all vector API operations, till then and for the sake of completeness of this patch we can let newly created IR based tests be part of this PR.

@jatin-bhateja I agree with Paul, it would be good to remove the newly added IR test changes from this PR to reduce the load on reviewers. You can always send it as a separate PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2419973468

From jbhateja at openjdk.org  Thu Oct 17 16:25:34 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 16:25:34 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v27]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <ZsejVRsI4V6pi5CWcRMniFQtMAtwcmy7b7-wrd_e1nE=.997911c4-581b-4671-89a1-9bef50c18259@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Prod build fix
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - New IR tests + additional IR transformations
 - Update adlc changes.
 - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
 - Update VectorMath.java
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Typographical error fixups
 - Doc fixups
 - ... and 21 more: https://git.openjdk.org/jdk/compare/236c71ca...d9a379b2

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=26
  Stats: 10219 lines in 55 files changed: 9784 ins; 28 del; 407 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

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 jbhateja at openjdk.org  Thu Oct 17 18:26:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 18:26:03 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v28]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <-wd5wj8QkFZ6vORqWPFZdV_CYCQl2Y7zPNSdW_luNSY=.3c848ace-6cdd-40a5-b924-8feef4346e2d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Restrict IR validation to newly added UMin/UMax transforms.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/d9a379b2..2b0fa016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=26-27

  Stats: 1373 lines in 3 files changed: 507 ins; 866 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Oct 17 18:26:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 18:26:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
 <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
Message-ID: <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>

On Thu, 17 Oct 2024 16:17:02 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> > > Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.
> > 
> > 
> > Agree, I am thinking of developing an automated IR validation infrastructure for all vector API operations, till then and for the sake of completeness of this patch we can let newly created IR based tests be part of this PR.
> 
> @jatin-bhateja I agree with Paul, it would be good to remove the newly added IR test changes from this PR to reduce the load on reviewers. You can always send it as a separate PR.

I have restricted the IR validation to just newly added UMin/UMax transformations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2420238761

From jbhateja at openjdk.org  Thu Oct 17 18:32:53 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 18:32:53 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v29]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <zh9At4PhK2u3hdvVYSilZ-E23ECKgu4MZqlUc7n161g=.f967f139-da8d-4d28-8f7b-8fee444ba4fb@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Remove Saturating IRNode patterns.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/2b0fa016..3ee0de07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=27-28

  Stats: 40 lines in 1 file changed: 0 ins; 40 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From vladimir.kozlov at oracle.com  Thu Oct 17 19:26:41 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 17 Oct 2024 12:26:41 -0700
Subject: Seemingly contradictory code in sharedRuntime.cpp
In-Reply-To: <CAP2b4GOhMHxWFGAar=DtVM9xW7odeM1gHOn=-L7JZPTWjoOU3g@mail.gmail.com>
References: <CAP2b4GOhMHxWFGAar=DtVM9xW7odeM1gHOn=-L7JZPTWjoOU3g@mail.gmail.com>
Message-ID: <069e0b62-b97d-4024-a57e-1f28fa4e02e8@oracle.com>

Thank you, Julian, for reporting this.

The issue was introduced by [1] changes. I think it is incorrectly removed `defined(_WIN64)` from `#if` in sharedRuntime.cpp

Thanks,
Vladimir K

[1] 
https://github.com/openjdk/jdk/commit/ce2a7ea40a22c652e5f8559c91d5eea197e2d708#diff-808315795bdfbd3d48d1665603fc2fe0db416fa299394371f24dbed2cb32caa4

On 10/17/24 8:28 AM, Julian Waters wrote:
> Hi all,
> 
> Recently while compiling the Windows JDK, gcc caught a very strange
> case in sharedRuntime.cpp. The SharedRuntime::frem and
> SharedRuntime::drem methods both contain code that is only compiled if
> _WIN64 is defined. The problem is this is then surrounded by an ifndef
> check for X86. HotSpot defines X86 if AMD64 or IA32 is defined. Since
> IA32 is not a supported architecture, only AMD64 is of interest to us
> here. But AMD64 and _WIN64 will always both be defined at the same
> time, as _WIN64 is an AMD64 platform. So by extension, X86 and _WIN64
> will always be defined together. But remember that the Windows
> specific code in frem and drem will only be compiled if X86 is not
> defined and _WIN64 is defined. This means the block of code that is
> guarded by the _WIN64 define is never ever compiled. To add to that,
> sharedRuntime_x86.cpp also contains alternate method definitions for
> SharedRuntime::frem and SharedRuntime::drem. This all leads me to
> believe it is a bug where the code meant for Windows x64 was
> erroneously added to the implementation for non x86 platforms instead
> of the correct one inside sharedRuntime_x86.cpp. I just thought I'd
> give everyone a heads up, and also to confirm that this is indeed a
> bug, before I start working on a fix
> 
> The code in question:
> 
> #if !defined(X86) // <----- This will always be defined if _WIN64 is defined!
> JRT_LEAF(jfloat, SharedRuntime::frem(jfloat x, jfloat y))
> #ifdef _WIN64 // <----- This will always be defined if X86 is defined!
>    // 64-bit Windows on amd64 returns the wrong values for
>    // infinity operands.
>    juint xbits = PrimitiveConversions::cast<juint>(x);
>    juint ybits = PrimitiveConversions::cast<juint>(y);
>    // x Mod Infinity == x unless x is infinity
>    if (((xbits & float_sign_mask) != float_infinity) &&
>         ((ybits & float_sign_mask) == float_infinity) ) {
>      return x;
>    }
>    return ((jfloat)fmod_winx64((double)x, (double)y));
> #else
>    return ((jfloat)fmod((double)x,(double)y));
> #endif
> JRT_END
> 
> JRT_LEAF(jdouble, SharedRuntime::drem(jdouble x, jdouble y))
> #ifdef _WIN64 <----- This will always be defined if X86 is defined!
>    julong xbits = PrimitiveConversions::cast<julong>(x);
>    julong ybits = PrimitiveConversions::cast<julong>(y);
>    // x Mod Infinity == x unless x is infinity
>    if (((xbits & double_sign_mask) != double_infinity) &&
>         ((ybits & double_sign_mask) == double_infinity) ) {
>      return x;
>    }
>    return ((jdouble)fmod_winx64((double)x, (double)y));
> #else
>    return ((jdouble)fmod((double)x,(double)y));
> #endif
> JRT_END
> #endif // !X86
> 
> best regards,
> Julian


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 mchung at openjdk.org  Thu Oct 17 20:49:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 17 Oct 2024 20:49:46 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification for
 core reflection
Message-ID: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>

The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3] uncovered over time.

The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   These VM hacks can be removed together with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   In addition, the special metaspace for reflection can also be removed.   I will create a separate issue to remove `Metaspace::ReflectionMetaspaceType` and update existing GTests together.

[1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
[2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
[3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

-------------

Commit messages:
 - 8327624: Remove VM implementation that bypass verification for core reflection

Changes: https://git.openjdk.org/jdk/pull/21571/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21571&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327624
  Stats: 981 lines in 17 files changed: 0 ins; 973 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21571/head:pull/21571

PR: https://git.openjdk.org/jdk/pull/21571

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 liach at openjdk.org  Thu Oct 17 22:06:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Oct 2024 22:06:14 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <oODbuFH2zjuvwWvgpcUNpAStux1PurM6UhW74YC_z00=.0c4fc01a-e389-4db7-87f3-02aca92e3ade@github.com>

On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

It seems we can now remove `AccessorGenerator`, `ByteVector*`, `ClassFile*`, `Label`, and `MagicAccessorImpl` Java files from `jdk.internal.reflect`. Do we plan to do that in another RFE?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21571#issuecomment-2420680392

From duke at openjdk.org  Thu Oct 17 22:07:16 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 17 Oct 2024 22:07:16 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v8]
In-Reply-To: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
Message-ID: <oC7V6BPzlccZd93dZPgCdAnQNKy5LAeEPEl5Z48ZmN4=.5dd29b29-9307-4a03-a282-e98c67ad3787@github.com>

> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:

  Use same keys for encryption and decryption

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19960/files
  - new: https://git.openjdk.org/jdk/pull/19960/files/f7bef0e3..c8ca0577

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=06-07

  Stats: 33 lines in 2 files changed: 4 ins; 14 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/19960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19960/head:pull/19960

PR: https://git.openjdk.org/jdk/pull/19960

From duke at openjdk.org  Thu Oct 17 22:25:39 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 17 Oct 2024 22:25:39 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v8]
In-Reply-To: <oC7V6BPzlccZd93dZPgCdAnQNKy5LAeEPEl5Z48ZmN4=.5dd29b29-9307-4a03-a282-e98c67ad3787@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <oC7V6BPzlccZd93dZPgCdAnQNKy5LAeEPEl5Z48ZmN4=.5dd29b29-9307-4a03-a282-e98c67ad3787@github.com>
Message-ID: <VSqbhrrqvy76QWhMetH6jrwVEdQhqrUVEMShYnAqQv4=.ed7b4ca6-59dd-4760-a23c-2870be2f4a17@github.com>

On Thu, 17 Oct 2024 22:07:16 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use same keys for encryption and decryption

Hi all! I'm sorry for such a late replies. I was able to optimize decryption sequence by using keys from encryption stage with reversed rounds order

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19960#issuecomment-2420721358

From duke at openjdk.org  Thu Oct 17 22:25:40 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 17 Oct 2024 22:25:40 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v7]
In-Reply-To: <9S-t7RTEcPhwD0WZLi_OYy9PK8UrKro19v2IbyHpKaI=.5f9663c8-5f33-429c-8077-47bae27608ed@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <9rglid_tIn1JA4zqOFygiz1hWYZGOPa8Ci1AI1qRHDA=.c70dd0ec-46b4-43c5-841e-7d91edf65eb4@github.com>
 <9S-t7RTEcPhwD0WZLi_OYy9PK8UrKro19v2IbyHpKaI=.5f9663c8-5f33-429c-8077-47bae27608ed@github.com>
Message-ID: <NFzThtgZG3wrMEtUrcQ6IkDFSXAsobvcrlAqH5tsxoc=.a6d15b18-0b2a-4395-a513-87a12412368b@github.com>

On Thu, 26 Sep 2024 05:39:11 GMT, Yanhong Zhu <yzhu at openjdk.org> wrote:

>> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Multiversion decrypt intrinsic
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2370:
> 
>> 2368:     assert(reg_number <= 14, "reg_number should be less than or equal to working_vregs size");
>> 2369: 
>> 2370:     for (int i = 0; i < reg_number; i++) {
> 
> Hello, I have a question about the order of register handling in loops. Why is it in ascending order instead of descending? Here?s an example: https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvkned.s.
>  And I look forward to your reply. Thanks.

Hi! It was in ascending order because I used different keys for encryption and decryption, while it is possible to use same set for both cases. Though both decryption implementations are functionally correct, the [current](https://github.com/openjdk/jdk/pull/19960/commits/c8ca05777a77c351d9c3d536ea11d7fd9af23e2c) one is more optimal

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1805517549

From duke at openjdk.org  Thu Oct 17 22:25:40 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 17 Oct 2024 22:25:40 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v7]
In-Reply-To: <5ow09TSwi-PdaV29TrkX4LhaJxyQxBFjLkYLxVAhcsA=.6ac81488-94c9-42e7-a4f3-b59256da30df@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <9rglid_tIn1JA4zqOFygiz1hWYZGOPa8Ci1AI1qRHDA=.c70dd0ec-46b4-43c5-841e-7d91edf65eb4@github.com>
 <5ow09TSwi-PdaV29TrkX4LhaJxyQxBFjLkYLxVAhcsA=.6ac81488-94c9-42e7-a4f3-b59256da30df@github.com>
Message-ID: <0YqUBORJX3rRLwE-B73RlFqVHC7daUZxRAGuJiG38EY=.7e6eaa74-94d2-4c5a-8cda-fc0d35f004a9@github.com>

On Wed, 25 Sep 2024 14:29:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Multiversion decrypt intrinsic
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2373:
> 
>> 2371:       __ vxor_vv(res, res, working_vregs[i]);
>> 2372:       __ vaesdm_vv(res, vzero);
>> 2373:     }
> 
> Seems that a lot more `vxor.vv` are emitted here compared with the openssl version [1]. I wonder if this could be further optimized. Or is there anything I missed? Thanks.
> 
> [1] https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-riscv64-zvkned.pl#L279-L295

You're absolutely right, thanks! Turned out I missed the fact that we can just use the encryption keys in reversed order for decryption

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1805517579

From mchung at openjdk.org  Thu Oct 17 22:44:05 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 17 Oct 2024 22:44:05 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21571/files
  - new: https://git.openjdk.org/jdk/pull/21571/files/4753637c..245cfb6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21571&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21571&range=00-01

  Stats: 1836 lines in 11 files changed: 0 ins; 1832 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21571/head:pull/21571

PR: https://git.openjdk.org/jdk/pull/21571

From mchung at openjdk.org  Thu Oct 17 22:44:06 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 17 Oct 2024 22:44:06 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <tcwHq7I7vx0-rYOPFW4n2PU2_lQ7wMRW_KDsaQAZ_j0=.51c264ac-2e3d-4801-aaa4-89a7e1de328a@github.com>

On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

Good catch!  Patch updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21571#issuecomment-2420740316

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 0ctopus13prime at gmail.com  Thu Oct 17 23:13:47 2024
From: 0ctopus13prime at gmail.com (=?UTF-8?B?6riw7KSA?=)
Date: Thu, 17 Oct 2024 16:13:47 -0700
Subject: Is it safe to use LD_PRELOAD to load a custom malloc library when
 running the OpenJDK?
Message-ID: <CAKPdV5iLCj_8Vnf3UYiswnLyGttgvrZih9-Md7Y8h96Oa5ivPg@mail.gmail.com>

Hello everyone, hope you're doing well!

I have a question, and I?m hoping this is the right place to ask. If it's
not, I?d appreciate it if someone could point me to the correct mailing
list.

Our team is heavily using JNI C++ code for computations that involve
frequent object allocations and deallocations. To optimize these memory
operations, we tested using jemalloc as a replacement for glibc, and
observed huge improvements in performance metrics.

We're currently using LD_PRELOAD to load the jemalloc library when
launching the JVM, so that all memory allocation and deallocation requests
are handled by jemalloc. However, I'm wondering if this approach could lead
to any unexpected issues, since it would also take the JVM's memory
allocation requests as well.

>From what I understand, heap allocations in the JVM don't use malloc
directly, as they rely on optimized assembly code or the JVM's internal
memory management system. Some folks on the internet have mentioned that
the JVM might have a custom malloc implementation designed specifically for
its use, preloading jemalloc may cause symbol conflicts. However, I haven't
been able to find any code supporting that hypothesis.

*My question is: is it safe to use LD_PRELOAD to load a custom malloc
library, like jemalloc, when running the JVM, at least with OpenJDK?*



Thank you in advance.

Dooyong Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241017/e6d5189b/attachment.htm>

From vladimir.x.ivanov at oracle.com  Thu Oct 17 23:15:32 2024
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 17 Oct 2024 16:15:32 -0700
Subject: Seemingly contradictory code in sharedRuntime.cpp
In-Reply-To: <069e0b62-b97d-4024-a57e-1f28fa4e02e8@oracle.com>
References: <CAP2b4GOhMHxWFGAar=DtVM9xW7odeM1gHOn=-L7JZPTWjoOU3g@mail.gmail.com>
 <069e0b62-b97d-4024-a57e-1f28fa4e02e8@oracle.com>
Message-ID: <13901ad1-5217-424a-ae43-b446213bfbc4@oracle.com>


> The issue was introduced by [1] changes. I think it is incorrectly 
> removed `defined(_WIN64)` from `#if` in sharedRuntime.cpp

It looks like _WIN64-specific code in sharedRuntime.cpp is redundant 
now. There's x86-specific implementation of SharedRuntime::frem in 
sharedRuntime_x86.cpp which is not guarded by "!defined(_WIN64)" anymore.

Best regards,
Vladimir Ivanov

> [1] 
> https://github.com/openjdk/jdk/commit/ce2a7ea40a22c652e5f8559c91d5eea197e2d708#diff-808315795bdfbd3d48d1665603fc2fe0db416fa299394371f24dbed2cb32caa4
> 
> On 10/17/24 8:28 AM, Julian Waters wrote:
>> Hi all,
>>
>> Recently while compiling the Windows JDK, gcc caught a very strange
>> case in sharedRuntime.cpp. The SharedRuntime::frem and
>> SharedRuntime::drem methods both contain code that is only compiled if
>> _WIN64 is defined. The problem is this is then surrounded by an ifndef
>> check for X86. HotSpot defines X86 if AMD64 or IA32 is defined. Since
>> IA32 is not a supported architecture, only AMD64 is of interest to us
>> here. But AMD64 and _WIN64 will always both be defined at the same
>> time, as _WIN64 is an AMD64 platform. So by extension, X86 and _WIN64
>> will always be defined together. But remember that the Windows
>> specific code in frem and drem will only be compiled if X86 is not
>> defined and _WIN64 is defined. This means the block of code that is
>> guarded by the _WIN64 define is never ever compiled. To add to that,
>> sharedRuntime_x86.cpp also contains alternate method definitions for
>> SharedRuntime::frem and SharedRuntime::drem. This all leads me to
>> believe it is a bug where the code meant for Windows x64 was
>> erroneously added to the implementation for non x86 platforms instead
>> of the correct one inside sharedRuntime_x86.cpp. I just thought I'd
>> give everyone a heads up, and also to confirm that this is indeed a
>> bug, before I start working on a fix
>>
>> The code in question:
>>
>> #if !defined(X86) // <----- This will always be defined if _WIN64 is 
>> defined!
>> JRT_LEAF(jfloat, SharedRuntime::frem(jfloat x, jfloat y))
>> #ifdef _WIN64 // <----- This will always be defined if X86 is defined!
>> ?? // 64-bit Windows on amd64 returns the wrong values for
>> ?? // infinity operands.
>> ?? juint xbits = PrimitiveConversions::cast<juint>(x);
>> ?? juint ybits = PrimitiveConversions::cast<juint>(y);
>> ?? // x Mod Infinity == x unless x is infinity
>> ?? if (((xbits & float_sign_mask) != float_infinity) &&
>> ??????? ((ybits & float_sign_mask) == float_infinity) ) {
>> ???? return x;
>> ?? }
>> ?? return ((jfloat)fmod_winx64((double)x, (double)y));
>> #else
>> ?? return ((jfloat)fmod((double)x,(double)y));
>> #endif
>> JRT_END
>>
>> JRT_LEAF(jdouble, SharedRuntime::drem(jdouble x, jdouble y))
>> #ifdef _WIN64 <----- This will always be defined if X86 is defined!
>> ?? julong xbits = PrimitiveConversions::cast<julong>(x);
>> ?? julong ybits = PrimitiveConversions::cast<julong>(y);
>> ?? // x Mod Infinity == x unless x is infinity
>> ?? if (((xbits & double_sign_mask) != double_infinity) &&
>> ??????? ((ybits & double_sign_mask) == double_infinity) ) {
>> ???? return x;
>> ?? }
>> ?? return ((jdouble)fmod_winx64((double)x, (double)y));
>> #else
>> ?? return ((jdouble)fmod((double)x,(double)y));
>> #endif
>> JRT_END
>> #endif // !X86
>>
>> best regards,
>> Julian
> 

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 psandoz at openjdk.org  Thu Oct 17 23:38:28 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 17 Oct 2024 23:38:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
 <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
 <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>
Message-ID: <sWXg913xsqvSuL3EiMoZqRwF0Hpro4lUdhZ1tP4LyXA=.e8330ff5-57d8-40e5-afdf-a088bf63be7d@github.com>

On Thu, 17 Oct 2024 18:23:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> I have restricted the IR validation to just newly added UMin/UMax transformations.

Even then i think it better to do so in follow on PR, otherwise it is a moving target for review and testing. This new test fails on aarch64 e.g.,


STATUS:Failed.`main' threw exception: compiler.lib.ir_framework.shared.TestFormatException: Violations (16) --------------- - Could not find VM flag "UseAVX" in @IR rule 1 at public void compiler.vectorapi.VectorUnsignedMinMaxIRTransformsTest.umin_ir_transform1_byte()
...


Testing tier 1 to 3 with latest PR looks good otherwise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2420845538

From liach at openjdk.org  Thu Oct 17 23:56:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Oct 2024 23:56:54 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <Xc6xPI3k3rN3lj3iBadSM3SOPaojT-WFeT5INFZ6t78=.2f4d0cd4-6566-4e24-81e8-8b7028e35824@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

The `jdk.internal.reflect` changes look good; need other reviewers to review hotspot changes.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2376578713

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 david.holmes at oracle.com  Fri Oct 18 02:08:32 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Oct 2024 12:08:32 +1000
Subject: Is it safe to use LD_PRELOAD to load a custom malloc library when
 running the OpenJDK?
In-Reply-To: <CAKPdV5iLCj_8Vnf3UYiswnLyGttgvrZih9-Md7Y8h96Oa5ivPg@mail.gmail.com>
References: <CAKPdV5iLCj_8Vnf3UYiswnLyGttgvrZih9-Md7Y8h96Oa5ivPg@mail.gmail.com>
Message-ID: <3417f887-0a86-4f84-b091-96b15304c99c@oracle.com>

On 18/10/2024 9:13 am, ?? wrote:
> Hello everyone, hope you're doing well!
> 
> I have a question, and I?m hoping this is the right place to ask. If 
> it's not, I?d appreciate it if someone could point me to the correct 
> mailing list.

Just to be clear these lists are for hotspot developers to use to 
discuss hotspot development, not for end users to ask about running Java.

That said ...

> Our team is heavily using JNI C++ code for computations that involve 
> frequent object allocations and deallocations. To optimize these memory 
> operations, we tested using |jemalloc| as a replacement for |glibc|, and 
> observed huge improvements in performance metrics.
> 
> We're currently using |LD_PRELOAD| to load the |jemalloc| library when 
> launching the JVM, so that all memory allocation and deallocation 
> requests are handled by |jemalloc|. However, I'm wondering if this 
> approach could lead to any unexpected issues, since it would also take 
> the JVM's memory allocation requests as well.
> 
>  From what I understand, heap allocations in the JVM don't use |malloc| 
> directly, as they rely on optimized assembly code or the JVM's internal 
> memory management system. Some folks on the internet have mentioned that 
> the JVM might have a custom |malloc| implementation designed 
> specifically for its use,?preloading jemalloc may cause 
> symbol?conflicts.?However, I haven't been able to find any code 
> supporting that hypothesis.
> 
> *_My question is: is it safe to use |LD_PRELOAD| to load a custom | 
> malloc| library, like |jemalloc|, when running the JVM, at least with 
> OpenJDK?_*

I've heard of numerous people doing this over the years. Hotspot uses 
custom internal allocators, but it doesn't replace the system malloc.

malloc-replacmeent libs like jemalloc sometimes expose bugs that the 
regular system mallocs have hidden ref:

https://bugs.openjdk.org/browse/JDK-8215355

HTH,
David

> 
> 
> Thank you in advance.
> 
> Dooyong Kim
> 


From dholmes at openjdk.org  Fri Oct 18 02:23:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 02:23:02 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
 <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
Message-ID: <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>

On Thu, 17 Oct 2024 08:36:53 GMT, John R Rose <jrose at openjdk.org> wrote:

> I read through it fairly thoroughly. I made a lot of suggestions. Rather than edit comments into lots of spots in this PR, I made the following patch file. [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)


+bool InstanceKlass::is_enum_subclass(bool direct_only) const {
+  InstanceKlass* s = java_super();
+  return (s == vmClasses::Enum_klass() ||
+          (s != null && s->java_super() == vmClasses::Enum_klass()));
+}

Just happened to notice you aren't checking `direct_only`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2421125248

From dholmes at openjdk.org  Fri Oct 18 02:37:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 02:37:40 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Nice cleanup! Great to see all this old code go. Just one mistake ...

Thanks

src/hotspot/share/classfile/classFileParser.cpp line 4098:

> 4096:       }
> 4097:     }
> 4098: 

This code should not be removed. The spec for this code should now be:

  // If the loader is not the boot loader then throw an exception if its
  // superclass is in package jdk.internal.reflect 

All we need do is remove the check:

&& !java_lang_ClassLoader::is_reflection_class_loader

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2376812107
PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1805745905

From fyang at openjdk.org  Fri Oct 18 02:39:46 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 18 Oct 2024 02:39:46 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v15]
In-Reply-To: <wLMksCqRgPQo1f3pZL0RP5cIR7cfIYccv5nOSSR5Cos=.ebd9ce9d-a5c3-4317-b048-661d516e9748@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <H0UdEaVmRv-FYHBmbsB9m_Ahq6qFEmTiTHIOwdRukCw=.eb122863-93c1-4a70-bde3-ecc2c9278010@github.com>
 <CQZHtBe-yqSPZe4Vgre1Op6i7HARa4Vc7H_YXK2xZHo=.f7469399-0c9f-4cea-804f-909c245f0430@github.com>
 <HnWiBs0HyWWs4-qvGv8RV1n8gOK2c0H7tgJX86AmAl8=.bfcf848d-de9e-4ab8-a5d3-420211806dbb@github.com>
 <wqDEYDwnK5zW6IP0_LC2UofuGIwl1X44F75ST9IBjOU=.463c08e4-11cd-4e8d-9ef1-0f7ee6355385@github.com>
 <kxFNj4GXhcr2L1fNcQmIiAeBAcfmoDzBR_9p6rcs460=.3b93690f-f2f1-48d2-b0fb-8ac98cac2c07@github.com>
 <wLMksCqRgPQo1f3pZL0RP5cIR7cfIYccv5nOSSR5Cos=.ebd9ce9d-a5c3-4317-b048-661d516e9748@github.com>
Message-ID: <E_z6R8VFkNwX0f09bFD6yycNniPjRt7Ji4DbzhCpF8o=.5ce5a5cf-ce10-4544-98c2-829729054dbe@github.com>

On Wed, 16 Oct 2024 14:30:29 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Note sure what you mean by "t0 and t1 is reserved from C2".
>> They are not allocatable by register allocator.
>> But C2 think there is RFLAG register (still not allocatable), which we have aliased with x6/t1.
>> This pseudo register will be SOC.
>> Any live SOC should be pushed before a call.
>> 
>> The clobbering we added for CallRuntime/CallDynamicJava is not needed AFAIK, check e.g. x86 it do not kill CR as RFLAG is also set to SOC on x86 (but here backed with a real register).
>
>> Note sure what you mean by "t0 and t1 is reserved from C2". They are not allocatable by register allocator. But C2 think there is RFLAG register (still not allocatable), which we have aliased with x6/t1. This pseudo register will be SOC. Any live SOC should be pushed before a call.
> 
> Yeah, they are not allocatable. That's what I mean by saying they are reserved :-)
> 
>> The clobbering we added for CallRuntime/CallDynamicJava is not needed AFAIK, check e.g. x86 it do not kill CR as RFLAG is also set to SOC on x86 (but here backed with a real register).
> 
> Yes, I also checked other CPU platforms and I think you are right in that these effect of killing CR are unnecessary. Maybe a separate PR to clean them up.

New PR for this cleanup: https://github.com/openjdk/jdk/pull/21576

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21406#discussion_r1805753519

From dholmes at openjdk.org  Fri Oct 18 02:55:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 02:55:37 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS [v3]
In-Reply-To: <iXPc8xUf9J-hOLvnrTIVpPxp2uL8lAJtVzMTPr8nvCk=.a1bcef7e-737a-4483-8c07-bee36cbed00f@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
 <iXPc8xUf9J-hOLvnrTIVpPxp2uL8lAJtVzMTPr8nvCk=.a1bcef7e-737a-4483-8c07-bee36cbed00f@github.com>
Message-ID: <A2Jd4ilK46yWRUePLgXTTA7umLXYwWDdpK7Z7wNjack=.92168bef-e6ea-41f9-9bfa-302a8ed45103@github.com>

On Thu, 17 Oct 2024 14:10:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> 8341444: Unnecessary check for JSRs in CDS
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Further changed comment
>  - Updated comment

Thank you!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21330#pullrequestreview-2376846509

From david.holmes at oracle.com  Fri Oct 18 03:03:25 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Oct 2024 13:03:25 +1000
Subject: Seemingly contradictory code in sharedRuntime.cpp
In-Reply-To: <CAP2b4GOhMHxWFGAar=DtVM9xW7odeM1gHOn=-L7JZPTWjoOU3g@mail.gmail.com>
References: <CAP2b4GOhMHxWFGAar=DtVM9xW7odeM1gHOn=-L7JZPTWjoOU3g@mail.gmail.com>
Message-ID: <5726ad99-c4bf-4c6a-a13e-6d11a572f3d9@oracle.com>

Note that _WIN64 is now also defined for Aarch64

David

On 18/10/2024 1:28 am, Julian Waters wrote:
> Hi all,
> 
> Recently while compiling the Windows JDK, gcc caught a very strange
> case in sharedRuntime.cpp. The SharedRuntime::frem and
> SharedRuntime::drem methods both contain code that is only compiled if
> _WIN64 is defined. The problem is this is then surrounded by an ifndef
> check for X86. HotSpot defines X86 if AMD64 or IA32 is defined. Since
> IA32 is not a supported architecture, only AMD64 is of interest to us
> here. But AMD64 and _WIN64 will always both be defined at the same
> time, as _WIN64 is an AMD64 platform. So by extension, X86 and _WIN64
> will always be defined together. But remember that the Windows
> specific code in frem and drem will only be compiled if X86 is not
> defined and _WIN64 is defined. This means the block of code that is
> guarded by the _WIN64 define is never ever compiled. To add to that,
> sharedRuntime_x86.cpp also contains alternate method definitions for
> SharedRuntime::frem and SharedRuntime::drem. This all leads me to
> believe it is a bug where the code meant for Windows x64 was
> erroneously added to the implementation for non x86 platforms instead
> of the correct one inside sharedRuntime_x86.cpp. I just thought I'd
> give everyone a heads up, and also to confirm that this is indeed a
> bug, before I start working on a fix
> 
> The code in question:
> 
> #if !defined(X86) // <----- This will always be defined if _WIN64 is defined!
> JRT_LEAF(jfloat, SharedRuntime::frem(jfloat x, jfloat y))
> #ifdef _WIN64 // <----- This will always be defined if X86 is defined!
>    // 64-bit Windows on amd64 returns the wrong values for
>    // infinity operands.
>    juint xbits = PrimitiveConversions::cast<juint>(x);
>    juint ybits = PrimitiveConversions::cast<juint>(y);
>    // x Mod Infinity == x unless x is infinity
>    if (((xbits & float_sign_mask) != float_infinity) &&
>         ((ybits & float_sign_mask) == float_infinity) ) {
>      return x;
>    }
>    return ((jfloat)fmod_winx64((double)x, (double)y));
> #else
>    return ((jfloat)fmod((double)x,(double)y));
> #endif
> JRT_END
> 
> JRT_LEAF(jdouble, SharedRuntime::drem(jdouble x, jdouble y))
> #ifdef _WIN64 <----- This will always be defined if X86 is defined!
>    julong xbits = PrimitiveConversions::cast<julong>(x);
>    julong ybits = PrimitiveConversions::cast<julong>(y);
>    // x Mod Infinity == x unless x is infinity
>    if (((xbits & double_sign_mask) != double_infinity) &&
>         ((ybits & double_sign_mask) == double_infinity) ) {
>      return x;
>    }
>    return ((jdouble)fmod_winx64((double)x, (double)y));
> #else
>    return ((jdouble)fmod((double)x,(double)y));
> #endif
> JRT_END
> #endif // !X86
> 
> best regards,
> Julian


From jrose at openjdk.org  Fri Oct 18 03:58:00 2024
From: jrose at openjdk.org (John R Rose)
Date: Fri, 18 Oct 2024 03:58:00 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <FNQ8C8DWodZYnFtwFGGP1bSb1hHwp7QijYYB1tC8vsY=.ee363dee-15f2-4f54-b744-be15d4a326ea@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

This is a most impressive example of C.D.E. (code deletion engineering).

I remember when this was written, as an accelerator for the JNI methods, long long before we had method handles to do the same thing more flexibly.  I think it was Ken Russell that did the work.  And of course I remember Mandy's newer work (3 years ago) fitting method handles into reflection (a move I applauded of course).

As it happens I was just reviewing the reflection implementation this week, to understand its interaction with upcoming Leyden changes to bootstrap sequences.  Of course I wondered, "when will we ever retire this older implementation?"  Happily, that day has come.

Thanks Mandy!

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2376932358

From iklam at openjdk.org  Fri Oct 18 04:08:37 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:08:37 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v9]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <SpnCtAq_0LNu7_emQ-Z1QQtolBtpeb0jkdpnkVhLjVc=.008bae82-a659-446b-85e2-463b65c14e1b@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @rose00 comments -- tighten up the checks for what can or cannot be aot-inited; removed is_trivial_clinit() as it is used only in logging but the meaning is unclear

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/7bab10b2..030cac23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=07-08

  Stats: 543 lines in 16 files changed: 356 ins; 80 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Fri Oct 18 04:11:47 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:11:47 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>

On Tue, 15 Oct 2024 17:03:40 GMT, Dan Heidinga <heidinga 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 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/cds/metaspaceShared.cpp line 873:
> 
>> 871:       Symbol* method_sig = vmSymbols::void_method_signature();
>> 872:       JavaCalls::call_static(&result, vmClasses::Class_klass(),
>> 873:                              method_name, method_sig, CHECK);
> 
> Is this a good candidate for a `runtimeResolve` helper method?  Can we roll it into the same mechanism as the other `runtimeResolve` classes use?

`Class::reflectionFactory` is a large table that must be cleared, or else we will bring unwanted (unsupported) objects into the cache.

During runtime, `reflectionFactory` will be initialized on demand, so there's no need to explicitly create it with `runtimeSetup`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805823385

From fyang at openjdk.org  Fri Oct 18 04:13:26 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 18 Oct 2024 04:13:26 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
Message-ID: <0PA5s2i-oqorkEtn7CzR28vc3vZZIL42Mx4dp2nR2Q0=.86742bb9-0467-45cf-98db-62426f6eebde@github.com>

On Thu, 17 Oct 2024 13:44:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated UEP pretty print with t1

Latest version LGTM. Thanks for fixing this!

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21406#pullrequestreview-2376943569

From iklam at openjdk.org  Fri Oct 18 04:19:29 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:19:29 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v9]
In-Reply-To: <SpnCtAq_0LNu7_emQ-Z1QQtolBtpeb0jkdpnkVhLjVc=.008bae82-a659-446b-85e2-463b65c14e1b@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SpnCtAq_0LNu7_emQ-Z1QQtolBtpeb0jkdpnkVhLjVc=.008bae82-a659-446b-85e2-463b65c14e1b@github.com>
Message-ID: <lO25avhbfpA3fo8Giwg_6AauA-4cJwXQzIWgR5hrSi4=.3e5b67e1-e0f6-4aa8-b2bb-19b6884029bc@github.com>

On Fri, 18 Oct 2024 04:08:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @rose00 comments -- tighten up the checks for what can or cannot be aot-inited; removed is_trivial_clinit() as it is used only in logging but the meaning is unclear

> I read through it fairly thoroughly. I made a lot of suggestions. Rather than edit comments into lots of spots in this PR, I made the following patch file. [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)
> 
> The first lines of the patch file state which revision the patch applies to, which is [4be6a25](https://github.com/openjdk/jdk/commit/4be6a255cdd300bb6e15ded1dc163b00cd24dbd8) from Tuesday.

Hi John,

Thank you so much for the code. I have merged most of your diffs into the PR. There are a few items left which I will go over tomorrow. I simplified the `InstanceKlass::interface_needs_clinit_execution_as_super()` as I don't need to check against non-interface classes, so I worry about adding code that's not used by this JEP.

I also moved the `InstanceKlass::assert_no_clinit_will_run_for_aot_initialized_class()` function to be closed to `InstanceKlass::initialize_with_aot_initialized_mirror()` -- the latter has been simplified as we would never need to take the "quicker path" from the previous version of the code.

I also cleaned up the "firewall" check in `mark_for_aot_initialization()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2421300475

From iklam at openjdk.org  Fri Oct 18 04:22:09 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:22:09 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <-gsu1c1EwtLH2w22G9YTdmEPXoGLIYTCdGIH8MrcL2M=.b62cd88d-edf7-4b9a-926d-79570d1cd2c4@github.com>

On Tue, 15 Oct 2024 15:19:36 GMT, Dan Heidinga <heidinga 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 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/cds/heapShared.cpp line 1140:
> 
>> 1138:       return false;
>> 1139:     }
>> 1140:   }
> 
> This is conservatively correct in that it checks all implemented interfaces.  We could be less conservative and only check interfaces that have a "non-abstract non-static" (aka default) method as those are the interfaces that will be initialized along with the class as per JVMS 5.5

I've removed this function altogether. It was used in logging only, and it wasn't clear what the output meant (w.r.t to interfaces that have non-trivial <clinit>). I think it's best to remove this function, and implement it properly in a future RFE that automatically aot-init all classes that can be initialized with no observable side effects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805829136

From iklam at openjdk.org  Fri Oct 18 04:28:06 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:28:06 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
Message-ID: <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>

On Wed, 16 Oct 2024 01:26:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:
>> 
>>> 233: }
>>> 234: 
>>> 235: // TODO -- is this really correct? Do we need a special ClassLoaderData for each hidden class?
>> 
>> There are multiple kinds of hidden classes: 
>> * default ones which can be unloaded immediately when no longer referenced
>> * MHs.Lookup.ClassOption::STRONG which are associated with their defining loader and can only be unloaded when that loader is unloaded.
>> 
>> I think we need special ClassLoaderData for the non-strong (default) hidden classes
>
> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've added a comment and tightened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

(I've replied to this comment. I can see it in the mailing list but it seems to be lost on this page, so I'll add it again)

We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've updated the comment and tghtened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805831730

From tanksherman27 at gmail.com  Fri Oct 18 04:49:57 2024
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 18 Oct 2024 12:49:57 +0800
Subject: Seemingly contradictory code in sharedRuntime.cpp
Message-ID: <CAP2b4GPNZ0aspH=QmDdkkSKjVhoETW6jGr18JcXC55DhSvzXPg@mail.gmail.com>

Hi David,

Thanks for pointing that out. This means that something interesting is
happening, as the code that is protected by the ifdef block has a
comment suggesting that it is solely meant for Windows x64, and not
any 64 bit Windows platform that could include ARM64. This possibly
means that the ARM64 implementation is using the x64 implementation,
with unknown consequences

best regards,
Julian

From liach at openjdk.org  Fri Oct 18 05:42:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 05:42:50 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
 <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>
Message-ID: <bawYxEbNMLLsVKFAcdwD3Bu_Zoc1_5w0kpIU8OJB9D4=.21544e14-d107-49bf-9d00-afa56b6bf63d@github.com>

On Fri, 18 Oct 2024 04:09:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/metaspaceShared.cpp line 873:
>> 
>>> 871:       Symbol* method_sig = vmSymbols::void_method_signature();
>>> 872:       JavaCalls::call_static(&result, vmClasses::Class_klass(),
>>> 873:                              method_name, method_sig, CHECK);
>> 
>> Is this a good candidate for a `runtimeResolve` helper method?  Can we roll it into the same mechanism as the other `runtimeResolve` classes use?
>
> `Class::reflectionFactory` is a large table that must be cleared, or else we will bring unwanted (unsupported) objects into the cache.
> 
> During runtime, `reflectionFactory` will be initialized on demand, so there's no need to explicitly create it with `runtimeSetup`.

That said, can reflectionFactory field be stable in the future with this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805889297

From david.holmes at oracle.com  Fri Oct 18 06:33:54 2024
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Oct 2024 16:33:54 +1000
Subject: Seemingly contradictory code in sharedRuntime.cpp
In-Reply-To: <CAP2b4GPNZ0aspH=QmDdkkSKjVhoETW6jGr18JcXC55DhSvzXPg@mail.gmail.com>
References: <CAP2b4GPNZ0aspH=QmDdkkSKjVhoETW6jGr18JcXC55DhSvzXPg@mail.gmail.com>
Message-ID: <d886b811-aa7c-450f-91de-e451d6e9c00d@oracle.com>

On 18/10/2024 2:49 pm, Julian Waters wrote:
> Hi David,
> 
> Thanks for pointing that out. This means that something interesting is
> happening, as the code that is protected by the ifdef block has a
> comment suggesting that it is solely meant for Windows x64, and not
> any 64 bit Windows platform that could include ARM64. This possibly
> means that the ARM64 implementation is using the x64 implementation,
> with unknown consequences

Possibly ... but cpu/aarch64/c1_LIRGenerator_aarch64.cpp sets up the 
called to SharedRuntime::frem so I think it is okay. I'm assuming the 
folk that did the Windows Aarch64 port would have looked at this.

Looking at:

https://bugs.openjdk.org/browse/JDK-8302191

which introduced the original set of ifdefs:

1. The original frem was unconditionally used for all platforms

2. They added an x86 specific version in sharedRuntime_x86.cpp:

#if defined(TARGET_COMPILER_gcc) && !defined(_WIN64)
JRT_LEAF(jfloat, SharedRuntime::frem(jfloat x, jfloat y))

which loosely implies it would be used for 32-bit or 64-bit Linux (as 
other platforms don't use gcc by default, and for some reason WIN64 was 
explicitly listed).

3. So they guarded the shared version by the inverse: not x86, or !gcc, 
or else WIN64 - which seems correct as far as it goes.

But then https://bugs.openjdk.org/browse/JDK-8314056

1. Made the x86 version unconditional - i.e. now used for all 32-bit and 
64-bit x86 platforms

2. So they removed the additional ifdefs from the shared version so that 
it was now only for !X86.

That also seems correct in isolation, but that then leaves the _WIN64 
ifdef'd code within the shared version as dead code from a Windows 
x86_64 perspective. But it is still used for Windows Aarch64 ... which 
is possibly harmless, but I doubt this actually applies:

  // 64-bit Windows on amd64 returns the wrong values for
  // infinity operands.

so potentially Windows Aarch64 may be able to use "better" code?

Anyway - good find!

Cheers,
David

> best regards,
> Julian


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 cnorrbin at openjdk.org  Fri Oct 18 09:52:50 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 18 Oct 2024 09:52:50 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <nuqK3YSBCQ9vLOflaYTdPcA98XLWchv6qmz3UJWLcJE=.b248e733-4fe0-4131-ab38-3822a6b15ad9@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
 <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
 <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>
 <m7ivLHEBzBJP3FLAH8_t2i6TUh__NJ52o9jg8EnCO1Y=.724de800-eb68-454e-9d74-dff62a5c170e@github.com>
 <nuqK3YSBCQ9vLOflaYTdPcA98XLWchv6qmz3UJWLcJE=.b248e733-4fe0-4131-ab38-3822a6b15ad9@github.com>
Message-ID: <TS3WtUnCzjV24OA-yBq5cE8Y5xgSd2XnaF6BhAeCLP0=.d8aeb660-43d1-4604-a31b-502d3789a99e@github.com>

On Wed, 16 Oct 2024 21:24:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The `len` in all these methods is the number of unicode characters, which yes, could be less than the length of the UTF8 array.
>> 
>> ---
>> 
>> `UTF8::convert_to_unicode` uses `UTF8::next`, like I also do in the new UTF8 equals/hash functions. Part of `UTF8::next` looks like this: 
>> 
>> ```c++
>>   switch ((ch = ptr[0]) >> 4) {
>>     default:
>>     ... work ... /* 1-byte character */
>>     break;
>> 
>>   case 0x8: case 0x9: case 0xA: case 0xB: case 0xF:
>>     /* Shouldn't happen. */
>>     break;
>> 
>>   case 0xC: case 0xD:
>>     /* 110xxxxx  10xxxxxx */
>>     ... work ... /* 2-byte character */
>>     break;
>> 
>>   case 0xE:
>>     /* 1110xxxx 10xxxxxx 10xxxxxx */
>>     ... work ... /* 3-byte character */
>>     break;
>>   } /* end of switch */
>> 
>> 
>> In this code, 4-byte long UTF8 characters are not converted. This leads me to believe that we do not support this range of characters. Or that we at least do not support it encoded in UTF8. With this restriction, we also do not have 2 wide (4 byte) UTF16 characters, as 3-byte UTF8 characters fit in a single (2 byte) UTF16 unit.
>> 
>> So for the question, I do not know what would happen. I believe it would be undefined behaviour as this character would not be supported encoded in UTF8. Just like if we would use `UTF8::convert_to_unicode` first to then compare two UTF16 strings.
>
> @caspernorrbin - Aarggh! Sorry I picked a bad example - the JVM uses modified-UTF8 which does not support 4-byte UTF8 encodings. Any UTF16 surrogate pair would be encoded as two three-byte modifed-UTF8 sequences.
> 
>> The len in all these methods is the number of unicode characters
> 
> Are you sure you meant "characters" there?
> 
> Let me try to back up a bit and go to the code that I have a problem with:
> 
> bool java_lang_String::equals(oop java_string, const char* utf8_string, int num_unicode_points) {
>   assert(java_string->klass() == vmClasses::String_klass(),
>          "must be java_string");
>   typeArrayOop value = java_lang_String::value_no_keepalive(java_string);
>   int length = java_lang_String::length(java_string, value);
>   if (length != num_unicode_points) {
>     return false;
>   }
> 
> The incoming String represents a single unicode character encoded as a surrogate pair - so `length == 2`. Each element in the surrogate pairs encodes as a 3-byte modified-UTF8 sequence, so the length of `utf8_string` is 6. For the length check to pass the incoming value of `num_unicode_points` has to be 2. So for this to succeed the caller always has to pass in the number of UTF16 elements that comprise the `java_string`. As Johan noted in the utf8.cpp file when it refers to "unicode" it really means UTF16, so in that sense `num_unicode_points` is not incorrect.  But it means those `len` parameters should also be named the same way.

You're right, I meant the number of code points..

The `num_unicode_points` in this case would come from `UTF8::unicode_length`, which would give 2 from the 6-byte UTF8 string in your example. But I agree that it is somewhat unclear, especially if someone were to use this function in the future.

I have two ideas how this could be improved:
I could either add clarifying comments and change naming across the different functions to be clearer on how to use and call correctly. Or I could instead change it so that the function takes the UTF8-length instead of the UTF16-length. That way you always pass the array length to the function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1806218904

From alanb at openjdk.org  Fri Oct 18 10:09:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 10:09:16 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <_zMUWasnrrO1r3Tuxvqb3YG_2lcidmqlXlF0GT5QiRI=.091fec45-32fc-4438-9159-6928922e3e63@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Good cleanup. 

I searched the tests as I expected to find some tests exercising -Djdk.reflect.useOldSerializableConstructor but nothing found.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2377641911

From jsjolen at openjdk.org  Fri Oct 18 11:41:15 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 18 Oct 2024 11:41:15 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <TS3WtUnCzjV24OA-yBq5cE8Y5xgSd2XnaF6BhAeCLP0=.d8aeb660-43d1-4604-a31b-502d3789a99e@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
 <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
 <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>
 <m7ivLHEBzBJP3FLAH8_t2i6TUh__NJ52o9jg8EnCO1Y=.724de800-eb68-454e-9d74-dff62a5c170e@github.com>
 <nuqK3YSBCQ9vLOflaYTdPcA98XLWchv6qmz3UJWLcJE=.b248e733-4fe0-4131-ab38-3822a6b15ad9@github.com>
 <TS3WtUnCzjV24OA-yBq5cE8Y5xgSd2XnaF6BhAeCLP0=.d8aeb660-43d1-4604-a31b-502d3789a99e@github.com>
Message-ID: <nV2U05cGdLMHBbkxMqNEMaufQu7oLGmMLlYs23g4bjc=.4f40dc12-3adf-4231-b671-6f96e8ab48ac@github.com>

On Fri, 18 Oct 2024 09:49:19 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> @caspernorrbin - Aarggh! Sorry I picked a bad example - the JVM uses modified-UTF8 which does not support 4-byte UTF8 encodings. Any UTF16 surrogate pair would be encoded as two three-byte modifed-UTF8 sequences.
>> 
>>> The len in all these methods is the number of unicode characters
>> 
>> Are you sure you meant "characters" there?
>> 
>> Let me try to back up a bit and go to the code that I have a problem with:
>> 
>> bool java_lang_String::equals(oop java_string, const char* utf8_string, int num_unicode_points) {
>>   assert(java_string->klass() == vmClasses::String_klass(),
>>          "must be java_string");
>>   typeArrayOop value = java_lang_String::value_no_keepalive(java_string);
>>   int length = java_lang_String::length(java_string, value);
>>   if (length != num_unicode_points) {
>>     return false;
>>   }
>> 
>> The incoming String represents a single unicode character encoded as a surrogate pair - so `length == 2`. Each element in the surrogate pairs encodes as a 3-byte modified-UTF8 sequence, so the length of `utf8_string` is 6. For the length check to pass the incoming value of `num_unicode_points` has to be 2. So for this to succeed the caller always has to pass in the number of UTF16 elements that comprise the `java_string`. As Johan noted in the utf8.cpp file when it refers to "unicode" it really means UTF16, so in that sense `num_unicode_points` is not incorrect.  But it means those `len` parameters should also be named the same way.
>
> You're right, I meant the number of code points..
> 
> The `num_unicode_points` in this case would come from `UTF8::unicode_length`, which would give 2 from the 6-byte UTF8 string in your example. But I agree that it is somewhat unclear, especially if someone were to use this function in the future.
> 
> I have two ideas how this could be improved:
> I could either add clarifying comments and change naming across the different functions to be clearer on how to use and call correctly. Or I could instead change it so that the function takes the UTF8-length instead of the UTF16-length. That way you always pass the array length to the function.

I just want consistency and clarity in the header prototypes, for me either option is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1806353639

From duke at openjdk.org  Fri Oct 18 12:15:46 2024
From: duke at openjdk.org (Mikhail Ablakatov)
Date: Fri, 18 Oct 2024 12:15:46 GMT
Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64
 [v2]
In-Reply-To: <ODsEMY4wzwbAqSzmlxvkydX7hYcec6s0e8ylx1jCEug=.f1686001-bbeb-4703-8d1e-a15ff016fc33@github.com>
References: <I7PDj30Q0O8N-IyPJkNK8Dp5LSN190vn3KbPGXuodKM=.d5b4c653-240f-4931-be3d-063dbe2d8dfa@github.com>
 <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com>
 <WZIP8OwfSX0-oxfQ7brEqgxcvjNOw7HGmVRmsLUhyiU=.464f8c5d-a39d-43e2-90d1-b554d42ad15c@github.com>
 <ODsEMY4wzwbAqSzmlxvkydX7hYcec6s0e8ylx1jCEug=.f1686001-bbeb-4703-8d1e-a15ff016fc33@github.com>
Message-ID: <R81VOkruNieFxKE_NzLTnOXvpWZ3i9GBPLT5m2JuGXg=.416704ff-e191-415e-838e-bcf540bc2057@github.com>

On Tue, 8 Oct 2024 09:42:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well.
>
>> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well.
> 
> I'm not sure we could do _much_ better. A great advantage of using a macro is that it enforces consistent naming across the stub and the inlined code.

@theRealAph , could you check this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21286#discussion_r1806394404

From tanksherman27 at gmail.com  Fri Oct 18 12:43:46 2024
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 18 Oct 2024 20:43:46 +0800
Subject: Seemingly contradictory code in sharedRuntime.cpp
In-Reply-To: <d886b811-aa7c-450f-91de-e451d6e9c00d@oracle.com>
References: <CAP2b4GPNZ0aspH=QmDdkkSKjVhoETW6jGr18JcXC55DhSvzXPg@mail.gmail.com>
 <d886b811-aa7c-450f-91de-e451d6e9c00d@oracle.com>
Message-ID: <CAP2b4GO-pNYgUCYvbEi5z=ZeOQgUzm2r34vJfBWrvhLG-LQmsA@mail.gmail.com>

Hi David,

Great analysis! That certainly helped clear things up a lot. I wonder
if there are any Windows ARM64 maintainers that we could flag down to
ask about this. The only maintainer of that port that I know of is
Monica (At least I remember she's one of the maintainers)

best regards,
Julian

On Fri, Oct 18, 2024 at 2:34?PM David Holmes <david.holmes at oracle.com> wrote:
>
> On 18/10/2024 2:49 pm, Julian Waters wrote:
> > Hi David,
> >
> > Thanks for pointing that out. This means that something interesting is
> > happening, as the code that is protected by the ifdef block has a
> > comment suggesting that it is solely meant for Windows x64, and not
> > any 64 bit Windows platform that could include ARM64. This possibly
> > means that the ARM64 implementation is using the x64 implementation,
> > with unknown consequences
>
> Possibly ... but cpu/aarch64/c1_LIRGenerator_aarch64.cpp sets up the
> called to SharedRuntime::frem so I think it is okay. I'm assuming the
> folk that did the Windows Aarch64 port would have looked at this.
>
> Looking at:
>
> https://bugs.openjdk.org/browse/JDK-8302191
>
> which introduced the original set of ifdefs:
>
> 1. The original frem was unconditionally used for all platforms
>
> 2. They added an x86 specific version in sharedRuntime_x86.cpp:
>
> #if defined(TARGET_COMPILER_gcc) && !defined(_WIN64)
> JRT_LEAF(jfloat, SharedRuntime::frem(jfloat x, jfloat y))
>
> which loosely implies it would be used for 32-bit or 64-bit Linux (as
> other platforms don't use gcc by default, and for some reason WIN64 was
> explicitly listed).
>
> 3. So they guarded the shared version by the inverse: not x86, or !gcc,
> or else WIN64 - which seems correct as far as it goes.
>
> But then https://bugs.openjdk.org/browse/JDK-8314056
>
> 1. Made the x86 version unconditional - i.e. now used for all 32-bit and
> 64-bit x86 platforms
>
> 2. So they removed the additional ifdefs from the shared version so that
> it was now only for !X86.
>
> That also seems correct in isolation, but that then leaves the _WIN64
> ifdef'd code within the shared version as dead code from a Windows
> x86_64 perspective. But it is still used for Windows Aarch64 ... which
> is possibly harmless, but I doubt this actually applies:
>
>   // 64-bit Windows on amd64 returns the wrong values for
>   // infinity operands.
>
> so potentially Windows Aarch64 may be able to use "better" code?
>
> Anyway - good find!
>
> Cheers,
> David
>
> > best regards,
> > Julian
>

From matsaave at openjdk.org  Fri Oct 18 13:28:03 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 18 Oct 2024 13:28:03 GMT
Subject: RFR: 8341444: Unnecessary check for JSRs in CDS [v3]
In-Reply-To: <A2Jd4ilK46yWRUePLgXTTA7umLXYwWDdpK7Z7wNjack=.92168bef-e6ea-41f9-9bfa-302a8ed45103@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
 <iXPc8xUf9J-hOLvnrTIVpPxp2uL8lAJtVzMTPr8nvCk=.a1bcef7e-737a-4483-8c07-bee36cbed00f@github.com>
 <A2Jd4ilK46yWRUePLgXTTA7umLXYwWDdpK7Z7wNjack=.92168bef-e6ea-41f9-9bfa-302a8ed45103@github.com>
Message-ID: <5aglZm5SKAsqGfuqciLYueY99Jem2wbG49QsmGyBoKM=.387f62df-e778-433c-ac05-9c5baf6443a6@github.com>

On Fri, 18 Oct 2024 02:52:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Further changed comment
>>  - Updated comment
>
> Thank you!

Thanks for the reviews @dholmes-ora and @coleenp!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21330#issuecomment-2422469079

From matsaave at openjdk.org  Fri Oct 18 13:28:05 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 18 Oct 2024 13:28:05 GMT
Subject: Integrated: 8341444: Unnecessary check for JSRs in CDS
In-Reply-To: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
References: <DhzgmaiCcSfDD5pGgxTgP_6Ht1qxKLS3JmFsV_gLRHA=.ee5baf3e-3740-4de3-ad71-101b05772b7f@github.com>
Message-ID: <rHe2nuMLlDGomZS98qQoySYdVuNFmVxjTlfySgUPM_I=.73cfef06-3e36-4d53-a745-309498b05a7f@github.com>

On Thu, 3 Oct 2024 17:45:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> 8341444: Unnecessary check for JSRs in CDS

This pull request has now been integrated.

Changeset: 28252bb4
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28252bb48da3c960a1a261af26650d74235a9531
Stats:     21 lines in 2 files changed: 0 ins; 16 del; 5 mod

8341444: Unnecessary check for JSRs in CDS

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/21330

From jbhateja at openjdk.org  Fri Oct 18 14:56:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 14:56:29 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Replacing flag based checks with CPU feature checks in IR validation test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/3ee0de07..dacc9313

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=28-29

  Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From heidinga at openjdk.org  Fri Oct 18 14:59:54 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 18 Oct 2024 14:59:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
Message-ID: <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>

On Fri, 18 Oct 2024 04:24:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've added a comment and tightened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)
>
> (I've replied to this comment. I can see it in the mailing list but it seems to be lost on this page, so I'll add it again)
> 
> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've updated the comment and tghtened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

I looked at the InnerClassLambdaMetaFactory and it only generates MHs.Lookup.ClassOption::STRONG classes that live as long as their corresponding loaders.  Given that, do we want an assert here that we are only dealing with strong hidden classes?  ie: `assert(ik->is_hidden() && !ik->is_non_strong_hidden());`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806644336

From fgao at openjdk.org  Fri Oct 18 15:03:46 2024
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 18 Oct 2024 15:03:46 GMT
Subject: RFR: 8337536: AArch64: Enable BTI branch protection for runtime
 part [v3]
In-Reply-To: <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
 <7JRzzIvH26CZPYCX76eWBbQSYUhMDnOqRufDtWaIXq8=.d3270022-4933-4fa7-828a-f57dbc5b8a46@github.com>
Message-ID: <T0dytb6zpyPhQIq7_SYHCQvzEPAR3ZWdzTiMqsgPc6I=.b9291b96-d058-451b-90c0-2e0203884b7e@github.com>

On Thu, 15 Aug 2024 15:32:28 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
>> 
>> Motivation
>> 
>> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
>> 
>> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
>> 
>> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
>> 
>> 
>>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>> 
>> 
>> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
>> 
>> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
>> 
>> Goal
>> 
>> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
>> 
>> Implementation
>> 
>> Task-1: find out the problematic input objects
>> 
>> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
>> 
>> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
>> 
>> 
>>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
>> 
>> 
>> Task-2: add `.note.gnu.property` section for these assembly files
>> 
>> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
>> 
>> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update i...
>
> Fei Gao 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:
> 
>  - Fix indentation
>  - Merge branch 'master' into enable-bti-runtime
>  - Clean up makefile
>  - Merge branch 'master' into enable-bti-runtime
>  - 8337536: AArch64: Enable BTI branch protection for runtime part
>    
>    This patch enables BTI branch protection for runtime part on
>    Linux/aarch64 platform.
>    
>    Motivation
>    
>    1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default.
>    User-level packages can gain additional hardening by compiling with the
>    GCC/Clang flag `-mbranch-protection=flag`. See [1].
>    
>    2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as
>    one VM configure flag, which would pass `-mbranch-protection=standard`
>    compilation flags to all c/c++ files. Note that `standard` turns on both
>    `pac-ret` and `bti` branch protections. For more details about code
>    reuse attacks and hardware-assisted branch protections on AArch64, see
>    [3].
>    
>    However, we checked the `.note.gnu.property` section of all the shared
>    libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so
>    didn't set these two target feature bits:
>    
>    ```
>      GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>      GNU_PROPERTY_AARCH64_FEATURE_1_PAC
>    ```
>    
>    Note-1: BTI is an all or nothing property for a link unit [4]. That is,
>    libjvm.so is not BTI-enabled.
>    
>    Note-2: PAC bit in `.note.gnu.property` section is used to protect
>    `.got.plt` table. It's independent of whether the relocatable objects
>    use PAC or not.
>    
>    Goal
>    
>    Hence, this patch aims to set PAC/BTI feature bits of the
>    `.note.gnu.property` section for libjvm.so.
>    
>    Implementation
>    
>    Task-1: find out the problematic input objects
>    
>    From [5], "Static linkers processing ELF relocatable objects must set
>    the feature bit in the output object or image only if all the input
>    objects have the corresponding feature bit set." Hence we suspect that
>    the root cause is probably that the PAC/BTI feature bits are not set
>    only for some input objects of libjvm.so.
>    
>    In order to find out these inputs, we passed `--force-bti` linker flag
>    [4] in my local test. This linker flag would warn if any input object
>    does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following
>    list:
>    
>  ...

I tested this PR based on latest JDK. Results are still good.

Thanks for all your reviews and approvals @magicus @theRealAph @e1iu @erikj79 .

I'll integrate it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20491#issuecomment-2422676849

From fgao at openjdk.org  Fri Oct 18 15:03:46 2024
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 18 Oct 2024 15:03:46 GMT
Subject: Integrated: 8337536: AArch64: Enable BTI branch protection for runtime
 part
In-Reply-To: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
References: <GLnWnEyDlgw9kfj7C_8YLTGNnRRjgM1wmmpAfViyHqg=.d0bc9b15-ea8c-4159-abd8-275b2a343322@github.com>
Message-ID: <q4mwIAPhwP8GvriVPlH_WgZwvnbdusCv82reu4ggnSE=.e233a2b2-4944-45a8-870c-be813c41d512@github.com>

On Wed, 7 Aug 2024 10:40:09 GMT, Fei Gao <fgao at openjdk.org> wrote:

> This patch enables BTI branch protection for runtime part on Linux/aarch64 platform.
> 
> Motivation
> 
> 1. Since Fedora 33, glibc+kernel are PAC/BTI enabled by default. User-level packages can gain additional hardening by compiling with the GCC/Clang flag `-mbranch-protection=flag`. See [1].
> 
> 2. In JDK-8277204 [2], `--enable-branch-protection` was introduced as one VM configure flag, which would pass `-mbranch-protection=standard` compilation flags to all c/c++ files. Note that `standard` turns on both `pac-ret` and `bti` branch protections. For more details about code reuse attacks and hardware-assisted branch protections on AArch64, see [3].
> 
> However, we checked the `.note.gnu.property` section of all the shared libraries under `jdk/lib` on Fedora 40, and found that only libjvm.so didn't set these two target feature bits:
> 
> 
>   GNU_PROPERTY_AARCH64_FEATURE_1_BTI
>   GNU_PROPERTY_AARCH64_FEATURE_1_PAC
> 
> 
> Note-1: BTI is an all or nothing property for a link unit [4]. That is, libjvm.so is not BTI-enabled.
> 
> Note-2: PAC bit in `.note.gnu.property` section is used to protect `.got.plt` table. It's independent of whether the relocatable objects use PAC or not.
> 
> Goal
> 
> Hence, this patch aims to set PAC/BTI feature bits of the `.note.gnu.property` section for libjvm.so.
> 
> Implementation
> 
> Task-1: find out the problematic input objects
> 
> From [5], "Static linkers processing ELF relocatable objects must set the feature bit in the output object or image only if all the input objects have the corresponding feature bit set." Hence we suspect that the root cause is probably that the PAC/BTI feature bits are not set only for some input objects of libjvm.so.
> 
> In order to find out these inputs, we passed `--force-bti` linker flag [4] in my local test. This linker flag would warn if any input object does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI. We got the following list:
> 
> 
>   src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
>   src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
> 
> 
> Task-2: add `.note.gnu.property` section for these assembly files
> 
> As mentioned in Motivation-2 part, `-mbranch-protection=standard` is passed to compile c/c++ files but these assembly files are missed.
> 
> In this patch, we also pass `-mbranch-protection=standard` flag to assembler (See the update in flags-cflags.m4 and flags-other.m4), and add `.note.gnu.property` section at the end...

This pull request has now been integrated.

Changeset: 4dcc7f3f
Author:    Fei Gao <fgao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4dcc7f3f2629e857b20f72e99189db8781aa65ff
Stats:     220 lines in 8 files changed: 191 ins; 5 del; 24 mod

8337536: AArch64: Enable BTI branch protection for runtime part

Co-authored-by: Hao Sun <haosun at openjdk.org>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: aph, ihse, erikj, eliu

-------------

PR: https://git.openjdk.org/jdk/pull/20491

From liach at openjdk.org  Fri Oct 18 15:36:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 15:36:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
 <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
Message-ID: <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>

On Fri, 18 Oct 2024 14:56:23 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> (I've replied to this comment. I can see it in the mailing list but it seems to be lost on this page, so I'll add it again)
>> 
>> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've updated the comment and tghtened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)
>
> I looked at the InnerClassLambdaMetaFactory and it only generates MHs.Lookup.ClassOption::STRONG classes that live as long as their corresponding loaders.  Given that, do we want an assert here that we are only dealing with strong hidden classes?  ie: `assert(ik->is_hidden() && !ik->is_non_strong_hidden());`

This is correct for the LMF, but I think we are using weak hidden classes in string concatenation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806691703

From coleenp at openjdk.org  Fri Oct 18 16:21:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 18 Oct 2024 16:21:11 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
Message-ID: <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>

On Fri, 18 Oct 2024 02:25:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused classes
>
> src/hotspot/share/classfile/classFileParser.cpp line 4098:
> 
>> 4096:       }
>> 4097:     }
>> 4098: 
> 
> This code should not be removed. The spec for this code should now be:
> 
>   // If the loader is not the boot loader then throw an exception if its
>   // superclass is in package jdk.internal.reflect 
> 
> All we need do is remove the check:
> 
> && !java_lang_ClassLoader::is_reflection_class_loader

Oh that's a good find.  Maybe we should write a test for this, if as I assume there isn't one already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1806742713

From psandoz at openjdk.org  Fri Oct 18 16:55:05 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 18 Oct 2024 16:55:05 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <sWXg913xsqvSuL3EiMoZqRwF0Hpro4lUdhZ1tP4LyXA=.e8330ff5-57d8-40e5-afdf-a088bf63be7d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
 <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
 <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>
 <sWXg913xsqvSuL3EiMoZqRwF0Hpro4lUdhZ1tP4LyXA=.e8330ff5-57d8-40e5-afdf-a088bf63be7d@github.com>
Message-ID: <xQwDLIoLtbOsbKokEYjRD4RVbj2WiTf_yF8rhlRM4ko=.52c9eebc-d760-4450-b9ce-17700c57b1da@github.com>

On Thu, 17 Oct 2024 23:35:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > I have restricted the IR validation to just newly added UMin/UMax transformations.
> 
> Even then i think it better to do so in follow on PR, otherwise it is a moving target for review and testing. This new test fails on aarch64 e.g.,
> 
> ```
> STATUS:Failed.`main' threw exception: compiler.lib.ir_framework.shared.TestFormatException: Violations (16) --------------- - Could not find VM flag "UseAVX" in @IR rule 1 at public void compiler.vectorapi.VectorUnsignedMinMaxIRTransformsTest.umin_ir_transform1_byte()
> ...
> ```
> 
> Testing tier 1 to 3 with latest PR looks good otherwise.

The updated test passes with latest changes. You will need a HotSpot re-review including the new test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2422875427

From xlinzheng at openjdk.org  Fri Oct 18 16:55:34 2024
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Fri, 18 Oct 2024 16:55:34 GMT
Subject: RFR: 8296448: RISC-V: Fix temp usages of heapbase register killed
 by MacroAssembler::en/decode_klass_not_null [v2]
In-Reply-To: <XMRWf9A3CpKk73DIEilmZ3qXvK2HQtU9sqWL0CdPhVM=.7eccbad2-2bc0-4026-906e-2152823aff0c@github.com>
References: <7NJqWAajnAuuq1Udf6GT8JeGZdNgBxWGASX0P8HhZE8=.9e7f7b23-3f6a-4954-91a0-d6a7ac123319@github.com>
 <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
 <XMRWf9A3CpKk73DIEilmZ3qXvK2HQtU9sqWL0CdPhVM=.7eccbad2-2bc0-4026-906e-2152823aff0c@github.com>
Message-ID: <hjNgRjPvOrOJkwEj6qnY3kfnpc2JvmW_BcuKR7vhLeE=.968cc2b7-cbe0-454b-a12b-045f93b2e4dd@github.com>

On Thu, 17 Oct 2024 09:09:42 GMT, Andreas Schwab <duke at openjdk.org> wrote:

> There is a potential conflict with the use of t0 in decode_klass_not_null:
> 
> ```
> assert_different_registers(t0, xbase);
> ```
> 
> since tmp in load_klass defaults to t0.

Thank you for pointing this out. Yes, code here in `MacroAssembler::decode_klass_not_null` seems to have a potential issue. But in reality I assume it is dead code.


// In MacroAssembler::decode_klass_not_null()
//  -> CompressedKlassPointers::base() is non-null also when reaching here
if (CompressedKlassPointers::shift() != 0) {
    assert(LogKlassAlignmentInBytes == CompressedKlassPointers::shift(), "decode alg wrong");
    assert_different_registers(t0, xbase);
    shadd(dst, src, xbase, t0, LogKlassAlignmentInBytes);
}

As per Thomas' clear comments here [1], `base > 0 && shift > 0` should not happen. Perhaps we can perform some cleanup here to remove unreachable code that causes confusion. Maybe something like https://github.com/zhengxiaolinX/jdk/commit/973a071e51d116909b9713e52850b4990c025183.

But it is untested due to a lack of resources, so waiting for someone kind to take it over.

BTW the current PR (11010) is still needed because the heapbase register should not be used as a temp register here.

Hope this can explain well.

Best,
Xiaolin


[1] https://github.com/openjdk/jdk/blob/4dcc7f3f2629e857b20f72e99189db8781aa65ff/src/hotspot/share/oops/compressedKlass.cpp#L103-L104

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11010#issuecomment-2422874709

From mchung at openjdk.org  Fri Oct 18 16:58:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Oct 2024 16:58:07 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
Message-ID: <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>

On Fri, 18 Oct 2024 16:17:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 4098:
>> 
>>> 4096:       }
>>> 4097:     }
>>> 4098: 
>> 
>> This code should not be removed. The spec for this code should now be:
>> 
>>   // If the loader is not the boot loader then throw an exception if its
>>   // superclass is in package jdk.internal.reflect 
>> 
>> All we need do is remove the check:
>> 
>> && !java_lang_ClassLoader::is_reflection_class_loader
>
> Oh that's a good find.  Maybe we should write a test for this, if as I assume there isn't one already.
> Edit: not with this RFE, just in general.

> // If the loader is not the boot loader then throw an exception if its
> // superclass is in package jdk.internal.reflect

This will never happen.   `jdk.internal.reflect` is a non-exported package in `java.base` module.  If another module `M` defines a class whose superclass is in `jdk.internal.reflect` package, `java.base` must export `jdk.internal.reflect` package to `M` for access.   Otherwise, it will fail the super access check, as done in the check below this deleted code.


Reflection::VerifyClassAccessResults vca_result =
     Reflection::verify_class_access(this_klass, InstanceKlass::cast(super), false);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1806781954

From mchung at openjdk.org  Fri Oct 18 17:00:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Oct 2024 17:00:45 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <FNQ8C8DWodZYnFtwFGGP1bSb1hHwp7QijYYB1tC8vsY=.ee363dee-15f2-4f54-b744-be15d4a326ea@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <FNQ8C8DWodZYnFtwFGGP1bSb1hHwp7QijYYB1tC8vsY=.ee363dee-15f2-4f54-b744-be15d4a326ea@github.com>
Message-ID: <D5XfCbb41xGrvQdNIO8n31u9NBOfHIlnFHkq1gm7o_Q=.3541ed34-e268-4ebc-9e85-14f10893bd39@github.com>

On Fri, 18 Oct 2024 03:54:40 GMT, John R Rose <jrose at openjdk.org> wrote:

> Happily, that day has come.

Yes, feeling happy!    I have been waiting to get rid of this last piece!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21571#issuecomment-2422885117

From mchung at openjdk.org  Fri Oct 18 17:21:43 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Oct 2024 17:21:43 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
 <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
Message-ID: <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>

On Fri, 18 Oct 2024 16:54:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Oh that's a good find.  Maybe we should write a test for this, if as I assume there isn't one already.
>> Edit: not with this RFE, just in general.
>
>> // If the loader is not the boot loader then throw an exception if its
>> // superclass is in package jdk.internal.reflect
> 
> This will never happen.   `jdk.internal.reflect` is a non-exported package in `java.base` module.  If another module `M` defines a class whose superclass is in `jdk.internal.reflect` package, `java.base` must export `jdk.internal.reflect` package to `M` for access.   Otherwise, it will fail the super access check, as done in the check below this deleted code.
> 
> 
> Reflection::VerifyClassAccessResults vca_result =
>      Reflection::verify_class_access(this_klass, InstanceKlass::cast(super), false);

`test/hotspot/jtreg/runtime/AccessCheckSuper.java` is one test that fails the super class access check.  @lfoltan may know whether there are more tests besides this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1806804666

From heidinga at openjdk.org  Fri Oct 18 17:49:49 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 18 Oct 2024 17:49:49 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
 <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
 <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>
Message-ID: <-864yF5rSsyoQ2WvB1ftDib87vZIE7LkHodH4yYMqB4=.649be68d-c6b6-40c3-a87f-4b5f0d8f641d@github.com>

On Fri, 18 Oct 2024 15:33:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I looked at the InnerClassLambdaMetaFactory and it only generates MHs.Lookup.ClassOption::STRONG classes that live as long as their corresponding loaders.  Given that, do we want an assert here that we are only dealing with strong hidden classes?  ie: `assert(ik->is_hidden() && !ik->is_non_strong_hidden());`
>
> This is correct for the LMF, but I think we are using weak hidden classes in string concatenation.

I just confirmed - the `InlineHiddenClassStrategy` in j.l.i.StringConcatFactory uses weak hidden classes.  It looks like there are two possible strategies though, and the InlineHiddenClassStrategy is only used if the MH strategy fails (more parameters than the high arity threshold)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806833155

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 jvos at openjdk.org  Fri Oct 18 18:26:44 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Oct 2024 18:26:44 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <iP9XRtTeh8wPBqtj-o6JGhHkRqZTia-qt9ghVH0E0Iw=.31a75e2b-b453-4e8f-956d-2ce6c86a39ac@github.com>

On Tue, 15 Oct 2024 20:22:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't hardcode server variant

src/java.base/unix/native/libjli/java_md.c line 279:

> 277:                            char jvmpath[], jint so_jvmpath,
> 278:                            char jvmcfg[],  jint so_jvmcfg) {
> 279:     /* Compute/set the name of the executable. This is needed for macOS. */

But this file is not used when on macOS, is it? (cfr java_md_macosx.m) )

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1806868617

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 duke at openjdk.org  Fri Oct 18 18:57:02 2024
From: duke at openjdk.org (Andreas Schwab)
Date: Fri, 18 Oct 2024 18:57:02 GMT
Subject: RFR: 8296448: RISC-V: Fix temp usages of heapbase register killed
 by MacroAssembler::en/decode_klass_not_null [v2]
In-Reply-To: <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
References: <7NJqWAajnAuuq1Udf6GT8JeGZdNgBxWGASX0P8HhZE8=.9e7f7b23-3f6a-4954-91a0-d6a7ac123319@github.com>
 <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
Message-ID: <fUwRFgFL5rBKNMnJX6adxFPaZ8nfRkVXmvvrA67Q4nU=.b2a166f6-6ec7-4de2-96a8-bf78cdc40b3c@github.com>

On Tue, 8 Nov 2022 09:00:38 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Please see the JBS issue for more crash details.
>> 
>> To reproduce using a cross-compiled build:
>> 
>> # dump one cds-nocoops.jsa
>> <java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:dump -Xlog:cds* -version
>> 
>> # reproduce
>> <java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:on -XX:-TieredCompilation \
>>        -Xlog:cds* -Xlog:gc+metaspace=info -jar renaissance-gpl-0.14.1.jar -r 1 movie-lens
>> 
>> 
>> `MacroAssembler::en/decode_klass_not_null` uses the heapbase register as a temp register in the interpreter, which may kill the in-use value when enabling C2 compilation and `UseCompressedClassPointers` meanwhile disabling `UseCompressedOops`. C1 won't have this issue for the xheapbase is not its allocation candidate. When CDS is enabled, the narrow klass base is mapped to some address like `0x0000000800000000`, so `MacroAssembler::decode_klass_not_null`, which lacks registers, will use `xheapbase` as a temp to load the klass base and kill the register in the interpreter. So adding a `-XX:+DeoptimizeALot` can speedily reproduce the issue.
>> 
>> To solve this, we shall decouple the xheapbase used as a temp register in `MacroAssembler::en/decode_klass_not_null`. AArch64 has advanced instructions so one register is enough to handle the logic. But in RISC-V we require at least two.
>> 
>> This patch introduces another argument `tmp` to related functions to decouple and eliminate such heapbase usages. One thing that deserves noticing is the `cmp_klass` case, which usually gets used at the beginning of a method entry when `t1` is used as ic holder klass and `t0` is occupied there. These positions are special since nearly all registers are usable except ones used for arguments and special purposes (thread register, etc.). I propose to use a call-clobbered `t2` register here, to keep aligning the `i2c2i_adapter` logic[1].
>> 
>> Tested hotspot tier1~4 on QEMU; jdk tier1~tier2 and hotspot tier1~tier2 on my Hifive unmatched board, and the reproducible movie-lens benchmark.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp#L629
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Thanks for your explanation.

This came up while trying to backport the RISC-V port to jdk16 (for
bootstrapping purpose).  In jdk16 base != 0 and shift != 0 is possible,
apparently due to lack of JDK-8265705.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11010#issuecomment-2423055647

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 luhenry at openjdk.org  Fri Oct 18 19:23:20 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 18 Oct 2024 19:23:20 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
Message-ID: <JMISLke9syGhja1cTNLHcA28EjZD-hItzE2EHK_LdUs=.abdddab8-7fdb-4278-9e4e-d6a8f75dea20@github.com>

On Thu, 17 Oct 2024 13:44:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> RISC-V don't have dedicated call/ret instructions.
>> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
>> The cpu have a return-address stack where it stores return addresses for prediction.
>> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
>> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
>> 
>> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
>> | ------------- | ------------- | ------------- |------------- |
>> |No | No | ? | None|
>> |No | Yes | ? | Pop|
>> |Yes | No | ? | Push|
>> |Yes | Yes | No | Pop, then push|
>> |Yes | Yes | Yes | Push|
>> 
>> And additionally:
>> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
>> 
>> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
>> This causes performance issues as the predictions is often wrong.
>> 
>> Average time for 10 best iterations (VF2):
>> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
>> |-- | -- | -- | -- |
>> |future-genetic | 22126.6 | 20461.8 | -7.52%|
>> |akka-uct | 97119.6 | 97498 | 0.39%|
>> |movie-lens | 82359.3 | 81009.2 | -1.64%|
>> |scala-doku | 29246.1 | 24518.6 | -16.16%|
>> |chi-square | 10207.3 | 10624.9 | 4.09%|
>> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
>> |finagle-http | 24845 | 24891.9 | 0.19%|
>> |reactors | 97473.9 | 96655.5 | -0.84%|
>> |dec-tree | 8322.99 | 8243.11 | -0.96%|
>> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
>> |als | 52678 | 51245.9 | -2.72%|
>> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
>> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
>> |philosophers | 9156.9 | 7754.5 | -15.32%|
>> |log-regression | 7621.65 | 7540.85 | -1.06%|
>> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
>> |mnemonics | 73087.3 | 69426.6 | -5.01%|
>> |dotty | 10970.9 | 10719.1 | -2.30%|
>> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
>> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
>> 
>> For some of workloads, e.g. call to small function in a loop, it really matters.
>> 
>> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
>> And changes all jumps to use x6(/t1) instead of x5(/t0).
>> This patch was incrementally done, i.e. the first change removed the default t0.
>> I visited all places makings jumps, to make sure t1 was available.
>> Then changed to default t1 and removed argument in many...
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated UEP pretty print with t1

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21406#pullrequestreview-2378825705

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 fbredberg at openjdk.org  Fri Oct 18 20:02:56 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 18 Oct 2024 20:02:56 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and EntryList
Message-ID: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>

Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.

Tested ok tier1-3.

-------------

Commit messages:
 - 8340796: Use a consistent order when loading cxq and EntryList

Changes: https://git.openjdk.org/jdk/pull/21584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340796
  Stats: 28 lines in 2 files changed: 24 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21584/head:pull/21584

PR: https://git.openjdk.org/jdk/pull/21584

From iklam at openjdk.org  Fri Oct 18 20:09:04 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 20:09:04 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/030cac23..3f094645

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=08-09

  Stats: 96 lines in 5 files changed: 88 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Fri Oct 18 20:11:24 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 20:11:24 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
 <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
 <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>
Message-ID: <0psOa7CmTMhsD-d_8aQrWvhf6nqqN1WDW336YmXVSUQ=.b7e6a508-6d80-4c6d-a0dd-0dffcce715b9@github.com>

On Wed, 16 Oct 2024 15:58:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Here's the call stack if I remove the "if" check on line 49. It can be reproduced with test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java from the PR repo.
>> 
>> 
>> 10 javaSignalHandler (sig=11, info=0x7ffff428fdb0, context=0x7ffff428fc80)
>> 12 Atomic::PlatformLoad::operator() (this=0x7ffff429097f, dest=0x28)
>> 13 Atomic::LoadImpl, void>::operator() (this=0x7ffff42909af, dest=0x28)
>> 14 Atomic::load (dest=0x28)
>> 15 ClassLoaderData::try_claim (this=0x0, claim=4)
>> 16 ClassLoaderData::oops_do (this=0x0, f=0x7fff6c014c88, claim_value=4, clear_mod_oops=false)
>> 17 ClaimMetadataVisitingOopIterateClosure::do_cld (this=0x7fff6c014c88, cld=0x0)
>> 18 ClaimMetadataVisitingOopIterateClosure::do_klass (this=0x7fff6c014c88, k=0x7fff763655d8)
>> 19 call_do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
>> 20 Devirtualizer::do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
>> 21 InstanceKlass::oop_oop_iterate (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
>> 22 OopOopIterateDispatch::Table::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, k=0x7fff763655d8)
>> 23 OopIteratorClosureDispatch::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, klass=0x7fff763655d8)
>> 24 oopDesc::oop_iterate (this=0xfffd72a0, cl=0x7fff6c014c88)
>> 25 G1FullGCMarker::follow_object (this=0x7fff6c014630, obj=0xfffd72a0)
>> 26 G1FullGCMarker::publish_and_drain_oop_tasks (this=0x7fff6c014630)
>> 27 G1FullGCMarker::follow_marking_stacks (this=0x7fff6c014630)
>> 28 G1FullGCMarker::complete_marking (this=0x7fff6c014630, oop_stacks=0x7fffd445c6b8, array_stacks=0x7fffd445c6d0, terminator=0x7fffd445c190)
>> 29 G1FullGCMarkTask::work (this=0x7fffd445c030, worker_id=0)
>> 30 WorkerTaskDispatcher::worker_run_task (this=0x7ffff008b9b8)
>> 31 WorkerThread::run (this=0x7ffff008bac0)
>> 
>> 
>> This is in a GC triggered by here (with -XX:VerifyArchivedFields=2).
>> 
>> 
>> void HeapShared::init_archived_fields_for(Klass* k, 
>>      const ArchivedKlassSubGraphInfoRecord* record) {
>>   verify_the_heap(k, "before");
>> 
>> 
>> At frame 18:
>> 
>> 
>> #18 0x00007ffff58505d1 in ClaimMetadataVisitingOopIterateClosure::do_klass 
>>     (this=0x7fff6c014c88, k=0x7fff763655d8)
>>     at src/hotspot/share/memory/iterator.inline.hpp:58
>> 58	  ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>> (gdb) psym k->_name
>> $1 = 0x7fff765430be "BulkLoaderTestApp$$Lambda+0x800000013"
>> (gdb) p k->_class_loader_data
>> $2 = (ClassLoaderData *) 0x0
>> (gdb) p SystemDictionary::_java_system_loader 
>> $3 = {_obj...
>
> I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache classes in loaded state" to address this properly.

I added an assert to limit the cases where the GCs can see null ClassLoaderData from a klass [3f09464](https://github.com/openjdk/jdk/pull/21143/commits/3f094645aae7ba420414121d20787d6a313ed4d0)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806971597

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 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 ascarpino at openjdk.org  Fri Oct 18 21:22:59 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 18 Oct 2024 21:22:59 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v5]
In-Reply-To: <tCuaZFrrX71Rw1Xh03-1Q-yds_lqVkU0ZJ-RPLjGFoU=.3088d06c-4754-4b00-b9cb-c6b6b00850cc@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <tCuaZFrrX71Rw1Xh03-1Q-yds_lqVkU0ZJ-RPLjGFoU=.3088d06c-4754-4b00-b9cb-c6b6b00850cc@github.com>
Message-ID: <37LXaInlMtR31NG9ziFUASr-bCMyYGsrlBQyoQjTXLQ=.71c6b447-8671-4631-b668-195760179a09@github.com>

On Wed, 16 Oct 2024 23:13:45 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into sha-512
>  - Updated code as per review comments
>  - Addressed a review comment
>  - Updated code as per review comment & updated test case
>  - Updated AMD64.java
>  - Merge master
>  - SHA-512 implementation using SHA-NI instructions

Tier 1-3 passed on windows-x64, linux-x64, and macos-aarch64

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20633#pullrequestreview-2378979993

From liach at openjdk.org  Fri Oct 18 21:30:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 21:30:09 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <-864yF5rSsyoQ2WvB1ftDib87vZIE7LkHodH4yYMqB4=.649be68d-c6b6-40c3-a87f-4b5f0d8f641d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
 <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
 <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>
 <-864yF5rSsyoQ2WvB1ftDib87vZIE7LkHodH4yYMqB4=.649be68d-c6b6-40c3-a87f-4b5f0d8f641d@github.com>
Message-ID: <yLl7uO-EOSfSaMLP92N_D3fIzVvA1JXQQlTi5X6Wbqg=.57ac3948-6c40-45b1-aeff-1a15db841e1c@github.com>

On Fri, 18 Oct 2024 17:47:00 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> This is correct for the LMF, but I think we are using weak hidden classes in string concatenation.
>
> I just confirmed - the `InlineHiddenClassStrategy` in j.l.i.StringConcatFactory uses weak hidden classes.  It looks like there are two possible strategies though, and the InlineHiddenClassStrategy is only used if the MH strategy fails (more parameters than the high arity threshold)

Currently the high arity threshold is 0, meaning weak hidden classes are always used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1807029898

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 jrose at openjdk.org  Sat Oct 19 00:27:26 2024
From: jrose at openjdk.org (John R Rose)
Date: Sat, 19 Oct 2024 00:27:26 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v11]
In-Reply-To: <O7JnEfjm-boQ_2BeE2Nwet09ioROEUX0w0fGv7vRR48=.72b6b3b4-c0f9-42b6-aaa2-11e42bab8a95@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
 <O7JnEfjm-boQ_2BeE2Nwet09ioROEUX0w0fGv7vRR48=.72b6b3b4-c0f9-42b6-aaa2-11e42bab8a95@github.com>
Message-ID: <OsieTrdZwZdrXSyxm11f1jxMAGAHffnJsQnnc8-WZvA=.c35196ba-5fac-417c-a3f0-b23854319a80@github.com>

On Wed, 16 Oct 2024 23:34:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
>> 
>> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp: No need to hold InvokeMethodIntrinsicTable_lock during bootstrap

Good changes.  One request:  Please add a comment, if there isn't one somewhere already, saying (as an order of magnitude) what is a typical size of the MH intrinsic table.  That would be an estimate of the number printed by this log message:


  log_info(cds)("Archived %d method handle intrinsics", len)

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20959#pullrequestreview-2379136181

From dlong at openjdk.org  Sat Oct 19 01:05:12 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 19 Oct 2024 01:05:12 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList
In-Reply-To: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
Message-ID: <1OBDLYx0bXK4r8hdIxuiLpRj4h0Ns2y_GXcJVmryN9w=.80957dcb-66bb-4d99-bc1e-1d12f2e99d42@github.com>

On Fri, 18 Oct 2024 14:44:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
> 
> Tested ok tier1-3.

We don't have a LoadLoad on aarch64 to enforce the ordering, so isn't it more correct to say that the code handles either ordering correctly, and leave x86 the way it was?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21584#issuecomment-2423418940

From duke at openjdk.org  Sat Oct 19 11:55:52 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Oct 2024 11:55:52 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <ogLSKo5cyl9xBx_VTqa7_2r2JjJvhC-mDC4iwyRHEVM=.402df357-94bd-43b9-b1c7-9e172e8de536@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Does?this?mean that?[JDK?4486457] will?finally be?able to?be?made?public?

[JDK?4486457]: https://bugs.openjdk.org/browse/JDK-4486457

-------------

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2379243219

From duke at openjdk.org  Sat Oct 19 11:55:52 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Oct 2024 11:55:52 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
 <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
 <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>
Message-ID: <ETK0SJ0qK5YYVRRyBZ4w8IZoURUghpOo88OlRNPi9mg=.612750f1-232b-49d4-8b0d-cf56a3f4049a@github.com>

On Fri, 18 Oct 2024 17:18:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> // If the loader is not the boot loader then throw an exception if its
>>> // superclass is in package jdk.internal.reflect
>> 
>> This should not be needed.   `jdk.internal.reflect` is a non-exported package in `java.base` module.  If another module `M` defines a class whose superclass is in `jdk.internal.reflect` package, `java.base` must export `jdk.internal.reflect` package to `M` for access.   Otherwise, it will fail the super access check, as done in the check below this deleted code.
>> 
>> 
>> Reflection::VerifyClassAccessResults vca_result =
>>      Reflection::verify_class_access(this_klass, InstanceKlass::cast(super), false);
>
> `test/hotspot/jtreg/runtime/AccessCheckSuper.java` is one test that fails the super class access check.  @lfoltan may know whether there are more tests besides this one.

This?code was?necessary back?when this?was the?`sun.reflect` package and?it?was not?able to?be?encapsulated (before?modules) to?prevent untrusted class?loaders from?leaking the?`MagicAccessorImpl` class?hierarchy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1807206230

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 yzhu at openjdk.org  Sun Oct 20 04:53:45 2024
From: yzhu at openjdk.org (Yanhong Zhu)
Date: Sun, 20 Oct 2024 04:53:45 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v8]
In-Reply-To: <oC7V6BPzlccZd93dZPgCdAnQNKy5LAeEPEl5Z48ZmN4=.5dd29b29-9307-4a03-a282-e98c67ad3787@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <oC7V6BPzlccZd93dZPgCdAnQNKy5LAeEPEl5Z48ZmN4=.5dd29b29-9307-4a03-a282-e98c67ad3787@github.com>
Message-ID: <7LkJO2Uk02yGok4inzS9HrswA8XgWow5GP5UueViw_I=.2233bfea-f0a8-4bc1-96d4-a4a75df5d297@github.com>

On Thu, 17 Oct 2024 22:07:16 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use same keys for encryption and decryption

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2279:

> 2277:   }
> 2278: 
> 2279:   void generate_aes_loadkeys(const Register &key, VectorRegister *working_vregs, int reg_number) {

Hi, maybe `rounds` is more readable than `reg_number` here.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2289:

> 2287: 
> 2288:   void generate_aes_encrypt(const VectorRegister &res, VectorRegister *working_vregs, int reg_number) {
> 2289:     assert(reg_number <= 15, "reg_number should be less than or equal to working_vregs size")

This lacks `;` at the end of statement, which is causing the GHA failure.

src/hotspot/share/opto/library_call.cpp line 7225:

> 7223: //------------------------------get_key_start_from_aescrypt_object-----------------------
> 7224: Node * LibraryCallKit::get_key_start_from_aescrypt_object(Node *aescrypt_object) {
> 7225: #if defined(PPC64) || defined(S390) || defined(RISCV)

Hi, I think RISCV64 is more specific here for now.

src/hotspot/share/opto/library_call.cpp line 7230:

> 7228:   // However, ppc64 vncipher processes MixColumns and requires the same round keys with encryption.
> 7229:   // The ppc64 stubs of encryption and decryption use the same round keys (sessionK[0]).
> 7230:   // The RISC-V stubs of encryption and decryption use the same round keys (sessionK[0]).

`// The ppc64 and riscv64 stubs...` would be better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1807636619
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1807633799
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1807634349
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1807634141

From gcao at openjdk.org  Mon Oct 21 01:44:48 2024
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 21 Oct 2024 01:44:48 GMT
Subject: RFR: 8296448: RISC-V: Fix temp usages of heapbase register killed
 by MacroAssembler::en/decode_klass_not_null [v2]
In-Reply-To: <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
References: <7NJqWAajnAuuq1Udf6GT8JeGZdNgBxWGASX0P8HhZE8=.9e7f7b23-3f6a-4954-91a0-d6a7ac123319@github.com>
 <PewIAA9YS84tV-xZpxn2DATcLbZ4W5wUaviBrvDrADE=.a8c697dc-c80e-421c-a2b5-36e58d24b8ce@github.com>
Message-ID: <Em6DNgvdekcLfOuVH_fO22Da-SVPcoOmctaQJm6sUgc=.5191ac2a-bd65-4198-880d-6d05438b45fc@github.com>

On Tue, 8 Nov 2022 09:00:38 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Please see the JBS issue for more crash details.
>> 
>> To reproduce using a cross-compiled build:
>> 
>> # dump one cds-nocoops.jsa
>> <java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:dump -Xlog:cds* -version
>> 
>> # reproduce
>> <java> -XX:-UseCompressedOops -XX:+UseCompressedClassPointers -Xshare:on -XX:-TieredCompilation \
>>        -Xlog:cds* -Xlog:gc+metaspace=info -jar renaissance-gpl-0.14.1.jar -r 1 movie-lens
>> 
>> 
>> `MacroAssembler::en/decode_klass_not_null` uses the heapbase register as a temp register in the interpreter, which may kill the in-use value when enabling C2 compilation and `UseCompressedClassPointers` meanwhile disabling `UseCompressedOops`. C1 won't have this issue for the xheapbase is not its allocation candidate. When CDS is enabled, the narrow klass base is mapped to some address like `0x0000000800000000`, so `MacroAssembler::decode_klass_not_null`, which lacks registers, will use `xheapbase` as a temp to load the klass base and kill the register in the interpreter. So adding a `-XX:+DeoptimizeALot` can speedily reproduce the issue.
>> 
>> To solve this, we shall decouple the xheapbase used as a temp register in `MacroAssembler::en/decode_klass_not_null`. AArch64 has advanced instructions so one register is enough to handle the logic. But in RISC-V we require at least two.
>> 
>> This patch introduces another argument `tmp` to related functions to decouple and eliminate such heapbase usages. One thing that deserves noticing is the `cmp_klass` case, which usually gets used at the beginning of a method entry when `t1` is used as ic holder klass and `t0` is occupied there. These positions are special since nearly all registers are usable except ones used for arguments and special purposes (thread register, etc.). I propose to use a call-clobbered `t2` register here, to keep aligning the `i2c2i_adapter` logic[1].
>> 
>> Tested hotspot tier1~4 on QEMU; jdk tier1~tier2 and hotspot tier1~tier2 on my Hifive unmatched board, and the reproducible movie-lens benchmark.
>> 
>> Thanks,
>> Xiaolin
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp#L629
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

> > There is a potential conflict with the use of t0 in decode_klass_not_null:
> > ```
> > assert_different_registers(t0, xbase);
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > since tmp in load_klass defaults to t0.
> 
> Thank you for pointing this out. Yes, code here in `MacroAssembler::decode_klass_not_null` seems to have a potential issue. But in reality I assume it is dead code.
> 
> ```
> // In MacroAssembler::decode_klass_not_null()
> //  -> CompressedKlassPointers::base() is non-null also when reaching here
> if (CompressedKlassPointers::shift() != 0) {
>     assert(LogKlassAlignmentInBytes == CompressedKlassPointers::shift(), "decode alg wrong");
>     assert_different_registers(t0, xbase);
>     shadd(dst, src, xbase, t0, LogKlassAlignmentInBytes);
> }
> ```
> 
> As per Thomas' clear comments here [1], `base > 0 && shift > 0` should not happen. Perhaps we can perform some cleanup here to remove unreachable code that causes confusion. Maybe something like [zhengxiaolinX at 973a071](https://github.com/zhengxiaolinX/jdk/commit/973a071e51d116909b9713e52850b4990c025183).
> 
> But it is untested due to a lack of resources, so waiting for someone kind to take it over.
> 
> BTW the current PR (11010) is still needed because the heapbase register should not be used as a temp register here.
> 
> Hope this can explain well.
> 
> Best, Xiaolin
> 
> [1]
> 
> https://github.com/openjdk/jdk/blob/4dcc7f3f2629e857b20f72e99189db8781aa65ff/src/hotspot/share/oops/compressedKlass.cpp#L103-L104

@zhengxiaolinX Hi, I have tested tier1(fastdebug) with this patch [zhengxiaolinX at 973a071](https://github.com/zhengxiaolinX/jdk/commit/973a071e51d116909b9713e52850b4990c025183) and everything works fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11010#issuecomment-2425386081

From rehn at openjdk.org  Mon Oct 21 06:58:20 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 21 Oct 2024 06:58:20 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
 <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>
Message-ID: <wDQKCBIM8C-SUqwod0NU1vzMvMzKKmvs41KdvPJw4Qc=.b81758f7-1e17-4868-8f6f-e8c19deea427@github.com>

On Thu, 17 Oct 2024 14:06:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated UEP pretty print with t1
>
> Thanks for the update. Hopefully, I think I can finish first round of review tomorrow. BTW: It will be good to know how this may affect other benchmark workloads, like specjbb2015, etc.

@RealFYang
I programmically looked for t1 uses in Nodes.
The only ones I found missing **cr** (set or kill) was ForwardExceptionjmp and RethrowException.
But compiler don't expect **cr** to survival these i.e. x86 do not kill **cr** in those cases.
Note, maybe some Node(s) was never created, so this is not 100% complete check, but 99%.

@luhenry thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2425764361

From rehn at openjdk.org  Mon Oct 21 07:07:27 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 21 Oct 2024 07:07:27 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v19]
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <oMyB5IZ9LifNNT9J-0b1Y9XwMrf0kxioSnn5nrvzSxM=.a8f2790b-86ec-4e90-97ab-c445e8f90795@github.com>

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into remove_t0
 - Updated UEP pretty print with t1
 - Merge branch 'master' into remove_t0
 - KILL cr
 - Merge branch 'master' into remove_t0
 - Allow x1 as Rs
 - Comments fixes
 - Merge branch 'master' into remove_t0
 - ICData move to t1, removed dead code
 - Revert clinit_barrier
 - ... and 12 more: https://git.openjdk.org/jdk/compare/d61f56a3...cf3fed8b

-------------

Changes: https://git.openjdk.org/jdk/pull/21406/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21406&range=18
  Stats: 183 lines in 18 files changed: 51 ins; 12 del; 120 mod
  Patch: https://git.openjdk.org/jdk/pull/21406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21406/head:pull/21406

PR: https://git.openjdk.org/jdk/pull/21406

From stefank at openjdk.org  Mon Oct 21 07:07:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 07:07:53 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
Message-ID: <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>

On Fri, 18 Oct 2024 20:09:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()

src/hotspot/share/memory/iterator.hpp line 177:

> 175: class ClaimMetadataVisitingOopIterateClosure : public OopIterateClosure {
> 176:  private:
> 177:   static void assert_is_pending_aot_linked_class(Klass* k) NOT_DEBUG_RETURN;

Suggestion:

 private:
  static void assert_is_pending_aot_linked_class(Klass* k) NOT_DEBUG_RETURN;

src/hotspot/share/memory/iterator.inline.hpp line 57:

> 55:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
> 56:   } else {
> 57:     assert_is_pending_aot_linked_class(k);

Would there be a drawback to just adding `assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");` here and skip the changes the both .hpp and .cpp files?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1808211577
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1808213774

From stefank at openjdk.org  Mon Oct 21 07:07:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 07:07:53 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <0psOa7CmTMhsD-d_8aQrWvhf6nqqN1WDW336YmXVSUQ=.b7e6a508-6d80-4c6d-a0dd-0dffcce715b9@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
 <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
 <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>
 <0psOa7CmTMhsD-d_8aQrWvhf6nqqN1WDW336YmXVSUQ=.b7e6a508-6d80-4c6d-a0dd-0dffcce715b9@github.com>
Message-ID: <maqAtEmA0mfT3PQyq-wC5ZdM9HcuFStx_lDMF4SQkic=.7daa8474-036e-498c-bfd0-374601649fe5@github.com>

On Fri, 18 Oct 2024 20:09:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache classes in loaded state" to address this properly.
>
> I added an assert to limit the cases where the GCs can see null ClassLoaderData from a klass [3f09464](https://github.com/openjdk/jdk/pull/21143/commits/3f094645aae7ba420414121d20787d6a313ed4d0)

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1808214635

From fyang at openjdk.org  Mon Oct 21 07:30:45 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 21 Oct 2024 07:30:45 GMT
Subject: RFR: 8340241: RISC-V: Returns mispredicted [v18]
In-Reply-To: <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
 <d4hNmOL9eR7WNfdyWqI_LZDYc05JLCC8pMU1KzZuOYE=.a5fba047-19e5-45e2-9ae6-dc667ffbb6e6@github.com>
 <DsN5GmxeGKnvl2Z-8OVlDrE__aADcvDbyIe6tXtdBhE=.d2fe9ca1-8794-44ec-9295-789a74d22bb0@github.com>
Message-ID: <Em5M2vF9fQuPGxXFlRQSszsz9GL2qo9iXrjSe-ltS2Q=.c9c4edde-d251-4744-88bd-81d5694e7ed4@github.com>

On Thu, 17 Oct 2024 14:06:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated UEP pretty print with t1
>
> Thanks for the update. Hopefully, I think I can finish first round of review tomorrow. BTW: It will be good to know how this may affect other benchmark workloads, like specjbb2015, etc.

> @RealFYang I programmically looked for t1 uses in Nodes. The only ones I found missing **cr** (set or kill) was ForwardExceptionjmp and RethrowException. But compiler don't expect **cr** to survival these i.e. x86 do not kill **cr** in those cases. Note, maybe some Node(s) was never created, so this is not 100% complete check, but 99%.

Hi, thanks for doing the check. Yeah, I think we should be safe to go.
(And I also created PR fixing similar issue for riscv-specific changes in the loom repo: https://github.com/openjdk/loom/pull/215)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21406#issuecomment-2425836642

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 lucy at openjdk.org  Mon Oct 21 08:14:11 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 21 Oct 2024 08:14:11 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
 <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
 <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>
Message-ID: <SttIpkWPsz0JZa0v9H9HDLjb2qd25scHpr-rolPTTUQ=.71bbfc92-f6af-4d2b-ab86-224b0e96c6f8@github.com>

On Wed, 16 Oct 2024 07:22:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?
>> 
>> It needs to return -Inf. ubsan seems wrong here: this IEEE-754 arithmetic is well defined, and has been for a very long while.
>
> Ubsan is just following the C++ standard 
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
> 5.6 Multiplicative operators  
>  ....
> 'The binary / operator yields the quotient, and the binary % operator yields the remainder from the division
> of the first expression by the second. If the second operand of / or % is zero the behavior is undefined.'
> 
> See also https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero .
> 
> However on our set of platforms in OpenJDK we probably get away with the expected results when dividing by 0  (because they all seem to follow IEEE-754).
> That's why I just added the static_assert.

To me, this feels like the C++ standard is not compatible with IEEE-754 arithmetic. Undefined behavior would give the optimizer freedom to do whatever it likes to do. That is in contrast to the well-defined IEEE-754 requirement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1808300823

From jbhateja at openjdk.org  Mon Oct 21 08:45:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 08:45:59 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <rYakfFq4-q_24ENg0rzIfrkGNGaB9QfWj7_EkPe-weQ=.25d650ef-fed3-4c7c-90d8-2bfabad0c96b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
 <rHYOu1rSW3Iy9CNsYpRuD7hrvUGLmpi0Rutk9GZ9R4A=.750e81f8-c9e3-4746-a958-1f21f32f0805@github.com>
 <rYakfFq4-q_24ENg0rzIfrkGNGaB9QfWj7_EkPe-weQ=.25d650ef-fed3-4c7c-90d8-2bfabad0c96b@github.com>
Message-ID: <C9JDS0SmaOLW7jUCOzMyG2LaK0S_Vw2T5iR6BgG-0AY=.a27b7b69-b9e4-466e-bca6-e0894ec3a756@github.com>

On Thu, 19 Sep 2024 06:28:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
>>> > 
>>> > 
>>> > Nomenclature is suggested by Paul.
>>> 
>>> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
>>> 
>> 
>> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
>> 
>> 
>> /**
>>  * The class {@code VectorMath} contains methods for performing
>>  * scalar numeric operations in support of vector numeric operations.
>>  */
>> public final class VectorMath {
>> 
>> 
>> These are referenced by the vector operators e.g.,
>> 
>> 
>>     /** Produce saturating {@code a+b}.  Integral only.
>>      * @see VectorMath#addSaturating(int, int)
>>      */
>>     public static final Binary SADD = binary("SADD", "+", VectorSupport.VECTOR_OP_SADD, VO_NOFP);
>> 
>> 
>> And in addition these methods would be used by any tail computation (and the fallback code).
>> 
>> At the moment we are uncertain whether such operations should reside elsewhere and we did not want to block progress. I am not beholden to the name, but so far i cannot think of a concise alternative.`VectorOperatorMath` is arguably more precise but more verbose.
>
>> > > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
>> > > 
>> > > 
>> > > Nomenclature is suggested by Paul.
>> > 
>> > 
>> > @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
>> 
>> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
> 
> Ok. I suppose these methods could eventually be moved to `java.lang.Math` or some other `java.lang` class, when the VectorAPI goes out of incubator mode?
> 
> I feel like these saturating operations, and also the unsigned ops could find a more wider use, away from (explicit) vector usage. For example, the saturating operations are nice because they prevent overflows, and in some cases that would be very nice to have readily available.

Hi @eme64 , 

Can you kindly review following changes, rest of the portions are already reviewed and approved.

https://github.com/openjdk/jdk/pull/20507/commits/2b0fa01633875926595656d8dcfd539c334f23a3

https://github.com/openjdk/jdk/pull/20507/commits/c56508899b000b8b1eb6755c901798a2a3685ef5

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426005754

From epeter at openjdk.org  Mon Oct 21 09:14:34 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 21 Oct 2024 09:14:34 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
Message-ID: <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>

On Fri, 18 Oct 2024 14:56:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replacing flag based checks with CPU feature checks in IR validation test.

Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.

I think these optimizations should be done in a separate PR. I see no reason why they need to be mixed in.

https://github.com/openjdk/jdk/commit/c56508899b000b8b1eb6755c901798a2a3685ef5 The `UMinVNode::Ideal` etc changes with IR rules.

I also cannot easily review just such a diff, it does not let me make comments - so I still have to go find the relevant code in the whole PR.

Some comments on this section:


Node* UMinVNode::Ideal(PhaseGVN* phase, bool can_reshape) {
  bool match1 = in(1)->Opcode() == Op_UMinV || in(1)->Opcode() == Op_UMaxV;
  bool match2 = in(2)->Opcode() == Op_UMinV || in(2)->Opcode() == Op_UMaxV;
  // UMin (UMin(a, b), UMax(a, b))  => UMin(a, b)
  // UMin (UMin(a, b), UMax(b, a))  => UMin(a, b)
  if (match1 && match2) {
    if ((in(1)->in(1) == in(2)->in(1) && in(1)->in(2) == in(2)->in(2)) ||
         (in(1)->in(2) == in(2)->in(1) && in(1)->in(1) == in(2)->in(2))) {
      return new UMinVNode(in(1)->in(1), in(1)->in(2), vect_type());
    }
  }
  return nullptr;
}


What about the reverse case `min(max, min)`? And are we sure we do not need to verify any types in all of these cases? Maybe not - but I'd rather be super sure - not that things get misinterpreted and then folded the wrong way.

I mean if I now approve only that diff, then I still need to approve the whole PR, which means I need to spend a lot of time on everything again. Otherwise, in theory people could smuggle anything in.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426080652

From eosterlund at openjdk.org  Mon Oct 21 10:03:09 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 21 Oct 2024 10:03:09 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList
In-Reply-To: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
Message-ID: <ebNdJqsgwHREqI4wTWjIYtpCYd0Yfz90VANslZFwR1o=.254a0046-bfe3-4da8-9bf6-5e0cdec0ecbd@github.com>

On Fri, 18 Oct 2024 14:44:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
> 
> Tested ok tier1-3.

Looks good to me.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21584#pullrequestreview-2381536482

From dholmes at openjdk.org  Mon Oct 21 10:16:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 10:16:05 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS)
In-Reply-To: <nV2U05cGdLMHBbkxMqNEMaufQu7oLGmMLlYs23g4bjc=.4f40dc12-3adf-4231-b671-6f96e8ab48ac@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <LWgsPmbz9IMM27FD5gcZoJufICMYEhdMsIm4xkzCImE=.37484095-9225-4ef0-b9ee-036d2848c8ca@github.com>
 <exlCO-asoAUH3WmvaYVrp_S6b1bDdWaX5c2JowpQNo0=.32c027f6-77cf-4e04-a388-00c09dcc70f6@github.com>
 <_qk6HGBMTHhkwxHdDAShaj2enwO14X2FJ_1uJKJsPmg=.6ea9b34e-297c-45c8-b4e9-abffa19b0905@github.com>
 <VjGauWgeRLo0EF6pMtGao34nZ1MBD5WWbr0sM_qxy9M=.bc848f50-a4ef-4a0f-910e-782fb17c17e4@github.com>
 <m7ivLHEBzBJP3FLAH8_t2i6TUh__NJ52o9jg8EnCO1Y=.724de800-eb68-454e-9d74-dff62a5c170e@github.com>
 <nuqK3YSBCQ9vLOflaYTdPcA98XLWchv6qmz3UJWLcJE=.b248e733-4fe0-4131-ab38-3822a6b15ad9@github.com>
 <TS3WtUnCzjV24OA-yBq5cE8Y5xgSd2XnaF6BhAeCLP0=.d8aeb660-43d1-4604-a31b-502d3789a99e@github.com>
 <nV2U05cGdLMHBbkxMqNEMaufQu7oLGmMLlYs23g4bjc=.4f40dc12-3adf-4231-b671-6f96e8ab48ac@github.com>
Message-ID: <ty6tjRREzqa83zEDGK3Lu8wXenvfyiZdHYsNxa0HbmM=.d636f5cb-7345-41d0-b39a-4fef26292f14@github.com>

On Fri, 18 Oct 2024 11:37:12 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> You're right, I meant the number of code points..
>> 
>> The `num_unicode_points` in this case would come from `UTF8::unicode_length`, which would give 2 from the 6-byte UTF8 string in your example. But I agree that it is somewhat unclear, especially if someone were to use this function in the future.
>> 
>> I have two ideas how this could be improved:
>> I could either add clarifying comments and change naming across the different functions to be clearer on how to use and call correctly. Or I could instead change it so that the function takes the UTF8-length instead of the UTF16-length. That way you always pass the array length to the function.
>
> I just want consistency and clarity in the header prototypes, for me either option is fine.

I agree with Johan, that either option would work, but as we are comparing different representations of strings so need a common format, and UTF-8 is the "lowest common denominator" then perhaps that is slightly better - and has the advantage of maintaining the correlation with the array length. The meaning of the parameters should always be clear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1808484174

From dholmes at openjdk.org  Mon Oct 21 10:25:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 10:25:45 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <_RnMPEisGbYYRP2gHhMaPFtWTwJWEyVPug509aGhS4A=.96345083-fe0e-44eb-b04a-80c31509ca1c@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2381587767

From dholmes at openjdk.org  Mon Oct 21 10:25:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 10:25:45 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <ETK0SJ0qK5YYVRRyBZ4w8IZoURUghpOo88OlRNPi9mg=.612750f1-232b-49d4-8b0d-cf56a3f4049a@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
 <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
 <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>
 <ETK0SJ0qK5YYVRRyBZ4w8IZoURUghpOo88OlRNPi9mg=.612750f1-232b-49d4-8b0d-cf56a3f4049a@github.com>
Message-ID: <EHHPl1nAVKMJTqi8MdDBg12k4wyV-O0xLvRI_QFc8L8=.f54da6e2-c647-49fd-9a77-b6ada0954af8@github.com>

On Sat, 19 Oct 2024 06:33:01 GMT, ExE Boss <duke at openjdk.org> wrote:

>> `test/hotspot/jtreg/runtime/AccessCheckSuper.java` is one test that fails the super class access check.  @lfoltan may know whether there are more tests besides this one.
>
> This?code was?necessary back?when this?was the?`sun.reflect` package and?it?was not?able to?be?encapsulated (before?modules) to?prevent untrusted class?loaders from?leaking the?`MagicAccessorImpl` class?hierarchy.

Okay ... so such subclass was and remains illegal and is now detected slightly later. That suggests to me this special case was in the wrong place and should have been inside `Reflection::verify_class_access`.

Anyway thanks for clarifying full removal is in fact what we want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1808498120

From fyang at openjdk.org  Mon Oct 21 11:48:15 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 21 Oct 2024 11:48:15 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v29]
In-Reply-To: <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
Message-ID: <-w4fewl6jgYElkyT7b7djL6LOU1Hg3KRerEh57A7dgg=.a54526fa-88f4-45e5-946f-9cd9c5c1ba82@github.com>

On Tue, 15 Oct 2024 11:08:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>> 
>> HotSpot shared runtime
>> ----------------------
>> 
>> Building hashed secondary tables is now unconditional. It takes very
>> little time, and now that the shared runtime always has the tables, it
>> might as well take advantage of them. The shared code is easier to
>> follow now, I think.
>> 
>> There might be a performance issue with x86-64 in that we build
>> HotSpot for a default x86-64 target that does not support popcount.
>> This means that HotSpot C++ runtime on x86 always uses a software
>> emulation for popcount, even though the vast majority of machines made
>> for the past 20 years can do popcount in a single instruction. It
>> wouldn't be terribly hard to do something about that.
>> 
>> Having said that, the software popcount is really not bad.
>> 
>> x86
>> ---
>> 
>> x86 is rather tricky, because we still support
>> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
>> well as 32- and 64-bit ports. There's some further complication in
>> that only `RCX` can be used as a shift count, so there's some register
>> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
>> rather gnarly, with multiple levels of conditionals at compile time
>> and runtime.
>> 
>> AArch64
>> -------
>> 
>> AArch64 is considerably more straightforward. We always have a
>> popcount instruction and (thankfully) no 32-bit code to worry about.
>> 
>> Generally
>> ---------
>> 
>> I would dearly love simply to rip out the "old" secondary supers cache
>> support, but I've left it in just in case someone has a performance
>> regression.
>> 
>> The versions of `MacroAssembler::lookup_secondary_supers_table` that
>> work with variable superclasses don't take a fixed set of temp
>> registers, and neither do they call out to to a slow path subroutine.
>> Instead, the slow patch is expanded inline.
>> 
>> I don't think this is necessarily bad. Apart from the very rare cases
>> where C2 can't determine the superclass to search for at compile time,
>> this code is only used for generating stubs, and it seemed to me
>> ridiculous to have stubs calling other stubs.
>> 
>> I've followed the guidance from @iwanowww not to obsess too much about
>> the performance of C1-compiled secondary supers lookups, and to prefer
>> simplicity over absolute performance. Nonetheless, this i...
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen assertion

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1819:

> 1817:   // This next instruction is equivalent to:
> 1818:   // mov(tmp_reg, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
> 1819:   // sub(temp2, r_array_index, tmp_reg);

One minor question about the code comment. Should this line be: `// sub(temp2, tmp_reg, slot);`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1808628155

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 jbhateja at openjdk.org  Mon Oct 21 12:25:37 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 12:25:37 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Factor out IR tests and Transforms to follow-up PRs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/dacc9313..7506ac14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=29-30

  Stats: 595 lines in 4 files changed: 0 ins; 595 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Mon Oct 21 12:29:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 12:29:03 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
Message-ID: <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>

On Mon, 21 Oct 2024 09:12:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replacing flag based checks with CPU feature checks in IR validation test.
>
> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
> 
> I think these optimizations should be done in a separate PR. I see no reason why they need to be mixed in.
> 
> https://github.com/openjdk/jdk/commit/c56508899b000b8b1eb6755c901798a2a3685ef5 The `UMinVNode::Ideal` etc changes with IR rules.
> 
> I also cannot easily review just such a diff, it does not let me make comments - so I still have to go find the relevant code in the whole PR.
> 
> Some comments on this section:
> 
> 
> Node* UMinVNode::Ideal(PhaseGVN* phase, bool can_reshape) {
>   bool match1 = in(1)->Opcode() == Op_UMinV || in(1)->Opcode() == Op_UMaxV;
>   bool match2 = in(2)->Opcode() == Op_UMinV || in(2)->Opcode() == Op_UMaxV;
>   // UMin (UMin(a, b), UMax(a, b))  => UMin(a, b)
>   // UMin (UMin(a, b), UMax(b, a))  => UMin(a, b)
>   if (match1 && match2) {
>     if ((in(1)->in(1) == in(2)->in(1) && in(1)->in(2) == in(2)->in(2)) ||
>          (in(1)->in(2) == in(2)->in(1) && in(1)->in(1) == in(2)->in(2))) {
>       return new UMinVNode(in(1)->in(1), in(1)->in(2), vect_type());
>     }
>   }
>   return nullptr;
> }
> 
> 
> Are we sure we do not need to verify any types in all of these cases? Maybe not - but I'd rather be super sure - not that things get misinterpreted and then folded the wrong way.
> 
> I mean if I now approve only that diff, then I still need to approve the whole PR, which means I need to spend a lot of time on everything again. Otherwise, in theory people could smuggle anything in.

Hey @eme64 ,

> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.

I understand reviewer's pain, which is why I mentioned about last two changes specifically. Vector API related PRs generally looks bulky due to script generated sources and tests. Barring that it may not demand much of your time.

But, to keep you motivated :-) and following @PaulSandoz and yours suggestions, I have moved out IR validations and Min / Max transforms to following follow up PRs.
   
   - https://bugs.openjdk.org/browse/JDK-8342676 (https://github.com/openjdk/jdk/pull/21604)
   - https://bugs.openjdk.org/browse/JDK-8342677 (https://github.com/openjdk/jdk/pull/21603)

Can you kindly run this though your test infrastructure and approve if it goes fine ?

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426527459

From aph at openjdk.org  Mon Oct 21 12:40:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Oct 2024 12:40:01 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v29]
In-Reply-To: <-w4fewl6jgYElkyT7b7djL6LOU1Hg3KRerEh57A7dgg=.a54526fa-88f4-45e5-946f-9cd9c5c1ba82@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <I1maHK6OJgZcVZYhBLZGFMA0QXXTA25qLUZcEv-bfF4=.fa0b5794-3e28-466b-b407-e5e70a4f7970@github.com>
 <-w4fewl6jgYElkyT7b7djL6LOU1Hg3KRerEh57A7dgg=.a54526fa-88f4-45e5-946f-9cd9c5c1ba82@github.com>
Message-ID: <Hqxp_diKZ960m3U071mow6G9mVinWIMsG2zPj8NngEM=.0355d59c-aae9-4a0a-bcc8-623bfb764602@github.com>

On Mon, 21 Oct 2024 11:44:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen assertion
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1819:
> 
>> 1817:   // This next instruction is equivalent to:
>> 1818:   // mov(tmp_reg, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>> 1819:   // sub(temp2, r_array_index, tmp_reg);
> 
> One minor question about the code comment. Should this line be: `// sub(temp2, tmp_reg, slot);`?

Yes, it is. Good spot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1808714248

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 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 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 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 ihse at openjdk.org  Mon Oct 21 13:10:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:10:29 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <iP9XRtTeh8wPBqtj-o6JGhHkRqZTia-qt9ghVH0E0Iw=.31a75e2b-b453-4e8f-956d-2ce6c86a39ac@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <iP9XRtTeh8wPBqtj-o6JGhHkRqZTia-qt9ghVH0E0Iw=.31a75e2b-b453-4e8f-956d-2ce6c86a39ac@github.com>
Message-ID: <PcJxaNFB6UcGSbywAdz0OLCnSp_tYi_zBJdd4gtUQ78=.f56e03b4-3984-4f3c-a4b5-a1cd12847ff7@github.com>

On Fri, 18 Oct 2024 18:23:13 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't hardcode server variant
>
> src/java.base/unix/native/libjli/java_md.c line 279:
> 
>> 277:                            char jvmpath[], jint so_jvmpath,
>> 278:                            char jvmcfg[],  jint so_jvmcfg) {
>> 279:     /* Compute/set the name of the executable. This is needed for macOS. */
> 
> But this file is not used when on macOS, is it? (cfr java_md_macosx.m) )

Hm. I think both are used? I'll need to double-check that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1808787882

From rehn at openjdk.org  Mon Oct 21 13:18:42 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 21 Oct 2024 13:18:42 GMT
Subject: Integrated: 8340241: RISC-V: Returns mispredicted
In-Reply-To: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
References: <7FDFU_yHa6gl4bu7eAOl0FZOtiJmaw8ikYu-La7HzL4=.350cbaa5-7f2d-456b-ae55-6a4ace08ecee@github.com>
Message-ID: <x_2m2JQE7mwhsEcX7E5F_0pEt503iJrM2_dF_A9k5nw=.d0d468ef-568d-4cab-a5d0-c83940153741@github.com>

On Tue, 8 Oct 2024 12:54:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> RISC-V don't have dedicated call/ret instructions.
> Instead the registers used in the jal/jalr instructions determine if this is a JUMP or CALL/RET.
> The cpu have a return-address stack where it stores return addresses for prediction.
> There are two possible calling conventions: x1 and x5 (or using both for co-routines).
> This stack is updated according this table (from unpriv manual, 2.5.1. Unconditional Jumps) for JALR:
> 
> | rd is x1/x5 | rs1 is x1/x5 | rd=rs1 | RAS action
> | ------------- | ------------- | ------------- |------------- |
> |No | No | ? | None|
> |No | Yes | ? | Pop|
> |Yes | No | ? | Push|
> |Yes | Yes | No | Pop, then push|
> |Yes | Yes | Yes | Push|
> 
> And additionally:
> "A JAL instruction should push the return address onto a return-address stack (RAS) only when rd is 'x1' or x5."
> 
> As the JDK is using x5/(t0) as main scratch all plains jumps are actually calls and calls are co-routine calls (push and pop).
> This causes performance issues as the predictions is often wrong.
> 
> Average time for 10 best iterations (VF2):
> | Benchmark | Baseline (ms) | RAS fixed (ms) | Diff |
> |-- | -- | -- | -- |
> |future-genetic | 22126.6 | 20461.8 | -7.52%|
> |akka-uct | 97119.6 | 97498 | 0.39%|
> |movie-lens | 82359.3 | 81009.2 | -1.64%|
> |scala-doku | 29246.1 | 24518.6 | -16.16%|
> |chi-square | 10207.3 | 10624.9 | 4.09%|
> |fj-kmeans | 55127.9 | 56169.1 | 1.89%|
> |finagle-http | 24845 | 24891.9 | 0.19%|
> |reactors | 97473.9 | 96655.5 | -0.84%|
> |dec-tree | 8322.99 | 8243.11 | -0.96%|
> |naive-bayes | 79249.1 | 76851.9 | -3.02%|
> |als | 52678 | 51245.9 | -2.72%|
> |par-mnemonics | 52237.4 | 53149.8 | 1.75%|
> |scala-kmeans | 2990.88 | 2992.14 | 0.04%|
> |philosophers | 9156.9 | 7754.5 | -15.32%|
> |log-regression | 7621.65 | 7540.85 | -1.06%|
> |gauss-mix | 9835.7 | 9396.25 | -4.47%|
> |mnemonics | 73087.3 | 69426.6 | -5.01%|
> |dotty | 10970.9 | 10719.1 | -2.30%|
> |finagle-chirper | 23386.1 | 23630.3 | 1.04%|
> |recursive fibonacci | 7338.56 | 5369.83 | **-26.83%**|
> 
> For some of workloads, e.g. call to small function in a loop, it really matters.
> 
> This patch blacklist x5(/t0) for JAL/JALR as we only use x1 calling convention.
> And changes all jumps to use x6(/t1) instead of x5(/t0).
> This patch was incrementally done, i.e. the first change removed the default t0.
> I visited all places makings jumps, to make sure t1 was available.
> Then changed to default t1 and removed argument in many cases.
> 
> Other approaches was tested, e.g. completely switch t0 <-> t1.
> This was much harder and more intr...

This pull request has now been integrated.

Changeset: 66ddaaa3
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66ddaaa3591851cc420ec9e0ffe460c78a9a51f5
Stats:     183 lines in 18 files changed: 51 ins; 12 del; 120 mod

8340241: RISC-V: Returns mispredicted

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/21406

From ihse at openjdk.org  Mon Oct 21 13:20:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:20:21 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>

On Tue, 15 Oct 2024 20:22:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't hardcode server variant

When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.

I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.

@jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2426658524

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 cnorrbin at openjdk.org  Mon Oct 21 13:37:59 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 21 Oct 2024 13:37:59 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v2]
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <itF3kjV167iEZ-Aun-VoFRAp9X3N1hkD93qaF_-7MDk=.55494964-66d7-4cfe-9ec4-7d98aee393e4@github.com>

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  length param change + feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21325/files
  - new: https://git.openjdk.org/jdk/pull/21325/files/c31b99d0..f883087c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=00-01

  Stats: 92 lines in 6 files changed: 12 ins; 2 del; 78 mod
  Patch: https://git.openjdk.org/jdk/pull/21325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325

PR: https://git.openjdk.org/jdk/pull/21325

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 cnorrbin at openjdk.org  Mon Oct 21 13:45:17 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 21 Oct 2024 13:45:17 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v2]
In-Reply-To: <itF3kjV167iEZ-Aun-VoFRAp9X3N1hkD93qaF_-7MDk=.55494964-66d7-4cfe-9ec4-7d98aee393e4@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <itF3kjV167iEZ-Aun-VoFRAp9X3N1hkD93qaF_-7MDk=.55494964-66d7-4cfe-9ec4-7d98aee393e4@github.com>
Message-ID: <vD1HutHXH7nQMe9LPASkwq7fbrRPcfdZvBl5Q0ywX_c=.f6cf8339-4186-46dd-b774-8ccf2339e7e1@github.com>

On Mon, 21 Oct 2024 13:37:59 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   length param change + feedback

I've now changed so that the functions pass around the string length, regardless of encoding. To make it a bit clearer, utf8 strings and lengths have the prefix `utf8_` to distinguish them from other encodings. With this change, the `num_unicode_points` has been reverted to using `len` names like before.
Please let me know if everything looks as expected or if there are further changes needed :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21325#issuecomment-2426725500

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 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 duke at openjdk.org  Mon Oct 21 14:41:57 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Mon, 21 Oct 2024 14:41:57 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v9]
In-Reply-To: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
Message-ID: <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>

> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

Arseny Bochkarev has updated the pull request incrementally with four additional commits since the last revision:

 - Use RISCV64 instead of RISCV
 - Fixed comment line
 - Rename reg_number -> rounds in aes_loadkeys
 - Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19960/files
  - new: https://git.openjdk.org/jdk/pull/19960/files/c8ca0577..5facf266

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=07-08

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/19960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19960/head:pull/19960

PR: https://git.openjdk.org/jdk/pull/19960

From duke at openjdk.org  Mon Oct 21 14:41:58 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Mon, 21 Oct 2024 14:41:58 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v8]
In-Reply-To: <7LkJO2Uk02yGok4inzS9HrswA8XgWow5GP5UueViw_I=.2233bfea-f0a8-4bc1-96d4-a4a75df5d297@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <oC7V6BPzlccZd93dZPgCdAnQNKy5LAeEPEl5Z48ZmN4=.5dd29b29-9307-4a03-a282-e98c67ad3787@github.com>
 <7LkJO2Uk02yGok4inzS9HrswA8XgWow5GP5UueViw_I=.2233bfea-f0a8-4bc1-96d4-a4a75df5d297@github.com>
Message-ID: <5ok1d-bmVmzDapoSczaf_xI8FzrPWffRZSdlajjKAFs=.cfb789a2-fa6b-4a9b-a5f0-a1ee96a80d0b@github.com>

On Sun, 20 Oct 2024 04:44:01 GMT, Yanhong Zhu <yzhu at openjdk.org> wrote:

>> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use same keys for encryption and decryption
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2279:
> 
>> 2277:   }
>> 2278: 
>> 2279:   void generate_aes_loadkeys(const Register &key, VectorRegister *working_vregs, int reg_number) {
> 
> Hi, maybe `rounds` is more readable than `reg_number` here.

Renamed

> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2289:
> 
>> 2287: 
>> 2288:   void generate_aes_encrypt(const VectorRegister &res, VectorRegister *working_vregs, int reg_number) {
>> 2289:     assert(reg_number <= 15, "reg_number should be less than or equal to working_vregs size")
> 
> This lacks `;` at the end of statement, which is causing the GHA failure.

Fixed, thanks!

> src/hotspot/share/opto/library_call.cpp line 7225:
> 
>> 7223: //------------------------------get_key_start_from_aescrypt_object-----------------------
>> 7224: Node * LibraryCallKit::get_key_start_from_aescrypt_object(Node *aescrypt_object) {
>> 7225: #if defined(PPC64) || defined(S390) || defined(RISCV)
> 
> Hi, I think RISCV64 is more specific here for now.

Done!

> src/hotspot/share/opto/library_call.cpp line 7230:
> 
>> 7228:   // However, ppc64 vncipher processes MixColumns and requires the same round keys with encryption.
>> 7229:   // The ppc64 stubs of encryption and decryption use the same round keys (sessionK[0]).
>> 7230:   // The RISC-V stubs of encryption and decryption use the same round keys (sessionK[0]).
> 
> `// The ppc64 and riscv64 stubs...` would be better.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1808954921
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1808955133
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1808955095
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1808955186

From aph at openjdk.org  Mon Oct 21 14:49:47 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 21 Oct 2024 14:49:47 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v30]
In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
Message-ID: <OZmta-WXHiJmnj0A489RhNzuAiAv299Zk9TcaenFRUQ=.97167ded-db1f-4279-afaa-425f0d91b67e@github.com>

> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
> 
> HotSpot shared runtime
> ----------------------
> 
> Building hashed secondary tables is now unconditional. It takes very
> little time, and now that the shared runtime always has the tables, it
> might as well take advantage of them. The shared code is easier to
> follow now, I think.
> 
> There might be a performance issue with x86-64 in that we build
> HotSpot for a default x86-64 target that does not support popcount.
> This means that HotSpot C++ runtime on x86 always uses a software
> emulation for popcount, even though the vast majority of machines made
> for the past 20 years can do popcount in a single instruction. It
> wouldn't be terribly hard to do something about that.
> 
> Having said that, the software popcount is really not bad.
> 
> x86
> ---
> 
> x86 is rather tricky, because we still support
> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as
> well as 32- and 64-bit ports. There's some further complication in
> that only `RCX` can be used as a shift count, so there's some register
> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp
> rather gnarly, with multiple levels of conditionals at compile time
> and runtime.
> 
> AArch64
> -------
> 
> AArch64 is considerably more straightforward. We always have a
> popcount instruction and (thankfully) no 32-bit code to worry about.
> 
> Generally
> ---------
> 
> I would dearly love simply to rip out the "old" secondary supers cache
> support, but I've left it in just in case someone has a performance
> regression.
> 
> The versions of `MacroAssembler::lookup_secondary_supers_table` that
> work with variable superclasses don't take a fixed set of temp
> registers, and neither do they call out to to a slow path subroutine.
> Instead, the slow patch is expanded inline.
> 
> I don't think this is necessarily bad. Apart from the very rare cases
> where C2 can't determine the superclass to search for at compile time,
> this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
> 
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absolute performance. Nonetheless, this is a
> complicated patch that touches many areas.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Correct comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19989/files
  - new: https://git.openjdk.org/jdk/pull/19989/files/cf71c835..63e905fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19989&range=28-29

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19989/head:pull/19989

PR: https://git.openjdk.org/jdk/pull/19989

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 duke at openjdk.org  Mon Oct 21 15:37:24 2024
From: duke at openjdk.org (duke)
Date: Mon, 21 Oct 2024 15:37:24 GMT
Subject: RFR: 8341052: SHA-512 implementation using SHA-NI [v5]
In-Reply-To: <tCuaZFrrX71Rw1Xh03-1Q-yds_lqVkU0ZJ-RPLjGFoU=.3088d06c-4754-4b00-b9cb-c6b6b00850cc@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
 <tCuaZFrrX71Rw1Xh03-1Q-yds_lqVkU0ZJ-RPLjGFoU=.3088d06c-4754-4b00-b9cb-c6b6b00850cc@github.com>
Message-ID: <TF5XkTV4SaLXDoX1lYZKxCPd8trZR5A0p1pijcDb6SU=.958d07ba-2111-42a8-acd7-33ed6d66624a@github.com>

On Wed, 16 Oct 2024 23:13:45 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.
>
> Smita Kamath has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into sha-512
>  - Updated code as per review comments
>  - Addressed a review comment
>  - Updated code as per review comment & updated test case
>  - Updated AMD64.java
>  - Merge master
>  - SHA-512 implementation using SHA-NI instructions

@smita-kamath 
Your change (at version af309deb89fe33a60c635f7a2269858dc1f757c2) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20633#issuecomment-2427030286

From svkamath at openjdk.org  Mon Oct 21 15:40:19 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Mon, 21 Oct 2024 15:40:19 GMT
Subject: Integrated: 8341052: SHA-512 implementation using SHA-NI
In-Reply-To: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
References: <idfvlsT7dHCbCzAt7rQL9fuwzkZ1iJtfSar1gmstkSY=.94f14ebe-30c9-4504-9c4b-68d9edb7c4ab@github.com>
Message-ID: <hEA4sSUl6bEUoGuBRaH2ab9TRGZmc24nyaIPAOCSS-U=.e0d60428-5e5d-4937-b397-904da5fb36f6@github.com>

On Mon, 19 Aug 2024 21:34:05 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

> Hi, I want to submit an optimization for SHA-512 algorithm using SHA instructions (sha512msg1, sha512msg2 and sha512rnds2) . Kindly review the code and provide feedback. Thank you.

This pull request has now been integrated.

Changeset: 18bcbf79
Author:    Smita Kamath <svkamath at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18bcbf7941f7567449983b3f317401efb3e34d39
Stats:     271 lines in 10 files changed: 252 ins; 11 del; 8 mod

8341052: SHA-512 implementation using SHA-NI

Reviewed-by: jbhateja, ascarpino, sviswanathan, sparasa

-------------

PR: https://git.openjdk.org/jdk/pull/20633

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 duke at openjdk.org  Mon Oct 21 15:44:40 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 21 Oct 2024 15:44:40 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v5]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <cuHYppRMNdeObF4gRWF_4t48ZmBecB3OBFWITvt63PI=.498c09c1-6107-4231-af1d-a4f7567aa1db@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  accepting review suggestions from Volodymyr and Vladimir

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21352/files
  - new: https://git.openjdk.org/jdk/pull/21352/files/1b5b71f0..f007a5b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=03-04

  Stats: 35 lines in 5 files changed: 5 ins; 8 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/21352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21352/head:pull/21352

PR: https://git.openjdk.org/jdk/pull/21352

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 cnorrbin at openjdk.org  Mon Oct 21 17:34:49 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 21 Oct 2024 17:34:49 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v3]
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  missed cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21325/files
  - new: https://git.openjdk.org/jdk/pull/21325/files/f883087c..8ee9937a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325

PR: https://git.openjdk.org/jdk/pull/21325

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 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 duke at openjdk.org  Mon Oct 21 19:46:41 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 21 Oct 2024 19:46:41 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v6]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <psunjWF1OpPUTOPJJgukGEHEuQ2fHbuuKh_v4HF_MAw=.2968a9e8-9669-43c2-834a-2cd607001a83@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - fix mismerge
 - Merge master
 - accepting review suggestions from Volodymyr and Vladimir
 - Merge branch 'master' into sha3-avx512-intrinsic
 - fix windows build
 - fix debug build
 - 8341527: AVX-512 intrinsic for SHA3

-------------

Changes: https://git.openjdk.org/jdk/pull/21352/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=05
  Stats: 406 lines in 9 files changed: 401 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21352/head:pull/21352

PR: https://git.openjdk.org/jdk/pull/21352

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:34:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:34:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v11]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <C380NMLhJ_bpgd6TE5M-I0NdtCwvXnIPRssuCb6oqi0=.413c9d00-e5e5-4010-9055-ad2fc6f3f819@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @stefank comment -- changed to assert(is_pending_aot_linked_class(k), "sanity")

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/3f094645..bdba2b66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=09-10

  Stats: 15 lines in 4 files changed: 2 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Mon Oct 21 20:34:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:34:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
Message-ID: <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>

On Mon, 21 Oct 2024 07:03:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()
>
> src/hotspot/share/memory/iterator.inline.hpp line 57:
> 
>> 55:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>> 56:   } else {
>> 57:     assert_is_pending_aot_linked_class(k);
> 
> Would there be a drawback to just adding `assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");` here and skip the changes the both .hpp and .cpp files?

I changed the code to `assert(is_pending_aot_linked_class(k), "sanity")`. Since iterator.hpp is widely used, I avoid including aotLinkedClassBulkLoader.hpp in this header, and route the call through iterator.cpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809487525

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 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 iklam at openjdk.org  Mon Oct 21 21:58:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 21:58:39 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v12]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <gPFtTrXg-Kq-yklTDLd5u159H-UqwOsi87LcUO0I0oo=.11accaf6-0e0d-46a6-b5e6-e73c275c3bca@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - dholmes-ora comment - removed direct_only parameter from InstanceKlass::is_enum_subclass()
 - In respond to @ashu-mehra review: add comment about why the main module name needs to be lifted out of MetaspaceShared::serialize()
 - 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
 - @stefank comment -- changed to assert(is_pending_aot_linked_class(k), "sanity")
 - Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()
 - @rose00 comments -- tighten up the checks for what can or cannot be aot-inited; removed is_trivial_clinit() as it is used only in logging but the meaning is unclear
 - @liach comments -- added comments; added asserts for HashMap safety in MethodType.java
 - Fixed typo in last commit; fixed header inclusion order
 - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
 - 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
 - ... and 29 more: https://git.openjdk.org/jdk/compare/a9ae70e2...044f28a7

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=11
  Stats: 2729 lines in 73 files changed: 2387 ins; 144 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Mon Oct 21 21:58:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 21:58:39 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
 <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
 <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>
Message-ID: <eQWogONr__xT9ru7QPG-qLF2C1Kmx8rXJcuv8kFSoNA=.7ffb5eee-9cd0-4f60-8fbc-06892650359e@github.com>

On Fri, 18 Oct 2024 02:19:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ```
> +bool InstanceKlass::is_enum_subclass(bool direct_only) const {
> +  InstanceKlass* s = java_super();
> +  return (s == vmClasses::Enum_klass() ||
> +          (s != null && s->java_super() == vmClasses::Enum_klass()));
> +}
> ```
> 
> Just happened to notice you aren't checking `direct_only`.

I consulted with John and removed the `direct_only` parameter as it's no longer needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2427815518

From iklam at openjdk.org  Mon Oct 21 22:04:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 22:04:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <eQWogONr__xT9ru7QPG-qLF2C1Kmx8rXJcuv8kFSoNA=.7ffb5eee-9cd0-4f60-8fbc-06892650359e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
 <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
 <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>
 <eQWogONr__xT9ru7QPG-qLF2C1Kmx8rXJcuv8kFSoNA=.7ffb5eee-9cd0-4f60-8fbc-06892650359e@github.com>
Message-ID: <4sSoZGQm9sqRAT_Yumn5klSfAjZ8JoaYwPC_QELDBaw=.f5a29771-4f09-4810-b4aa-13249b948d96@github.com>

On Mon, 21 Oct 2024 21:56:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> I read through it fairly thoroughly. I made a lot of suggestions. Rather than edit comments into lots of spots in this PR, I made the following patch file. [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)
>> 
>> 
>> +bool InstanceKlass::is_enum_subclass(bool direct_only) const {
>> +  InstanceKlass* s = java_super();
>> +  return (s == vmClasses::Enum_klass() ||
>> +          (s != null && s->java_super() == vmClasses::Enum_klass()));
>> +}
>> 
>> Just happened to notice you aren't checking `direct_only`.
>
>> ```
>> +bool InstanceKlass::is_enum_subclass(bool direct_only) const {
>> +  InstanceKlass* s = java_super();
>> +  return (s == vmClasses::Enum_klass() ||
>> +          (s != null && s->java_super() == vmClasses::Enum_klass()));
>> +}
>> ```
>> 
>> Just happened to notice you aren't checking `direct_only`.
> 
> I consulted with John and removed the `direct_only` parameter as it's no longer needed.

> @iklam Changes to move main module name from modules.cpp to elsewhere do not look related to AOT-linking of indy. If so, can they be done in a separate PR.

The change is actually necessary --  the main module name used to be restored inside `MetaspaceShared::serialize()`, which happens after we decide to accept the CDS archive. When the main module doesn't match, we will disable the "archived full module graph" and keep on using the rest of the CDS archive.

With aot-linked classes, the main module is needed early to decide whether to reject a CDS archive altogether. Therefore, I needed to lift its processing our of `MetaspaceShared::serialize()` and put its information directly inside the archive file header.

(This change could have been included in https://github.com/openjdk/jdk/pull/20843 , but that might be too much work now that the review for JEP 483 is winding down).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2427822847

From sviswanathan at openjdk.org  Mon Oct 21 23:00:17 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 21 Oct 2024 23:00:17 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v6]
In-Reply-To: <psunjWF1OpPUTOPJJgukGEHEuQ2fHbuuKh_v4HF_MAw=.2968a9e8-9669-43c2-834a-2cd607001a83@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <psunjWF1OpPUTOPJJgukGEHEuQ2fHbuuKh_v4HF_MAw=.2968a9e8-9669-43c2-834a-2cd607001a83@github.com>
Message-ID: <MNIvbcsiLo_O9x54RCM1BJGD-M63rcikuYAYwWmXLeo=.109aefc2-f8e4-4791-afc6-91f09fe195c3@github.com>

On Mon, 21 Oct 2024 19:46:41 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - fix mismerge
>  - Merge master
>  - accepting review suggestions from Volodymyr and Vladimir
>  - Merge branch 'master' into sha3-avx512-intrinsic
>  - fix windows build
>  - fix debug build
>  - 8341527: AVX-512 intrinsic for SHA3

src/hotspot/cpu/x86/assembler_x86.cpp line 8547:

> 8545:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_evex()), "");
> 8546:   // TODO check what legacy_mode needs to be set to
> 8547:   InstructionAttr attributes(vector_len, /* vex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

If you notice W needs to be set to 1 for evex and is ignored for avx encoding.  To be consistent with other similar instruction definition (e.g. addsd), here vex_w could be set as VM_Version::supports_evex(). Also the attributes definition need to be followed by attributes.set_rex_vex_w_reverted(). So this should look like as below:


InstructionAttr attributes(vector_len, /* vex_w */ VM_Version::supports_evex(), /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);
attributes.set_rex_vex_w_reverted();

src/hotspot/cpu/x86/assembler_x86.cpp line 16228:

> 16226: 
> 16227: void Assembler::evpermt2d(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 16228:   assert(vector_len <= AVX_256bit ? VM_Version::supports_avx512vlbw() : VM_Version::supports_avx512bw(), "");

The evpermt2d instruction is foundational instruction and doesn't need avx512bw() so the assert could be changed to:
assert(VM_Version::supports_evex() && (vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl()), "");

src/hotspot/cpu/x86/assembler_x86.cpp line 16236:

> 16234: 
> 16235: void Assembler::evpermt2q(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 16236:   assert(vector_len <= AVX_256bit ? VM_Version::supports_avx512vlbw() : VM_Version::supports_avx512bw(), "");

The evpermt2q instruction is foundational instruction and doesn't need avx512bw() so the assert could be changed to:
assert(VM_Version::supports_evex() && (vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl()), "");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1809606398
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1809618137
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1809619156

From iklam at openjdk.org  Mon Oct 21 23:33:21 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 23:33:21 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v13]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <pmw4_RSGSke0Ts_6yfn-46CagAAY-m3Tydo5W8CnYmM=.e7923e39-3afd-4ddf-b607-a0fda3dd0bf3@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/044f28a7..07e80df8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=11-12

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From dholmes at openjdk.org  Mon Oct 21 23:54:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 23:54:22 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList
In-Reply-To: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
Message-ID: <HlrNEklFxVyccjFrqlIF_Sv2G2UQ6TjoLT3bvUX31Rk=.c168ed24-b9f1-476f-a7f1-c6c13806b970@github.com>

On Fri, 18 Oct 2024 14:44:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
> 
> Tested ok tier1-3.

I'm not really seeing the need for any code change here given that the code works fine whichever order you read them. Having a convention is not unreasonable but unless you document in the comments (in all the platform files) that there is a convention noone will remember it is there.

And given:

   if ((intptr_t(_EntryList)|intptr_t(_cxq)) == 0 || _succ != nullptr) {
      return;
    }

you don't know for sure which order the compiler will issue the loads anyway.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 480:

> 478:   membar(StoreLoad);
> 479: 
> 480:   // Check if the entry lists are empty.

Suggestion:

  // Check if the entry lists are empty (EntryList first - by convention).

src/hotspot/share/runtime/objectMonitor.cpp line 1158:

> 1156: // The race could be removed by reading cxq before EntryList, but it
> 1157: // would come with an added cost of needing a loadload fence between the
> 1158: // reads.

I think you can write this much more succinctly as this isn't really a race per-se, but part of the overall operation of the protocol. Suggestion:

// Note that we read the EntryList and then the cxq after dropping the lock, so the values need not form a stable
// snapshot. In particular, after reading the (empty) EntryList, another thread could acquire and release the lock, moving 
// any entries in the cxq to the EntryList, causing the current thread to see an empty cxq and conclude there are no
// waiters. But this is okay as the thread that moved the cxq is responsible for waking the successor.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21584#pullrequestreview-2383486636
PR Review Comment: https://git.openjdk.org/jdk/pull/21584#discussion_r1809666545
PR Review Comment: https://git.openjdk.org/jdk/pull/21584#discussion_r1809661601

From dholmes at openjdk.org  Mon Oct 21 23:54:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 23:54:22 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList
In-Reply-To: <HlrNEklFxVyccjFrqlIF_Sv2G2UQ6TjoLT3bvUX31Rk=.c168ed24-b9f1-476f-a7f1-c6c13806b970@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HlrNEklFxVyccjFrqlIF_Sv2G2UQ6TjoLT3bvUX31Rk=.c168ed24-b9f1-476f-a7f1-c6c13806b970@github.com>
Message-ID: <NAfebQGzs_uXXCNWZk3HUR_yacgV_pbEE3fstnLMRW8=.00050a53-1b6a-4e14-af25-20623369b3f9@github.com>

On Mon, 21 Oct 2024 23:40:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
>> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
>> 
>> Tested ok tier1-3.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1158:
> 
>> 1156: // The race could be removed by reading cxq before EntryList, but it
>> 1157: // would come with an added cost of needing a loadload fence between the
>> 1158: // reads.
> 
> I think you can write this much more succinctly as this isn't really a race per-se, but part of the overall operation of the protocol. Suggestion:
> 
> // Note that we read the EntryList and then the cxq after dropping the lock, so the values need not form a stable
> // snapshot. In particular, after reading the (empty) EntryList, another thread could acquire and release the lock, moving 
> // any entries in the cxq to the EntryList, causing the current thread to see an empty cxq and conclude there are no
> // waiters. But this is okay as the thread that moved the cxq is responsible for waking the successor.

Update: okay the fields are volatile so maybe the compiler will preserve the written order.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21584#discussion_r1809668294

From sviswanathan at openjdk.org  Tue Oct 22 00:14:22 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 22 Oct 2024 00:14:22 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v6]
In-Reply-To: <psunjWF1OpPUTOPJJgukGEHEuQ2fHbuuKh_v4HF_MAw=.2968a9e8-9669-43c2-834a-2cd607001a83@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <psunjWF1OpPUTOPJJgukGEHEuQ2fHbuuKh_v4HF_MAw=.2968a9e8-9669-43c2-834a-2cd607001a83@github.com>
Message-ID: <CJ4_sVcBOjN-sdJV-FS75xoJQniMDm2Pj1SyK93I9wc=.c1a4c045-3fcd-4846-892d-a1f04eb82fcd@github.com>

On Mon, 21 Oct 2024 19:46:41 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - fix mismerge
>  - Merge master
>  - accepting review suggestions from Volodymyr and Vladimir
>  - Merge branch 'master' into sha3-avx512-intrinsic
>  - fix windows build
>  - fix debug build
>  - 8341527: AVX-512 intrinsic for SHA3

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 138:

> 136: 
> 137:   // set up the masks
> 138:   __ mov64(rax, 0x1F);

This could just be a movl or movd.

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 147:

> 145:   __ kmovwl(k2, rax);
> 146:   __ shrl(rax, 1);
> 147:   __ kmovwl(k1, rax);

The same could be achieved by:
__ kshiftrwl(k4, k5, 1);
__ kshiftrwl(k3, k5, 2);
__ kshiftrwl(k2, k5, 3);
__ kshiftrwl(k1, k5, 4);

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 288:

> 286:     __ movq(rax, ofs); // return ofs
> 287:   } else {
> 288:     __ mov64(rax, 0);

This could be  xorq(rax, rax).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1809659854
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1809661605
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1809672304

From iklam at openjdk.org  Tue Oct 22 00:58:00 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 00:58:00 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v14]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <ltzOrCWNuzNN9KsCSNz-sHI8Rjz-z081xrgBUJV3yJ4=.15dd43dc-5fc8-4473-a40e-d4abce4aac41@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - @ashu-mehra comments: renamed to find_required_hidden_classes(), etc, and added checks for only hidden classes
 - fixed minimal build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/07e80df8..6916e187

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=12-13

  Stats: 56 lines in 9 files changed: 18 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Tue Oct 22 00:58:00 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 00:58:00 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <bawYxEbNMLLsVKFAcdwD3Bu_Zoc1_5w0kpIU8OJB9D4=.21544e14-d107-49bf-9d00-afa56b6bf63d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
 <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>
 <bawYxEbNMLLsVKFAcdwD3Bu_Zoc1_5w0kpIU8OJB9D4=.21544e14-d107-49bf-9d00-afa56b6bf63d@github.com>
Message-ID: <K4faLPg0OMoaGveUB8xAJauKq78p2uCy-GPpCfWtlUs=.81eb16e9-78e3-49da-966c-3c0e4b12da1c@github.com>

On Fri, 18 Oct 2024 05:39:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `Class::reflectionFactory` is a large table that must be cleared, or else we will bring unwanted (unsupported) objects into the cache.
>> 
>> During runtime, `reflectionFactory` will be initialized on demand, so there's no need to explicitly create it with `runtimeSetup`.
>
> That said, can reflectionFactory field be stable in the future with this?

Perhaps. In the Leyden repo we are doing some optimizations for reflection. See the `ArchiveReflectionData` flag in the Leyden premain repo.. I am not sure if `reflectionFactory` itself needs to be cached.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809702708

From iklam at openjdk.org  Tue Oct 22 01:10:29 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 01:10:29 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <vlnQGlbG7NDzWUc_gJWL6qO7pDIfmnww-JBHGiH-2zs=.3a3e0644-ea17-42aa-96de-d0d024e19f87@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
 <vlnQGlbG7NDzWUc_gJWL6qO7pDIfmnww-JBHGiH-2zs=.3a3e0644-ea17-42aa-96de-d0d024e19f87@github.com>
Message-ID: <wkQOXn5_fy6Il0KzTdwUMfs9Ox5f-rdjUASXzaFwuy8=.095b506d-31c9-42f0-b89b-8f84e5402056@github.com>

On Wed, 16 Oct 2024 23:16:00 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo in last commit; fixed header inclusion order
>
> src/hotspot/share/cds/dumpTimeClassInfo.hpp line 45:
> 
>> 43:   bool                         _is_early_klass;
>> 44:   bool                         _has_checked_exclusion;
>> 45:   bool                         _is_required;
> 
> Is this flag only used for hidden classes?

I changed it to `_is_required_hidden_class`.

> src/hotspot/share/cds/heapShared.cpp line 717:
> 
>> 715: };
>> 716: 
>> 717: void HeapShared::find_archivable_hidden_classes_in_object(oop root) {
> 
> If this function find archivable hidden classes, shouldn't there be a check for`is_hidden()` on the InstanceKlass being marked as `required`. Am I missing something?

I added the `ik->is_hidden()` check as you suggested. I also renamed the `find_archivable_hidden_classes_xxx` functions to `find_required_hidden_classes_xxx()`. This is to avoid confusion with `HeapShared::is_archivable_hidden_klass()`, which means "it is possible to archive X", but not "it is necessary to archive X".

> src/hotspot/share/cds/heapShared.cpp line 790:
> 
>> 788: 
>> 789:   init_seen_objects_table();
>> 790:   {
> 
> Why was this scope introduced?

To indicate that these calls must be made while the "see objects" table is available.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 675:
> 
>> 673: 
>> 674: // Returns true if the class should be excluded. This can be called before
>> 675: // SystemDictionaryShared::check_excluded_classes().
> 
> There are a couple of references to check_excluded_classes() in the comments but this function no longer exists. Can you please update the comment accordingly.

I replaced with the new name of the function `find_all_archivable_classes()`.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 759:
> 
>> 757:       if (k->is_hidden() && should_hidden_class_be_archived(k)) {
>> 758:         SystemDictionaryShared::check_for_exclusion(k, &info);
>> 759:         if (info.is_excluded()) {
> 
> Is it possible that a hidden class for which `should_hidden_class_be_archived()` returns true is marked for exclusion by `SDS::check_for exclusion`? I guess only possibility is if for some reason its super or interface is excluded. Is that possible?

We filter out hidden classes that cannot be supported (e.g., when a Lambda uses an interface using "old" bytecodes). See

https://github.com/openjdk/jdk/pull/21143/files#diff-fc60af483d061250f01054372fd56eba517a6b8dd37a742a66dfb0e15cb68e40R366-R372

https://github.com/openjdk/jdk/pull/21143/files#diff-2520dedd703ec600cd3037ec0008e9d7f45c6a41acaefac019339641bc749163R149-R152

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709541
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709627
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709670
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709979
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809710069

From jwaters at openjdk.org  Tue Oct 22 01:22:26 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 01:22:26 GMT
Subject: RFR: 8342769: gcc port broken on HotSpot
Message-ID: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>

Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight withing SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

-------------

Commit messages:
 - 8342769

Changes: https://git.openjdk.org/jdk/pull/21627/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342769
  Stats: 69 lines in 6 files changed: 33 ins; 31 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From dholmes at openjdk.org  Tue Oct 22 02:08:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 02:08:14 GMT
Subject: RFR: 8342769: gcc port broken on HotSpot
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>

On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight withing SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

The sharedRuntime stuff is tricky and messy. Not sure about what is best/right/workable there. Maybe we even need to factor out like ./os/windows/sharedRuntimeRem.cpp?

src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 102:

> 100: const julong double_sign_mask = CONST64(0x7FFFFFFFFFFFFFFF);
> 101: const julong double_infinity  = CONST64(0x7FF0000000000000);
> 102: #endif

Isn't all this better suited for sharedRuntime_x86_64.cpp?

src/hotspot/os/windows/memMapPrinter_windows.cpp line 178:

> 176:     st->print("%s-%s", mapping_info._state_buffer.base(), mapping_info._type_buffer.base());
> 177:     INDENT_BY(63);
> 178:     st->print("%#11llx", reinterpret_cast<unsigned long long>(mem_info.BaseAddress) - reinterpret_cast<unsigned long long>(mem_info.AllocationBase));

What is the issue with const here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21627#pullrequestreview-2383602156
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1809742941
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1809742617

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 kbarrett at openjdk.org  Tue Oct 22 03:41:16 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Oct 2024 03:41:16 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <SttIpkWPsz0JZa0v9H9HDLjb2qd25scHpr-rolPTTUQ=.71bbfc92-f6af-4d2b-ab86-224b0e96c6f8@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
 <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
 <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>
 <SttIpkWPsz0JZa0v9H9HDLjb2qd25scHpr-rolPTTUQ=.71bbfc92-f6af-4d2b-ab86-224b0e96c6f8@github.com>
Message-ID: <HJF3NaBZVaT23sdZh3snmKft3PRiqIfNLEfPjlsYNjk=.07974901-48dc-41e3-a8b1-d37d0897c791@github.com>

On Mon, 21 Oct 2024 08:10:45 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Ubsan is just following the C++ standard 
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
>> 5.6 Multiplicative operators  
>>  ....
>> 'The binary / operator yields the quotient, and the binary % operator yields the remainder from the division
>> of the first expression by the second. If the second operand of / or % is zero the behavior is undefined.'
>> 
>> See also https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero .
>> 
>> However on our set of platforms in OpenJDK we probably get away with the expected results when dividing by 0  (because they all seem to follow IEEE-754).
>> That's why I just added the static_assert.
>
> To me, this feels like the C++ standard is not compatible with IEEE-754 arithmetic. Undefined behavior would give the optimizer freedom to do whatever it likes to do. That is in contrast to the well-defined IEEE-754 requirement.

`ATTRIBUTE_NO_UBSAN` suppresses conditions found by ubsan instrumentation. If
ubsan is enabled, the compiler's optimizer presumably doesn't take advantage
of the no-UB assumption, as that would defeat the point of ubsan. But in a
non-ubsan-enabled build, I think that attribute does nothing and the compiler
may take advantage of the no-UB assumption. So that part of the change may not
do anything useful for non-ubsan builds.

cppreference is inconsistent about this. It first states that division by zero
is UB, as per the standard. But then it says if the type `is_iec599`, then
division by zero returns the IEEE defined value (correctly signed infinity if
lhs is non-zero, NaN if lhs is zero) and raises the appropriate floating point
trap. I think this claim makes sense for a C compiler that supports Annex F.
But C++ isn't C, and I don't see anything comparable in a C++ standard.

I can't find any text in any version of either the C or C++ standard to
support the claimed `is_iec599` behavior though.

I did find this, which has some interesting bits.
https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero

For example, it is suggested that claiming `is_iec599` implicity defines the
behavior for floating point division by zero (among other things). It is also
mentioned that gcc does that, but (some version of?) clang-the-compiler
doesn't implement iec599, even though the standard library one is using might
claim so. Hm...

It also mentions that the default for `-fsanitize=undefined` for clang includes
`float-divide-by-zero`, while gcc does not.  Any chance the reported issue is
arising with clang as the compiler?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1809801664

From jwaters at openjdk.org  Tue Oct 22 03:44:12 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 03:44:12 GMT
Subject: RFR: 8342769: gcc port broken on HotSpot
In-Reply-To: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
Message-ID: <Xt5ipBMoWKcb0Wq8p6NSFUPt2svRVkmOD4Pn4xJK8k4=.6d425642-eb58-4702-9333-4b11f12a1197@github.com>

On Tue, 22 Oct 2024 02:02:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight withing SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> src/hotspot/os/windows/memMapPrinter_windows.cpp line 178:
> 
>> 176:     st->print("%s-%s", mapping_info._state_buffer.base(), mapping_info._type_buffer.base());
>> 177:     INDENT_BY(63);
>> 178:     st->print("%#11llx", reinterpret_cast<unsigned long long>(mem_info.BaseAddress) - reinterpret_cast<unsigned long long>(mem_info.AllocationBase));
> 
> What is the issue with const here?

More a correctness issue. The const is not required since the cast result is an rvalue unsigned long long. It's similar to something like a method's return type being marked as `const int get();` where the const doesn't really mean anything since there is no possible way for it to be modified

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1809803408

From jwaters at openjdk.org  Tue Oct 22 03:48:11 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 03:48:11 GMT
Subject: RFR: 8342769: gcc port broken on HotSpot
In-Reply-To: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
Message-ID: <CuOj12vy1DIujX5OKFyYKCpkO4zeEvpYoc7FbODJQMk=.ad5296f2-0590-451d-942c-22fc3063a19f@github.com>

On Tue, 22 Oct 2024 02:03:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 102:
> 
>> 100: const julong double_sign_mask = CONST64(0x7FFFFFFFFFFFFFFF);
>> 101: const julong double_infinity  = CONST64(0x7FF0000000000000);
>> 102: #endif
> 
> Isn't all this better suited for sharedRuntime_x86_64.cpp?

You mean the entire custom frem and drem implementation unique to x64 Windows, or just this block of constants here? These constants are used by the custom Windows implementation, so they have to be in the same file. Moving the entire definition for Windows x64 to sharedRuntime_x86_64.cpp seems to be duplicating code even more, and I still don't know whether this is the right solution. It may be that this custom implementation may not be needed anymore and should be removed, which is why I left it in the sharedRuntime_x86.cpp file for the time being

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1809806538

From kbarrett at openjdk.org  Tue Oct 22 03:51:14 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Oct 2024 03:51:14 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <HJF3NaBZVaT23sdZh3snmKft3PRiqIfNLEfPjlsYNjk=.07974901-48dc-41e3-a8b1-d37d0897c791@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
 <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
 <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>
 <SttIpkWPsz0JZa0v9H9HDLjb2qd25scHpr-rolPTTUQ=.71bbfc92-f6af-4d2b-ab86-224b0e96c6f8@github.com>
 <HJF3NaBZVaT23sdZh3snmKft3PRiqIfNLEfPjlsYNjk=.07974901-48dc-41e3-a8b1-d37d0897c791@github.com>
Message-ID: <8h5zGu1hxUZk4wloON39CCcUfKhlt33Ya_zlDAmd3gc=.38adb012-3049-4224-8a31-190f73271db2@github.com>

On Tue, 22 Oct 2024 03:38:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> To me, this feels like the C++ standard is not compatible with IEEE-754 arithmetic. Undefined behavior would give the optimizer freedom to do whatever it likes to do. That is in contrast to the well-defined IEEE-754 requirement.
>
> `ATTRIBUTE_NO_UBSAN` suppresses conditions found by ubsan instrumentation. If
> ubsan is enabled, the compiler's optimizer presumably doesn't take advantage
> of the no-UB assumption, as that would defeat the point of ubsan. But in a
> non-ubsan-enabled build, I think that attribute does nothing and the compiler
> may take advantage of the no-UB assumption. So that part of the change may not
> do anything useful for non-ubsan builds.
> 
> cppreference is inconsistent about this. It first states that division by zero
> is UB, as per the standard. But then it says if the type `is_iec599`, then
> division by zero returns the IEEE defined value (correctly signed infinity if
> lhs is non-zero, NaN if lhs is zero) and raises the appropriate floating point
> trap. I think this claim makes sense for a C compiler that supports Annex F.
> But C++ isn't C, and I don't see anything comparable in a C++ standard.
> 
> I can't find any text in any version of either the C or C++ standard to
> support the claimed `is_iec599` behavior though.
> 
> I did find this, which has some interesting bits.
> https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero
> 
> For example, it is suggested that claiming `is_iec599` implicity defines the
> behavior for floating point division by zero (among other things). It is also
> mentioned that gcc does that, but (some version of?) clang-the-compiler
> doesn't implement iec599, even though the standard library one is using might
> claim so. Hm...
> 
> It also mentions that the default for `-fsanitize=undefined` for clang includes
> `float-divide-by-zero`, while gcc does not.  Any chance the reported issue is
> arising with clang as the compiler?

Never mind my question about whether this was happening with clang as the compiler rather than gcc.
Our ubsan configuration explicitly includes `-fsantize=float-divide-by-zero`.
https://github.com/openjdk/jdk/blame/8bcd4920f1b03d0ef8e295e53557c629f05ceaa4/make/autoconf/jdk-options.m4#L516

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1809808536

From jwaters at openjdk.org  Tue Oct 22 03:52:11 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 03:52:11 GMT
Subject: RFR: 8342769: gcc port broken on HotSpot
In-Reply-To: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
Message-ID: <VzU5ViGI5CNaMdkNP3tY0JcGfuDSoPQwogc45LSNXi0=.478b0780-b2d1-4643-a308-8878cc916bd0@github.com>

On Tue, 22 Oct 2024 02:04:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The sharedRuntime stuff is tricky and messy. Not sure about what is best/right/workable there. Maybe we even need to factor out like ./os/windows/sharedRuntimeRem.cpp?

I'm not sure what is best too. I think we might need more people looking at this, in particular Windows ARM64 maintainers, because they might be the only platform that this change will affect. Some in the mailing lists mentioned that fmod_winx64 might not be needed anymore and could be removed entirely

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2428153963

From iklam at openjdk.org  Tue Oct 22 04:04:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 04:04:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v15]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <ljzL27S6RRkk3XHppu_OQxwcWtGrcSLDjm2HqwZA324=.a0d97a9d-8215-426c-a9a9-d04c9ebdafc6@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed JDK-8342732: java/lang/invoke/MethodTypeSecurityManager.java fails with "should never leak JDK internal class" in case AOTClassLinking enabled
 - Fixed JDK-8342723: Crash with "assert(_instance != nullptr) failed: cannot enqueue events before the service thread runs" in case AOTClassLinking enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/6916e187..d3663890

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=13-14

  Stats: 17 lines in 4 files changed: 15 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From darcy at openjdk.org  Tue Oct 22 04:14:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 04:14:21 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <8h5zGu1hxUZk4wloON39CCcUfKhlt33Ya_zlDAmd3gc=.38adb012-3049-4224-8a31-190f73271db2@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
 <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
 <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>
 <SttIpkWPsz0JZa0v9H9HDLjb2qd25scHpr-rolPTTUQ=.71bbfc92-f6af-4d2b-ab86-224b0e96c6f8@github.com>
 <HJF3NaBZVaT23sdZh3snmKft3PRiqIfNLEfPjlsYNjk=.07974901-48dc-41e3-a8b1-d37d0897c791@github.com>
 <8h5zGu1hxUZk4wloON39CCcUfKhlt33Ya_zlDAmd3gc=.38adb012-3049-4224-8a31-190f73271db2@github.com>
Message-ID: <9bdBznqfxmAolEvznsHK4XktMI_kVSmKoDG3lngYxwI=.fd5393f3-e3eb-45ce-8278-bee41d715007@github.com>

On Tue, 22 Oct 2024 03:48:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> `ATTRIBUTE_NO_UBSAN` suppresses conditions found by ubsan instrumentation. If
>> ubsan is enabled, the compiler's optimizer presumably doesn't take advantage
>> of the no-UB assumption, as that would defeat the point of ubsan. But in a
>> non-ubsan-enabled build, I think that attribute does nothing and the compiler
>> may take advantage of the no-UB assumption. So that part of the change may not
>> do anything useful for non-ubsan builds.
>> 
>> cppreference is inconsistent about this. It first states that division by zero
>> is UB, as per the standard. But then it says if the type `is_iec599`, then
>> division by zero returns the IEEE defined value (correctly signed infinity if
>> lhs is non-zero, NaN if lhs is zero) and raises the appropriate floating point
>> trap. I think this claim makes sense for a C compiler that supports Annex F.
>> But C++ isn't C, and I don't see anything comparable in a C++ standard.
>> 
>> I can't find any text in any version of either the C or C++ standard to
>> support the claimed `is_iec599` behavior though.
>> 
>> I did find this, which has some interesting bits.
>> https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero
>> 
>> For example, it is suggested that claiming `is_iec599` implicity defines the
>> behavior for floating point division by zero (among other things). It is also
>> mentioned that gcc does that, but (some version of?) clang-the-compiler
>> doesn't implement iec599, even though the standard library one is using might
>> claim so. Hm...
>> 
>> It also mentions that the default for `-fsanitize=undefined` for clang includes
>> `float-divide-by-zero`, while gcc does not.  Any chance the reported issue is
>> arising with clang as the compiler?
>
> Never mind my question about whether this was happening with clang as the compiler rather than gcc.
> Our ubsan configuration explicitly includes `-fsantize=float-divide-by-zero`.
> https://github.com/openjdk/jdk/blame/8bcd4920f1b03d0ef8e295e53557c629f05ceaa4/make/autoconf/jdk-options.m4#L516

> I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?

Catching up on email, whatever the appropriate C/C++ idiom is, it is appropriate for this file to assert "use IEEE 754 semantics for floating-point operations." The divide by zero behavior is well-defined by IEEE 754/IEC 559.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1809827572

From john.r.rose at oracle.com  Tue Oct 22 04:49:33 2024
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 21 Oct 2024 21:49:33 -0700
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <pgNVGyhN6uSCgipzMJeUoJd0BMJnb9qa-7Hpn6EWz6M=.8d294031-08a7-4450-a7af-1f46bb159436@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
 <pgNVGyhN6uSCgipzMJeUoJd0BMJnb9qa-7Hpn6EWz6M=.8d294031-08a7-4450-a7af-1f46bb159436@github.com>
Message-ID: <EF4DE7C2-4045-4D82-86FD-22591E98C405@oracle.com>

On 15 Oct 2024, at 12:35, Ioi Lam wrote:

> On Tue, 15 Oct 2024 19:08:20 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>
>>> 597:
>>> 598:     /** Number of CPUS, to place bounds on some sizings */
>>> 599:     static @Stable int NCPU;
>>
>> I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.
>
> We have been archiving `ConcurrentHashMap` objects for many JDK releases (to support archiving of modules) and `NCPU` would change between CDS archive dump time and program run time. We have not seen any problems, so I think it's safe to use the `@Stable` annotation.

Is it necessary to get constant folding from NCPU?  I guess a division is slow, but it does not seem to be a hot path, at all.  The division is not in any loop.  If there is no performance issue, it?s perhaps more honest just to use a mutable variable.  I guess what we need here is something that means ?stable except for AOT activity?.

Normally, making something stable means it should be used according to the contract of stable, which is only one second value, and no third, after the initial default.

There is a sub-rosa contract, as well, which is that we can add third values if they do not conflict with the second values.  But we have to convince ourselves that is safe, because the second and third values can (in general) co-exist as folded constants in JIT code.

We currently refuse to fold stable constants in AOT code (and there?s no AOT code in this JEP anyway) so the AOT-only stable binding is tolerable.

Here?s what I think we should do later (not in this PR):  Amend the contract for @Stable that the value is allowed to be different during the AOT assembly phase than later.  Working out the details will require some discussion:  Should the AOT-AP reset stable values that need new bindings?  (Probably??)  Or should there be a warmup method that takes full responsibility for managing the stable value during the production run?

For now, I?m content to make this guy NCPU either stable or not.  But it is clear that, along with other details, we will need an amended story for the life-cycle of a stable variable that includes the AOT assembly phase.

Eventually, something like this may well play into a similar Leyden story for user-visible stables.  Those would be declared by an object API, not the private annotation we use in the JDK.  User-visible stable objects are likely to be wrappers for JDK-level stable-annotated fields, and that?s how the turtles tend to stack up.

No PR change requested here!

From dholmes at openjdk.org  Tue Oct 22 04:57:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 04:57:17 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v3]
In-Reply-To: <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>
Message-ID: <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>

On Mon, 21 Oct 2024 17:34:49 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed cleanup

This is a lot clearer now - thanks. Though I confess I still have some trouble following the `len` parameter through all the code paths.

A few minor suggestions and some queries.

Thanks

src/hotspot/share/classfile/javaClasses.hpp line 186:

> 184:   static unsigned int hash_code(const char *utf8_str, int utf8_len) {
> 185:     unsigned int h = 0;
> 186:     int num_unicode_points = UTF8::unicode_length(utf8_str, utf8_len);

Suggestion:

    int unicode_length = UTF8::unicode_length(utf8_str, utf8_len);

It is clearer to always use the same name for the local assigned from `UTF8::unicode_length`.

src/hotspot/share/classfile/javaClasses.hpp line 188:

> 186:     int num_unicode_points = UTF8::unicode_length(utf8_str, utf8_len);
> 187: 
> 188:     jchar a;

Suggestion:

    jchar c;

Use a consistent pattern for this.

src/hotspot/share/classfile/stringTable.cpp line 144:

> 142:     return java_lang_String::hash_code(wrapped_str.utf8_str, len);
> 143:   }
> 144:   ShouldNotReachHere();

Suggestion:

  case default:
    ShouldNotReachHere();
  }

src/hotspot/share/classfile/stringTable.cpp line 159:

> 157:     return java_lang_String::equals(java_string, wrapped_str.utf8_str, len);
> 158:   }
> 159:   ShouldNotReachHere();

Suggestion:

 case default:
   ShouldNotReachHere();
 }

src/hotspot/share/classfile/stringTable.cpp line 434:

> 432:   }
> 433:   }
> 434:   ShouldNotReachHere();

Suggestion:

  case default:
    ShouldNotReachHere();
    }

src/hotspot/share/classfile/stringTable.cpp line 449:

> 447:     return java_lang_String::create_from_str(wrapped_str.utf8_str, THREAD);
> 448:   }
> 449:   ShouldNotReachHere();

Suggestion:

  case default:
    ShouldNotReachHere();
  }

src/hotspot/share/classfile/stringTable.cpp line 473:

> 471: oop StringTable::intern(const char* utf8_string, TRAPS) {
> 472:   if (utf8_string == nullptr) return nullptr;
> 473:   int length = static_cast<int>(strlen(utf8_string));

Is the source for such a string always a constant pool entry, and so known to < 64K in length?

src/hotspot/share/classfile/stringTable.cpp line 491:

> 489:     // Convert to unicode for alt hashing
> 490:     int length = len;
> 491:     const jchar *chars = to_unicode(name, length, CHECK_NULL);

Suggestion:

    const jchar* chars = to_unicode(name, length, CHECK_NULL);

src/hotspot/share/oops/symbol.hpp line 262:

> 260: 
> 261:   // Returns the non-null-terminated utf8 string stored in the symbol
> 262:   const char* get_utf8() const { return reinterpret_cast<const char*>(bytes()); }

Not sure this really helps as it will cause confusion between `as_utf8` and `get_utf8`. A `Symbol` is a canonicalized string in modified UTF8 form - so `bytes` is that raw representation.

test/hotspot/gtest/classfile/test_stringConversion.cpp line 30:

> 28: // Tests that string functions (hash code/equals) stay consistant when comparing equal strings and converting between strings types
> 29: 
> 30: // Simple ASCII string " Java(R)!! "

Suggestion:

// Simple ASCII string "Java(R)!!"

Please remove leading and trailing space within the quotes in all cases.

test/hotspot/gtest/classfile/test_stringConversion.cpp line 35:

> 33: static const jchar static_ascii_unicode_str[] = {0x004A, 0x0061, 0x0076, 0x0061, 0x0028, 0x0052, 0x0029, 0x0021, 0x0021};
> 34: 
> 35: // Complex string " Ja?v??!?? ", UTF8 has character lengths 13122133 = 16

Not sure it is okay to have those special characters in the source code. ??

test/hotspot/gtest/classfile/test_stringConversion.cpp line 36:

> 34: 
> 35: // Complex string " Ja?v??!?? ", UTF8 has character lengths 13122133 = 16
> 36: static const unsigned char static_utf8_str[] = {0x4A, 0x61, 0xCC, 0x84, 0x76, 0xC3, 0xA1, 0xC2, 0xAE, 0x21, 0xE2, 0x98, 0xBA, 0xE2, 0x98, 0xBB};

0x61 is `a` not a-with-tilde ??

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2383720565
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809823372
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809823686
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809825027
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809825653
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809900301
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809902426
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809912885
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809913933
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809820730
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809931686
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809927400
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1809938717

From yzhu at openjdk.org  Tue Oct 22 05:45:14 2024
From: yzhu at openjdk.org (Yanhong Zhu)
Date: Tue, 22 Oct 2024 05:45:14 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v9]
In-Reply-To: <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
Message-ID: <HtE9EqSLVFkt8iSl4hi5uVWUU5Gj-ogh3t5kTbPld3s=.afffce40-7cc6-40ff-b861-ca94286aabe9@github.com>

On Mon, 21 Oct 2024 14:41:57 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Use RISCV64 instead of RISCV
>  - Fixed comment line
>  - Rename reg_number -> rounds in aes_loadkeys
>  - Fix typo

Thanks for the update. Do you mind several more minor cleanups? Looks good to me otherwise. Thanks.
[addon-cleanup.diff.txt](https://github.com/user-attachments/files/17470674/addon-cleanup.diff.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19960#issuecomment-2428306715

From iklam at openjdk.org  Tue Oct 22 06:22:43 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:22:43 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v16]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <gJaAuNIdvxZRKNY5zolFrSOFAWelTOJjw-OVkLVcayY=.e6cf05aa-b8aa-4ab7-9d86-5fb0d59da067@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with three additional commits since the last revision:

 - 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)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/d3663890..021466dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=14-15

  Stats: 90 lines in 7 files changed: 40 ins; 30 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Tue Oct 22 06:26:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:26:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
Message-ID: <flDY6rbsejKhpqlU2AfvCm4fDGMDur6ZDGsfRRPeQYk=.2153a882-98ee-45cf-bd43-d116ccc22921@github.com>

On Mon, 14 Oct 2024 15:54:15 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>
> src/hotspot/share/cds/archiveUtils.cpp line 377:
> 
>> 375:   if (SystemDictionaryShared::is_excluded_class(src_ik)) {
>> 376:     return false;
>> 377:   }
> 
> Do we want an assert here that `ArchiveBuilder::current()->get_buffered_addr(src_ik)->has_aot_initialized_mirror() == false`?

These classes are not buffered so `ArchiveBuilder::current()->get_buffered_addr(src_ik)` won't work. I added this assert instead.


  if (SystemDictionaryShared::is_excluded_class(src_ik)) {
    assert(!ArchiveBuilder::current()->has_been_buffered(src_ik), "sanity");
    return false;
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810019800

From iklam at openjdk.org  Tue Oct 22 06:26:27 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:26:27 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <54Mbb-RA8vascKhl9W2lI103ZF9HqQ_I0x1Rx7wdaeI=.07cf9872-c5fa-45a8-ae9e-617a7f418381@github.com>

On Tue, 15 Oct 2024 15:12:44 GMT, Dan Heidinga <heidinga 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 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - 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
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - 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
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/cds/heapShared.cpp line 457:
> 
>> 455:   if (HeapShared::is_archivable_hidden_klass(ik)) {
>> 456:     // We can't rerun the <clinit> method of hidden classes as we don't save
>> 457:     // the classData, so we must archive its mirror in initialized state.
> 
> Is this comment still accurate?  It looks like we do save the class_data on line 506

This comment is obsolete. Also, we won't come for any class unless it's already initialized. So I deleted the comment and changed the assert to this for all classes


assert(ik->is_initialized(), "must be");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810021339

From iklam at openjdk.org  Tue Oct 22 06:30:29 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:30:29 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <P2bNpw2Ke20lBr7tLUfXdnwjqmPiEFqBchB2naVSgJ4=.c42ea920-e67c-4312-ad82-e11944747168@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
 <P2bNpw2Ke20lBr7tLUfXdnwjqmPiEFqBchB2naVSgJ4=.c42ea920-e67c-4312-ad82-e11944747168@github.com>
Message-ID: <i7GqBMUjKs6UKJcZEaWC7JVeT76kdGhun0wconArtQ0=.dd612fd7-150b-46ac-b968-a7e1459c9420@github.com>

On Wed, 16 Oct 2024 22:56:06 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo in last commit; fixed header inclusion order
>
> src/hotspot/share/cds/heapShared.cpp line 675:
> 
>> 673:     const char* klass_name = info->klass_name;
>> 674:     for (; fields[i].valid(); i++) {
>> 675:       ArchivableStaticFieldInfo* f = &fields[i];
> 
> It looks like the pattern of nested for-loops is copied from HeapShared::archive_object_subgraphs()
> but this pattern doesn't seem to give any advantage here. If so can we replace it with just single for loop to make it easier to understand?

I changed it to a single loop as suggested.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 775:
> 
>> 773:   // Now, all hidden classes that have not yet been scanned must be marked as excluded
>> 774:   auto exclude_remaining_hidden = [&] (InstanceKlass* k, DumpTimeClassInfo& info) {
>> 775:     if (k->is_hidden() && !info.has_checked_exclusion()) {
> 
> Suggestion: Check for `has_checked_exclusion()` is not really required as the call to `SDS::check_for_exclusion()` does that. And the condition in `guarantee()` can be updated as `info.is_excluded() || info.is_required()`.

I changed the code to the following to make sure that `should_hidden_class_be_archived(k)` is mutually exclusive with `info.is_excluded()`.


  auto exclude_remaining_hidden = [&] (InstanceKlass* k, DumpTimeClassInfo& info) {
    if (k->is_hidden()) {
      SystemDictionaryShared::check_for_exclusion(k, &info);
      if (CDSConfig::is_dumping_invokedynamic()) {
        if (should_hidden_class_be_archived(k)) {
          guarantee(!info.is_excluded(), "Must be");
        } else {
          guarantee(info.is_excluded(), "Must be");
        }
      }
    }
  };


Unfortunately I can do this only for `CDSConfig::is_dumping_invokedynamic()`. In the "legacy CDS" mode of lambda support, we actually would return true from `should_hidden_class_be_archived(k)` and then later decide to exclude `k`.

> src/hotspot/share/oops/constantPool.cpp line 340:
> 
>> 338:     src_cp->iterate_archivable_resolved_references([&](int rr_index) {
>> 339:       keep_resolved_refs.at_put(rr_index, true);
>> 340:       });
> 
> Indentation seems off here

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810025512
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810025031
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810025626

From iklam at openjdk.org  Tue Oct 22 06:32:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:32:55 GMT
Subject: RFR: 8293187: Store initialized Enum classes in AOTCache [v16]
In-Reply-To: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
References: <OEELZe5CFIis1Ptt1ud5ImEmokcz4-YuIguQ0WqE_6E=.6596bd43-6861-4a0d-9c3b-f82fcf05c07f@github.com>
Message-ID: <wfRb2fIIGq7mzQdcIzFMKD3PCyocRKHU2zOlOjPliNA=.1bd9e68e-9f2e-43e7-bf8b-7573df7ca1d5@github.com>

> This is the 4th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Problem:**
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store [`sun.invoke.util.Wrapper`](https://github.com/openjdk/jdk/blob/c3711dc90980fb3e63ff199612c201c4464626bf/src/java.base/share/classes/sun/invoke/util/Wrapper.java) enums in the AOT cache. Although CDS has some limited support for storing enums, the `Wrapper` type is too complex for the existing solution to handle. Please see the JBS issue for details.
> 
> **Solution:**
> 
> In the assembly phase, we store the initialized states of the `Wrapper` class (captured in a `java.lang.Class` object, a.k.a. the *mirror* of this class) into the AOT cache. 
> 
> In production run, we no longer execute `Wrapper::<clinit>`, because all the static fields (contained in its mirror) are already initialized.
> 
> **Review Notes:**
> 
> - The new capability is controlled by `CDSConfig::is_initing_classes_at_dump_time()`. We can aot-initialize classes only if `-XX:+AOTClassLinking`  is enabled.
>     - The old (more limited) support for enums is still there (it's required when `AOTClassLinking` is disabled). See the call to `CDSEnumKlass::handle_enum_obj()` in heapShared.cpp. 
> - `AOTClassInitializer::can_archive_initialized_mirror()` decides what classes can be aot-initialized. This is currently a very small set of classes, but will expand in [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336)
> - Before, `HeapShared::archive_java_mirrors()` would clear out all the states in the archived mirrors. With this PR, the states of aot-initialized classes are preserved via `HeapShared::copy_aot_initialized_mirror()`.
> - During the early state of the production run, `AOTLinkedClassBulkLoader::init_required_classes_for_loader()` is called to make sure that:
>     - all aot-initialized classes are moved into the `initialized` state (without executing its `<clinit>` method). This is done in `InstanceKlass::initialize_from_cds()`
>     - the classes of all the objects that are reachable from the aot-initialized mirrors are initialized. See comments above ` HeapShared::init_classes_reachable_from_archived_mirrors()` 
> 
> **Caveats:**
> 
> Not all Enum classes can be stored in the initialized state. E.g., some Enums might have static fields that depend on the environment:
> 
> 
> enum Foo {
>     [....]
>     static fin...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - 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
 - 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
 - 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
 - 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
 - Adjust TEST.groups after merge with mainline
 - For aot-inited classes, require the <clinit> of all supertypes to be executed in assembly phase as well
 - changed dumptime_xxx to dump_time_xxx to be consistent with other fields in heapShared.hpp
 - comments from @adinn and @ashu-mehra
 - 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
 - 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
 - ... and 17 more: https://git.openjdk.org/jdk/compare/9d3d8bd9...6affd393

-------------

Changes: https://git.openjdk.org/jdk/pull/20958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20958&range=15
  Stats: 990 lines in 20 files changed: 878 ins; 25 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/20958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20958/head:pull/20958

PR: https://git.openjdk.org/jdk/pull/20958

From iklam at openjdk.org  Tue Oct 22 06:35:04 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:35:04 GMT
Subject: RFR: 8293337: Store method handle intrinsics in AOT cache [v12]
In-Reply-To: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
References: <4fMDUSZRg0HcIiZmr-yqr7vleFXrD_zNXpdd_pfgHQ8=.4a679e86-b0f9-4101-bcc2-f49d8bcb417b@github.com>
Message-ID: <Wp8T89C67qR8H3Yo6eNW0Z0l2h-LvA667HbnIL_PQ7Q=.554b001a-82a4-4ab2-90ee-e6cc16c467c8@github.com>

> This is the 5th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR is necessary to support [JDK-8293336: AOT-linking of invokedynamic for lambda expression and string concat](https://bugs.openjdk.org/browse/JDK-8293336), which needs to store Java heap objects that have native pointers to the C++ `Method` objects  returned by `SystemDictionary::find_method_handle_intrinsic()` 
> 
> These `Method` objects are created within the JVM. They do not belong to any actual Java classes. We store all these `Method` objects into the AOT cache, so that they can be referenced by other artifacts in the AOT cache.
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 19 additional commits since the last revision:

 - 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
 - @coleenp: No need to hold InvokeMethodIntrinsicTable_lock during bootstrap
 - 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-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-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-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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - @coleenp comments
 - 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-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - ... and 9 more: https://git.openjdk.org/jdk/compare/c8d12032...27337ead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20959/files
  - new: https://git.openjdk.org/jdk/pull/20959/files/1e79b7e2..27337ead

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20959&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20959&range=10-11

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20959/head:pull/20959

PR: https://git.openjdk.org/jdk/pull/20959

From iklam at openjdk.org  Tue Oct 22 06:53:35 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:53:35 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v17]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <51FcVJxb8SzgO6C_cUx_8ZuwC99yhkq_jXpbrmyQaJs=.236008f1-319a-482d-8d96-598dc65a486e@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - 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
 - 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
 - Fixed JDK-8342723: Crash with "assert(_instance != nullptr) failed: cannot enqueue events before the service thread runs" in case AOTClassLinking enabled
 - @ashu-mehra comments: renamed to find_required_hidden_classes(), etc, and added checks for only hidden classes
 - fixed minimal build
 - Fixed JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled
 - dholmes-ora comment - removed direct_only parameter from InstanceKlass::is_enum_subclass()
 - ... and 38 more: https://git.openjdk.org/jdk/compare/875c066d...f0bc1ae6

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=16
  Stats: 2793 lines in 76 files changed: 2445 ins; 146 del; 202 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From stefank at openjdk.org  Tue Oct 22 07:09:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 07:09:23 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
 <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
Message-ID: <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>

On Mon, 21 Oct 2024 20:31:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/memory/iterator.inline.hpp line 57:
>> 
>>> 55:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>>> 56:   } else {
>>> 57:     assert_is_pending_aot_linked_class(k);
>> 
>> Would there be a drawback to just adding `assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");` here and skip the changes the both .hpp and .cpp files?
>
> I changed the code to `assert(is_pending_aot_linked_class(k), "sanity")`. Since iterator.hpp is widely used, I avoid including aotLinkedClassBulkLoader.hpp in this header, and route the call through iterator.cpp.

My proposal was to use it in this file (iterator.inline.hpp) and not iterator.hpp. I see no need to route this through the .cpp file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810071099

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 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:46:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 09:46:34 GMT
Subject: RFR: 8342769: gcc port broken on HotSpot
In-Reply-To: <CuOj12vy1DIujX5OKFyYKCpkO4zeEvpYoc7FbODJQMk=.ad5296f2-0590-451d-942c-22fc3063a19f@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
 <CuOj12vy1DIujX5OKFyYKCpkO4zeEvpYoc7FbODJQMk=.ad5296f2-0590-451d-942c-22fc3063a19f@github.com>
Message-ID: <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com>

On Tue, 22 Oct 2024 03:45:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86.cpp line 102:
>> 
>>> 100: const julong double_sign_mask = CONST64(0x7FFFFFFFFFFFFFFF);
>>> 101: const julong double_infinity  = CONST64(0x7FF0000000000000);
>>> 102: #endif
>> 
>> Isn't all this better suited for sharedRuntime_x86_64.cpp?
>
> You mean the entire custom frem and drem implementation unique to x64 Windows, or just this block of constants here? These constants are used by the custom Windows implementation, so they have to be in the same file. Moving the entire definition for Windows x64 to sharedRuntime_x86_64.cpp seems to be duplicating code even more, and I still don't know whether this is the right solution. It may be that this custom implementation may not be needed anymore and should be removed, which is why I left it in the sharedRuntime_x86.cpp file for the time being

I did mean the entire thing. I don't see any point in WIN64 code being in the x86 file when there is an x86_64 file. Of course I had forgotten about the Aarch64 Windows side, so maybe as I said this is really something for a os/windows file rather then `cpu/<arch>` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1810380132

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 duke at openjdk.org  Tue Oct 22 11:33:57 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 22 Oct 2024 11:33:57 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v7]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  assembly changes suggested by sviswa7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21352/files
  - new: https://git.openjdk.org/jdk/pull/21352/files/52d2fbaf..e4979df2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=05-06

  Stats: 14 lines in 2 files changed: 0 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21352/head:pull/21352

PR: https://git.openjdk.org/jdk/pull/21352

From duke at openjdk.org  Tue Oct 22 11:44:16 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 22 Oct 2024 11:44:16 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v6]
In-Reply-To: <MNIvbcsiLo_O9x54RCM1BJGD-M63rcikuYAYwWmXLeo=.109aefc2-f8e4-4791-afc6-91f09fe195c3@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <psunjWF1OpPUTOPJJgukGEHEuQ2fHbuuKh_v4HF_MAw=.2968a9e8-9669-43c2-834a-2cd607001a83@github.com>
 <MNIvbcsiLo_O9x54RCM1BJGD-M63rcikuYAYwWmXLeo=.109aefc2-f8e4-4791-afc6-91f09fe195c3@github.com>
Message-ID: <Luu6NHkrwrjpmrsTf3rx0o62iyKLMytjQBs-h8iIx-k=.696b7038-8ccd-4789-b846-bca9654b1fb8@github.com>

On Mon, 21 Oct 2024 22:22:17 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Ferenc Rakoczi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - fix mismerge
>>  - Merge master
>>  - accepting review suggestions from Volodymyr and Vladimir
>>  - Merge branch 'master' into sha3-avx512-intrinsic
>>  - fix windows build
>>  - fix debug build
>>  - 8341527: AVX-512 intrinsic for SHA3
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 8547:
> 
>> 8545:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_evex()), "");
>> 8546:   // TODO check what legacy_mode needs to be set to
>> 8547:   InstructionAttr attributes(vector_len, /* vex_w */ true, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);
> 
> If you notice W needs to be set to 1 for evex and is ignored for avx encoding.  To be consistent with other similar instruction definition (e.g. addsd), here vex_w could be set as VM_Version::supports_evex(). Also the attributes definition need to be followed by attributes.set_rex_vex_w_reverted(). So this should look like as below:
> 
> 
> InstructionAttr attributes(vector_len, /* vex_w */ VM_Version::supports_evex(), /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);
> attributes.set_rex_vex_w_reverted();

Changed as suggested.

> src/hotspot/cpu/x86/assembler_x86.cpp line 16228:
> 
>> 16226: 
>> 16227: void Assembler::evpermt2d(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
>> 16228:   assert(vector_len <= AVX_256bit ? VM_Version::supports_avx512vlbw() : VM_Version::supports_avx512bw(), "");
> 
> The evpermt2d instruction is foundational instruction and doesn't need avx512bw() so the assert could be changed to:
> assert(VM_Version::supports_evex() && (vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl()), "");

Changed as suggested.

> src/hotspot/cpu/x86/assembler_x86.cpp line 16236:
> 
>> 16234: 
>> 16235: void Assembler::evpermt2q(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
>> 16236:   assert(vector_len <= AVX_256bit ? VM_Version::supports_avx512vlbw() : VM_Version::supports_avx512bw(), "");
> 
> The evpermt2q instruction is foundational instruction and doesn't need avx512bw() so the assert could be changed to:
> assert(VM_Version::supports_evex() && (vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl()), "");

Changed as suggested.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 138:
> 
>> 136: 
>> 137:   // set up the masks
>> 138:   __ mov64(rax, 0x1F);
> 
> This could just be a movl or movd.

Changed as suggested.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 147:
> 
>> 145:   __ kmovwl(k2, rax);
>> 146:   __ shrl(rax, 1);
>> 147:   __ kmovwl(k1, rax);
> 
> The same could be achieved by:
> __ kshiftrwl(k4, k5, 1);
> __ kshiftrwl(k3, k5, 2);
> __ kshiftrwl(k2, k5, 3);
> __ kshiftrwl(k1, k5, 4);

Changed as suggested.

> src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 288:
> 
>> 286:     __ movq(rax, ofs); // return ofs
>> 287:   } else {
>> 288:     __ mov64(rax, 0);
> 
> This could be  xorq(rax, rax).

Changed as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1810562847
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1810562945
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1810563063
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1810563149
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1810563236
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1810563309

From duke at openjdk.org  Tue Oct 22 11:47:38 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 22 Oct 2024 11:47:38 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
 <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
Message-ID: <Be0GEMddzDo2KG1luVL1poXDqmewb-LfuttDf5Jqv_M=.2027d69b-8c46-4e3a-9dd6-54f741987896@github.com>

On Wed, 16 Oct 2024 16:58:07 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:
>> 
>> #### Failure 1
>> Tests: 
>> - `testlibrary_tests/ir_framework/tests/TestCPUFeatureCheck.java`
>>   - Additional flags: `-XX:+UseParallelGC -XX:+UseNUMA`
>> - `compiler/loopopts/superword/TestDependencyOffsets.java`
>>   - Additional flags: `-ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation`
>> ```	
>> CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 106 stepping 6 microcode 0x1, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, avx512f, avx512cd, sha, fma, clflush, hv, rdtscp, rdpid, fsrm, f16c, pku, ospke
>> CPU Model and flags from /proc/cpuinfo:
>> model name	: Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz
>> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves nt_good wbnoinvd arat vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid fsrm md_clear arch_capabilities
>> 
>> 
>> Failure:
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/opt/mach5/mesos/work_dir/slaves/a4a7850a-7c35-410a-b879-d77fbb2f6087-S144302/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d6cec7c3-7401-41e9-aaad-f45b38c7a9e7/runs/9e85fc0d-9d6b-426f-b5d8-e84e2daa4c8c/workspace/open/src/hotspot/cpu/x86/assembler_x86.cpp:2979), pid=1550324, tid=1550336
>> #  Error: assert(VM_Version::supports_avx512dq()) failed
>> .....
>> Command Line: -Djava.library.path=/opt/mach5/mesos/work_dir/jib-master/install/2024-10-15-1659164.christian.hagedorn.jdk-test/linux-x64-debug.test/hotspot/jtreg/native -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:MaxRAMPercentage=4.1...
>
>> This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:
>> 
> 
> @chhagedorn could you send me the mach5 command line (or other means) to run these tests?

> @ferakocz I think you need to enble SHA3 testing in jtreg tests we have by modifying: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L106
> 
> [JDK-8252204](https://bugs.openjdk.org/browse/JDK-8252204) added several C2 tests for SHA3 intrinsics in `test/hotspot/jtreg/compiler/intrinsics/sha`. Please make sure your changes passed those tests.

I did that, plus restored the error message, now all the tests suggested by @chhagedorn pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2429056363

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 galder at openjdk.org  Tue Oct 22 13:16:25 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 22 Oct 2024 13:16:25 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
Message-ID: <y3QBXx3AmozmxxTST0xHJbIY-Ej8r4n_fOmzOaZ1NhI=.74234f19-128a-432c-a8ee-f91801b9e1b5@github.com>

On Thu, 17 Oct 2024 10:10:56 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o 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 30 additional commits since the last revision:
> 
>  - Use same default size as in other vector reduction benchmarks
>  - Renamed benchmark class
>  - Double/Float tests only when avx enabled
>  - Make state class non-final
>  - Restore previous benchmark iterations and default param size
>  - Add clipping range benchmark that uses min/max
>  - Encapsulate benchmark state within an inner class
>  - Avoid creating result array in benchmark method
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/8c2fe27c...0a8718e1

The CI failure was on downloading boot JDK

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2429253091

From mli at openjdk.org  Tue Oct 22 13:17:30 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 22 Oct 2024 13:17:30 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <YdGTI2fl025IbjZgYLv4sFiz2TwFA1eKPmmncYNfz78=.9ae6c20a-de16-4cce-926b-84fb7f86cc22@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2385172700

From mbaesken at openjdk.org  Tue Oct 22 13:22:32 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Oct 2024 13:22:32 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <0vdoS0I-Mp_nUWFfbx2FZE3yLLMAOn7Yy8zW-ZmmYrM=.c151bbd7-b368-401a-8136-e1c5f53206a2@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

java/text/Format/CompactNumberFormat/TestCompactNumber.java
or
jdk/incubator/vector/Double128VectorTests.java

trigger the issue too (when using ubsan - enabled binaries on linux ppc64le).
So any reviews ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21500#issuecomment-2429266133

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 lucy at openjdk.org  Tue Oct 22 13:44:15 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Tue, 22 Oct 2024 13:44:15 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <YQXEeuf_i_B7DMPB00o7tIUUHyS5EMY3dWY7VEz6MKc=.3a81b3bb-5dba-44dd-b805-faa2042981b5@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

After all the discussion: LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21500#pullrequestreview-2385250994

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 duke at openjdk.org  Tue Oct 22 13:56:22 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Tue, 22 Oct 2024 13:56:22 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <x-loo3OKauI38cT-m3oxk1JRmWWeudP40p48dsm6Fhw=.c38f2d64-6916-4d52-88bb-eb8cfbb90167@github.com>

On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-2429355919

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 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 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 iklam at openjdk.org  Tue Oct 22 15:35:43 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 15:35:43 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
 <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
 <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>
Message-ID: <PEOfgnY1tuFdYetoWDoxDhAUBE9HOu02a82WGCSlGMg=.86136092-3126-437c-8e9c-5856ce39b431@github.com>

On Tue, 22 Oct 2024 07:06:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I changed the code to `assert(is_pending_aot_linked_class(k), "sanity")`. Since iterator.hpp is widely used, I avoid including aotLinkedClassBulkLoader.hpp in this header, and route the call through iterator.cpp.
>
> My proposal was to use it in this file (iterator.inline.hpp) and not iterator.hpp. I see no need to route this through the .cpp file.

iterator.inline.hpp is included by many cpp file (580 out of 1409 .o files in hotspot), so I don't want to add aotLinkedClassBulkLoader.hpp to it.


scanning    580 iterator.inline.hpp
   2 found    580 oop.inline.hpp
   3 found    580 zIterator.inline.hpp
   4 found    580 zBarrierSet.inline.hpp
   5 found     60 g1OopClosures.inline.hpp
   6 found      7 g1FullGCOopClosures.inline.hpp
   7 found      5 psPromotionManager.inline.hpp

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810959378

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: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: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: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 psandoz at openjdk.org  Tue Oct 22 15:59:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 22 Oct 2024 15:59:38 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <vUK5ijP4bDH0P3SKlKcdY3g2D45oROAFDBPCqCda15o=.901e3d96-629a-4b60-b57f-e3137c2a964a@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2385653877

From psandoz at openjdk.org  Tue Oct 22 15:59:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 22 Oct 2024 15:59:38 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
 <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
Message-ID: <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>

On Mon, 21 Oct 2024 12:25:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>

Internal tier 1 to 3 testing passed (i needed to merge with master at 7133d1b983d, due to some updates to unrelated test configuration files the test infrastructure expects).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2429666927

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 stefank at openjdk.org  Tue Oct 22 16:08:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 16:08:39 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <PEOfgnY1tuFdYetoWDoxDhAUBE9HOu02a82WGCSlGMg=.86136092-3126-437c-8e9c-5856ce39b431@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
 <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
 <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>
 <PEOfgnY1tuFdYetoWDoxDhAUBE9HOu02a82WGCSlGMg=.86136092-3126-437c-8e9c-5856ce39b431@github.com>
Message-ID: <2NzD8szEoiVyDYb2ZSwdX6C8wXSWEDmv881xEjMmHLQ=.576942a1-1dec-4b09-aa53-203de4766c55@github.com>

On Tue, 22 Oct 2024 15:32:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> My proposal was to use it in this file (iterator.inline.hpp) and not iterator.hpp. I see no need to route this through the .cpp file.
>
> iterator.inline.hpp is included by many cpp file (580 out of 1409 .o files in hotspot), so I don't want to add aotLinkedClassBulkLoader.hpp to it.
> 
> 
> scanning    580 iterator.inline.hpp
>    2 found    580 oop.inline.hpp
>    3 found    580 zIterator.inline.hpp
>    4 found    580 zBarrierSet.inline.hpp
>    5 found     60 g1OopClosures.inline.hpp
>    6 found      7 g1FullGCOopClosures.inline.hpp
>    7 found      5 psPromotionManager.inline.hpp

>From what I can tell it is a tiny header with very few dependencies. I don't think we gain much by trying to prevent it from being include. I would strongly prefer to have cleaner code in iterator.hpp/cpp than trying to get rid of that include.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1811012268

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 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 duke at openjdk.org  Tue Oct 22 17:47:57 2024
From: duke at openjdk.org (hanklo6)
Date: Tue, 22 Oct 2024 17:47:57 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
Message-ID: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>

The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.

-------------

Commit messages:
 - Set bmi1 flag in test

Changes: https://git.openjdk.org/jdk/pull/21644/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342768
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21644/head:pull/21644

PR: https://git.openjdk.org/jdk/pull/21644

From sviswanathan at openjdk.org  Tue Oct 22 17:54:05 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 22 Oct 2024 17:54:05 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
In-Reply-To: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
Message-ID: <G1H0f3EBaQ-5iaIco1_jb0Zyt0M_0D7T9hoY5SN51zQ=.595c24b7-85cc-4065-a6ad-bbf198bdbc1f@github.com>

On Tue, 22 Oct 2024 17:41:13 GMT, hanklo6 <duke at openjdk.org> wrote:

> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.

test/hotspot/gtest/x86/test_assemblerx86.cpp line 70:

> 68: TEST_VM(AssemblerX86, validate) {
> 69:   FlagSetting flag_change_apx(UseAPX, true);
> 70:   VM_Version::set_bmi1_cpuFeatures();

Let us also call the set_avx_cpuFeatures() and set_evex_cpuFeatures() in TEST_VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1811151167

From duke at openjdk.org  Tue Oct 22 18:11:45 2024
From: duke at openjdk.org (hanklo6)
Date: Tue, 22 Oct 2024 18:11:45 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
Message-ID: <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>

> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.

hanklo6 has updated the pull request incrementally with one additional commit since the last revision:

  set avx and evex in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21644/files
  - new: https://git.openjdk.org/jdk/pull/21644/files/ad94cc08..ed7c10a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21644&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21644&range=00-01

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21644/head:pull/21644

PR: https://git.openjdk.org/jdk/pull/21644

From duke at openjdk.org  Tue Oct 22 18:11:45 2024
From: duke at openjdk.org (hanklo6)
Date: Tue, 22 Oct 2024 18:11:45 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <G1H0f3EBaQ-5iaIco1_jb0Zyt0M_0D7T9hoY5SN51zQ=.595c24b7-85cc-4065-a6ad-bbf198bdbc1f@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <G1H0f3EBaQ-5iaIco1_jb0Zyt0M_0D7T9hoY5SN51zQ=.595c24b7-85cc-4065-a6ad-bbf198bdbc1f@github.com>
Message-ID: <VFMD67TXsJFWWMsds_DSkzQNZBNnzgXDDWbAJwPZStc=.63389dc4-f198-42d6-99fb-db7c8eea6389@github.com>

On Tue, 22 Oct 2024 17:51:16 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   set avx and evex in test
>
> test/hotspot/gtest/x86/test_assemblerx86.cpp line 70:
> 
>> 68: TEST_VM(AssemblerX86, validate) {
>> 69:   FlagSetting flag_change_apx(UseAPX, true);
>> 70:   VM_Version::set_bmi1_cpuFeatures();
> 
> Let us also call the set_avx_cpuFeatures() and set_evex_cpuFeatures() in TEST_VM.

Thanks, done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1811171817

From sviswanathan at openjdk.org  Tue Oct 22 18:16:05 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 22 Oct 2024 18:16:05 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
Message-ID: <TxhGnjyxFLUOYUZdOOvkYWxb_fUrCpYzkvDpEJ4rrMg=.5852d137-2e64-481f-bf23-848b0763bc9d@github.com>

On Tue, 22 Oct 2024 18:11:45 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set avx and evex in test

@dholmes-ora Could you please verify that the test now passes on your MacPro6?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2429940105

From mchung at openjdk.org  Tue Oct 22 18:17:14 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 18:17:14 GMT
Subject: Integrated: 8327624: Remove VM implementation that bypass verification
 for core reflection
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <U3D3JYxrkGhMuHA7eiGpsRppUWkpr2dQnySgEzZs1s4=.82584958-b3f3-4c5f-9bfb-41607d29e98a@github.com>

On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

This pull request has now been integrated.

Changeset: d6eddcda
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6eddcdaf92f2352266ba519608879141997cd63
Stats:     2817 lines in 28 files changed: 0 ins; 2805 del; 12 mod

8327624: Remove VM implementation that bypass verification for core reflection

Reviewed-by: liach, dholmes, jrose, alanb, mli

-------------

PR: https://git.openjdk.org/jdk/pull/21571

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 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 dlong at openjdk.org  Tue Oct 22 19:30:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 22 Oct 2024 19:30:05 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <hlg52bYLG9YBrxDo2oBnXLkCrMAsoBxs2PaHLTSUh9Q=.24ef9a44-2d2a-4d07-8508-d4aaf8487007@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

If this file requires certain IEEE divide-by-zero semantics, then should we also add static asserts for those?  Something like:
static_assert(-1.0 / 0.0 == -INFINITY, "IEEE 754 required");
static_assert(1.0 / 0.0 == INFINITY, "IEEE 754 required");
static_assert(std::isnan(0.0 / 0.0), "IEEE 754 required");

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21500#issuecomment-2430079359

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 kbarrett at openjdk.org  Tue Oct 22 20:22:05 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Oct 2024 20:22:05 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <hlg52bYLG9YBrxDo2oBnXLkCrMAsoBxs2PaHLTSUh9Q=.24ef9a44-2d2a-4d07-8508-d4aaf8487007@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <hlg52bYLG9YBrxDo2oBnXLkCrMAsoBxs2PaHLTSUh9Q=.24ef9a44-2d2a-4d07-8508-d4aaf8487007@github.com>
Message-ID: <xWVEqm0U81Q946yjZmN1vQUUba83IDUQRyYEcA3JoOE=.e1e26227-571f-4d0c-aba3-9365981fd8a0@github.com>

On Tue, 22 Oct 2024 19:27:56 GMT, Dean Long <dlong at openjdk.org> wrote:

> If this file requires certain IEEE divide-by-zero semantics, then should we also add static asserts for those? Something like: static_assert(-1.0 / 0.0 == -INFINITY, "IEEE 754 required"); static_assert(1.0 / 0.0 == INFINITY, "IEEE 754 required"); static_assert(std::isnan(0.0 / 0.0), "IEEE 754 required");

These expressions are UB, so not constexpr, so shouldn't be usable in a static_assert.  And indeed, gcc says

static_assert_iec599.cpp:4:27: error: non-constant condition for static assertion
    4 |   static_assert(1.0 / 0.0 == INFINITY, "1/0 failed");
      |                           ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21500#issuecomment-2430180370

From matsaave at openjdk.org  Tue Oct 22 20:27:16 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 22 Oct 2024 20:27:16 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops
Message-ID: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>

[JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

-------------

Commit messages:
 - Enabled uncompressed oops on Epsilon and Shenandoah
 - Merge branch 'master' into archive_uncompressed_oops_8341371
 - Added uncompressed oops to tests
 - 8341371: CDS cannot load archived heap objects with -XX:+UseSerialGC -XX:-UseCompressedOops

Changes: https://git.openjdk.org/jdk/pull/21647/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341371
  Stats: 153 lines in 12 files changed: 117 ins; 21 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21647/head:pull/21647

PR: https://git.openjdk.org/jdk/pull/21647

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 kbarrett at openjdk.org  Tue Oct 22 21:57:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Oct 2024 21:57:04 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <9bdBznqfxmAolEvznsHK4XktMI_kVSmKoDG3lngYxwI=.fd5393f3-e3eb-45ce-8278-bee41d715007@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <XiCbA1_-Z6strsf57kWAjCE6lLyNpKclCDlTHyBvKqw=.ceaa131b-8055-46ae-8607-588e7f57256b@github.com>
 <j70f5gQtc8CtZEUU1KRq0TbRRWpD1lRwXASRmlI8xN0=.5967654c-854c-48a8-a245-dfe4cd140210@github.com>
 <bpJVEvErubauRo4W6bAii7Cd3kjJD9rBmO1ASE8HNRI=.3b5d3b41-4f7a-411d-8399-c503ffba790f@github.com>
 <SttIpkWPsz0JZa0v9H9HDLjb2qd25scHpr-rolPTTUQ=.71bbfc92-f6af-4d2b-ab86-224b0e96c6f8@github.com>
 <HJF3NaBZVaT23sdZh3snmKft3PRiqIfNLEfPjlsYNjk=.07974901-48dc-41e3-a8b1-d37d0897c791@github.com>
 <8h5zGu1hxUZk4wloON39CCcUfKhlt33Ya_zlDAmd3gc=.38adb012-3049-4224-8a31-190f73271db2@github.com>
 <9bdBznqfxmAolEvznsHK4XktMI_kVSmKoDG3lngYxwI=.fd5393f3-e3eb-45ce-8278-bee41d715007@github.com>
Message-ID: <2pgSF-dOruHQkTD8MqZORi-5VDFJsjDxr3J4a3dik84=.98a882ed-40e2-4abf-8adf-ec2d27cd4aae@github.com>

On Tue, 22 Oct 2024 04:11:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Never mind my question about whether this was happening with clang as the compiler rather than gcc.
>> Our ubsan configuration explicitly includes `-fsantize=float-divide-by-zero`.
>> https://github.com/openjdk/jdk/blame/8bcd4920f1b03d0ef8e295e53557c629f05ceaa4/make/autoconf/jdk-options.m4#L516
>
>> I'm not sure what the implications of this actually are. Do we really need it? Maybe @jddarcy can comment?
> 
> Catching up on email, whatever the appropriate C/C++ idiom is, it is appropriate for this file to assert "use IEEE 754 semantics for floating-point operations." The divide by zero behavior is well-defined by IEEE 754/IEC 559.

It's not clear there is any in-language mechanism (whether portable or compiler-specific) for reliably requesting or verifying that one will get that behavior.  A static_assert of is_iec599 _might_ be sufficient verification, but the standard is at least unclear on that.  But that seems to be the best we've got.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21500#discussion_r1811490684

From kbarrett at openjdk.org  Tue Oct 22 22:08:05 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 22 Oct 2024 22:08:05 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <lXWIBGpn03vSSE1gsdydZ2IJ70wuj0s_or6bgj6H8q8=.96b9fbee-b3b1-447b-ae2c-bfec71d5368a@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

I don't see a better approach than the addition of the static_asserts.  I wish
the language standards were clearer, but oh well...

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21500#pullrequestreview-2386476870

From dlong at openjdk.org  Tue Oct 22 22:35:06 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 22 Oct 2024 22:35:06 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <xWVEqm0U81Q946yjZmN1vQUUba83IDUQRyYEcA3JoOE=.e1e26227-571f-4d0c-aba3-9365981fd8a0@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <hlg52bYLG9YBrxDo2oBnXLkCrMAsoBxs2PaHLTSUh9Q=.24ef9a44-2d2a-4d07-8508-d4aaf8487007@github.com>
 <xWVEqm0U81Q946yjZmN1vQUUba83IDUQRyYEcA3JoOE=.e1e26227-571f-4d0c-aba3-9365981fd8a0@github.com>
Message-ID: <J1GYaB_kSqVeFYGgpahaMqCcxYwByYCCqQDnypF9kco=.4dfbfb39-05cb-4bb6-861f-9445d41479e0@github.com>

On Tue, 22 Oct 2024 20:19:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> These expressions are UB, so not constexpr, so shouldn't be usable in a static_assert. And indeed, gcc says

OK, then how about regular runtime asserts?  They would only be in debug builds and the compiler should be able to figure out the result at build time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21500#issuecomment-2430438622

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 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 sviswanathan at openjdk.org  Wed Oct 23 00:22:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 23 Oct 2024 00:22:06 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
Message-ID: <-V5MG-H9Blq88ZdrYU6bIkDoAgi69259ktjMzpox4pc=.65790c46-84a7-4ea2-9518-08da8c2dbe60@github.com>

On Tue, 22 Oct 2024 18:11:45 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set avx and evex in test

src/hotspot/cpu/x86/vm_version_x86.hpp line 646:

> 644:   static void set_evex_cpuFeatures() { _features |= (CPU_AVX512F | CPU_SSE | CPU_SSE2 | CPU_VZEROUPPER ); }
> 645:   static void set_apx_cpuFeatures() { _features |= CPU_APX_F; }
> 646:   static void set_bmi1_cpuFeatures() { _features |= CPU_BMI1; }

It would be better to change this as:
static void set_bmi_cpuFeatures() { _features |= (CPU_BMI1 | CPU_BMI2 | CPU_LZCNT); }
And then use set_bmi_cpuFeatures() in the gtest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1811590174

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 kvn at openjdk.org  Wed Oct 23 01:01:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Oct 2024 01:01:04 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
Message-ID: <7UbLpPwnc0qVVCA_q8Hcetr6QeYOL3qmdumZSgdECf4=.04f8024e-3836-4a22-95ee-4c3f8b9d58a3@github.com>

On Tue, 22 Oct 2024 18:11:45 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set avx and evex in test

There is an other issue found with this test: https://bugs.openjdk.org/browse/JDK-8342862

Question: why we run this test on not APX machines?
The original PR was "for testing APX encoding of extended gpr instructions".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2430583397
PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2430584885

From kbarrett at openjdk.org  Wed Oct 23 01:10:07 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 23 Oct 2024 01:10:07 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <J1GYaB_kSqVeFYGgpahaMqCcxYwByYCCqQDnypF9kco=.4dfbfb39-05cb-4bb6-861f-9445d41479e0@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
 <hlg52bYLG9YBrxDo2oBnXLkCrMAsoBxs2PaHLTSUh9Q=.24ef9a44-2d2a-4d07-8508-d4aaf8487007@github.com>
 <xWVEqm0U81Q946yjZmN1vQUUba83IDUQRyYEcA3JoOE=.e1e26227-571f-4d0c-aba3-9365981fd8a0@github.com>
 <J1GYaB_kSqVeFYGgpahaMqCcxYwByYCCqQDnypF9kco=.4dfbfb39-05cb-4bb6-861f-9445d41479e0@github.com>
Message-ID: <bNNgPlDIJtqsY_uQAWyjGkiP3GKaVjsGurnBbREzgpc=.577b117d-2b77-47b1-8398-1df419ce8a69@github.com>

On Tue, 22 Oct 2024 22:32:47 GMT, Dean Long <dlong at openjdk.org> wrote:

> > These expressions are UB, so not constexpr, so shouldn't be usable in a static_assert. And indeed, gcc says
> 
> OK, then how about regular runtime asserts? They would only be in debug builds and the compiler should be able to figure out the result at build time.

UB => nasal demons, including passing the test on a platform that should fail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21500#issuecomment-2430592754

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 fyang at openjdk.org  Wed Oct 23 01:40:17 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 23 Oct 2024 01:40:17 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v9]
In-Reply-To: <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
Message-ID: <GsqfHJPpGvgtfN88JtySopb8_aNHfPBxkUDk2qJlyRg=.849828b4-2fc7-4872-81fb-f62255a7a9c7@github.com>

On Mon, 21 Oct 2024 14:41:57 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Use RISCV64 instead of RISCV
>  - Fixed comment line
>  - Rename reg_number -> rounds in aes_loadkeys
>  - Fix typo

src/hotspot/share/opto/library_call.cpp line 7229:

> 7227:   // Intel's extension is based on this optimization and AESCrypt generates round keys by preprocessing MixColumns.
> 7228:   // However, ppc64 vncipher processes MixColumns and requires the same round keys with encryption.
> 7229:   // The ppc64 and RISCV64 stubs of encryption and decryption use the same round keys (sessionK[0]).

Nit: A small `riscv64` will do here.

// The ppc64 and riscv64 stubs of encryption and decryption use the same round keys (sessionK[0]).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1810407702

From jiangli at openjdk.org  Wed Oct 23 01:44:08 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Oct 2024 01:44:08 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>
Message-ID: <N2aJZCe4omsgw1E7s46gAKTEJ_h5xUKeOVxYrkf4EFA=.2b9e15c2-4154-48ca-a75d-4fa04323a710@github.com>

On Mon, 21 Oct 2024 13:17:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
> 
> I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
> 
> @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.

@magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2430624032

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: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: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 iklam at openjdk.org  Wed Oct 23 05:04:05 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 23 Oct 2024 05:04:05 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <UerwUw4MtQHC8QkhjbWD8aAkhdWVeozIl-1NFSS3YTM=.62746be0-a932-4fb4-9228-ed5992fa5821@github.com>

On Tue, 22 Oct 2024 19:32:03 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/archiveHeapLoader.cpp line 245:

> 243:   }
> 244: };
> 245: 

This new class looks almost the same as the existing PatchUncompressedEmbeddedPointers class. I think you can change PatchUncompressedEmbeddedPointers to take an additional `intx runtime_offset` parameter in its constructor, which will be `loaded_region->_runtime_offset` or `ArchiveHeapLoader::mapped_heap_delta()`.

src/hotspot/share/cds/filemap.cpp line 2137:

> 2135:   FileMapRegion* r = region_at(MetaspaceShared::hp);
> 2136:   assert(is_aligned(r->mapping_offset(), sizeof(HeapWord)), "must be");
> 2137:   assert(ArchiveHeapLoader::can_use(), "cannot be used by ArchiveHeapLoader::can_load() mode");

The error message needs to be updated.

src/hotspot/share/prims/whitebox.cpp line 2162:

> 2160: 
> 2161: WB_ENTRY(jboolean, WB_CanWriteJavaHeapArchive(JNIEnv* env))
> 2162:   return HeapShared::can_write() && ArchiveHeapLoader::can_use();

Do we still need the `&& ArchiveHeapLoader::can_use()` part?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21647#pullrequestreview-2387142172
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1811841631
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1811844617
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1811846134

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 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 gcao at openjdk.org  Wed Oct 23 05:41:17 2024
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 23 Oct 2024 05:41:17 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v28]
In-Reply-To: <YNm_tUXXGIDIxWb7UJTp4Fjgvg51KIIpZnhbfPHk4kU=.329c561f-6de7-43eb-80bc-e7bb1f0243c2@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <hNhLOoNftDPqrcLvGnc3924MmDMlSi25DtOU-RIaZgA=.74e2d44c-da0e-469d-b074-a492220a4302@github.com>
 <YNm_tUXXGIDIxWb7UJTp4Fjgvg51KIIpZnhbfPHk4kU=.329c561f-6de7-43eb-80bc-e7bb1f0243c2@github.com>
Message-ID: <o6SJZRWLizY6ycE8IgnDvt_cLjJLbx7bntiMJ-mfW8g=.5eebf3ca-2547-4214-8a41-56cadfcbf465@github.com>

On Tue, 15 Oct 2024 10:41:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen assertion
>
> By the way, to see the performance benefit of this patch run the test case SecondarySuperCacheInterContention.java, like so:
> 
> `/build/macosx-aarch64-server-fastdebug/jdk/bin/java -XX:-UseSecondarySupersTable -XX:+UseSecondarySupersCache -jar build/macosx-aarch64-server-fastdebug/images/test/micro/benchmarks.jar SecondarySuperCacheInterContention`

@theRealAph Hi, And here is the version for riscv: https://github.com/zifeihan/jdk/commit/2c5296859597f5edc6601a5d1780126ec373d4dc . Do you want to have it in this PR? Or shall I create another one? Thanks. By the way, Already passed tier1-tier3 tests on the linux-riscv64 platform(SOPHON SG2042).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2430954416

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 dholmes at openjdk.org  Wed Oct 23 07:10:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 07:10:05 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <TxhGnjyxFLUOYUZdOOvkYWxb_fUrCpYzkvDpEJ4rrMg=.5852d137-2e64-481f-bf23-848b0763bc9d@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
 <TxhGnjyxFLUOYUZdOOvkYWxb_fUrCpYzkvDpEJ4rrMg=.5852d137-2e64-481f-bf23-848b0763bc9d@github.com>
Message-ID: <ykwU3JfAlKUDJnevywlksp_V1Xzp7rFDEKOfUajilqM=.19f19ce0-84be-45b1-bdd1-f9d2ae138072@github.com>

On Tue, 22 Oct 2024 18:13:55 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> @dholmes-ora Could you please verify that the test now passes on your MacPro6?

I will test it once it seems to be in a final state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2431098850

From mbaesken at openjdk.org  Wed Oct 23 07:11:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Oct 2024 07:11:09 GMT
Subject: RFR: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <kJZJQshZzQFlyOa_FacC6gGnA15n49JMjKBpedsa47Q=.9de90649-897d-44ea-93ab-7aa9b55f03fb@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

Thanks for the reviews !

The other static_assert  could be added in a separate PR if they are really desired.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21500#issuecomment-2431098479

From mbaesken at openjdk.org  Wed Oct 23 07:11:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Oct 2024 07:11:10 GMT
Subject: Integrated: 8338449: ubsan: division by zero in sharedRuntimeTrans.cpp
In-Reply-To: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
References: <48SWt02erMD0GYi3evlGn00E3jGX1-gqupHivJacO0I=.fc933e89-0e8a-4008-a187-b6932ee0e418@github.com>
Message-ID: <g_fRT39r712y0J9EqCNrvbiXOFfd9sGU8Z6yNf_i9qA=.8c291817-ef5c-427d-afa2-e1630a261f47@github.com>

On Mon, 14 Oct 2024 14:08:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running with ubsan enabled binaries on Linux ppc64le, some divisions by zero are detected in the java/lang/Math jdk jtreg tests dealing with log - related calculations.
> 
> java/lang/Math/Log10Tests.java: Tests for {Math, StrictMath}.log10
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:219:27: runtime error: division by zero
>     #0 0x7fffa7e14abc in SharedRuntime::dlog10(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f4abc)
>     #1 0x7fff8b8fc8e8 (<unknown module>)
>  
> test
> java/lang/Math/LogTests.java: Tests for {Math, StrictMath}.log
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:125:27: runtime error: division by zero
>     #0 0x7fff887f48bc in __ieee754_log(double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f48bc)
>     #1 0x7fff6b8fc768 (<unknown module>)
>  
> test
> java/lang/Math/PowTests.java: Tests for {Math, StrictMath}.pow
>  
> /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:508:23: runtime error: division by zero
>     #0 0x7fff92fd61f0 in SharedRuntime::dpow(double, double) (/build_ubsan/images/jdk/lib/server/libjvm.so+0x69f61f0)
>     #1 0x7fff7701c8ec (<unknown module>)
> 
> The coding does intentional division by zero. 
> We should probably check for IEEE compliance  (or rewrite the coding);  but checking for compliance might be sufficient.

This pull request has now been integrated.

Changeset: 37cfaa8d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37cfaa8deb4cc15864bb6dc2c8a87fc97cff2f0d
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8338449: ubsan: division by zero in sharedRuntimeTrans.cpp

Reviewed-by: lucy, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/21500

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 jvos at openjdk.org  Wed Oct 23 08:26:07 2024
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 23 Oct 2024 08:26:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <yDZJc66GqRWwaNORthZ6yepgT6iJPCI29-l_opf33OI=.a310dfa1-11a2-4243-8ed4-2adae0e878ee@github.com>

On Tue, 15 Oct 2024 20:22:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't hardcode server variant

I tried to build/run this on Linux as well (since I'm using parts of this PR in https://github.com/openjdk/mobile/pull/30) and I noticed that the executable doesn't start (even with --version):

images/static-jdk/bin/java --version
Error: Failed , because images/static-jdk/bin/java: undefined symbol: JNI_CreateJavaVM

The `JNI_CreateJavaVM` symbol seems to be local only:

nm images/static-jdk/bin/java |grep JNI_CreateJ
0000000000e22430 t JNI_CreateJavaVM

Hence calling it with `dlsym` won't work. And indeed, that is how it is called from `./java.base/unix/native/libjli/java_md.c ` `(LoadJavaVM)`

dlsym(libjvm, "JNI_CreateJavaVM");

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2431273631

From aph at openjdk.org  Wed Oct 23 09:03:22 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 23 Oct 2024 09:03:22 GMT
Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and
 interpreter [v28]
In-Reply-To: <YNm_tUXXGIDIxWb7UJTp4Fjgvg51KIIpZnhbfPHk4kU=.329c561f-6de7-43eb-80bc-e7bb1f0243c2@github.com>
References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com>
 <hNhLOoNftDPqrcLvGnc3924MmDMlSi25DtOU-RIaZgA=.74e2d44c-da0e-469d-b074-a492220a4302@github.com>
 <YNm_tUXXGIDIxWb7UJTp4Fjgvg51KIIpZnhbfPHk4kU=.329c561f-6de7-43eb-80bc-e7bb1f0243c2@github.com>
Message-ID: <oqUcR0arwPaMVt72WRW1Qo2oxYPR_6VZ3zwynJFI3tE=.d734fc3c-e1e1-464f-9b59-9b855df4e282@github.com>

On Tue, 15 Oct 2024 10:41:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen assertion
>
> By the way, to see the performance benefit of this patch run the test case SecondarySuperCacheInterContention.java, like so:
> 
> `/build/macosx-aarch64-server-fastdebug/jdk/bin/java -XX:-UseSecondarySupersTable -XX:+UseSecondarySupersCache -jar build/macosx-aarch64-server-fastdebug/images/test/micro/benchmarks.jar SecondarySuperCacheInterContention`

> @theRealAph Hi, And here is the version for riscv: [zifeihan at 2c52968](https://github.com/zifeihan/jdk/commit/2c5296859597f5edc6601a5d1780126ec373d4dc) . Do you want to have it in this PR? Or shall I create another one? Thanks. By the way, Already passed tier1-tier3 tests on the linux-riscv64 platform(SOPHON SG2042).

There's no need to merge with this PR. It should be a simple enough thing to approve.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19989#issuecomment-2431378144

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 fyang at openjdk.org  Wed Oct 23 10:28:50 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 23 Oct 2024 10:28:50 GMT
Subject: RFR: 8342882: RISC-V: Unify handling of jumps to runtime
Message-ID: <3F1Bd23soK36LccU_SOZiWwKRNCLJEGu9hS9GDkK__M=.6623ff60-528a-4956-b324-5ecf9d76f47c@github.com>

This fixes and unifies handling of jumps to runtime. Was previously discussed here [1]. ( Tagging @robehn )
Seems not reasonable for `MacroAssembler::j(const Address &dest, Register temp)` to directly delegate work to `MacroAssembler::j(const address dest, Register temp)` for literal Address. This could generate a plain `JAL`, which means when we relocate the code, but the `JAL` immediate could be too large. This relaxes this constaint.

[1] https://github.com/openjdk/jdk/pull/21406#issuecomment-2415965656

Testing in progress on linux-riscv64.
- [ ] tier1 - tier3 (release)
- [ ] tier1 (fastdebug)

-------------

Commit messages:
 - JDK-8342882: RISC-V: Unify handling of jumps to runtime

Changes: https://git.openjdk.org/jdk/pull/21661/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342882
  Stats: 31 lines in 7 files changed: 2 ins; 9 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21661/head:pull/21661

PR: https://git.openjdk.org/jdk/pull/21661

From rehn at openjdk.org  Wed Oct 23 11:16:06 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 23 Oct 2024 11:16:06 GMT
Subject: RFR: 8342882: RISC-V: Unify handling of jumps to runtime
In-Reply-To: <3F1Bd23soK36LccU_SOZiWwKRNCLJEGu9hS9GDkK__M=.6623ff60-528a-4956-b324-5ecf9d76f47c@github.com>
References: <3F1Bd23soK36LccU_SOZiWwKRNCLJEGu9hS9GDkK__M=.6623ff60-528a-4956-b324-5ecf9d76f47c@github.com>
Message-ID: <LLTj3H4_i4f4cPWYKV6zrsh3aDMOtC-iAkAEE8BFZzY=.46111cd7-6ab3-4607-a159-9db3451ee2f6@github.com>

On Wed, 23 Oct 2024 10:20:10 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This fixes and unifies handling of jumps to runtime. Was previously discussed here [1]. ( Tagging @robehn )
> Seems not reasonable for `MacroAssembler::j(const Address &dest, Register temp)` to directly delegate work to `MacroAssembler::j(const address dest, Register temp)` for literal Address. This could generate a plain `JAL`, which means when we relocate the code, but the `JAL` immediate could be too large. This relaxes this constaint.
> 
> [1] https://github.com/openjdk/jdk/pull/21406#issuecomment-2415965656
> 
> Simply did a native fastdebug build and tried specjbb2005 workload.
> More testing in progress on linux-riscv64.
> - [ ] tier1 - tier3 (release)
> - [ ] tier1 (fastdebug)

Thanks, looks good!

-------------

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21661#pullrequestreview-2388250735

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 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 eastigeevich at openjdk.org  Wed Oct 23 12:55:09 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 23 Oct 2024 12:55:09 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
Message-ID: <v7B0Jz4nz4AUKmPb5xU_ft2055KR0RuN5tHRsKdBtro=.de7df144-d5e1-482f-9039-9992158b5de8@github.com>

On Mon, 7 Oct 2024 13:21:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> With this change, I have adjusted the default settings for CodeCacheSegmentSize and CodeEntryAlignment for AARCH and ARM32. The main goal is to improve code density by reducing the number of wasted bytes (approximately **4%** waste). Improving code density may also have the side effect of boosting performance in large applications
>> 
>> Each nmethod occupies a number of code cache segments (minimum allocation blocks). Since the size of an nmethod is not aligned to 128 bytes, the last occupied segment is half empty. Reducing the size of the code cache segments correspondingly minimizes waste. However, we should be careful about reducing the CodeCacheSegmentSize too much, as smaller segment sizes will increase the overhead of the CodeHeap::_segmap bitmap. A CodeCacheSegmentSize of 64 seems to be an optimal balance.
>> 
>> The current large default value for CodeCacheSegmentSize (64+64) was historically introduced with the comment "Tiered compilation has large code-entry alignment" which doesn't make much sense to me. The history of this comment and value is as follows:
>> - The PPC port was introduced with CodeEntryAlignment=128 (recently reduced to 64: https://github.com/openjdk/jdk/commit/09a78b5d) and CodeCacheSegmentSize was adjusted accordingly for that platform.
>> - Soon after, the 128-byte alignment was applied to all platforms to hide a debug mode warning (https://github.com/openjdk/jdk/commit/e8bc971d). Despite the change (and Segmented Code Cache introduced later), the warning can still be reproduced today using the -XX:+VerifyCodeCache fastdebug option in large applications (10K nmethods ~ 10K free blocks in between them).
>> 
>> I believe it is time to remove the comment and update the default value.
>> 
>> I also suggest updating the default CodeEntryAlignment value for AARCH. The current setting is much larger than for x86 and was likely based on the typical cache line size of 64 bytes. Cortex-A57, A72 architecture software optimisation guides recommend a 32-byte alignment for subroutine entry points. Neoverse architecture software optimisation guides do not mention recommended entry point alignment.
>> 
>> For reference, the default [function_align setting in GCC](https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/cortexa72.h#L44) is typically 16 or 32 bytes, depending on the target architecture.
>> 
>> Hotspot performance tests with -XX:CodeCacheSegmentSize=64 and -XX:CodeEntryAlignment=16 options showed the following result...
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.

64 for N1/N2 and 32 for V1/V2 looks good to me.

-------------

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20864#pullrequestreview-2388571996

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 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 cnorrbin at openjdk.org  Wed Oct 23 13:51:33 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 23 Oct 2024 13:51:33 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v4]
In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
Message-ID: <GwDbfFOxmQSmqbDtKQNP1C4FmwUvEl6fU126SZhbf18=.304f4bdd-30e7-4eaf-a9ea-5b11cce0b6d5@github.com>

> Hi everyone,
> 
> String interning can be done on 4 different types of strings:
> - oop-strings (unicode)
> - oop-strings (latin1)
> - Symbols (non-null-terminated utf8)
> - null-terminated utf8 char arrays
> 
> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
> 
> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
> 
> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
> 
> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
> 
> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
> Also tested and passes tiers 1-3.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  feedback from david

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21325/files
  - new: https://git.openjdk.org/jdk/pull/21325/files/8ee9937a..cc7530cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=02-03

  Stats: 34 lines in 6 files changed: 13 ins; 8 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325

PR: https://git.openjdk.org/jdk/pull/21325

From cnorrbin at openjdk.org  Wed Oct 23 13:54:07 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 23 Oct 2024 13:54:07 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v3]
In-Reply-To: <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>
 <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>
Message-ID: <U1pPtouN13EjK17VXHWvtnKaFbIdW62_erLNhlzImsw=.6d1ddf6d-b00b-4359-94f2-6c782170cf3b@github.com>

On Tue, 22 Oct 2024 03:59:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed cleanup
>
> src/hotspot/share/oops/symbol.hpp line 262:
> 
>> 260: 
>> 261:   // Returns the non-null-terminated utf8 string stored in the symbol
>> 262:   const char* get_utf8() const { return reinterpret_cast<const char*>(bytes()); }
> 
> Not sure this really helps as it will cause confusion between `as_utf8` and `get_utf8`. A `Symbol` is a canonicalized string in modified UTF8 form - so `bytes` is that raw representation.

I moved this to a private `StringTable` function instead to reduce confusion. It is used quite a few times there, so was created more for convenience and readability.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1812820400

From cnorrbin at openjdk.org  Wed Oct 23 14:02:18 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 23 Oct 2024 14:02:18 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v3]
In-Reply-To: <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>
 <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>
Message-ID: <GAmeTxKYN1zL_S6S5et5t_uSM5CQx-NmaKa3JF8KgVE=.744721c5-5a27-4f19-8cb1-3e9317e437ed@github.com>

On Tue, 22 Oct 2024 04:39:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed cleanup
>
> src/hotspot/share/classfile/stringTable.cpp line 473:
> 
>> 471: oop StringTable::intern(const char* utf8_string, TRAPS) {
>> 472:   if (utf8_string == nullptr) return nullptr;
>> 473:   int length = static_cast<int>(strlen(utf8_string));
> 
> Is the source for such a string always a constant pool entry, and so known to < 64K in length?

I am not sure. The previous implementation stored length as `int`, so my assumption is that it would be fine. If it is a problem, I could take some time to change the various lengths to `size_t`s instead.

> test/hotspot/gtest/classfile/test_stringConversion.cpp line 35:
> 
>> 33: static const jchar static_ascii_unicode_str[] = {0x004A, 0x0061, 0x0076, 0x0061, 0x0028, 0x0052, 0x0029, 0x0021, 0x0021};
>> 34: 
>> 35: // Complex string " Ja?v??!?? ", UTF8 has character lengths 13122133 = 16
> 
> Not sure it is okay to have those special characters in the source code. ??

Since the file is encoded in UTF8, my assumption is that it would be fine to have these. Someone with a primitive editor might see "???" or something similar instead though.

> test/hotspot/gtest/classfile/test_stringConversion.cpp line 36:
> 
>> 34: 
>> 35: // Complex string " Ja?v??!?? ", UTF8 has character lengths 13122133 = 16
>> 36: static const unsigned char static_utf8_str[] = {0x4A, 0x61, 0xCC, 0x84, 0x76, 0xC3, 0xA1, 0xC2, 0xAE, 0x21, 0xE2, 0x98, 0xBA, 0xE2, 0x98, 0xBB};
> 
> 0x61 is `a` not a-with-tilde ??

'a?' in this case is an 'a' (0x61) followed by a [Combining Macron](https://www.compart.com/en/unicode/U+0304) '??' (0xCC 0x84)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1812829225
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1812835664
PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1812838984

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 matsaave at openjdk.org  Wed Oct 23 15:45:09 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 23 Oct 2024 15:45:09 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops
In-Reply-To: <UerwUw4MtQHC8QkhjbWD8aAkhdWVeozIl-1NFSS3YTM=.62746be0-a932-4fb4-9228-ed5992fa5821@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <UerwUw4MtQHC8QkhjbWD8aAkhdWVeozIl-1NFSS3YTM=.62746be0-a932-4fb4-9228-ed5992fa5821@github.com>
Message-ID: <ieV8-KLJR4TSGdhfd_qiAyPula_cxH0E6SAm_5SUa90=.c6ed20c1-7046-4acd-ac89-72eac7e75596@github.com>

On Wed, 23 Oct 2024 05:00:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.
>
> src/hotspot/share/prims/whitebox.cpp line 2162:
> 
>> 2160: 
>> 2161: WB_ENTRY(jboolean, WB_CanWriteJavaHeapArchive(JNIEnv* env))
>> 2162:   return HeapShared::can_write() && ArchiveHeapLoader::can_use();
> 
> Do we still need the `&& ArchiveHeapLoader::can_use()` part?

I left it in since it may be a valuable check in case there are further changes or additions to the GCs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813067894

From kvn at openjdk.org  Wed Oct 23 15:56:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Oct 2024 15:56:05 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
Message-ID: <nNjOLcjgxX18UisQtQa3CbR6WcEQKzXYHkNM6J6wkrU=.88ffcb91-42d6-444c-b994-64a8060fbf31@github.com>

On Tue, 22 Oct 2024 18:11:45 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set avx and evex in test

"This test is including a huge, generated file `asmtest.out.h`. I'm guessing this is the culprit of the long compile time."

May be the test should be compiled conditionally to avoid affect on JVM build.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2432705194

From matsaave at openjdk.org  Wed Oct 23 16:40:44 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 23 Oct 2024 16:40:44 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v2]
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <yIyDglLtuKhez4DgW5wAX-93AC78MXppqkb8w36Q0-0=.6d467528-b10b-4e6f-958f-348a566e4602@github.com>

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Ioi comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21647/files
  - new: https://git.openjdk.org/jdk/pull/21647/files/da78b148..da433327

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=00-01

  Stats: 30 lines in 2 files changed: 7 ins; 19 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21647/head:pull/21647

PR: https://git.openjdk.org/jdk/pull/21647

From ccheung at openjdk.org  Wed Oct 23 16:47:06 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 23 Oct 2024 16:47:06 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v2]
In-Reply-To: <yIyDglLtuKhez4DgW5wAX-93AC78MXppqkb8w36Q0-0=.6d467528-b10b-4e6f-958f-348a566e4602@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <yIyDglLtuKhez4DgW5wAX-93AC78MXppqkb8w36Q0-0=.6d467528-b10b-4e6f-958f-348a566e4602@github.com>
Message-ID: <NR7V4oHt9GnNw1rz1y9Kyl14xwXHxHrIZBZVOqx7nXg=.893968bb-b1f4-4354-9d6d-0faaebf0a4df@github.com>

On Wed, 23 Oct 2024 16:40:44 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi comments

I spotted couple of things in the test cases.

test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java line 41:

> 39: 
> 40: // Below is exactly the same as above, except:
> 41: // - requires vm.bits == "64"

I don't see this requirement in the new test.

test/hotspot/jtreg/runtime/cds/appcds/TestEpsilonGCWithCDS.java line 46:

> 44: /*
> 45:  * @test Loading CDS archived heap objects into EpsilonGC
> 46:  * @bug 8234679

Please update the bug id.

test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java line 41:

> 39: 
> 40: // Below is exactly the same as above, except:
> 41: // - requires vm.bits == "64"

I don't see this requirement in the new test.

test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java line 46:

> 44:  /*
> 45:  * @test Loading CDS archived heap objects into ParallelGC
> 46:  * @bug 8274788

Please update the bug id.

-------------

Changes requested by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21647#pullrequestreview-2389409982
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813166147
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813167449
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813169167
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813169654

From matsaave at openjdk.org  Wed Oct 23 16:55:21 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 23 Oct 2024 16:55:21 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v3]
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <6hF2-lkUNnzJpmou-rgkj9oSQEwlyAr-ltZFV7At4Ck=.27d2542b-7d76-4eb3-b5f0-4690935cf467@github.com>

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Calvin comments and copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21647/files
  - new: https://git.openjdk.org/jdk/pull/21647/files/da433327..35a6fa4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=01-02

  Stats: 9 lines in 6 files changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21647/head:pull/21647

PR: https://git.openjdk.org/jdk/pull/21647

From matsaave at openjdk.org  Wed Oct 23 17:12:40 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 23 Oct 2024 17:12:40 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v4]
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <mVmqtudKUR8HLr0Wm1Wo2Dphi3IrUGnmj2YE7ZmKL8c=.bedad5be-e1f8-49d3-8d62-d45ee9dc1124@github.com>

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Added @requires

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21647/files
  - new: https://git.openjdk.org/jdk/pull/21647/files/35a6fa4d..8395f445

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21647/head:pull/21647

PR: https://git.openjdk.org/jdk/pull/21647

From ccheung at openjdk.org  Wed Oct 23 17:12:40 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 23 Oct 2024 17:12:40 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v3]
In-Reply-To: <6hF2-lkUNnzJpmou-rgkj9oSQEwlyAr-ltZFV7At4Ck=.27d2542b-7d76-4eb3-b5f0-4690935cf467@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <6hF2-lkUNnzJpmou-rgkj9oSQEwlyAr-ltZFV7At4Ck=.27d2542b-7d76-4eb3-b5f0-4690935cf467@github.com>
Message-ID: <cAHONda1zBfiE0fsfBSn9B4-WKTt8WFNtPd4GzIWyss=.0c56cfe4-c827-4abd-89fd-6ab852b3dc34@github.com>

On Wed, 23 Oct 2024 16:55:21 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calvin comments and copyright

Changes requested by ccheung (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java line 50:

> 48:  * @requires vm.gc.Parallel
> 49:  * @requires vm.gc.G1
> 50:  * requires vm.bits == "64"

Missing the `@` before `requires`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21647#pullrequestreview-2389468004
PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813197656

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 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 iklam at openjdk.org  Wed Oct 23 18:48:06 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 23 Oct 2024 18:48:06 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v4]
In-Reply-To: <ieV8-KLJR4TSGdhfd_qiAyPula_cxH0E6SAm_5SUa90=.c6ed20c1-7046-4acd-ac89-72eac7e75596@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <UerwUw4MtQHC8QkhjbWD8aAkhdWVeozIl-1NFSS3YTM=.62746be0-a932-4fb4-9228-ed5992fa5821@github.com>
 <ieV8-KLJR4TSGdhfd_qiAyPula_cxH0E6SAm_5SUa90=.c6ed20c1-7046-4acd-ac89-72eac7e75596@github.com>
Message-ID: <fgjaUyTTWPgLDhsQqEnCEpl8aracgGcjMaTYRUKjGEo=.c0286838-df81-450e-83ea-da4be6560fd7@github.com>

On Wed, 23 Oct 2024 15:42:26 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/prims/whitebox.cpp line 2162:
>> 
>>> 2160: 
>>> 2161: WB_ENTRY(jboolean, WB_CanWriteJavaHeapArchive(JNIEnv* env))
>>> 2162:   return HeapShared::can_write() && ArchiveHeapLoader::can_use();
>> 
>> Do we still need the `&& ArchiveHeapLoader::can_use()` part?
>
> I left it in since it may be a valuable check in case there are further changes or additions to the GCs.

But the code does not do what its name suggests. If this is not required now, I think we should remove the can_load part so the code is not confusing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21647#discussion_r1813352439

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: <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 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 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 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 kvn at openjdk.org  Wed Oct 23 22:54:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 23 Oct 2024 22:54:04 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
Message-ID: <Dl_ngI3xb76fXEkhvTr3X34M4A2X3K_E0Yyhdzf9xco=.ce633261-fc38-4aa6-ba3d-459551113ca4@github.com>

On Tue, 22 Oct 2024 18:11:45 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   set avx and evex in test

What is holding this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2433676488

From duke at openjdk.org  Wed Oct 23 23:25:19 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 23 Oct 2024 23:25:19 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
Message-ID: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>

> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.

hanklo6 has updated the pull request incrementally with one additional commit since the last revision:

  Add flags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21644/files
  - new: https://git.openjdk.org/jdk/pull/21644/files/ed7c10a2..d564a588

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21644&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21644&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21644/head:pull/21644

PR: https://git.openjdk.org/jdk/pull/21644

From duke at openjdk.org  Wed Oct 23 23:25:19 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 23 Oct 2024 23:25:19 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v2]
In-Reply-To: <-V5MG-H9Blq88ZdrYU6bIkDoAgi69259ktjMzpox4pc=.65790c46-84a7-4ea2-9518-08da8c2dbe60@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <aKcG59WPRf1Cc6viwqxO6ImAzJ7YCvGotgtDtv4MCTQ=.55394a77-032f-41da-aeea-5b9bd97dedd5@github.com>
 <-V5MG-H9Blq88ZdrYU6bIkDoAgi69259ktjMzpox4pc=.65790c46-84a7-4ea2-9518-08da8c2dbe60@github.com>
Message-ID: <Tca45bH04TZaknFMz9GS8kiQsFwu_WjuqGEiE96_rO8=.a626931e-18c3-480b-afe6-f3703bbf7d1f@github.com>

On Wed, 23 Oct 2024 00:19:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   set avx and evex in test
>
> src/hotspot/cpu/x86/vm_version_x86.hpp line 646:
> 
>> 644:   static void set_evex_cpuFeatures() { _features |= (CPU_AVX512F | CPU_SSE | CPU_SSE2 | CPU_VZEROUPPER ); }
>> 645:   static void set_apx_cpuFeatures() { _features |= CPU_APX_F; }
>> 646:   static void set_bmi1_cpuFeatures() { _features |= CPU_BMI1; }
> 
> It would be better to change this as:
> static void set_bmi_cpuFeatures() { _features |= (CPU_BMI1 | CPU_BMI2 | CPU_LZCNT); }
> And then use set_bmi_cpuFeatures() in the gtest.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1813940235

From sviswanathan at openjdk.org  Wed Oct 23 23:33:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 23 Oct 2024 23:33:06 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <u78PL8CQG9bp03Gw8c2SFmDAQPODVv8KF5Lq70AFW_E=.af5424c0-2e24-40c8-9031-ff45afc6e1e5@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21644#pullrequestreview-2390859454

From dholmes at openjdk.org  Thu Oct 24 01:46:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 01:46:11 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v4]
In-Reply-To: <GwDbfFOxmQSmqbDtKQNP1C4FmwUvEl6fU126SZhbf18=.304f4bdd-30e7-4eaf-a9ea-5b11cce0b6d5@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <GwDbfFOxmQSmqbDtKQNP1C4FmwUvEl6fU126SZhbf18=.304f4bdd-30e7-4eaf-a9ea-5b11cce0b6d5@github.com>
Message-ID: <61GRbui39zp3EpKxxgy9Nm0v0atWY0ufImcx35XfHSM=.a62e7b03-c95f-47cd-917e-7484f4104c91@github.com>

On Wed, 23 Oct 2024 13:51:33 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> String interning can be done on 4 different types of strings:
>> - oop-strings (unicode)
>> - oop-strings (latin1)
>> - Symbols (non-null-terminated utf8)
>> - null-terminated utf8 char arrays
>> 
>> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table.
>> 
>> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation.
>> 
>> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations.
>> 
>> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build)
>> 
>> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types.
>> Also tested and passes tiers 1-3.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from david

Thanks for updates!

-------------

PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2391029595

From dholmes at openjdk.org  Thu Oct 24 01:46:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 01:46:12 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v3]
In-Reply-To: <GAmeTxKYN1zL_S6S5et5t_uSM5CQx-NmaKa3JF8KgVE=.744721c5-5a27-4f19-8cb1-3e9317e437ed@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>
 <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>
 <GAmeTxKYN1zL_S6S5et5t_uSM5CQx-NmaKa3JF8KgVE=.744721c5-5a27-4f19-8cb1-3e9317e437ed@github.com>
Message-ID: <y5EOy90Xc8bztnfSCtcHsN_8SKu4SzYezjW3PypoYXw=.62bc9c2a-4c7f-4fa1-ab78-fe5a7357295f@github.com>

On Wed, 23 Oct 2024 13:59:16 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> test/hotspot/gtest/classfile/test_stringConversion.cpp line 36:
>> 
>>> 34: 
>>> 35: // Complex string " Ja?v??!?? ", UTF8 has character lengths 13122133 = 16
>>> 36: static const unsigned char static_utf8_str[] = {0x4A, 0x61, 0xCC, 0x84, 0x76, 0xC3, 0xA1, 0xC2, 0xAE, 0x21, 0xE2, 0x98, 0xBA, 0xE2, 0x98, 0xBB};
>> 
>> 0x61 is `a` not a-with-tilde ??
>
> 'a?' in this case is an 'a' (0x61) followed by a [Combining Macron](https://www.compart.com/en/unicode/U+0304) '??' (0xCC 0x84)

Oh that is subtle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1814116942

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 dholmes at openjdk.org  Thu Oct 24 01:56:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 01:56:18 GMT
Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop,
 TRAPS) [v3]
In-Reply-To: <GAmeTxKYN1zL_S6S5et5t_uSM5CQx-NmaKa3JF8KgVE=.744721c5-5a27-4f19-8cb1-3e9317e437ed@github.com>
References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com>
 <HgFuxNuqgmwP3r-ydgduxM3u6lj4JcX4T1iqIeC43WE=.accf48bc-05d8-4f71-acb5-289d35d36760@github.com>
 <EdNRa2v2CV4qJ16p2mgIe639ewQ08RKnVCYC-r4o9n4=.64daeb76-2cca-4cef-bd3d-6954b6267762@github.com>
 <GAmeTxKYN1zL_S6S5et5t_uSM5CQx-NmaKa3JF8KgVE=.744721c5-5a27-4f19-8cb1-3e9317e437ed@github.com>
Message-ID: <hRTUv7jbJVU_C6-OfON0YgvXjsYmXJqNpQFlO6pgAdk=.99d76114-7d27-47c0-b559-0cd6d9bab4d5@github.com>

On Wed, 23 Oct 2024 13:55:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/classfile/stringTable.cpp line 473:
>> 
>>> 471: oop StringTable::intern(const char* utf8_string, TRAPS) {
>>> 472:   if (utf8_string == nullptr) return nullptr;
>>> 473:   int length = static_cast<int>(strlen(utf8_string));
>> 
>> Is the source for such a string always a constant pool entry, and so known to < 64K in length?
>
> I am not sure. The previous implementation stored length as `int`, so my assumption is that it would be fine. If it is a problem, I could take some time to change the various lengths to `size_t`s instead.

See the preamble in utf8.hpp. The unicode length of a utf8 string is assumed/required to fit in an int, but the raw utf8 length need not. Changing to use size_t may have a significant fanout however.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1814128014

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 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: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 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 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 epeter at openjdk.org  Thu Oct 24 06:23:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:23:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <TGwYvzGK2pFFJer7EghvuyiyKYvc8VGYb5vVmboyF04=.6566f83b-fca3-46d1-a973-a3d94f9366c6@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

src/hotspot/cpu/x86/x86.ad line 10725:

> 10723: %}
> 10724: 
> 10725: instruct vector_saturating_subword_mem(vec dst, vec src1, memory src2)

Nit: above you always have `add` and `sub` in the name and the `format`. I and here and in some cases below not. Would be nice if it was consistent - would also make reading the OptoAssembly easier if one knows if it is an add or sub ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814331929

From epeter at openjdk.org  Thu Oct 24 06:34:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:34:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 32:

> 30:  * @since   24
> 31:  */
> 32: public final class VectorMath {

I think this class could have been split into a separate RFE, together with its tests. I would prefer that next time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814340685

From epeter at openjdk.org  Thu Oct 24 06:34:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:34:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
Message-ID: <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>

On Thu, 24 Oct 2024 06:28:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Factor out IR tests and Transforms to follow-up PRs.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 32:
> 
>> 30:  * @since   24
>> 31:  */
>> 32: public final class VectorMath {
> 
> I think this class could have been split into a separate RFE, together with its tests. I would prefer that next time.

Also: why did we not add these `Long.minUnsigned` etc? I guess that was already discussed?
Because we can easily also use this with the auto-vectorizer or more generally. Saturating and unsigned ops are generally useful I think...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814343654

From thartmann at openjdk.org  Thu Oct 24 06:58:15 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Oct 2024 06:58:15 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <j9w7aKhuBlEHymNJvhOeD0v3vOq2bAVJBLIgCR9UUjQ=.eea03372-3c7d-4ced-a1c5-d532976612ad@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21644#pullrequestreview-2391486413

From epeter at openjdk.org  Thu Oct 24 06:58:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:58:18 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

Ok, now it looks better.

I would still have preferred the `VectorMath` class with its test to be in a separate PR. Please do that next time.

I have a few more questions / comments, but we are really close now.
I'm especially worried about only testing a few constant values - we should try to go for better coverage - of all values if possible.

src/hotspot/cpu/x86/x86.ad line 10790:

> 10788:   predicate(is_subword_type(Matcher::vector_element_basic_type(n)) &&
> 10789:             n->is_SaturatingVector() && !n->as_SaturatingVector()->is_unsigned());
> 10790:   match(Set dst (SaturatingAddV (Binary dst (LoadVector src)) mask));

Do equivalent store operations exist we could also match for?

test/jdk/jdk/incubator/vector/VectorMathTest.java line 70:

> 68:     public static short[] INPUT_SS = {Short.MIN_VALUE,   (short)(Short.MIN_VALUE + TEN_S), ZERO_S, (short)(Short.MAX_VALUE - TEN_S), Short.MAX_VALUE};
> 69:     public static int[]   INPUT_SI = {Integer.MIN_VALUE, (Integer.MIN_VALUE + TEN_I),      ZERO_I, Integer.MAX_VALUE - TEN_I,        Integer.MAX_VALUE};
> 70:     public static long[]  INPUT_SL = {Long.MIN_VALUE,    Long.MIN_VALUE + TEN_L,           ZERO_L, Long.MAX_VALUE - TEN_L,           Long.MAX_VALUE};

Ok, now we have 4 or 5 hand-crafted examples. Is that sufficient? Some random values would be nice, then we know that at least eventually we have full coverage.

test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingBinary-Masked-op.template line 8:

> 6: 
> 7:         for (int ic = 0; ic < INVOC_COUNT; ic++) {
> 8:             for (int i = 0; i < a.length; i += SPECIES.length()) {

I think this does not check if the generated vectors are too long. We had bugs in the past where we should have created say 2-element vectors, but the backend wrongly created 4-element vectors. This is especially an issue with vectors that do direct memory access.

With a simple "counting-up" test, you will probably not catch this. It could be good to have a "counting-down" example as well. What do you think?

test/jdk/jdk/incubator/vector/templates/Unit-header.template line 1244:

> 1242:                 return fill(s * BUFFER_REPS,
> 1243:                             i -> ($type$)($Boxtype$.MIN_VALUE + 100));
> 1244:             })

Not sure I see this right. But are we only providing these 4 constants as inputs, and all values in the input arrays will be identical? If that is true: we should have some random inputs, or at least dependent on `i`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2391445047
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814366518
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814355931
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814363960
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814371488

From epeter at openjdk.org  Thu Oct 24 06:58:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:58:18 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
Message-ID: <g6VkTPXiCIZyAfGBqV-mBR9szOQj5d6Y_cAh5xrQDpY=.1119ee52-5212-4220-9afe-859782e747af@github.com>

On Thu, 24 Oct 2024 06:44:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Factor out IR tests and Transforms to follow-up PRs.
>
> test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingBinary-Masked-op.template line 8:
> 
>> 6: 
>> 7:         for (int ic = 0; ic < INVOC_COUNT; ic++) {
>> 8:             for (int i = 0; i < a.length; i += SPECIES.length()) {
> 
> I think this does not check if the generated vectors are too long. We had bugs in the past where we should have created say 2-element vectors, but the backend wrongly created 4-element vectors. This is especially an issue with vectors that do direct memory access.
> 
> With a simple "counting-up" test, you will probably not catch this. It could be good to have a "counting-down" example as well. What do you think?

Also: all of these cases load, and directly store again. Does that not mean all tests will probably pick the "..._mem" backend operations? Or do we actually end up testing all backend operations with the tests we have here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814368049

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 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 dholmes at openjdk.org  Thu Oct 24 07:20:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 07:20:05 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <FFzwlEK2fMgOj0PaWIdLkr0unxD1MuZ6XFvFW5YEjok=.b975ffc3-79ec-48f9-87cf-716ea709e8af@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

I will submit this to our CI to see if we can verify it on the macMini

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2434486850

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 tschatzl at openjdk.org  Thu Oct 24 08:11:57 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 24 Oct 2024 08:11:57 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
Message-ID: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>

Hi all,

  please review this change that makes ZGC compile without the C2 compiler.

The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).

Testing: manual compilation without C2, gha

Thanks,
  Thomas

-------------

Commit messages:
 - Hi all,

Changes: https://git.openjdk.org/jdk/pull/21677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342939
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21677/head:pull/21677

PR: https://git.openjdk.org/jdk/pull/21677

From eosterlund at openjdk.org  Thu Oct 24 08:20:05 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Oct 2024 08:20:05 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
Message-ID: <Rn4tmbBG02esTRkjTgBMO24YlLt_CwP7qxNfvuG-mVY=.324f6c89-9165-4e7c-a416-8f8c2351007f@github.com>

On Thu, 24 Oct 2024 08:06:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes ZGC compile without the C2 compiler.
> 
> The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).
> 
> Testing: manual compilation without C2, gha
> 
> Thanks,
>   Thomas

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21677#pullrequestreview-2391679825

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 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 mli at openjdk.org  Thu Oct 24 10:21:04 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 24 Oct 2024 10:21:04 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
Message-ID: <UmtCEFBHheVW8IfKuTVTNqcOxg9CTRdRNVON69j2tFk=.ae7a2ac5-44a0-45ba-944a-771da3400ffd@github.com>

On Thu, 24 Oct 2024 08:06:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes ZGC compile without the C2 compiler.
> 
> The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).
> 
> Testing: manual compilation without C2, gha
> 
> Thanks,
>   Thomas

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21677#pullrequestreview-2392027366

From ihse at openjdk.org  Thu Oct 24 10:27:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Oct 2024 10:27:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <HzglriUa-aM_fagDfIFtWwtdx0DvSTbfgi1MgbkKvFQ=.d0809b64-2b53-4c12-9664-c52097e49625@github.com>

On Tue, 15 Oct 2024 20:22:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't hardcode server variant

Just to clarify, the problem:

chmod: /Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib: No such file or directory

mentioned in https://github.com/openjdk/jdk/pull/20837#issuecomment-2327132241 is a separate issue, fixed by  [JDK-8342858](https://bugs.openjdk.org/browse/JDK-8342858).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2434888627

From dholmes at openjdk.org  Thu Oct 24 10:55:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 10:55:06 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <Dg5M-gQhZt-7tecElIiNMe_CaSylJ_8iLzNAi91AzgI=.d47cb703-eaa2-4851-910e-3e3441f06bde@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

Not 100% sure I hit the same machine but it passed on a number of different mac systems so ... worth a shot. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2434944835

From fyang at openjdk.org  Thu Oct 24 11:25:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 24 Oct 2024 11:25:08 GMT
Subject: RFR: 8342882: RISC-V: Unify handling of jumps to runtime
In-Reply-To: <LLTj3H4_i4f4cPWYKV6zrsh3aDMOtC-iAkAEE8BFZzY=.46111cd7-6ab3-4607-a159-9db3451ee2f6@github.com>
References: <3F1Bd23soK36LccU_SOZiWwKRNCLJEGu9hS9GDkK__M=.6623ff60-528a-4956-b324-5ecf9d76f47c@github.com>
 <LLTj3H4_i4f4cPWYKV6zrsh3aDMOtC-iAkAEE8BFZzY=.46111cd7-6ab3-4607-a159-9db3451ee2f6@github.com>
Message-ID: <sVjUvycI2j20xxn4hm9LjG23tXCZyEB6Tei8T1viE6Y=.0b92581b-6e69-4abf-aa5c-23b52881a99a@github.com>

On Wed, 23 Oct 2024 11:13:34 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Thanks, looks good!

Hi, Thanks for the quick review. My local tier1-3 test on linux-riscv64 is good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21661#issuecomment-2435003669

From fyang at openjdk.org  Thu Oct 24 11:25:09 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 24 Oct 2024 11:25:09 GMT
Subject: Integrated: 8342882: RISC-V: Unify handling of jumps to runtime
In-Reply-To: <3F1Bd23soK36LccU_SOZiWwKRNCLJEGu9hS9GDkK__M=.6623ff60-528a-4956-b324-5ecf9d76f47c@github.com>
References: <3F1Bd23soK36LccU_SOZiWwKRNCLJEGu9hS9GDkK__M=.6623ff60-528a-4956-b324-5ecf9d76f47c@github.com>
Message-ID: <t3KtHgitQj8WUI50fBx33skqUNEdBA9_KaTOXXhpQYs=.d9138bfd-3da6-4362-a856-dccf1f19a736@github.com>

On Wed, 23 Oct 2024 10:20:10 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This fixes and unifies handling of jumps to runtime. Was previously discussed here [1]. ( Tagging @robehn )
> Seems not reasonable for `MacroAssembler::j(const Address &dest, Register temp)` to directly delegate work to `MacroAssembler::j(const address dest, Register temp)` for literal Address. This could generate a plain `JAL`, which means when we relocate the code, but the `JAL` immediate could be too large. This change relaxes this constaint.
> 
> [1] https://github.com/openjdk/jdk/pull/21406#issuecomment-2415965656
> 
> Simply did a native fastdebug build and tried specjbb2005 workload.
> More testing on linux-riscv64 in progress.
> - [x] tier1 - tier3 (release)
> - [x] hotspot:tier1 (fastdebug)

This pull request has now been integrated.

Changeset: 85774b71
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85774b713edf8782f162ac25b61ce99a77e116f4
Stats:     31 lines in 7 files changed: 2 ins; 9 del; 20 mod

8342882: RISC-V: Unify handling of jumps to runtime

Reviewed-by: rehn

-------------

PR: https://git.openjdk.org/jdk/pull/21661

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 jsjolen at openjdk.org  Thu Oct 24 12:32:08 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 24 Oct 2024 12:32:08 GMT
Subject: RFR: 8340178: Make ArrayWithFreeList have Index type and move to
 utilities [v2]
In-Reply-To: <Hpe8VEEgT4X8uZgC19Xb26eOcAimthccH8-7awV34Bk=.3253a53a-662c-46f2-9278-50afd7f7d6f8@github.com>
References: <60GYHj6KckbaHKY1mDgIyiEjzkqdAKpRyNchQXi37xE=.2b6b0cbb-4066-4c56-9ff6-af58ffd55b38@github.com>
 <Hpe8VEEgT4X8uZgC19Xb26eOcAimthccH8-7awV34Bk=.3253a53a-662c-46f2-9278-50afd7f7d6f8@github.com>
Message-ID: <KpIu2-6EyRGHJPcBl8k5J7Hb-u_9Qh1spIUGsiaJVKo=.3dbf3a29-4ba1-4377-ac83-0041b3df4249@github.com>

On Wed, 18 Sep 2024 09:48:37 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This PR does multiple things:
>> 
>> 1. Gives `AWFL` an index template `I` which specifies the type of the indices, this lets us have very small indices and that saves memory.
>> 2. Gives `AWFL` the ability to store things in a static memory area of a specific length
>> 3. Finally, moves it to utilities for general consumption
>> 
>> For some context:
>> 
>> I tried to give `GrowableArray` the index type feature, but I hit a brick wall at changing the assert messages. It's also not a feature which has consensus, some people like it, and some people think it's too complex. I find putting a smaller and hidden `resizable_array` class In AWFL to be an acceptable compromise. I also believe that `GA` will not find too much competition with `AWFL`, as it has a less rich API and is really meant as an allocator interface rather than a general array type.
>> 
>> **Hint for reviewers:** Do NOT go into "Files changed", look at the commits to see the actual changes and ignore the commits with "Move" in the title.
>
> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Fixes after merge
>  - Merge remote-tracking branch 'openjdk/master' into move-to-utils
>  - Use int
>  - No need for reinterpret cast
>  - Style
>  - Change test
>  - Change AWFL
>  - Move AWFL
>  - Move test
>  - Changes to NCSS

Still awaiting review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20002#issuecomment-2435163794

From thartmann at openjdk.org  Thu Oct 24 12:47:06 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 24 Oct 2024 12:47:06 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <I2OFzlgM0QJuE7TZvIu8_fThpy8SZb7OFYzS8ViIGXU=.cccc33b6-02e5-4d2c-8e02-d6b0fc6dc9e8@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

Let's integrate this asap to get our testing back to a clean state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21644#issuecomment-2435196489

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 jbhateja at openjdk.org  Thu Oct 24 13:28:07 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:28:07 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <KKXoSiANoxHkEg1rtjHyry9WoLAgeF1yNQc6uxSzPjE=.b80bb641-aca3-470b-bcfe-081b9f7868be@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

src/hotspot/cpu/x86/vm_version_x86.hpp line 646:

> 644:   static void set_evex_cpuFeatures() { _features |= (CPU_AVX512F | CPU_SSE | CPU_SSE2 | CPU_VZEROUPPER ); }
> 645:   static void set_apx_cpuFeatures() { _features |= CPU_APX_F; }
> 646:   static void set_bmi_cpuFeatures() { _features |= (CPU_BMI1 | CPU_BMI2 | CPU_LZCNT); }

__ popcntl(rbx, r8);                                                        //    {load}popcnt ebx, r8d    IID137
    __ popcntl(r8, r9);                                                         //    {load}popcnt r8d, r9d    IID138
    __ popcntl(r9, r10);                                                        //    {load}popcnt r9d, r10d    IID139

Please also add feature CPU_POPCNT

test/hotspot/gtest/x86/test_assemblerx86.cpp line 71:

> 69:   FlagSetting flag_change_apx(UseAPX, true);
> 70:   VM_Version::set_bmi_cpuFeatures();
> 71:   VM_Version::set_evex_cpuFeatures();

FTR, Tests are mainly around REX2 promoted MAP0 and MAP1 legacy instructions, but entire APX support is currently enabled under EVEX flag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1814984450
PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1814145204

From jbhateja at openjdk.org  Thu Oct 24 13:36:50 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:36:50 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Review resolutions.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Factor out IR tests and Transforms to follow-up PRs.
 - Replacing flag based checks with CPU feature checks in IR validation test.
 - Remove Saturating IRNode patterns.
 - Restrict IR validation to newly added UMin/UMax transforms.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Prod build fix
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - New IR tests + additional IR transformations
 - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=31
  Stats: 9395 lines in 52 files changed: 8959 ins; 29 del; 407 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Oct 24 13:36:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:36:51 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
Message-ID: <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>

On Thu, 24 Oct 2024 06:46:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Factor out IR tests and Transforms to follow-up PRs.
>
> src/hotspot/cpu/x86/x86.ad line 10790:
> 
>> 10788:   predicate(is_subword_type(Matcher::vector_element_basic_type(n)) &&
>> 10789:             n->is_SaturatingVector() && !n->as_SaturatingVector()->is_unsigned());
>> 10790:   match(Set dst (SaturatingAddV (Binary dst (LoadVector src)) mask));
> 
> Do equivalent store operations exist we could also match for?

ISA only supports memory operands as second source operand.

> test/jdk/jdk/incubator/vector/VectorMathTest.java line 70:
> 
>> 68:     public static short[] INPUT_SS = {Short.MIN_VALUE,   (short)(Short.MIN_VALUE + TEN_S), ZERO_S, (short)(Short.MAX_VALUE - TEN_S), Short.MAX_VALUE};
>> 69:     public static int[]   INPUT_SI = {Integer.MIN_VALUE, (Integer.MIN_VALUE + TEN_I),      ZERO_I, Integer.MAX_VALUE - TEN_I,        Integer.MAX_VALUE};
>> 70:     public static long[]  INPUT_SL = {Long.MIN_VALUE,    Long.MIN_VALUE + TEN_L,           ZERO_L, Long.MAX_VALUE - TEN_L,           Long.MAX_VALUE};
> 
> Ok, now we have 4 or 5 hand-crafted examples. Is that sufficient? Some random values would be nice, then we know that at least eventually we have full coverage.

Hand crafter cases contains delimiting and general cases, in short they sufficiently cover entire value range.

> test/jdk/jdk/incubator/vector/templates/Unit-header.template line 1244:
> 
>> 1242:                 return fill(s * BUFFER_REPS,
>> 1243:                             i -> ($type$)($Boxtype$.MIN_VALUE + 100));
>> 1244:             })
> 
> Not sure I see this right. But are we only providing these 4 constants as inputs, and all values in the input arrays will be identical? If that is true: we should have some random inputs, or at least dependent on `i`.

Most important test points in a saturating operations are the edge conditions where overflow semantics differs and operation saturates a value than wrapping it around.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814998684
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814999013
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814998545

From jbhateja at openjdk.org  Thu Oct 24 13:36:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:36:51 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
Message-ID: <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>

On Thu, 24 Oct 2024 06:31:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 32:
>> 
>>> 30:  * @since   24
>>> 31:  */
>>> 32: public final class VectorMath {
>> 
>> I think this class could have been split into a separate RFE, together with its tests. I would prefer that next time.
>
> Also: why did we not add these `Long.minUnsigned` etc? I guess that was already discussed?
> Because we can easily also use this with the auto-vectorizer or more generally. Saturating and unsigned ops are generally useful I think...

PR is specially targeting explicit vectorization flow, we plan to address scalar intrinsification and auto-vectorization later, once type system has exposure to unsigned types.

>> test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingBinary-Masked-op.template line 8:
>> 
>>> 6: 
>>> 7:         for (int ic = 0; ic < INVOC_COUNT; ic++) {
>>> 8:             for (int i = 0; i < a.length; i += SPECIES.length()) {
>> 
>> I think this does not check if the generated vectors are too long. We had bugs in the past where we should have created say 2-element vectors, but the backend wrongly created 4-element vectors. This is especially an issue with vectors that do direct memory access.
>> 
>> With a simple "counting-up" test, you will probably not catch this. It could be good to have a "counting-down" example as well. What do you think?
>
> Also: all of these cases load, and directly store again. Does that not mean all tests will probably pick the "..._mem" backend operations? Or do we actually end up testing all backend operations with the tests we have here?

To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 

I have create an RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815000046
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814998821

From epeter at openjdk.org  Thu Oct 24 13:44:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 13:44:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

src/hotspot/cpu/x86/x86.ad line 10593:

> 10591:   match(Set dst (SaturatingAddV src1 src2));
> 10592:   match(Set dst (SaturatingSubV src1 src2));
> 10593:   format %{ "vector_addsub_saturating_subword $dst, $src1, $src2" %}

Could the `Opcode` be put into the `format` string? Not strictly necessary, but would be neat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815010088

From epeter at openjdk.org  Thu Oct 24 13:44:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 13:44:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
 <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
Message-ID: <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>

On Thu, 24 Oct 2024 13:30:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/VectorMathTest.java line 70:
>> 
>>> 68:     public static short[] INPUT_SS = {Short.MIN_VALUE,   (short)(Short.MIN_VALUE + TEN_S), ZERO_S, (short)(Short.MAX_VALUE - TEN_S), Short.MAX_VALUE};
>>> 69:     public static int[]   INPUT_SI = {Integer.MIN_VALUE, (Integer.MIN_VALUE + TEN_I),      ZERO_I, Integer.MAX_VALUE - TEN_I,        Integer.MAX_VALUE};
>>> 70:     public static long[]  INPUT_SL = {Long.MIN_VALUE,    Long.MIN_VALUE + TEN_L,           ZERO_L, Long.MAX_VALUE - TEN_L,           Long.MAX_VALUE};
>> 
>> Ok, now we have 4 or 5 hand-crafted examples. Is that sufficient? Some random values would be nice, then we know that at least eventually we have full coverage.
>
> Hand crafter cases contains delimiting and general cases, in short they sufficiently cover entire value range.

@PaulSandoz do you think this is sufficient coverage?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815012386

From epeter at openjdk.org  Thu Oct 24 13:44:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 13:44:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
Message-ID: <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>

On Thu, 24 Oct 2024 13:30:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Also: all of these cases load, and directly store again. Does that not mean all tests will probably pick the "..._mem" backend operations? Or do we actually end up testing all backend operations with the tests we have here?
>
> To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 
> 
> I have create an RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.

Ok, we can file a separate RFE. Though I really have voiced 2 concerns:
- Making sure we always test `_mem` and `_reg` variants in the backend. See your https://bugs.openjdk.org/browse/JDK-8342959
- Making sure we have tests that would detect vectors that are too long. This would require some padding between the vectors, so that we have some untouched space - and if it does get touched we know that a vector was too long. Does that make sense? This is I guess also a general concern - and would have to be applied to all vector instructions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815017678

From jbhateja at openjdk.org  Thu Oct 24 14:03:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 14:03:26 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
 <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
Message-ID: <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>

On Thu, 24 Oct 2024 13:36:53 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Review resolutions.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>>  - Factor out IR tests and Transforms to follow-up PRs.
>>  - Replacing flag based checks with CPU feature checks in IR validation test.
>>  - Remove Saturating IRNode patterns.
>>  - Restrict IR validation to newly added UMin/UMax transforms.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>>  - Prod build fix
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>>  - New IR tests + additional IR transformations
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c
>
> src/hotspot/cpu/x86/x86.ad line 10593:
> 
>> 10591:   match(Set dst (SaturatingAddV src1 src2));
>> 10592:   match(Set dst (SaturatingSubV src1 src2));
>> 10593:   format %{ "vector_addsub_saturating_subword $dst, $src1, $src2" %}
> 
> Could the `Opcode` be put into the `format` string? Not strictly necessary, but would be neat.

Desirable future extension, but its not related to this specific PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815050398

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 epeter at openjdk.org  Thu Oct 24 14:07:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 14:07:24 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
 <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
 <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>
Message-ID: <vo7yaqOXbMBtIITyjIIYq-DQqL25Y6noa2PBRdW1fMU=.99921f1a-fd0c-44ce-840a-ea342adeb7ab@github.com>

On Thu, 24 Oct 2024 13:59:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 10593:
>> 
>>> 10591:   match(Set dst (SaturatingAddV src1 src2));
>>> 10592:   match(Set dst (SaturatingSubV src1 src2));
>>> 10593:   format %{ "vector_addsub_saturating_subword $dst, $src1, $src2" %}
>> 
>> Could the `Opcode` be put into the `format` string? Not strictly necessary, but would be neat.
>
> Desirable future extension, but its not related to this specific PR.

Well, here it would be especially interesting, because it would tell us if we have a `sub` or an `add`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815058565

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 jbhateja at openjdk.org  Thu Oct 24 14:10:15 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 14:10:15 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
 <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
 <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>
Message-ID: <DNAWXAMOALG7D0uTxP5P4qDQJ5EV8baLwMTMYCZEPlY=.de326730-62df-4f90-9730-aac0e77ca118@github.com>

On Thu, 24 Oct 2024 13:38:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hand crafter cases contains delimiting and general cases, in short they sufficiently cover entire value range.
>
> @PaulSandoz do you think this is sufficient coverage?

Please note this test was added just to cover scalar operation validation in VectorMath, automated tests exercise these APIs in fallback implementation anyways.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815064343

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 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 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 psandoz at openjdk.org  Thu Oct 24 15:04:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 24 Oct 2024 15:04:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
Message-ID: <Vyw79ZVROQcEbDaCsKyIHAedT6tbEYrpXNcnkpME1QA=.edaa7e1e-678f-4806-abdd-7bf88d28e2a9@github.com>

On Thu, 24 Oct 2024 13:31:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Also: why did we not add these `Long.minUnsigned` etc? I guess that was already discussed?
>> Because we can easily also use this with the auto-vectorizer or more generally. Saturating and unsigned ops are generally useful I think...
>
> PR is specially targeting explicit vectorization flow, we plan to address scalar intrinsification and auto-vectorization later, once type system has exposure to unsigned types.

We are uncertain about their locations in `java.lang` at the moment. For now it's better to place them under incubation and then revisit later when we are more certain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815180240

From psandoz at openjdk.org  Thu Oct 24 15:10:15 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 24 Oct 2024 15:10:15 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <DNAWXAMOALG7D0uTxP5P4qDQJ5EV8baLwMTMYCZEPlY=.de326730-62df-4f90-9730-aac0e77ca118@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
 <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
 <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>
 <DNAWXAMOALG7D0uTxP5P4qDQJ5EV8baLwMTMYCZEPlY=.de326730-62df-4f90-9730-aac0e77ca118@github.com>
Message-ID: <koMDh1i6p6SEDncMXgPq9vbHZO9pFHgTYjvE10Mx21I=.a7879b0a-de1c-4f89-9228-c025332b2c51@github.com>

On Thu, 24 Oct 2024 14:07:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @PaulSandoz do you think this is sufficient coverage?
>
> Please note this test was added just to cover scalar operation validation in VectorMath, automated tests exercise these APIs in fallback implementation anyways.

I think the coverage is sufficient for now and we can expand later. The test is written so that it should be possible to more easily refactor and add further dynamically generated test cases. (Note it is deliberately not a test designed to specifically exercise C2 - if/when we add auto vectorization IR tests would be required).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815191672

From psandoz at openjdk.org  Thu Oct 24 15:19:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 24 Oct 2024 15:19:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
 <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
Message-ID: <HhVt-vF5pur1QVZzkxyCS2dZf8fx95zomNgvASaPaC0=.872254c0-6d39-4fe9-b43d-b1de1fa3f03a@github.com>

On Thu, 24 Oct 2024 13:41:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 
>> 
>> I have create an RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.
>
> Ok, we can file a separate RFE. Though I really have voiced 2 concerns:
> - Making sure we always test `_mem` and `_reg` variants in the backend. See your https://bugs.openjdk.org/browse/JDK-8342959
> - Making sure we have tests that would detect vectors that are too long. This would require some padding between the vectors, so that we have some untouched space - and if it does get touched we know that a vector was too long. Does that make sense? This is I guess also a general concern - and would have to be applied to all vector instructions.

Good point on vector operations overrunning bounds. I worry about the computational increase of doing this generally for all operations (explicit or for auto vectorization i suppose). Perhaps we can focus on areas where we know this may be problematic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815211324

From kvn at openjdk.org  Thu Oct 24 15:26:23 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Oct 2024 15:26:23 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
Message-ID: <F50yt3kok3eE02x8VXcLzS4I9yud_kuYr20pij9o0O4=.05f3f2d5-d6a9-4897-99d8-0162f3f2edb6@github.com>

On Wed, 23 Oct 2024 23:25:19 GMT, hanklo6 <duke at openjdk.org> wrote:

>> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.
>
> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add flags

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21644#pullrequestreview-2393035843

From kvn at openjdk.org  Thu Oct 24 15:26:24 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Oct 2024 15:26:24 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <KKXoSiANoxHkEg1rtjHyry9WoLAgeF1yNQc6uxSzPjE=.b80bb641-aca3-470b-bcfe-081b9f7868be@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
 <KKXoSiANoxHkEg1rtjHyry9WoLAgeF1yNQc6uxSzPjE=.b80bb641-aca3-470b-bcfe-081b9f7868be@github.com>
Message-ID: <cnDWu4i5ZNXPL_ZBnfTE-FswSJlk1aLsu8ahWJyNSUw=.526d5cf7-6289-4d5e-9f00-cb5e3f258af2@github.com>

On Thu, 24 Oct 2024 13:22:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> hanklo6 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add flags
>
> src/hotspot/cpu/x86/vm_version_x86.hpp line 646:
> 
>> 644:   static void set_evex_cpuFeatures() { _features |= (CPU_AVX512F | CPU_SSE | CPU_SSE2 | CPU_VZEROUPPER ); }
>> 645:   static void set_apx_cpuFeatures() { _features |= CPU_APX_F; }
>> 646:   static void set_bmi_cpuFeatures() { _features |= (CPU_BMI1 | CPU_BMI2 | CPU_LZCNT); }
> 
> __ popcntl(rbx, r8);                                                        //    {load}popcnt ebx, r8d    IID137
>     __ popcntl(r8, r9);                                                         //    {load}popcnt r8d, r9d    IID138
>     __ popcntl(r9, r10);                                                        //    {load}popcnt r9d, r10d    IID139
> 
> Please also add feature CPU_POPCNT

I suggest to do that in separate PR since we already tested current version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1815223385

From fbredberg at openjdk.org  Thu Oct 24 15:28:37 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 24 Oct 2024 15:28:37 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
Message-ID: <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>

> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
> 
> Tested ok tier1-3.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Update after review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21584/files
  - new: https://git.openjdk.org/jdk/pull/21584/files/21da21e5..f1ef577a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21584&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21584&range=00-01

  Stats: 33 lines in 6 files changed: 0 ins; 16 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21584/head:pull/21584

PR: https://git.openjdk.org/jdk/pull/21584

From fbredberg at openjdk.org  Thu Oct 24 15:50:06 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 24 Oct 2024 15:50:06 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <HlrNEklFxVyccjFrqlIF_Sv2G2UQ6TjoLT3bvUX31Rk=.c168ed24-b9f1-476f-a7f1-c6c13806b970@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HlrNEklFxVyccjFrqlIF_Sv2G2UQ6TjoLT3bvUX31Rk=.c168ed24-b9f1-476f-a7f1-c6c13806b970@github.com>
Message-ID: <WFb_aSU7JonX6ZIGO6YtJSyBuuudwjH2gd1quCrwaeQ=.044f580a-dec5-4476-82cc-b574759c5821@github.com>

On Mon, 21 Oct 2024 23:48:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 480:
> 
>> 478:   membar(StoreLoad);
>> 479: 
>> 480:   // Check if the entry lists are empty.
> 
> Suggestion:
> 
>   // Check if the entry lists are empty (EntryList first - by convention).

fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21584#discussion_r1815271380

From fbredberg at openjdk.org  Thu Oct 24 15:50:07 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 24 Oct 2024 15:50:07 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <NAfebQGzs_uXXCNWZk3HUR_yacgV_pbEE3fstnLMRW8=.00050a53-1b6a-4e14-af25-20623369b3f9@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HlrNEklFxVyccjFrqlIF_Sv2G2UQ6TjoLT3bvUX31Rk=.c168ed24-b9f1-476f-a7f1-c6c13806b970@github.com>
 <NAfebQGzs_uXXCNWZk3HUR_yacgV_pbEE3fstnLMRW8=.00050a53-1b6a-4e14-af25-20623369b3f9@github.com>
Message-ID: <Blt6r8f_NdQqF1QpcAmjyVIFYKkrG6CRTUmiTUrkuJM=.b86b2ac0-7c78-4260-a9d9-d6b242b7b2eb@github.com>

On Mon, 21 Oct 2024 23:51:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1158:
>> 
>>> 1156: // The race could be removed by reading cxq before EntryList, but it
>>> 1157: // would come with an added cost of needing a loadload fence between the
>>> 1158: // reads.
>> 
>> I think you can write this much more succinctly as this isn't really a race per-se, but part of the overall operation of the protocol. Suggestion:
>> 
>> // Note that we read the EntryList and then the cxq after dropping the lock, so the values need not form a stable
>> // snapshot. In particular, after reading the (empty) EntryList, another thread could acquire and release the lock, moving 
>> // any entries in the cxq to the EntryList, causing the current thread to see an empty cxq and conclude there are no
>> // waiters. But this is okay as the thread that moved the cxq is responsible for waking the successor.
>
> Update: okay the fields are volatile so maybe the compiler will preserve the written order.

I'd decided to go with your suggestion. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21584#discussion_r1815274837

From sviswanathan at openjdk.org  Thu Oct 24 15:57:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 24 Oct 2024 15:57:06 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <Be0GEMddzDo2KG1luVL1poXDqmewb-LfuttDf5Jqv_M=.2027d69b-8c46-4e3a-9dd6-54f741987896@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
 <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
 <Be0GEMddzDo2KG1luVL1poXDqmewb-LfuttDf5Jqv_M=.2027d69b-8c46-4e3a-9dd6-54f741987896@github.com>
Message-ID: <jY_Yc2TdJ7GvpJEWb6nGUwevjy_iTPtrrwhwKDqwgV4=.b2dea8d2-e878-4eff-8bc0-4b2b35f562c2@github.com>

On Tue, 22 Oct 2024 11:44:30 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>>> This is not a review but I've run some testing with the current patch and found the following two failures on linux-x64-debug:
>>> 
>> 
>> @chhagedorn could you send me the mach5 command line (or other means) to run these tests?
>
>> @ferakocz I think you need to enble SHA3 testing in jtreg tests we have by modifying: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L106
>> 
>> [JDK-8252204](https://bugs.openjdk.org/browse/JDK-8252204) added several C2 tests for SHA3 intrinsics in `test/hotspot/jtreg/compiler/intrinsics/sha`. Please make sure your changes passed those tests.
> 
> I did that, plus restored the error message, now all the tests suggested by @chhagedorn pass.

@ferakocz Thanks for taking my inputs into consideration and the corresponding changes. Would it be also possible for you to add comments to the rounds24_loop code if you want us to review that in detail. Otherwise the PR looks good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2435668971

From fbredberg at openjdk.org  Thu Oct 24 15:58:05 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 24 Oct 2024 15:58:05 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList
In-Reply-To: <1OBDLYx0bXK4r8hdIxuiLpRj4h0Ns2y_GXcJVmryN9w=.80957dcb-66bb-4d99-bc1e-1d12f2e99d42@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <1OBDLYx0bXK4r8hdIxuiLpRj4h0Ns2y_GXcJVmryN9w=.80957dcb-66bb-4d99-bc1e-1d12f2e99d42@github.com>
Message-ID: <cx_vZhMueOZEdS4uRUQg3vLNn9w09X6M7OzOQPkYMfk=.453160fe-7502-44d8-88d8-7cfaf11b0e0f@github.com>

On Sat, 19 Oct 2024 01:01:21 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
>> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
>> 
>> Tested ok tier1-3.
>
> We don't have a LoadLoad on aarch64 to enforce the ordering, so isn't it more correct to say that the code handles either ordering correctly, and leave x86 the way it was?

@dean-long 
> We don't have a LoadLoad on aarch64 to enforce the ordering, so isn't it more correct to say that the code handles either ordering correctly, and leave x86 the way it was?

Both you and David was on to the same thing, so I decided to rewrite as per David's suggestion. However I will change the x86 code so it will follow the same order as the rest, just to avoid any head scratching about why x86 is done differently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21584#issuecomment-2435671276

From duke at openjdk.org  Thu Oct 24 16:04:13 2024
From: duke at openjdk.org (hanklo6)
Date: Thu, 24 Oct 2024 16:04:13 GMT
Subject: RFR: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
 [v3]
In-Reply-To: <cnDWu4i5ZNXPL_ZBnfTE-FswSJlk1aLsu8ahWJyNSUw=.526d5cf7-6289-4d5e-9f00-cb5e3f258af2@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
 <nxRAoeOgqp6E8_lTLxh_oLvwKKu60SIQZEvDVlefmEk=.77b38b4a-0975-4fe1-b8cc-7b9fb5dc8105@github.com>
 <KKXoSiANoxHkEg1rtjHyry9WoLAgeF1yNQc6uxSzPjE=.b80bb641-aca3-470b-bcfe-081b9f7868be@github.com>
 <cnDWu4i5ZNXPL_ZBnfTE-FswSJlk1aLsu8ahWJyNSUw=.526d5cf7-6289-4d5e-9f00-cb5e3f258af2@github.com>
Message-ID: <RcZUNh5EMHOx9XsvRnAN4su7TEVTjPqlRf4-XV-35JQ=.e97c3024-fd26-4497-914b-6ba02820a73f@github.com>

On Thu, 24 Oct 2024 15:22:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/vm_version_x86.hpp line 646:
>> 
>>> 644:   static void set_evex_cpuFeatures() { _features |= (CPU_AVX512F | CPU_SSE | CPU_SSE2 | CPU_VZEROUPPER ); }
>>> 645:   static void set_apx_cpuFeatures() { _features |= CPU_APX_F; }
>>> 646:   static void set_bmi_cpuFeatures() { _features |= (CPU_BMI1 | CPU_BMI2 | CPU_LZCNT); }
>> 
>> __ popcntl(rbx, r8);                                                        //    {load}popcnt ebx, r8d    IID137
>>     __ popcntl(r8, r9);                                                         //    {load}popcnt r8d, r9d    IID138
>>     __ popcntl(r9, r10);                                                        //    {load}popcnt r9d, r10d    IID139
>> 
>> Please also add feature CPU_POPCNT
>
> I suggest to do that in separate PR since we already tested current version.

Thanks, I'll add it on another PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21644#discussion_r1815297592

From duke at openjdk.org  Thu Oct 24 16:04:13 2024
From: duke at openjdk.org (hanklo6)
Date: Thu, 24 Oct 2024 16:04:13 GMT
Subject: Integrated: 8342768: GTest AssemblerX86.validate_vm failed:
 assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported
In-Reply-To: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
References: <aUZ_E05Uroe4O9G9zl7M5J9bKlc0jZ1h-PIYmmbHYRs=.6df5de01-95e4-4c21-a66b-36857c198de3@github.com>
Message-ID: <zZbjnSZXLoDmVy-eOm7nu3HoxO3d7IlAfq2NgiNTaBA=.0baf6cf8-45cf-4d17-aaec-03ed393dc268@github.com>

On Tue, 22 Oct 2024 17:41:13 GMT, hanklo6 <duke at openjdk.org> wrote:

> The `tzcnt` instruction requires the VM to support `bmi1` feature, which we set directly when running the test.

This pull request has now been integrated.

Changeset: d8c3b0f8
Author:    hanklo6 <hank.lo at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8c3b0f834c603fe115ef4ca442727948b7a834e
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8342768: GTest AssemblerX86.validate_vm failed: assert(VM_Version::supports_bmi1()) failed: tzcnt instruction not supported

Reviewed-by: sviswanathan, thartmann, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/21644

From kvn at openjdk.org  Thu Oct 24 16:39:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Oct 2024 16:39:05 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
Message-ID: <T0HHdw1VKmLsivKPNvA0W9kYDj0fRY0TTzEn3uv17Es=.d1ff1b9d-b099-430b-92a5-0d3c79ea5e2f@github.com>

On Thu, 24 Oct 2024 08:06:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes ZGC compile without the C2 compiler.
> 
> The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).
> 
> Testing: manual compilation without C2, gha
> 
> Thanks,
>   Thomas

Do you have something similar for C1, Graal?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21677#pullrequestreview-2393207053

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 duke at openjdk.org  Thu Oct 24 17:40:05 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Thu, 24 Oct 2024 17:40:05 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v7]
In-Reply-To: <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>
Message-ID: <Wk93AyIqkL5E-nZpkMGyxj5COpydbTQAEoRf_NgAYN4=.7d153147-58d8-4378-afde-3fe020c07588@github.com>

On Tue, 22 Oct 2024 11:33:57 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assembly changes suggested by sviswa7

Could someone approve my changes so that I can integrate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2435936374

From jbhateja at openjdk.org  Thu Oct 24 17:41:16 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 17:41:16 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <vo7yaqOXbMBtIITyjIIYq-DQqL25Y6noa2PBRdW1fMU=.99921f1a-fd0c-44ce-840a-ea342adeb7ab@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
 <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
 <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>
 <vo7yaqOXbMBtIITyjIIYq-DQqL25Y6noa2PBRdW1fMU=.99921f1a-fd0c-44ce-840a-ea342adeb7ab@github.com>
Message-ID: <9FAHfjE1Kq9dlE7RRWdqnXZYGQ0SXVevZi4EWuYinv0=.28778d36-1a8e-408c-a447-adc963cdd1b8@github.com>

On Thu, 24 Oct 2024 14:04:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Desirable future extension, but its not related to this specific PR.
>
> Well, here it would be especially interesting, because it would tell us if we have a `sub` or an `add`.

Lets address it in a follow up PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815473182

From sviswanathan at openjdk.org  Thu Oct 24 18:00:15 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 24 Oct 2024 18:00:15 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v7]
In-Reply-To: <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>
Message-ID: <CUVQeSHfQaG_eeippEz3FXeRqLj-k9A0xGW5cOF6aYM=.ebc57396-f750-46ab-9eed-2875e09e0c8a@github.com>

On Tue, 22 Oct 2024 11:33:57 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assembly changes suggested by sviswa7

I haven't reviewed the rounds_24 loop. Other than that the PR looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21352#pullrequestreview-2393381768

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 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 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 eosterlund at openjdk.org  Thu Oct 24 19:09:04 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 24 Oct 2024 19:09:04 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <T0HHdw1VKmLsivKPNvA0W9kYDj0fRY0TTzEn3uv17Es=.d1ff1b9d-b099-430b-92a5-0d3c79ea5e2f@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
 <T0HHdw1VKmLsivKPNvA0W9kYDj0fRY0TTzEn3uv17Es=.d1ff1b9d-b099-430b-92a5-0d3c79ea5e2f@github.com>
Message-ID: <fxeQ9xuiOuftlVJQB3di1NBTDTeS_LLpmaGhgi_GeUM=.f69312c7-e8d1-42a8-a383-038b8cb48e08@github.com>

On Thu, 24 Oct 2024 16:36:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Do you have something similar for C1, Graal?

This is used to identify compilers that elide barriers on freshly allocated objects. So it's C2 only now. Should have Graal too. Tom is fixing that as we speak I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21677#issuecomment-2436145678

From kvn at openjdk.org  Thu Oct 24 19:14:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 24 Oct 2024 19:14:06 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
Message-ID: <s0VpjOw_jbztyN5XtCa5OkyJvgl6LDYxArp0yVob9hI=.ef2af646-ba34-4e72-84dd-850281ab5397@github.com>

On Thu, 24 Oct 2024 08:06:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes ZGC compile without the C2 compiler.
> 
> The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).
> 
> Testing: manual compilation without C2, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by kvn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21677#pullrequestreview-2393513396

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 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 matsaave at openjdk.org  Thu Oct 24 20:15:39 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 24 Oct 2024 20:15:39 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v5]
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <5fbkBeoXHfCfKGVVIPG0zexDYgEbuia9fEXtfBhqEFE=.d01ef3dc-992b-4109-8aba-0f3be19adc8c@github.com>

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed can_use from whitebox

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21647/files
  - new: https://git.openjdk.org/jdk/pull/21647/files/8395f445..5400c057

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21647/head:pull/21647

PR: https://git.openjdk.org/jdk/pull/21647

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 dlong at openjdk.org  Thu Oct 24 20:32:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 24 Oct 2024 20:32:07 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
Message-ID: <8zvdm2YPP7PgsIoKgdQOtsJtZkfVbFqtJGHdOVeQz5w=.8d668ddd-cb69-4118-a19a-0589f79d03d4@github.com>

On Thu, 24 Oct 2024 15:28:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
>> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
>> 
>> Tested ok tier1-3.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

If reading cxq first avoids the benign "race", then why not make that the preferred ordering convention?

It sounds like we are not too concerned about avoiding this particular protocol state (if we aren't calling it a race), but if we were, there are platform-specific things we could try.  For example, some platforms should be able to read both fields at the same time if the fields are adjacent in memory and suitably aligned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21584#issuecomment-2436281358

From coleenp at openjdk.org  Thu Oct 24 20:39:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 20:39:10 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
Message-ID: <jQIHVn5xIK3L0ytB4w_A7jc5nKNQ_l72l6VivJVElE8=.2136f9a1-6033-473f-acca-c12eaf37c44a@github.com>

On Thu, 24 Oct 2024 15:28:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
>> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
>> 
>> Tested ok tier1-3.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

Even though the order isn't strictly important, having the convention to read one before the other avoids the situation where we wonder whether someone's already looked at this to work out whether it's safe to do.  Note this came up in a code review and rather than wondering again whether this is good at some later date, I like that it's in the same order with the comment that explains that load ordering is unnecessary.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21584#pullrequestreview-2393661680

From coleenp at openjdk.org  Thu Oct 24 20:55:19 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 20:55:19 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
Message-ID: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>

Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.

Tested with tier1-7.

-------------

Commit messages:
 - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

Changes: https://git.openjdk.org/jdk/pull/21695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340212
  Stats: 100 lines in 7 files changed: 95 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

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 [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 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 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: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: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 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 duke at openjdk.org  Thu Oct 24 21:18:07 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Thu, 24 Oct 2024 21:18:07 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v7]
In-Reply-To: <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <RYddKYqCoHeyUqHaOpjHOdnnvazND2l-AQVtGNUoM24=.264ebbe4-b441-42e9-865f-0529a8f85b1d@github.com>
Message-ID: <TTNeYsbhoHuPkNMHNYk8FCfSrzSKhMi7k-57X5TIC3E=.1912d777-efec-4502-be68-11fbed055aeb@github.com>

On Tue, 22 Oct 2024 11:33:57 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assembly changes suggested by sviswa7

Everything from me was addressed too, thanks!

-------------

Marked as reviewed by vpaprotsk at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/21352#pullrequestreview-2393720872

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 duke at openjdk.org  Thu Oct 24 21:55:18 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 24 Oct 2024 21:55:18 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v10]
In-Reply-To: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
Message-ID: <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>

> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

Arseny Bochkarev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Replace RISCV64 -> riscv64 in comment
 - Minor renaming of labels and reg_number
 - Use RISCV64 instead of RISCV
 - Fixed comment line
 - Rename reg_number -> rounds in aes_loadkeys
 - Fix typo
 - Use same keys for encryption and decryption
 - Multiversion decrypt intrinsic
 - Use one L_end for all AES key sizes
 - Multiversion encryption depending on keylen
 - ... and 7 more: https://git.openjdk.org/jdk/compare/d1540e2a...e90b0d05

-------------

Changes: https://git.openjdk.org/jdk/pull/19960/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=09
  Stats: 203 lines in 4 files changed: 190 ins; 11 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19960/head:pull/19960

PR: https://git.openjdk.org/jdk/pull/19960

From duke at openjdk.org  Thu Oct 24 21:55:18 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 24 Oct 2024 21:55:18 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v9]
In-Reply-To: <HtE9EqSLVFkt8iSl4hi5uVWUU5Gj-ogh3t5kTbPld3s=.afffce40-7cc6-40ff-b861-ca94286aabe9@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
 <HtE9EqSLVFkt8iSl4hi5uVWUU5Gj-ogh3t5kTbPld3s=.afffce40-7cc6-40ff-b861-ca94286aabe9@github.com>
Message-ID: <Ib3QSDmRcGVzYOEl5nrEsbLIURSp1eVGjINfgNmLaMg=.0855e62c-177d-4121-9019-3bdff80bd687@github.com>

On Tue, 22 Oct 2024 05:42:14 GMT, Yanhong Zhu <yzhu at openjdk.org> wrote:

>> Arseny Bochkarev has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> Thanks for the update. Do you mind several more minor cleanups? Looks good to me otherwise. Thanks.
> [addon-cleanup.diff.txt](https://github.com/user-attachments/files/17470674/addon-cleanup.diff.txt)

@yhzhu20 Done!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19960#issuecomment-2436399683

From duke at openjdk.org  Thu Oct 24 21:55:19 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 24 Oct 2024 21:55:19 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v9]
In-Reply-To: <GsqfHJPpGvgtfN88JtySopb8_aNHfPBxkUDk2qJlyRg=.849828b4-2fc7-4872-81fb-f62255a7a9c7@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
 <GsqfHJPpGvgtfN88JtySopb8_aNHfPBxkUDk2qJlyRg=.849828b4-2fc7-4872-81fb-f62255a7a9c7@github.com>
Message-ID: <WZ5M-_UYVskemP90o-87bktA_gMQ3ABiLKbQehZIvak=.ce5c7cbc-0030-4596-978b-c56d5f52bd86@github.com>

On Tue, 22 Oct 2024 10:00:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Arseny Bochkarev has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> src/hotspot/share/opto/library_call.cpp line 7229:
> 
>> 7227:   // Intel's extension is based on this optimization and AESCrypt generates round keys by preprocessing MixColumns.
>> 7228:   // However, ppc64 vncipher processes MixColumns and requires the same round keys with encryption.
>> 7229:   // The ppc64 and RISCV64 stubs of encryption and decryption use the same round keys (sessionK[0]).
> 
> Nit: A small `riscv64` will do here.
> 
> // The ppc64 and riscv64 stubs of encryption and decryption use the same round keys (sessionK[0]).
> 
> 
> (PS: Please also merge with latest jdk master)

All done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1815732972

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 coleenp at openjdk.org  Thu Oct 24 22:39:18 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 22:39:18 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v2]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <XdnpgJnbVAdKYOkb93uBgvSerEce45S_uMKoy9h3AAo=.dfd96f5c-52da-44e3-ac88-73c06f580862@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  include formatBuffer.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/08eda748..791a59d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

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 jiangli at openjdk.org  Thu Oct 24 23:14:09 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 23:14:09 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <N2aJZCe4omsgw1E7s46gAKTEJ_h5xUKeOVxYrkf4EFA=.2b9e15c2-4154-48ca-a75d-4fa04323a710@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>
 <N2aJZCe4omsgw1E7s46gAKTEJ_h5xUKeOVxYrkf4EFA=.2b9e15c2-4154-48ca-a75d-4fa04323a710@github.com>
Message-ID: <9Zl_5SycthY0QWHqfuyHiOaH4nzVM7ngWRGuqNBuM6g=.31fbe17e-1c86-4ace-9322-7a1b942d2e9e@github.com>

On Wed, 23 Oct 2024 01:40:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
> > I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
> > @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.
> 
> @magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.

Sorry for the delay. I finally found some time to look into this today. Running the latest `static-jdk` `bin/java` built from your branch fails for me as well:


$ bin/java
Error: failed , because bin/java: undefined symbol: JNI_CreateJavaVM


I only took a quick look, but I think this looks like https://bugs.openjdk.org/browse/JDK-8339522 that I filed in September.


$ nm bin/java | grep JNI_CreateJavaVM
000000000162733c t JNI_CreateJavaVM
0000000001626e75 t _ZL22JNI_CreateJavaVM_innerPP7JavaVM_PPvS2_
jianglizhou at leia:~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ nm -D bin/java | grep JNI_CreateJavaVM


The VM dynamic symbols are not exported properly. This is related to the https://github.com/openjdk/jdk/pull/20837#discussion_r1744611776 discussion comment thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2436496612

From iklam at openjdk.org  Thu Oct 24 23:27:06 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Oct 2024 23:27:06 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v5]
In-Reply-To: <5fbkBeoXHfCfKGVVIPG0zexDYgEbuia9fEXtfBhqEFE=.d01ef3dc-992b-4109-8aba-0f3be19adc8c@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <5fbkBeoXHfCfKGVVIPG0zexDYgEbuia9fEXtfBhqEFE=.d01ef3dc-992b-4109-8aba-0f3be19adc8c@github.com>
Message-ID: <rc_bjF4F8qmA7fKlcJ6OtFwIx2i1yPGayged8l493wM=.03c0cfd4-9c4f-4159-9b24-3e16d6e2d287@github.com>

On Thu, 24 Oct 2024 20:15:39 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed can_use from whitebox

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21647#pullrequestreview-2393868829

From jiangli at openjdk.org  Thu Oct 24 23:39:07 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 23:39:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <xMfGwygwvEEqpdyRINSpxEFWIgv_Rnu0ccet-vOITcA=.efa2cc8a-bb0e-43b4-bf3a-27fcd3367a38@github.com>

On Tue, 15 Oct 2024 20:22:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't hardcode server variant

> > > When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
> > > I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
> > > @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.
> > 
> > 
> > @magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.
> 
> Sorry for the delay. I finally found some time to look into this today. Running the latest `static-jdk` `bin/java` built from your branch fails for me as well:
> 
> ```
> $ bin/java
> Error: failed , because bin/java: undefined symbol: JNI_CreateJavaVM
> ```
> 
> I only took a quick look, but I think this looks like https://bugs.openjdk.org/browse/JDK-8339522 that I filed in September.
> 
> ```
> $ nm bin/java | grep JNI_CreateJavaVM
> 000000000162733c t JNI_CreateJavaVM
> 0000000001626e75 t _ZL22JNI_CreateJavaVM_innerPP7JavaVM_PPvS2_
> jianglizhou at leia:~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ nm -D bin/java | grep JNI_CreateJavaVM
> ```
> 
> The VM dynamic symbols are not exported properly. This is related to the [#20837 (comment)](https://github.com/openjdk/jdk/pull/20837#discussion_r1744611776) discussion comment thread.

Checking the `ld` command line, I think it is indeed https://bugs.openjdk.org/browse/JDK-8339522 issue. `-Wl,--exclude-libs,ALL` is included in the command:

$ cat ./support/static-native/launcher/BUILD_LAUNCHER_java_run_ld.cmdline
/usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,-z,noexecstack -m64 -pie -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -Wl,-rpath,$ORIGIN -Wl,--disable-new-dtags -Wl,-rpath,$ORIGIN/../lib -Wl,--disable-new-dtags -o /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/static-native/launcher/java /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/static-native/launcher/main.o -Wl,--export-dynamic -Wl,--whole-archive /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libverify/static/libverify.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libjava/static/libjava.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libzip/static/libzip.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-sl
 owdebug/support/native/java.base/libjimage/static/libjimage.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libjli/static/libjli.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libnet/static/libnet.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libnio/static/libnio.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libjsig/static/libjsig.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libsyslookup/static/libsyslookup.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libsimdsort/static/libsimdsort.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libawt/static/libawt.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_
 64-server-slowdebug/support/native/java.desktop/libawt_xawt/static/libawt_xawt.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libjawt/static/libjawt.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libmlib_image/static/libmlib_image.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/liblcms/static/liblcms.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libjavajpeg/static/libjavajpeg.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libfontmanager/static/libfontmanager.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libjsound/static/libjsound.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.instrument/libinstrume
 nt/static/libinstrument.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.management/libmanagement/static/libmanagement.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.prefs/libprefs/static/libprefs.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.rmi/librmi/static/librmi.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.security.jgss/libj2gss/static/libj2gss.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.smartcardio/libj2pcsc/static/libj2pcsc.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.attach/libattach/static/libattach.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.crypto.cryptoki/libj2pkcs11/static/libj2pkcs11.a /...jianglizhou/github/jdk_pull_20837/bu
 ild/linux-x86_64-server-slowdebug/support/native/jdk.hotspot.agent/libsaproc/static/libsaproc.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.incubator.vector/libjsvml/static/libjsvml.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.jdwp.agent/libdt_socket/static/libdt_socket.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.jdwp.agent/libjdwp/static/libjdwp.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.management/libmanagement_ext/static/libmanagement_ext.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.management.agent/libmanagement_agent/static/libmanagement_agent.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.net/libextnet/static/libextnet.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-serve
 r-slowdebug/support/native/jdk.sctp/libsctp/static/libsctp.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.security.auth/libjaas/static/libjaas.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/hotspot/variant-server/libjvm/objs/static/libjvm.a -Wl,--no-whole-archive -lX11 -lXext -lXi -lXrender -lXtst -lasound -ldl -lfreetype -lm -lpthread -lrt -lz -static-libgcc -static-libstdc++ -l:libstdc++.a -lz -ldl -lpthread

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2436518730

From dholmes at openjdk.org  Fri Oct 25 00:01:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 00:01:10 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
Message-ID: <phhxThr7Kpsl3jbJCVNUOs0koId_LrL1ZzPuwmlSFXY=.504861d9-4fa9-4e29-8cf7-4ab51b273c9b@github.com>

On Thu, 24 Oct 2024 15:28:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
>> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
>> 
>> Tested ok tier1-3.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

LGTM!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21584#pullrequestreview-2393898957

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 jbhateja at openjdk.org  Fri Oct 25 02:06:17 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Oct 2024 02:06:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
 <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
Message-ID: <8QrQacNaEZcyAYAcGLLzIm4xN-0G1-5BRxmSi__vMBU=.2ffa14a0-9fde-4587-9bc3-6b5bfaef33a0@github.com>

On Thu, 24 Oct 2024 13:41:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 
>> 
>> I have created a new RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.
>
> Ok, we can file a separate RFE. Though I really have voiced 2 concerns:
> - Making sure we always test `_mem` and `_reg` variants in the backend. See your https://bugs.openjdk.org/browse/JDK-8342959
> - Making sure we have tests that would detect vectors that are too long. This would require some padding between the vectors, so that we have some untouched space - and if it does get touched we know that a vector was too long. Does that make sense? This is I guess also a general concern - and would have to be applied to all vector instructions.

Hi @eme64 , @PaulSandoz , in general bounds overrun problem is only pertinent to a very small portion of vector ISA which supports memory destination flavor e.g. [VCVTPS2PH](https://www.felixcloutier.com/x86/vcvtps2ph) , in all other cases we only load exact memory size into vector i.e. 4 , 8 and 16 bytes of memory will be loaded into 128 bit vector. Similarly, store vector writes exact memory size and intermediate vector operations with all register operands can operate at equally sized or lowest upper vector size for a given vector species.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815901472

From jbhateja at openjdk.org  Fri Oct 25 02:11:13 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Oct 2024 02:11:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
Message-ID: <KcU5Z1yqIieSNA_yXI2GgVoFR9Mx8_hxTPLnokvfQLg=.b5c261fc-56a9-4bee-a2d9-5b3c434dc09d@github.com>

On Mon, 21 Oct 2024 09:12:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replacing flag based checks with CPU feature checks in IR validation test.
>
> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
> 
> I think these optimizations should be done in a separate PR. I see no reason why they need to be mixed in.
> 
> https://github.com/openjdk/jdk/commit/c56508899b000b8b1eb6755c901798a2a3685ef5 The `UMinVNode::Ideal` etc changes with IR rules.
> 
> I also cannot easily review just such a diff, it does not let me make comments - so I still have to go find the relevant code in the whole PR.
> 
> Some comments on this section:
> 
> 
> Node* UMinVNode::Ideal(PhaseGVN* phase, bool can_reshape) {
>   bool match1 = in(1)->Opcode() == Op_UMinV || in(1)->Opcode() == Op_UMaxV;
>   bool match2 = in(2)->Opcode() == Op_UMinV || in(2)->Opcode() == Op_UMaxV;
>   // UMin (UMin(a, b), UMax(a, b))  => UMin(a, b)
>   // UMin (UMin(a, b), UMax(b, a))  => UMin(a, b)
>   if (match1 && match2) {
>     if ((in(1)->in(1) == in(2)->in(1) && in(1)->in(2) == in(2)->in(2)) ||
>          (in(1)->in(2) == in(2)->in(1) && in(1)->in(1) == in(2)->in(2))) {
>       return new UMinVNode(in(1)->in(1), in(1)->in(2), vect_type());
>     }
>   }
>   return nullptr;
> }
> 
> 
> Are we sure we do not need to verify any types in all of these cases? Maybe not - but I'd rather be super sure - not that things get misinterpreted and then folded the wrong way.
> 
> I mean if I now approve only that diff, then I still need to approve the whole PR, which means I need to spend a lot of time on everything again. Otherwise, in theory people could smuggle anything in.

Hi @eme64 , Let me know if there are other comments, else looking forward to you approval :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2436663568

From fyang at openjdk.org  Fri Oct 25 03:24:23 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 25 Oct 2024 03:24:23 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups
Message-ID: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>

Hi, please review this small code cleanups.

Witnessed some explicit type conversion to `address` is not necessary now.
Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
This also adds one temporary register parameter for the `cmpptr` assembler routine.

Testing on linux-riscv64:
- [ ] tier1 (release)

-------------

Commit messages:
 - 8343030: RISC-V: Small assembler cleanups

Changes: https://git.openjdk.org/jdk/pull/21699/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343030
  Stats: 33 lines in 8 files changed: 2 ins; 11 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21699/head:pull/21699

PR: https://git.openjdk.org/jdk/pull/21699

From yzhu at openjdk.org  Fri Oct 25 03:51:08 2024
From: yzhu at openjdk.org (Yanhong Zhu)
Date: Fri, 25 Oct 2024 03:51:08 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v10]
In-Reply-To: <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
Message-ID: <BaVJMPwYeJv6VNK8UkRi17Ru6SjAgSKJGe58PEK-Ht4=.e44003d5-8a7c-4fb7-829a-61512d46a2e9@github.com>

On Thu, 24 Oct 2024 21:55:18 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Replace RISCV64 -> riscv64 in comment
>  - Minor renaming of labels and reg_number
>  - Use RISCV64 instead of RISCV
>  - Fixed comment line
>  - Rename reg_number -> rounds in aes_loadkeys
>  - Fix typo
>  - Use same keys for encryption and decryption
>  - Multiversion decrypt intrinsic
>  - Use one L_end for all AES key sizes
>  - Multiversion encryption depending on keylen
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d1540e2a...e90b0d05

Marked as reviewed by yzhu (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19960#pullrequestreview-2394105814

From yzhu at openjdk.org  Fri Oct 25 03:51:09 2024
From: yzhu at openjdk.org (Yanhong Zhu)
Date: Fri, 25 Oct 2024 03:51:09 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v9]
In-Reply-To: <HtE9EqSLVFkt8iSl4hi5uVWUU5Gj-ogh3t5kTbPld3s=.afffce40-7cc6-40ff-b861-ca94286aabe9@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <WdQLW1HmvULDnp7T_qJYNYplqZ8PkuCZiN5Kik-8UJo=.523cb743-17fd-48ed-862d-24fce566d696@github.com>
 <HtE9EqSLVFkt8iSl4hi5uVWUU5Gj-ogh3t5kTbPld3s=.afffce40-7cc6-40ff-b861-ca94286aabe9@github.com>
Message-ID: <ejpebAs7pE42mWBUo5wwsiIc9Lt9BziMOwcAC0VTVWw=.7ad824e4-9657-4839-b53f-ecfe7cd8fd1a@github.com>

On Tue, 22 Oct 2024 05:42:14 GMT, Yanhong Zhu <yzhu at openjdk.org> wrote:

>> Arseny Bochkarev has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> Thanks for the update. Do you mind several more minor cleanups? Looks good to me otherwise. Thanks.
> [addon-cleanup.diff.txt](https://github.com/user-attachments/files/17470674/addon-cleanup.diff.txt)

> @yhzhu20 Done!

Thank you. Approved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19960#issuecomment-2436762302

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 epeter at openjdk.org  Fri Oct 25 07:11:20 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 25 Oct 2024 07:11:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <aG2JGZxd4WxT-NyNBlIjsPb_J8sq1WfSUoPBmjT2YzU=.6838a077-d786-4834-ba0d-11e12d08ca2c@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

Ok, I'll approve it now, since @PaulSandoz is ok with the test coverage.
I did not review all the x86 backend instructions, I don't have the time or understanding for that - I rely on testing for correctness here.

Thanks for the work @jatin-bhateja ? 
The VectorAPI is a lot of work, and we are grateful for your contributions!

I am still worried about general test coverage. One can always do it later - but will that actually be done? I suppose this is a trade-off between spending time on quality vs quantity of features. Bugs in the VectorAPI will probably mostly show in miscompilations. Those are hard to catch without solid testing and rigorous result verification. The VectorAPI is also not widely used yet, so miscompilations will only slowly be discovered. Miscompilations in Auto-Vectorization are quicker discovered because there is more code out there that is sensitive to it.

Maybe I'm coming across as annoying with all my RFE-splitting suggestions. But I do think that it is the job of the PR-author to make the code as reviewable and high-quality before it is sent for review. The author knows the code best, and should not burden the reviewers unnecessarily with combined features. A PR that is 2x as long is not just 2x as much work to review. It takes the reviewer more time - maybe 4x because it is harder to understand what belongs together, if everything is sufficiently tested. Also, the number of review-rounds increases. Every time the reviewer is then required to read all code again. This is really a waste of time and very frustrating. But I think you understand that now, and I am looking forward to nicely portioned PRs in the future ;)

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2394395794

From tschatzl at openjdk.org  Fri Oct 25 07:20:09 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 07:20:09 GMT
Subject: RFR: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
Message-ID: <HNymtSLQxz77sGwJpSxjJ2_3cv4PIAa7LHsWQUt3q5I=.1b6140a2-14a0-4380-bee5-d21ecb17c97d@github.com>

On Thu, 24 Oct 2024 08:06:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes ZGC compile without the C2 compiler.
> 
> The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).
> 
> Testing: manual compilation without C2, gha
> 
> Thanks,
>   Thomas

I verified that ZGC builds with only c1 and c2 too, did not check Graal, but apparently that's being handled already.

Thanks @fisk @vnkozlov @Hamlin-Li for your reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21677#issuecomment-2437068843

From tschatzl at openjdk.org  Fri Oct 25 07:20:10 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 25 Oct 2024 07:20:10 GMT
Subject: Integrated: 8342939: Building ZGC without compiler2 fails
In-Reply-To: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
References: <1_dmlXIVETQbUG_IwOYjpi5j5J59rbhtRJYVT-yMU9U=.ecdda5de-e13e-4499-9e53-ca9a5b55fdcf@github.com>
Message-ID: <daaLgL54JV7l_5FmdxoY6So64j8-5TUXnbuMKDBCSPk=.60e48b5e-6b41-407e-8b25-74ffc976f52e@github.com>

On Thu, 24 Oct 2024 08:06:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that makes ZGC compile without the C2 compiler.
> 
> The solution is to ifdef the offending C2 code, and returning `false` for the predicate that checks whether this is a C2 compilation (which can't be because there is no C2 compiled in).
> 
> Testing: manual compilation without C2, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 4635351b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4635351b1570fcea07fac1ece5f76f528d68c2a7
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8342939: Building ZGC without compiler2 fails

Reviewed-by: eosterlund, mli, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/21677

From mli at openjdk.org  Fri Oct 25 08:08:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 25 Oct 2024 08:08:06 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups
In-Reply-To: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
Message-ID: <pLeWZZo8FGlbbNr-iAlgaN_xd1WAErF7UBQUWEegysY=.162bc340-64ce-4437-9c0d-912b9d447c65@github.com>

On Fri, 25 Oct 2024 03:07:19 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this small code cleanups.
> 
> Witnessed some explicit type conversion to `address` is not necessary now.
> Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
> This also adds one temporary register parameter for the `cmpptr` assembler routine.
> 
> Testing on linux-riscv64:
> - [ ] tier1 (release)

Looks good.
Just one minor comment.

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1324:

> 1322:   // increment/decrement may trash both t0 and t1.
> 1323: 
> 1324:   void increment (const Address dst, int64_t value = 1, Register tmp1 = t0, Register tmp2 = t1);

To align with the pattern in this file, extra space should be removed.

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1327:

> 1325:   void incrementw(const Address dst, int32_t value = 1, Register tmp1 = t0, Register tmp2 = t1);
> 1326: 
> 1327:   void decrement (const Address dst, int64_t value = 1, Register tmp1 = t0, Register tmp2 = t1);

Same here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21699#pullrequestreview-2394517303
PR Review Comment: https://git.openjdk.org/jdk/pull/21699#discussion_r1816195932
PR Review Comment: https://git.openjdk.org/jdk/pull/21699#discussion_r1816196144

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 jbhateja at openjdk.org  Fri Oct 25 08:59:13 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Oct 2024 08:59:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
 <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
 <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>
Message-ID: <5b8t9BfyScOG01ZBVh6pwUr6nssDucvq2idxtNd_7sc=.0f08654f-1e75-4c39-bcd0-0ad7e8adca44@github.com>

On Tue, 22 Oct 2024 15:56:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hey @eme64 ,
>> 
>>> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
>> 
>> I understand reviewer's pain, which is why I mentioned about last two changes specifically. Vector API related PRs generally looks bulky due to script generated sources and tests. Barring that it may not demand much of your time.
>> 
>> But, to keep you motivated :-) and following @PaulSandoz and yours suggestions, I have moved out IR validations and Min / Max transforms to following follow up PRs.
>>    
>>    - https://bugs.openjdk.org/browse/JDK-8342676 (https://github.com/openjdk/jdk/pull/21604)
>>    - https://bugs.openjdk.org/browse/JDK-8342677 (https://github.com/openjdk/jdk/pull/21603)
>> 
>> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>> 
>> Best Regards,
>> Jatin
>
>> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>>
> 
> Internal tier 1 to 3 testing passed (i needed to merge with master at 7133d1b983d, due to some updates to unrelated test configuration files the test infrastructure expects).

> Ok, I'll approve it now, since @PaulSandoz is ok with the test coverage. I did not review all the x86 backend instructions, I don't have the time or understanding for that - I rely on testing for correctness here.
> 
> Thanks for the work @jatin-bhateja ? The VectorAPI is a lot of work, and we are grateful for your contributions!
> 
> I am still worried about general test coverage. One can always do it later - but will that actually be done? I suppose this is a trade-off between spending time on quality vs quantity of features. Bugs in the VectorAPI will probably mostly show in miscompilations. Those are hard to catch without solid testing and rigorous result verification. The VectorAPI is also not widely used yet, so miscompilations will only slowly be discovered. Miscompilations in Auto-Vectorization are quicker discovered because there is more code out there that is sensitive to it.
> 
> Maybe I'm coming across as annoying with all my RFE-splitting suggestions. But I do think that it is the job of the PR-author to make the code as reviewable and high-quality before it is sent for review. The author knows the code best, and should not burden the reviewers unnecessarily with combined features. A PR that is 2x as long is not just 2x as much work to review. It takes the reviewer more time - maybe 4x because it is harder to understand what belongs together, if everything is sufficiently tested. Also, the number of review-rounds increases. Every time the reviewer is then required to read all code again. This is really a waste of time and very frustrating. But I think you understand that now, and I am looking forward to nicely portioned PRs in the future ;)

We are in same boat @eme64 , I understand reviewers pain, and no debate on coverage and validations ? 

@sviswa7 , I guess we need a cursory re-approval from you for integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2437252005

From rehn at openjdk.org  Fri Oct 25 09:19:07 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 25 Oct 2024 09:19:07 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups
In-Reply-To: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
Message-ID: <JmeJPcTD4B2b9oLbd9k_i23h-oRZhKjsKukuSOmNryU=.ba3073f9-54cb-4589-86b9-68cae9770c21@github.com>

On Fri, 25 Oct 2024 03:07:19 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this small code cleanups.
> 
> Witnessed some explicit type conversion to `address` is not necessary now.
> Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
> This also adds one temporary register parameter for the `cmpptr` assembler routine.
> 
> Testing on linux-riscv64:
> - [ ] tier1 (release)

lgtm

-------------

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21699#pullrequestreview-2394708721

From fyang at openjdk.org  Fri Oct 25 09:30:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 25 Oct 2024 09:30:41 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups [v2]
In-Reply-To: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
Message-ID: <zgEBfHCuSFAef6FOwnL8h4056zDMhm_3lV3e14pf9ho=.5aa815d2-be90-4486-b180-5da8c1196b16@github.com>

> Hi, please review this small code cleanups.
> 
> Witnessed some explicit type conversion to `address` is not necessary now.
> Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
> This also adds one temporary register parameter for the `cmpptr` assembler routine.
> 
> Testing on linux-riscv64:
> - [ ] tier1 (release)

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21699/files
  - new: https://git.openjdk.org/jdk/pull/21699/files/001b2e27..ea73a278

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21699&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21699&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21699/head:pull/21699

PR: https://git.openjdk.org/jdk/pull/21699

From fyang at openjdk.org  Fri Oct 25 09:30:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 25 Oct 2024 09:30:41 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups [v2]
In-Reply-To: <pLeWZZo8FGlbbNr-iAlgaN_xd1WAErF7UBQUWEegysY=.162bc340-64ce-4437-9c0d-912b9d447c65@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
 <pLeWZZo8FGlbbNr-iAlgaN_xd1WAErF7UBQUWEegysY=.162bc340-64ce-4437-9c0d-912b9d447c65@github.com>
Message-ID: <d7L1ml1F8TLet_qldpPuO0NznBfT37Sw_lLkoPCz0yo=.47b35faf-42aa-4366-9764-af30cb70a83f@github.com>

On Fri, 25 Oct 2024 08:05:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1324:
> 
>> 1322:   // increment/decrement may trash both t0 and t1.
>> 1323: 
>> 1324:   void increment (const Address dst, int64_t value = 1, Register tmp1 = t0, Register tmp2 = t1);
> 
> To align with the pattern in this file, extra space should be removed.

Fixed. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21699#discussion_r1816348259

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 aph at openjdk.org  Fri Oct 25 10:18:14 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 25 Oct 2024 10:18:14 GMT
Subject: RFR: 8331117: [PPC64] secondary_super_cache does not scale well
 [v2]
In-Reply-To: <4oTnnVeBbxCTfBDoQnldpIyHh8GlPcjXwVlmaPQPrrw=.5243b504-e336-4ff2-bb59-525766d78a34@github.com>
References: <aV_vzPm-JnRU0uem3qjivjr-jHxZFLbTwx-UkIkw-v8=.bc0bef74-199b-4944-a2ad-ecaa6a326bce@github.com>
 <kwUprC3TdPe8xwn_hxV7IWeCWpftTmiNAdY3-74GZmY=.14f961e7-1b36-4951-be8a-acb5062cd496@github.com>
 <hytwg5ftyIKn0091nBdtDQYR5VKhVq0DdRJmo-Oax7o=.3f50ecdf-8f37-43cd-92ed-95c6c82a97db@github.com>
 <4oTnnVeBbxCTfBDoQnldpIyHh8GlPcjXwVlmaPQPrrw=.5243b504-e336-4ff2-bb59-525766d78a34@github.com>
Message-ID: <vYtTgUSYaghOhGXrJIR01N6zY-PuEbrx6yj6B6hSDSI=.ab1159fb-0440-4499-bace-af1365a21a24@github.com>

On Fri, 7 Jun 2024 14:38:55 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> But if I revert the changes I had done, then it passes. Same situation I'm facing on s390x. Is this expected ?
> 
> failure log: [type_profile_failure.log](https://github.com/user-attachments/files/15741205/type_profile_failure.log)

Sorry for necro-posting, but I saw that there had never been a reply to this one.

The IR tests that are faliing count the number of CMP nodes in a type check. When we disable the use of secondary_super_cache in C2, we reduce the number of CMP nodes, because we are no longer checking the secondary_super_cache. This is failure OK for now, because it never triggers without diagnostic VM options, but when we remove the secondary_super_cache altogether this test will have to be revised.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19368#issuecomment-2437413279

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 mli at openjdk.org  Fri Oct 25 11:10:05 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 25 Oct 2024 11:10:05 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups [v2]
In-Reply-To: <zgEBfHCuSFAef6FOwnL8h4056zDMhm_3lV3e14pf9ho=.5aa815d2-be90-4486-b180-5da8c1196b16@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
 <zgEBfHCuSFAef6FOwnL8h4056zDMhm_3lV3e14pf9ho=.5aa815d2-be90-4486-b180-5da8c1196b16@github.com>
Message-ID: <1FoixQ3zUFf7Gl1gxCFb3-lZzmHIFpu8eMG4h3H8Gm4=.3c63edf3-1365-474a-8c21-8ad91cccc178@github.com>

On Fri, 25 Oct 2024 09:30:41 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please review this small code cleanups.
>> 
>> Witnessed some explicit type conversion to `address` is not necessary now.
>> Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
>> This also adds one temporary register parameter for the `cmpptr` assembler routine.
>> 
>> Testing on linux-riscv64:
>> - [ ] tier1 (release)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment

Marked as reviewed by mli (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21699#pullrequestreview-2394966546

From shade at openjdk.org  Fri Oct 25 11:18:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Oct 2024 11:18:39 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
Message-ID: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>

Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.

I'll put some performance data in the comments.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `tier1`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/21707/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21707&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343056
  Stats: 27 lines in 4 files changed: 14 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21707.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21707/head:pull/21707

PR: https://git.openjdk.org/jdk/pull/21707

From shade at openjdk.org  Fri Oct 25 11:18:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Oct 2024 11:18:39 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <W1H79o-rAFthzfbH8BjZbyycmnNAylvhix1Rx8txWH0=.75b762ee-67d3-4b92-adc2-612d3d8017cc@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

On various tests on x86_64, this gives me +3% faster runs in -Xcomp scenarios.


## -Xcomp -XX:-TieredCompilation Hello

# Before
  Time (mean ? ?):     617.0 ms ?   3.8 ms    [User: 584.8 ms, System: 31.0 ms]
  Range (min ? max):   612.5 ms ? 625.7 ms    20 runs
 
# After
  Time (mean ? ?):     596.0 ms ?   5.8 ms    [User: 562.3 ms, System: 32.5 ms]
  Range (min ? max):   588.6 ms ? 610.6 ms    20 runs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21707#issuecomment-2437366117

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 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 duke at openjdk.org  Fri Oct 25 14:16:40 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Fri, 25 Oct 2024 14:16:40 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v8]
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:

  added comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21352/files
  - new: https://git.openjdk.org/jdk/pull/21352/files/e4979df2..b9cc7dba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21352&range=06-07

  Stats: 25 lines in 1 file changed: 24 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21352/head:pull/21352

PR: https://git.openjdk.org/jdk/pull/21352

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 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 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 duke at openjdk.org  Fri Oct 25 17:30:14 2024
From: duke at openjdk.org (duke)
Date: Fri, 25 Oct 2024 17:30:14 GMT
Subject: Withdrawn: 8337666: AArch64: SHA3 GPR intrinsic
In-Reply-To: <VIV1m6Mj4E0dmUwrzVDtM89BTR9JV8QEEqB03CdOp38=.883b8fd0-f7a9-4366-b0a9-bd45be51938f@github.com>
References: <VIV1m6Mj4E0dmUwrzVDtM89BTR9JV8QEEqB03CdOp38=.883b8fd0-f7a9-4366-b0a9-bd45be51938f@github.com>
Message-ID: <4kbad68rSQLSRSGioQbgNDZGfhC_7IREVCum9amnXeQ=.eeb27157-d297-4e10-af51-39af7b57e3f0@github.com>

On Thu, 1 Aug 2024 14:38:12 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> This is an implementation of SHA3 intrinsics for AArch64 that operates GPRs. It follows the Java implementation algorithm but eagerly uses available registers. For example, FP+R18 are used when it's allowed. On simpler cores like RPi3 or Surface Pro it is 23-53% faster than C2 compiled version; on Graviton 3 it is 8-14% faster than C2 compiled version (which is faster than the current intrinsic); on Apple Silicon it is faster than C2 compiled version but slower than the ARMv8.2-SHA intrinsic. Improvements on a particular CPU depend on the input length. For instance, for Graviton 2:
> 
> 
> Benchmark (ops/ms)	(digesterName)	(length)	G2
> MessageDigests.digest	SHA3-256	64	28.28%
> MessageDigests.digest	SHA3-256	16384	53.58%
> MessageDigests.digest	SHA3-512	64	27.97%
> MessageDigests.digest	SHA3-512	16384	43.90%
> MessageDigests.getAndDigest	SHA3-256	64	26.18%
> MessageDigests.getAndDigest	SHA3-256	16384	52.82%
> MessageDigests.getAndDigest	SHA3-512	64	24.73%
> MessageDigests.getAndDigest	SHA3-512	16384	44.31%
> 
> 
> (results for intermediate input lengths look like steps)
> 
> Existing intrinsic implementation is put under a flag `UseSIMDForSHA3Intrinsic` which is on by default where the intrinsic is enabled currently.
> 
> Sanity tests were modified to cover new intrinsic variants (`-XX:-UseSIMDForSHA3Intrinsic -XX:+-PreserveFramePointer`) on aarch64 hw. Existing test cases where intrinsic is enabled are executed with `-XX:+IgnoreUnrecognizedVMOptions -XX:+UseSIMDForSHA3Intrinsic`, on platforms where the sha3 extension is missing they still are cut off by isSHA3IntrinsicAvailable() predicate.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20422

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 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 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 kvn at openjdk.org  Fri Oct 25 18:44:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Oct 2024 18:44:06 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <Cj7NGUozNpQubLcJCSTJdAgIT_GSFMWm9gu3CmhRNU8=.0cf0204c-7c54-4b8b-a927-dd594939e6ea@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

Not related to your changes. But I am confused about `grow()` code which set new `_size` value.  It is set to the same value as `_data_size` but it is described as "Used 32-bit words" vs "Allocated words" for `_data_size`.
I think it should be set to `new_word_capacity`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21707#pullrequestreview-2396163533

From kvn at openjdk.org  Fri Oct 25 18:50:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Oct 2024 18:50:05 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <i_H7PsOhx_COd_ODnHzWnmzWUd1YZRAgwJrlGp8dLO4=.05b94bc4-8fdc-4f71-8c21-c76b05a60c9f@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

This change added `_data_size`:
https://github.com/openjdk/jdk/commit/40bbdf472c74c466393b49f52b59e78710f25c77
https://bugs.openjdk.org/browse/JDK-8234328

@cl4es what do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21707#issuecomment-2438582068

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 matsaave at openjdk.org  Fri Oct 25 20:43:43 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 25 Oct 2024 20:43:43 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v6]
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <MFflLf0HgZIq3DI7mUwW9vZDhhdTuCYK857CMRRMm-I=.a7dbc68c-c6d2-4be3-95df-12924cea4f86@github.com>

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

Matias Saavedra Silva 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 10 additional commits since the last revision:

 - Added @requires to ParallelGC test
 - Merge branch 'master' into archive_uncompressed_oops_8341371
 - Removed can_use from whitebox
 - Added @requires
 - Calvin comments and copyright
 - Ioi comments
 - Enabled uncompressed oops on Epsilon and Shenandoah
 - Merge branch 'master' into archive_uncompressed_oops_8341371
 - Added uncompressed oops to tests
 - 8341371: CDS cannot load archived heap objects with -XX:+UseSerialGC -XX:-UseCompressedOops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21647/files
  - new: https://git.openjdk.org/jdk/pull/21647/files/5400c057..6d82f7db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21647&range=04-05

  Stats: 108047 lines in 174 files changed: 4473 ins; 102169 del; 1405 mod
  Patch: https://git.openjdk.org/jdk/pull/21647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21647/head:pull/21647

PR: https://git.openjdk.org/jdk/pull/21647

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 ccheung at openjdk.org  Fri Oct 25 21:10:09 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 25 Oct 2024 21:10:09 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v6]
In-Reply-To: <MFflLf0HgZIq3DI7mUwW9vZDhhdTuCYK857CMRRMm-I=.a7dbc68c-c6d2-4be3-95df-12924cea4f86@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <MFflLf0HgZIq3DI7mUwW9vZDhhdTuCYK857CMRRMm-I=.a7dbc68c-c6d2-4be3-95df-12924cea4f86@github.com>
Message-ID: <cPiN2iZsy1U04G-aR8JYVoaGomMwdSdPKkrBoiUNXVM=.7238511d-ae9a-4b3d-b985-8200799a0335@github.com>

On Fri, 25 Oct 2024 20:43:43 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva 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 10 additional commits since the last revision:
> 
>  - Added @requires to ParallelGC test
>  - Merge branch 'master' into archive_uncompressed_oops_8341371
>  - Removed can_use from whitebox
>  - Added @requires
>  - Calvin comments and copyright
>  - Ioi comments
>  - Enabled uncompressed oops on Epsilon and Shenandoah
>  - Merge branch 'master' into archive_uncompressed_oops_8341371
>  - Added uncompressed oops to tests
>  - 8341371: CDS cannot load archived heap objects with -XX:+UseSerialGC -XX:-UseCompressedOops

Marked as reviewed by ccheung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21647#pullrequestreview-2396503546

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 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 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 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 redestad at openjdk.org  Fri Oct 25 21:34:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 25 Oct 2024 21:34:12 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <3GydexEdC6IaPTr0p8XIPbzggZd1uvRX30QibolvKAE=.79d5f9ea-a2b2-4417-9b90-1a830eeec879@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

The split between `_size` and `_data_size` is there to allow keeping the same storage when we reset a vectset; when we grow the `_data` array they are grown to the same value, `x`, which is `new_word_capacity` aligned up to the nearest power of two. When not growing `_data` but just reclaiming previously used space in that array we only update `_size` (and zero out any pre-existing data). 

The "clever" thing then happens when `_size` has been reset to 0: `_data` and `_data_size` remain untouched. If later we need to grow back up to some `new_word_capacity`, then if `new_word_capacity` is below `_data_size` we don't need a `REALLOC_ARENA_ARRAY` but just bump `_size` and do some zeroing. Otherwise we do the realloc, then zero. IIRC this was a pretty decent win over the status quo, especially for footprint given how freed memory wasn't actually freed up.

So I don't think there's any pre-existing issue and it looks like this PR does the right thing in the context.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21707#issuecomment-2438906443

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 sviswanathan at openjdk.org  Fri Oct 25 21:57:27 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 25 Oct 2024 21:57:27 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <CndQffU65bO_h-gsfgZ_96fbgA69L0nAQRykYNYvmSs=.d1280e98-4776-48fb-a072-3d1cc4ae89a5@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

Changes look good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2396570637

From sviswanathan at openjdk.org  Fri Oct 25 22:01:12 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 25 Oct 2024 22:01:12 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
 <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
 <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>
Message-ID: <LwskziWHBESRYkcaxjjyllm14atUV5VEItqBEJiJLyo=.feaab00d-4f1d-492c-9184-3ec0a0cd5b81@github.com>

On Tue, 22 Oct 2024 15:56:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hey @eme64 ,
>> 
>>> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
>> 
>> I understand reviewer's pain, which is why I mentioned about last two changes specifically. Vector API related PRs generally looks bulky due to script generated sources and tests. Barring that it may not demand much of your time.
>> 
>> But, to keep you motivated :-) and following @PaulSandoz and yours suggestions, I have moved out IR validations and Min / Max transforms to following follow up PRs.
>>    
>>    - https://bugs.openjdk.org/browse/JDK-8342676 (https://github.com/openjdk/jdk/pull/21604)
>>    - https://bugs.openjdk.org/browse/JDK-8342677 (https://github.com/openjdk/jdk/pull/21603)
>> 
>> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>> 
>> Best Regards,
>> Jatin
>
>> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>>
> 
> Internal tier 1 to 3 testing passed (i needed to merge with master at 7133d1b983d, due to some updates to unrelated test configuration files the test infrastructure expects).

@PaulSandoz Looks like you also need to re-approve.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2438938409

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 kvn at openjdk.org  Fri Oct 25 22:30:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Oct 2024 22:30:04 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <MyEmyIhpE6TWTKjhQPoloCFZNKO3cfi7Du_KewDUItw=.d91a5a04-f2e4-41db-9f74-5219da125e2a@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

Thank you, Claes, for explanation.

The change looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21707#pullrequestreview-2396593809

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 redestad at openjdk.org  Fri Oct 25 22:44:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 25 Oct 2024 22:44:06 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <0U37aLhAd76oZbIprHV-h8_CkUVAeVUFi-wArfi-qA4=.4a912c38-0f4d-4f40-8a3c-64918944a92c@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21707#pullrequestreview-2396602227

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 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 fyang at openjdk.org  Sat Oct 26 03:35:12 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 26 Oct 2024 03:35:12 GMT
Subject: RFR: 8343030: RISC-V: Small assembler cleanups [v2]
In-Reply-To: <zgEBfHCuSFAef6FOwnL8h4056zDMhm_3lV3e14pf9ho=.5aa815d2-be90-4486-b180-5da8c1196b16@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
 <zgEBfHCuSFAef6FOwnL8h4056zDMhm_3lV3e14pf9ho=.5aa815d2-be90-4486-b180-5da8c1196b16@github.com>
Message-ID: <fMWa1sC24i325iZ5M2jqy9pkVXt0cPtBGQ6MW1CqGf0=.7265c970-3574-4ad3-8de7-0500b5cca49f@github.com>

On Fri, 25 Oct 2024 09:30:41 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please review this small code cleanups.
>> 
>> Witnessed some explicit type conversion to `address` is not necessary now.
>> Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
>> This also adds one temporary register parameter for the `cmpptr` assembler routine.
>> 
>> Testing on linux-riscv64:
>> - [x] tier1 (release)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment

Thanks all for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21699#issuecomment-2439238105

From fyang at openjdk.org  Sat Oct 26 03:35:13 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 26 Oct 2024 03:35:13 GMT
Subject: Integrated: 8343030: RISC-V: Small assembler cleanups
In-Reply-To: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
References: <ERZX8R_KF9-o1f38tVQn1nONY5cmcjZdtn0wr-A0O3U=.c5e2029e-77cc-42f4-a4e9-108bbac1fd7f@github.com>
Message-ID: <Bo_agvePoTqAoltqoPjPM9xG6oXBJt2PVb7WEtdPmKg=.79a8819c-eaef-43f0-8f0b-8a2179994fd8@github.com>

On Fri, 25 Oct 2024 03:07:19 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this small code cleanups.
> 
> Witnessed some explicit type conversion to `address` is not necessary now.
> Also we can make use of `void la(Register Rd, const address addr)` where possible to simplify the code.
> This also adds one temporary register parameter for the `cmpptr` assembler routine.
> 
> Testing on linux-riscv64:
> - [x] tier1 (release)

This pull request has now been integrated.

Changeset: 1476f6c4
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1476f6c47511ad9dceda3633776ace3ee353d7ed
Stats:     31 lines in 8 files changed: 2 ins; 11 del; 18 mod

8343030: RISC-V: Small assembler cleanups

Reviewed-by: mli, rehn

-------------

PR: https://git.openjdk.org/jdk/pull/21699

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 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 fyang at openjdk.org  Sun Oct 27 23:03:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 27 Oct 2024 23:03:18 GMT
Subject: RFR: 8343115: SkipIfEqual class is not used after JDK-8335946
Message-ID: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>

Hi, please review this cleanup change.
This simply removed SkipIfEqual class for all cpu platforms as it's not used anymore after JDK-8335946.

Testing:
- [x] GHA

-------------

Commit messages:
 - 8343115: SkipIfEqual class is not used after JDK-8335946

Changes: https://git.openjdk.org/jdk/pull/21731/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21731&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343115
  Stats: 184 lines in 11 files changed: 0 ins; 184 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21731/head:pull/21731

PR: https://git.openjdk.org/jdk/pull/21731

From duke at openjdk.org  Sun Oct 27 23:03:18 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sun, 27 Oct 2024 23:03:18 GMT
Subject: RFR: 8343115: SkipIfEqual class is not used after JDK-8335946
In-Reply-To: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
References: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
Message-ID: <oWC85k_ceJ5JS-n4kWOFTApyyOIOqUzFI5WYuWYJRqk=.072049ee-7ebc-4842-9692-b6ff76a824e0@github.com>

On Sun, 27 Oct 2024 03:45:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this cleanup change.
> This simply removed SkipIfEqual class for all cpu platforms as it's not used anymore after JDK-8335946.
> 
> Testing:
> - [x] GHA

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21731#pullrequestreview-2397580046

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: <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: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: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 fyang at openjdk.org  Mon Oct 28 07:28:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 28 Oct 2024 07:28:04 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v10]
In-Reply-To: <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
Message-ID: <CNQUc31lweSYNs2QsNuWqMavcG4mD5QozXd0FGDIoU4=.36893484-4130-446b-9b54-8128831c8a3e@github.com>

On Thu, 24 Oct 2024 21:55:18 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Replace RISCV64 -> riscv64 in comment
>  - Minor renaming of labels and reg_number
>  - Use RISCV64 instead of RISCV
>  - Fixed comment line
>  - Rename reg_number -> rounds in aes_loadkeys
>  - Fix typo
>  - Use same keys for encryption and decryption
>  - Multiversion decrypt intrinsic
>  - Use one L_end for all AES key sizes
>  - Multiversion encryption depending on keylen
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d1540e2a...e90b0d05

Thanks for the update. Two comments remain. seems fine otherwise.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2283:

> 2281:     for (int i = 0; i < rounds; i++) {
> 2282:       __ vle32_v(working_vregs[i], key);
> 2283:       __ vrev8_v(working_vregs[i], working_vregs[i]);

What's is this `vrev8_v` for? I wonder how this maps to the code-samples at [1]. Might deserve a code comment here. 

[1] https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvkned.s

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 423:

> 421: 
> 422:   // AES
> 423:   if (UseZvkn) {

Was checking and enablement for `UseAES` VM option missed here?

Reference: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L289

-------------

PR Review: https://git.openjdk.org/jdk/pull/19960#pullrequestreview-2397866709
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1818490883
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1818333010

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 fbredberg at openjdk.org  Mon Oct 28 09:04:42 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 28 Oct 2024 09:04:42 GMT
Subject: RFR: 8340796: Use a consistent order when loading cxq and
 EntryList [v2]
In-Reply-To: <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
 <HnvtxeMv9k84_OxY1zuLr63wM2sSxJwVubqPCuHFeac=.0eb6c8a0-9bd3-4ceb-a24d-e7455223ec54@github.com>
Message-ID: <goNC1wOkZ_GksXWQzHgsWk5bwIVojeadAjVV2aQ8ua4=.8d852220-25ad-4783-8a27-44ef1a2a208f@github.com>

On Thu, 24 Oct 2024 15:28:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
>> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
>> 
>> Tested ok tier1-3.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update after review

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21584#issuecomment-2440930440

From fbredberg at openjdk.org  Mon Oct 28 09:08:28 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 28 Oct 2024 09:08:28 GMT
Subject: Integrated: 8340796: Use a consistent order when loading cxq and
 EntryList
In-Reply-To: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
References: <IZuSVf0ki5LxSnlRtSXKHg7aqwD7tArZtJKwRxtAQeY=.af754c10-c35c-4df7-b7a6-08218f344d50@github.com>
Message-ID: <8Z0E-ckFlyooyOVG6OrSihZqbFMWG8CudFLZAR4eY0A=.f4a0b95a-47f4-4f10-bdfe-dbdfe971a332@github.com>

On Fri, 18 Oct 2024 14:44:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> Made sure we use a consistent order when reading ObjectMonitor EntryList and cxq while exiting the monitor.
> That consistent order is EntryList before cxq. Added a comment in the shared code to explaining why it's okay that waiters slip undetected between reading EntryList and cxq.
> 
> Tested ok tier1-3.

This pull request has now been integrated.

Changeset: eb3669a5
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb3669a5869d3066341e63dfb8792bd967663656
Stats:     22 lines in 6 files changed: 8 ins; 0 del; 14 mod

8340796: Use a consistent order when loading cxq and EntryList

Reviewed-by: dholmes, coleenp, eosterlund

-------------

PR: https://git.openjdk.org/jdk/pull/21584

From duke at openjdk.org  Mon Oct 28 09:20:25 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Mon, 28 Oct 2024 09:20:25 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <jY_Yc2TdJ7GvpJEWb6nGUwevjy_iTPtrrwhwKDqwgV4=.b2dea8d2-e878-4eff-8bc0-4b2b35f562c2@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
 <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
 <Be0GEMddzDo2KG1luVL1poXDqmewb-LfuttDf5Jqv_M=.2027d69b-8c46-4e3a-9dd6-54f741987896@github.com>
 <jY_Yc2TdJ7GvpJEWb6nGUwevjy_iTPtrrwhwKDqwgV4=.b2dea8d2-e878-4eff-8bc0-4b2b35f562c2@github.com>
Message-ID: <LjNreQlj-JKsxal9lbZC8TWJpBf3FTxz7-0pwN3lQDE=.cf442a6a-f291-49c1-a915-93fb8ef9857b@github.com>

On Thu, 24 Oct 2024 15:54:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>>> @ferakocz I think you need to enble SHA3 testing in jtreg tests we have by modifying: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java#L106
>>> 
>>> [JDK-8252204](https://bugs.openjdk.org/browse/JDK-8252204) added several C2 tests for SHA3 intrinsics in `test/hotspot/jtreg/compiler/intrinsics/sha`. Please make sure your changes passed those tests.
>> 
>> I did that, plus restored the error message, now all the tests suggested by @chhagedorn pass.
>
> @ferakocz Thanks for taking my inputs into consideration and the corresponding changes. Would it be also possible for you to add comments to the rounds24_loop code if you want us to review that in detail. Otherwise the PR looks good to me.

@sviswa7 and @vpaprotsk, I added comments to the algorithm implementation, could you take another look and approve again if you are satisfied with them? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2441003262

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 coleenp at openjdk.org  Mon Oct 28 12:11:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 12:11:11 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no longer
 needed
Message-ID: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>

Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
Tested with tier1-4

-------------

Commit messages:
 - 8342561: Metaspace for generated reflection classes is no longer needed

Changes: https://git.openjdk.org/jdk/pull/21738/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342561
  Stats: 52 lines in 7 files changed: 3 ins; 39 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21738/head:pull/21738

PR: https://git.openjdk.org/jdk/pull/21738

From shade at openjdk.org  Mon Oct 28 12:13:17 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 12:13:17 GMT
Subject: RFR: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <u8hi0BcvvtWUXY-y04OsPnAyk22nGQGV_85_Thi9TmM=.ac0580ff-1378-45e3-b623-12f9de80f270@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

Thanks! All tests pass on our side, so I am integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21707#issuecomment-2441412281

From shade at openjdk.org  Mon Oct 28 12:17:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 12:17:54 GMT
Subject: Integrated: 8343056: C2: Micro-optimize Node lists grow
In-Reply-To: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
References: <R4Y4GFJ3hcF3ebh9SiwkFSSJsmZlVyjAfH4NV1XPzpU=.bb67ef28-ef96-4603-9623-69178d6c697c@github.com>
Message-ID: <ekLIL4rEVheZF8nwB0893ZXO7Vd1V-GIVDMIyaXZ18A=.6c248db0-cdb8-4b41-b0fe-0687a91306af@github.com>

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

This pull request has now been integrated.

Changeset: a5ad974b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5ad974bec932c63ddc647c9986a513ae32ef663
Stats:     27 lines in 4 files changed: 14 ins; 6 del; 7 mod

8343056: C2: Micro-optimize Node lists grow

Reviewed-by: kvn, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/21707

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 shade at openjdk.org  Mon Oct 28 12:36:08 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 12:36:08 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
Message-ID: <BNjjTvWW-XVHoqeuO1mAikRTaH1EsLY3QSPBRvLYulA=.9e22ff5f-76ce-4ed2-b1a1-3d8e1eb63abf@github.com>

On Mon, 28 Oct 2024 12:04:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
> Tested with tier1-4

Looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21738#pullrequestreview-2398946188

From bulasevich at openjdk.org  Mon Oct 28 12:36:12 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Mon, 28 Oct 2024 12:36:12 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM
In-Reply-To: <NK_MHHcZzrQ78v9RRTAkXqBibJLVbTcKvWkMIh59eg0=.6bcad355-7a02-4710-89ca-d56b8b374ca2@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <Juvz6Oj7vk1W4xxlZXkfz0asUVLIhO00-bM8IIdP_ro=.c63c189b-433c-4748-944d-85d44bccd369@github.com>
 <vqgfqxWAv_soSLK7ZJwFy8V5K_DGr6KnNTRlAu2EWd0=.d37581f7-1658-496c-841f-dffbe5238233@github.com>
 <dfqtLjLMMS_gWaTgG-FuVKwm6HyeVwWAFtePVhK_dZo=.b7ec672f-29db-452a-b12e-cc0896a7f7ee@github.com>
 <R2AdTwigicPuJHFbDOIV_-e1Xs-O7Tt3T8j-Y8taX1g=.ce5a5980-4280-4ee8-9e60-3f290bd7f745@github.com>
 <NK_MHHcZzrQ78v9RRTAkXqBibJLVbTcKvWkMIh59eg0=.6bcad355-7a02-4710-89ca-d56b8b374ca2@github.com>
Message-ID: <1_TTGCu1z3bBiYX8_ERVmuChV4n5x3YALSRMyInrQm8=.6b367def-1f19-4cd6-b610-b5fbea6918d3@github.com>

On Fri, 13 Sep 2024 16:53:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov Many thanks!
>> Do you reproduce the regression on a public benchmark that I can also try?
>> Now I restrict CodeEntryAlignment=16 for V1 and V2 only. And I restart my performance tests.
>
>> Do you reproduce the regression on a public benchmark that I can also try?
> 
> It was our internal benchmark.

@vnkozlov
I committed CodeEntryAlignment=32 (instead of initially proposed 16) for V1/V2 and lost the PR "ready" label.
Formally, the PR is approved by you and Evgeny, but re-review is required from your side. Can you please approve once again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20864#issuecomment-2441464167

From stuefe at openjdk.org  Mon Oct 28 12:56:36 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Oct 2024 12:56:36 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
Message-ID: <P6JVXDxNKDT7SGSETOsjqTLEIMMDEQdf91bGP1cLhEI=.0aaf2657-b087-45cf-985b-ef0809c750bc@github.com>

On Mon, 28 Oct 2024 12:04:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
> Tested with tier1-4

Good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21738#pullrequestreview-2398995119

From coleenp at openjdk.org  Mon Oct 28 12:59:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 12:59:51 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
Message-ID: <8wvdrPVphcTmSus92ZWMZsq7Bk-QbZjBLIGGLc5xeiI=.9dc417a9-1994-4c7e-b20c-ebc415cd3724@github.com>

On Mon, 28 Oct 2024 12:04:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
> Tested with tier1-4

Thanks for the quick reviews.  Would you consider this trivial?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21738#issuecomment-2441517314

From stuefe at openjdk.org  Mon Oct 28 13:10:32 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Oct 2024 13:10:32 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <8wvdrPVphcTmSus92ZWMZsq7Bk-QbZjBLIGGLc5xeiI=.9dc417a9-1994-4c7e-b20c-ebc415cd3724@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
 <8wvdrPVphcTmSus92ZWMZsq7Bk-QbZjBLIGGLc5xeiI=.9dc417a9-1994-4c7e-b20c-ebc415cd3724@github.com>
Message-ID: <D1GXCW-sQf_efXboumOmkNBEPwx_WWRJBvcxUtF3QuA=.965c37c4-72dc-4cf3-a238-e0755242a7aa@github.com>

On Mon, 28 Oct 2024 12:57:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks for the quick reviews. Would you consider this trivial?

Sure, though it borders on non-trivial :) But you have your two reviews already, is this just to circumvent the 24hrs rule?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21738#issuecomment-2441543110

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 coleenp at openjdk.org  Mon Oct 28 13:14:50 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 13:14:50 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
Message-ID: <5jlHGOnsxo8uM4gz-L-zPdYXGAtbZugpxcm_ch3vRuw=.65e536ae-7b04-4407-a062-711b41c099c8@github.com>

On Mon, 28 Oct 2024 12:04:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
> Tested with tier1-4

Yes it's mostly removal and non controversial and want to get it off the list while I have it here in front of me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21738#issuecomment-2441549924

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 coleenp at openjdk.org  Mon Oct 28 13:50:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 13:50:08 GMT
Subject: RFR: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
Message-ID: <0EHpAoBjP-gg4l_b4AadZHNsQ9m4prG_fJ9RvajmGPw=.a341e796-42f2-4f37-857d-461cce1c9c55@github.com>

On Mon, 28 Oct 2024 12:04:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
> Tested with tier1-4

Thanks Thomas and Aleksey.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21738#issuecomment-2441640848

From coleenp at openjdk.org  Mon Oct 28 13:53:49 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 13:53:49 GMT
Subject: Integrated: 8342561: Metaspace for generated reflection classes is no
 longer needed
In-Reply-To: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
References: <t7DM2wW_VuJ0fEvUFqALfoZ8s9l9y7k3b1wLoHraD8I=.9aabd9fd-9d42-4303-b008-7cc97de63e8b@github.com>
Message-ID: <kWI-ODnAYa-YI3yuSPYYE_zQJEWhMWeJwPD68VO-H5E=.332245f8-5270-4dfa-82d8-5b12a066f8dd@github.com>

On Mon, 28 Oct 2024 12:04:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Removed code and test for the special metaspace size for reflection DelegatingClassLoader which only had one class.  Now that it's gone, we don't need the special size.  I changed some of the test cases to use ClassMirrorHolderMetaspaceType as a smaller alternate type instead and the tests seem fine with that.
> Tested with tier1-4

This pull request has now been integrated.

Changeset: 120a9357
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/120a9357b3cf63427a6c8539128b69b11b9beca3
Stats:     52 lines in 7 files changed: 3 ins; 39 del; 10 mod

8342561: Metaspace for generated reflection classes is no longer needed

Reviewed-by: shade, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/21738

From coleenp at openjdk.org  Mon Oct 28 13:53:49 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 13:53:49 GMT
Subject: RFR: 8343115: SkipIfEqual class is not used after JDK-8335946
In-Reply-To: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
References: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
Message-ID: <jsX1fGjTy60pB6ZtFEFUUVQE4umlme3kZMtIFTs8jXQ=.75d8f9aa-5151-4bcd-87a6-b6db83bec25c@github.com>

On Sun, 27 Oct 2024 03:45:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this cleanup change.
> This simply removed SkipIfEqual class for all cpu platforms as it's not used anymore after JDK-8335946.
> 
> Testing:
> - [x] GHA

Thank you for this cleanup.  It looks good.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21731#pullrequestreview-2399142624

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: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: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: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 matsaave at openjdk.org  Mon Oct 28 14:35:36 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 28 Oct 2024 14:35:36 GMT
Subject: RFR: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops [v5]
In-Reply-To: <rc_bjF4F8qmA7fKlcJ6OtFwIx2i1yPGayged8l493wM=.03c0cfd4-9c4f-4159-9b24-3e16d6e2d287@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
 <5fbkBeoXHfCfKGVVIPG0zexDYgEbuia9fEXtfBhqEFE=.d01ef3dc-992b-4109-8aba-0f3be19adc8c@github.com>
 <rc_bjF4F8qmA7fKlcJ6OtFwIx2i1yPGayged8l493wM=.03c0cfd4-9c4f-4159-9b24-3e16d6e2d287@github.com>
Message-ID: <3pBDeuislEBY3UadwJ3_8XvwzFG5izewA7P3WiWBuXc=.51a7bc87-88e8-46e1-821a-0b5f146ef842@github.com>

On Thu, 24 Oct 2024 23:24:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed can_use from whitebox
>
> Marked as reviewed by iklam (Reviewer).

Thanks for the reviews @iklam and @calvinccheung!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21647#issuecomment-2441756486

From matsaave at openjdk.org  Mon Oct 28 14:35:36 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 28 Oct 2024 14:35:36 GMT
Subject: Integrated: 8341371: CDS cannot load archived heap objects with
 -XX:+UseSerialGC -XX:-UseCompressedOops
In-Reply-To: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
References: <zQspbeQP93SOHiEU17eTA0gX6yup52TJZQuH-7QCToA=.aedf38ff-7049-413a-b629-8bdd64e59c1f@github.com>
Message-ID: <Di8whYa2f92v2HbvwEdc2083gSx3kCt3h9Si96wCx-U=.d93fd9c2-f3e2-45c1-96e2-29303670b017@github.com>

On Tue, 22 Oct 2024 19:32:03 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> [JDK-8298614](https://bugs.openjdk.org/browse/JDK-8298614) enabled writing the archived heap region with SerialGC and ParallelGC, but archives written with XX:-UseCompressedOops can't be loaded at runtime. This patch enables heap loading for SerialGC and ParallelGC as well as EpsilonGC and Shenandoah since they were enabled in [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913). Related tests were updated to check for the new conditions. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: 9f6211bc
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f6211bcf1b46e4bfba2d128d9eb8457bc0cde51
Stats:     149 lines in 12 files changed: 107 ins; 21 del; 21 mod

8341371: CDS cannot load archived heap objects with -XX:+UseSerialGC -XX:-UseCompressedOops

Reviewed-by: ccheung, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/21647

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 psandoz at openjdk.org  Mon Oct 28 15:37:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 28 Oct 2024 15:37:02 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <PIZqSfpRdtE8UABPYLchyhWD0Zskksm1VSJe7n5bZuo=.be206ea4-d953-4caf-ab7b-6a2ff15b7dbe@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2399452258

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 jbhateja at openjdk.org  Mon Oct 28 16:34:40 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Oct 2024 16:34:40 GMT
Subject: Integrated: 8338021: Support new unsigned and saturating vector
 operators in VectorAPI
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <K4WBXwGSTsojNmBtM3BWDn954xCNfFRt8riA0a6PO9Q=.9cfd6ef4-681d-4363-9104-b49db3f327fb@github.com>

On Thu, 8 Aug 2024 06:50:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

This pull request has now been integrated.

Changeset: 52382e28
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52382e285fdf853c01605f8e0d7f3f5d34965802
Stats:     9395 lines in 52 files changed: 8959 ins; 29 del; 407 mod

8338021: Support new unsigned and saturating vector operators in VectorAPI

Reviewed-by: psandoz, epeter, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/20507

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 duke at openjdk.org  Mon Oct 28 16:56:31 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 28 Oct 2024 16:56:31 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v8]
In-Reply-To: <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
Message-ID: <_GoqJ8iAR_naCUg8X4mCRVeffj4gOE9Ub36AdA9xig4=.ab81aad6-8ae0-45c5-88f3-1f25bd1c9d87@github.com>

On Fri, 25 Oct 2024 14:16:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

Thanks for the comments. Still looks good to me 

(I haven't reviewed the core loop instruction-by-instruction either, I would need to spend a lot more time getting to know SHA3. But this is why I was asking about KAT/testing; This is 'condition-less' code,  and no additions/carries-to-propagate. Testing _should_ have 100% code-coverage with just a few tests., so no need to tests carries, input text value-independent. Do need to vary input length to test loop bounds).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2442122971

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: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: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: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 kvn at openjdk.org  Mon Oct 28 18:03:57 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 28 Oct 2024 18:03:57 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
Message-ID: <o5FxJ2-oi-_gIk7rbxHHdJ7rhHtR7OC3IdKy-Fork0E=.30bfbc19-bd93-4a3b-a06d-e67665c1bbc4@github.com>

On Mon, 7 Oct 2024 13:21:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> With this change, I have adjusted the default settings for CodeCacheSegmentSize and CodeEntryAlignment for AARCH and ARM32. The main goal is to improve code density by reducing the number of wasted bytes (approximately **4%** waste). Improving code density may also have the side effect of boosting performance in large applications
>> 
>> Each nmethod occupies a number of code cache segments (minimum allocation blocks). Since the size of an nmethod is not aligned to 128 bytes, the last occupied segment is half empty. Reducing the size of the code cache segments correspondingly minimizes waste. However, we should be careful about reducing the CodeCacheSegmentSize too much, as smaller segment sizes will increase the overhead of the CodeHeap::_segmap bitmap. A CodeCacheSegmentSize of 64 seems to be an optimal balance.
>> 
>> The current large default value for CodeCacheSegmentSize (64+64) was historically introduced with the comment "Tiered compilation has large code-entry alignment" which doesn't make much sense to me. The history of this comment and value is as follows:
>> - The PPC port was introduced with CodeEntryAlignment=128 (recently reduced to 64: https://github.com/openjdk/jdk/commit/09a78b5d) and CodeCacheSegmentSize was adjusted accordingly for that platform.
>> - Soon after, the 128-byte alignment was applied to all platforms to hide a debug mode warning (https://github.com/openjdk/jdk/commit/e8bc971d). Despite the change (and Segmented Code Cache introduced later), the warning can still be reproduced today using the -XX:+VerifyCodeCache fastdebug option in large applications (10K nmethods ~ 10K free blocks in between them).
>> 
>> I believe it is time to remove the comment and update the default value.
>> 
>> I also suggest updating the default CodeEntryAlignment value for AARCH. The current setting is much larger than for x86 and was likely based on the typical cache line size of 64 bytes. Cortex-A57, A72 architecture software optimisation guides recommend a 32-byte alignment for subroutine entry points. Neoverse architecture software optimisation guides do not mention recommended entry point alignment.
>> 
>> For reference, the default [function_align setting in GCC](https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/cortexa72.h#L44) is typically 16 or 32 bytes, depending on the target architecture.
>> 
>> Hotspot performance tests with -XX:CodeCacheSegmentSize=64 and -XX:CodeEntryAlignment=16 options showed the following result...
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.

Last update is good

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20864#pullrequestreview-2399819506

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 never at openjdk.org  Mon Oct 28 19:21:05 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 28 Oct 2024 19:21:05 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData
Message-ID: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>

Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.

-------------

Commit messages:
 - 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData

Changes: https://git.openjdk.org/jdk/pull/21746/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21746&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338007
  Stats: 41 lines in 4 files changed: 35 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21746/head:pull/21746

PR: https://git.openjdk.org/jdk/pull/21746

From sviswanathan at openjdk.org  Mon Oct 28 19:27:39 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 28 Oct 2024 19:27:39 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v8]
In-Reply-To: <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
Message-ID: <xy28LYHNK60ZFFr4xPRwaMuz-wETDQo3tAOUmcdN2r0=.cd490755-11ac-4d42-a480-fc9bd9ffcc54@github.com>

On Fri, 25 Oct 2024 14:16:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

Thanks for the comments, very helpful. I have verified the theta mapping, chi step, and the xor step. They look good. Now making my way through the rho and sigma perms and rotates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2442440756

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 dnsimon at openjdk.org  Mon Oct 28 19:37:55 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 28 Oct 2024 19:37:55 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData
In-Reply-To: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
Message-ID: <-73Zni4ULRsMUVX8LZEoWZva14T3AN3T-B79kzxvYFo=.52787449-c9d9-495c-9ebc-4c52e51ba7a7@github.com>

On Mon, 28 Oct 2024 19:13:28 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.

LGTM.

src/hotspot/share/oops/methodData.cpp line 1230:

> 1228: }
> 1229: 
> 1230: // Reinitialize the storage of an existing MDO at a safepoint.  Doing it this will ensure it's not

Doing it this *way* will

-------------

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21746#pullrequestreview-2400036182
PR Review Comment: https://git.openjdk.org/jdk/pull/21746#discussion_r1819644517

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 shade at openjdk.org  Mon Oct 28 20:06:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 20:06:24 GMT
Subject: RFR: 8343167: Unnecessary define checks in InterpreterRuntime after
 JDK-8199809
Message-ID: <m-4wfZWepMB6oXnGXWgh-OVCX6l5QSNU-kLsK63XbVc=.9629f202-bd5b-4b07-aa86-3338ecf548ef@github.com>

[JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. 

Additional testing:
 - [x] Linux x86_64 server fastdebug, `make bootcycle-images`
 - [x] Linux x86_32 server fastdebug, `make bootcycle-images`
 - [ ] GHA

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/21747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343167
  Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21747/head:pull/21747

PR: https://git.openjdk.org/jdk/pull/21747

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 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 duke at openjdk.org  Mon Oct 28 20:51:41 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Mon, 28 Oct 2024 20:51:41 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v11]
In-Reply-To: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
Message-ID: <GhbCS1BS5PLLMmPhBu6mMos8yQvA2yIVUxLT6r1-_vg=.caa1f6c6-dd78-4513-95cc-2149726dca97@github.com>

> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

Arseny Bochkarev has updated the pull request incrementally with two additional commits since the last revision:

 - Utilize the UseAES flag
 - Left comment on keys endiannes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19960/files
  - new: https://git.openjdk.org/jdk/pull/19960/files/e90b0d05..0f38182d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=09-10

  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19960/head:pull/19960

PR: https://git.openjdk.org/jdk/pull/19960

From duke at openjdk.org  Mon Oct 28 20:51:41 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Mon, 28 Oct 2024 20:51:41 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v10]
In-Reply-To: <CNQUc31lweSYNs2QsNuWqMavcG4mD5QozXd0FGDIoU4=.36893484-4130-446b-9b54-8128831c8a3e@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
 <CNQUc31lweSYNs2QsNuWqMavcG4mD5QozXd0FGDIoU4=.36893484-4130-446b-9b54-8128831c8a3e@github.com>
Message-ID: <kZgfhrFPOmp4q4urH__AgNWpnkQCzdaU75vGwFaehec=.78a55319-0c5a-4b63-b0d2-36b1721a609f@github.com>

On Mon, 28 Oct 2024 07:23:15 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Arseny Bochkarev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Replace RISCV64 -> riscv64 in comment
>>  - Minor renaming of labels and reg_number
>>  - Use RISCV64 instead of RISCV
>>  - Fixed comment line
>>  - Rename reg_number -> rounds in aes_loadkeys
>>  - Fix typo
>>  - Use same keys for encryption and decryption
>>  - Multiversion decrypt intrinsic
>>  - Use one L_end for all AES key sizes
>>  - Multiversion encryption depending on keylen
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/d1540e2a...e90b0d05
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2283:
> 
>> 2281:     for (int i = 0; i < rounds; i++) {
>> 2282:       __ vle32_v(working_vregs[i], key);
>> 2283:       __ vrev8_v(working_vregs[i], working_vregs[i]);
> 
> What's is this `vrev8_v` for? I wonder how this maps to the code-samples at [1]. Might deserve a code comment here. 
> 
> [1] https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvkned.s

I'm not very familiar with OpenSSL but I guess it is just uses different endianness when storing the result :shrug:  (compared to [big-endian](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.11) JVM). I'll left the note on it in the code

> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 423:
> 
>> 421: 
>> 422:   // AES
>> 423:   if (UseZvkn) {
> 
> Was checking and enablement for `UseAES` VM option missed here?
> 
> Reference: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L289

Thanks! I like the way it is done in aarch64, so I used it here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1819743553
PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1819743506

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 sviswanathan at openjdk.org  Mon Oct 28 22:11:50 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 28 Oct 2024 22:11:50 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v8]
In-Reply-To: <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
Message-ID: <qC-0ieed8EZD-ETItzUQmb7H6eYsTcDTJ-ug7ia0dTQ=.de07d565-7462-443f-9a65-581b0d528e17@github.com>

On Fri, 25 Oct 2024 14:16:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21352#pullrequestreview-2400352048

From sviswanathan at openjdk.org  Mon Oct 28 22:11:50 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 28 Oct 2024 22:11:50 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v4]
In-Reply-To: <Be0GEMddzDo2KG1luVL1poXDqmewb-LfuttDf5Jqv_M=.2027d69b-8c46-4e3a-9dd6-54f741987896@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <5H9O9IpwKljEMvZ0G2JUJeve9-HtfYppsxiWsFRDqhE=.b4f1e7b4-56d6-4fe8-acca-02e58883235b@github.com>
 <qzzlNMj29HeJaISD-cJRo1VXwZ3MIRy47GBvfmJ848U=.69d26512-7b81-446e-88c8-892a6f505009@github.com>
 <46mRcSE93kh9LBxGZjasXTeLSvEuk7Ab5L12ZYIso1Q=.189fbde8-8e5f-47a8-ad22-a41beeba8bed@github.com>
 <Be0GEMddzDo2KG1luVL1poXDqmewb-LfuttDf5Jqv_M=.2027d69b-8c46-4e3a-9dd6-54f741987896@github.com>
Message-ID: <6-y06QWl_qi1_CQA-HiYxvANzJ7MRKEU02x0TO_inZ4=.08e31ff0-cfb0-4ef8-8d10-174b746bd1d5@github.com>

On Tue, 22 Oct 2024 11:44:30 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> test/hotspot/jtreg/compiler/intrinsics/sha

The rho and sigma perms/rotates also look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2442767610

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 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 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 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 fyang at openjdk.org  Tue Oct 29 00:18:10 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 29 Oct 2024 00:18:10 GMT
Subject: RFR: 8343115: SkipIfEqual class is not used after JDK-8335946
In-Reply-To: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
References: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
Message-ID: <ibIaAtaZbjZy9pBgQxUbSBgfWcHVpOdvKwAuq6TGH3g=.f3defd8b-ea70-4e97-9709-29222a0a627e@github.com>

On Sun, 27 Oct 2024 03:45:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this cleanup change.
> This simply removed SkipIfEqual class for all cpu platforms as it's not used anymore after JDK-8335946.
> 
> Testing:
> - [x] GHA

Thanks all for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21731#issuecomment-2442909895

From fyang at openjdk.org  Tue Oct 29 00:18:10 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 29 Oct 2024 00:18:10 GMT
Subject: Integrated: 8343115: SkipIfEqual class is not used after JDK-8335946
In-Reply-To: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
References: <ESnNwicgAPMVKumzHkfVjLaYJjN1FzKPMqC1aF1_7P0=.a14c0ced-694f-437d-8e02-2bcbb1559556@github.com>
Message-ID: <TsN0di3M1Vv5qYo8hCIRmel1rb9SYI28pymM04ad3Fk=.eea4c0b6-a335-496a-bf07-1ab33001b886@github.com>

On Sun, 27 Oct 2024 03:45:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this cleanup change.
> This simply removed SkipIfEqual class for all cpu platforms as it's not used anymore after JDK-8335946.
> 
> Testing:
> - [x] GHA

This pull request has now been integrated.

Changeset: f0075d59
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0075d593db657182e1857e54710a1052e9d1cf0
Stats:     184 lines in 11 files changed: 0 ins; 184 del; 0 mod

8343115: SkipIfEqual class is not used after JDK-8335946

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/21731

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 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 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 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 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 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 mgronlun at openjdk.org  Tue Oct 29 10:33:46 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 10:33:46 GMT
Subject: RFR: 8343177: JFR: Remove critical section for thread id assignment
Message-ID: <430mnItIA1UjjtseRV4_duukmmJ5A8_NewyVG9oiGS8=.d810700f-4217-4d32-a235-c65a7ab88da8@github.com>

Greetings,

With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments.

However, a critical section at this location makes it difficult to build robust signal handlers, for example, because we need help reading the thread ID.

We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude).

The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. 

Testing: jdk_jfr Tier 1- 3, Stress testing

Thanks
Markus

-------------

Commit messages:
 - 8343177

Changes: https://git.openjdk.org/jdk/pull/21756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343177
  Stats: 79 lines in 10 files changed: 46 ins; 13 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21756/head:pull/21756

PR: https://git.openjdk.org/jdk/pull/21756

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 jbechberger at openjdk.org  Tue Oct 29 11:00:18 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:18 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
Message-ID: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>

This is the code for the [JEP draft: CPU Time based profiling for JFR].

-------------

Commit messages:
 - Use try-with-resources in tests
 - Fix stackTrace setting issue
 - Fix threshold setting issue
 - Add missing files
 - Simplify rate parsing
 - Small fixes
 - Small build fix for non-Linux
 - Small clean up
 - Change thread and weight name
 - Add missing files
 - ... and 113 more: https://git.openjdk.org/jdk/compare/b6700095...366aced5

Changes: https://git.openjdk.org/jdk/pull/20752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342818
  Stats: 2350 lines in 48 files changed: 2147 ins; 176 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/20752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752

PR: https://git.openjdk.org/jdk/pull/20752

From egahlin at openjdk.org  Tue Oct 29 11:00:23 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

How is throttling handled? We don't want buffers to be filled up with sample events?

Not sure what is the best approach is, but I like to get a better understanding of the trade-offs.

In alternative 2, only use a rate / throttle, would you include the CPU time as field in the event as a weight factor, similar to the Object Allocation event?

Johannes, Markus, and I discussed the configuration, and we decided to have only one option called "rate," which might become "throttle". The option can accept either a period (e.g., 20ms) or a maximum rate (e.g., 1000/s). If the latter, the period is calculated from the number of cores when the setting is applied. In the future, it might be recalculated if the number of cores changes. The CPUTimeSample event will have a field that indicates what the CPU time was, perhaps called "weight" or "cpuTime". If needed, we will discuss this further next week.

Markus and I discussed the naming, and we are leaning against using "throttle" as the setting name. It is easier for users to understand if allocation, exception, socket read, etc., can share the same name for a rate like 500/s. The timespan or period for the CPUTimeSample event will serve as an override for advanced users. Other throttle settings in the future could have similar overrides, such as 1 MB for a memory-based event.

When it comes to naming the field, we think "sampleTime" could work. We don't want to give the impression that the method actually executed during that time, which would be the case with "cpuTime." We discussed the name "weight," but we believe users will interpret it as CPU time and create GUI aggregations with total CPU time per thread or method anyway. If we use "sampleTime", we can place a proper unit on the field, which doesn't make sense for "weight".

Regarding the implementation, I think you can simplify things by just selecting a CPUThrottleSetting implementation in the EventControl class. There's no need to add native support, as it seems unlikely that CPUThrottle will be useful for other events in the future.


    private static Control defineThrottle(PlatformEventType type) {
        ...
        type.add(PrivateAccess.getInstance().newSettingDescriptor(...);
        if (type.getName().equals("jdk.CPUTimeSample") {
            return new Control(new CPUThrottleSetting(type), def);
        }
        return new Control(new ThrottleSetting(type), def);
    }


The Rate annotation class can be removed.

src/hotspot/share/jfr/metadata/metadata.xml line 939:

> 937:   </Event>
> 938: 
> 939:   <Event name="CPUTimeExecutionSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Sample" description="Snapshot of a threads state from the CPU time sampler"

Maybe we should leave out "Execution" and only have CPUTimeSample?

src/hotspot/share/jfr/metadata/metadata.xml line 939:

> 937:   </Event>
> 938: 
> 939:   <Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Sample" description="Snapshot of a threads state from the CPU time sampler"

I think we can drop "Profiling" from the label, "CPU Time Method Sample"

src/hotspot/share/jfr/periodic/jfrPeriodic.cpp line 148:

> 146: TRACE_REQUEST_FUNC(NativeMethodSample) {
> 147: }
> 148: TRACE_REQUEST_FUNC(CPUTimeSample) {

The event doesn't need to be periodic.

src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java line 86:

> 84:                 if (pEventType.hasPeriod()) {
> 85:                     pEventType.setEventHook(true);
> 86:                     if (!pEventType.isMethodSampling() || !pEventType.isCPUTimeMethodSampling()) {

The event doesn't have a period. You should be able to remove this.

src/jdk.jfr/share/classes/jdk/jfr/internal/query/FieldBuilder.java line 132:

> 130:             return true;
> 131:         }
> 132:         if (fieldName.equals("stackTrace.isNull")) {

With the failed field, this is no longer needed, I believe?

src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 404:

> 402: 
> 403: [application.cpu-time-hot-methods]
> 404: label = "Java Methods that Executes the Most from CPU time sampler"

Use headline-style capitalization, capitalize the first and last words, and all nouns, pronouns, adjectives, verbs and adverbs.

src/jdk.jfr/share/classes/jdk/jfr/internal/util/ParsedCPUThrottle.java line 33:

> 31:  * A rate or fixed period, see {@link jdk.jfr.internal.Rate}
> 32:  */
> 33: public sealed interface ParsedCPUThrottle {

This seems complicated. Why isn't possible to keep the Rate class as is (no renaming) and then only create a TimespanRate class and do something like this:

    public record TimespanRate(double rate) {
    
        public static TimespanRate of(String text) {
           Rate r = Rate.of(text);
           if (r != null) {
              double rate = r.amount() * ...
              return new TimespanRate(rate)
           } else {
              long v = ValueParser.parseTimespanWithInfinity(text);
              double rate = v * ...
              return new TimespanRate(rate);
          }
      }
    
      public boolean isHigher(TimespanRate that) {
          return rate() > that.rate();
      }
    }

test/jdk/jdk/jfr/event/profiling/TestCPUTimeEventThrottling.java line 76:

> 74: 
> 75:     private static EventCount countEvents(int timeMs, String rate) throws Exception {
> 76:         Recording recording = new Recording();

Use try-with-resources.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeFullStackTrace.java line 31:

> 29:  * @test
> 30:  * @key jfr
> 31:  * @requires vm.hasJFR

What happens if you run the test on a platform that doesn't support CPU Time sample?

test/jdk/jdk/jfr/event/profiling/TestFullStackTrace.java line 44:

> 42:  * @requires vm.hasJFR
> 43:  * @library /test/lib
> 44:  * @run main/othervm jdk.jfr.event.profiling.TestFullStackTrace wall-clock

Create separate tests for CPU time sampling events. It makes them easier to problem list and disable for specific platforms. If you want to share verification code, create  helper class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2340781084
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2380263077
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2407736399
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416197137
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751987754
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769540838
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1806357857
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1806357106
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1806355696
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751894865
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1806455856
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1810756770
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769541205
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751940865

From jbechberger at openjdk.org  Tue Oct 29 11:00:23 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
Message-ID: <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>

On Thu, 5 Sep 2024 13:16:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Changes requested by mgronlun (Reviewer).

Regarding enqueue buffer handling (cc @mgronlun): we need to check regularly whether we need to renew the buffer. If we omit this, than it leads to many errors in the method resolve logic (catched by the ThreadCrashProtection).

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 92:
> 
>> 90:     case _thread_blocked:
>> 91:     case _thread_in_native:
>> 92:     case _thread_in_vm: // walking in vm causes weird bugs (assertions in G1 fail), so don't
> 
> Is this comment still relevant?

It isn't. Good catch.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 102:
> 
>> 100: static bool is_excluded(JavaThread* thread) {
>> 101:   return thread->is_hidden_from_external_view() ||
>> 102:     (os::is_readable_pointer(thread->jfr_thread_local()) && thread->jfr_thread_local()->is_excluded());
> 
> thread->jfr_thread_local() is always safe. Its a member struct of Thread.

removed

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 135:
> 
>> 133:   JfrTicks _start_time;
>> 134:   JfrTicks _end_time;
>> 135:   JavaThread* _sampled_thread;
> 
> You can store the thread's traceid (u8) here instead of the Thread* itself.
> 
> Then, later, you can skip using both JFRRecordSampledThreadCallback and crash protection.

No, we can't. This crashes the sampler. The problem is, that obtaining the traceid via `JfrThreadLocal::thread_id(jt)` acquires a lock (and more) when the traceid is not set already. So we can't use it in the signal handler.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 154:
> 
>> 152:   void set_end_time(JfrTicks end_time) { _end_time = end_time; }
>> 153:   JfrTicks end_time() const { return _end_time; }
>> 154:   void set_sampled_thread(JavaThread* thread) { Atomic::store(&_sampled_thread, thread); }
> 
> Why atomic store? Again, try to use the traceid of the thread (from the JfrThreadLocal (updated dynamically depending on vthread or regular thread).

Removed the atomic store

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 197:
> 
>> 195:     } else {
>> 196:       _error = ERROR_NO_TOPFRAME;
>> 197:       return;
> 
> Can remove.

removed

> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.hpp line 75:
> 
>> 73:   friend class JfrStackTrace;
>> 74:   friend class JfrThreadSampler;
>> 75:   friend class JfrCPUTimeThreadSampler;
> 
> Not needed.

removed

> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp line 92:
> 
>> 90:   auto holder = method->method_holder();
>> 91:   auto res = load(holder, method);
>> 92:   return res;
> 
> Why this change?

Good catch, I'll remove it

> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 35:
> 
>> 33: 
>> 34: JfrAsyncStackFrame::JfrAsyncStackFrame(const Method* method, int bci, u1 type, int lineno, const InstanceKlass* ik) :
>> 35:   _klass(ik), _method(method), _line(lineno), _bci(bci), _type(type) {}
> 
> Might be possible to delay processing of line numbers.

As explained above: I think this would not be a good idea, as this would lead to additional load in the queue consuming thread, especially bad when the profiled systems has lots of cores.

> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 49:
> 
>> 47: 
>> 48: static inline bool is_full(const JfrBuffer* enqueue_buffer) {
>> 49:   return enqueue_buffer->free_size() < min_valid_free_size_bytes;
> 
> The enqueue_buffer constructs can be removed from this code because the thread does not suspend other threads. Hence, it can rely on the regular JfrTraceId load barrier tagging mechanism (which renews and enqueues new buffers implicitly).

removed

> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 99:
> 
>> 97:       type = JfrStackFrame::FRAME_INLINE;
>> 98:     }
>> 99:     _frames[count] = JfrAsyncStackFrame(method, bci, type, method->line_number_from_bci(bci), method->method_holder());
> 
> Calculating line number information is expensive. There is no need to do it for the sampled thread; it can be done by the thread registering the trace into the stack trace repository (it ejects an attempt to store a JfrStackTrace with no line number information).

Why wouldn't we then do this in parallel in the sampled threads? Especially on systems with lot's of cores, this could otherwise be an issue and drastically increase the amount of dropped samples.

> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 118:
> 
>> 116:   const JfrAsyncStackTrace* _asyncTrace;
>> 117:   JfrStackTrace* _trace;
>> 118:   const JfrBuffer* const _enqueue_buffer;
> 
> Remove, not necessary.

removed

> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 126:
> 
>> 124:   for (u4 i = 0; i < _nr_of_frames; i++) {
>> 125:     const JfrAsyncStackFrame& frame = _frames[i];
>> 126:     if (!Method::is_valid_method(frame._method) || is_full(enqueue_buffer)) {
> 
> We should try to remove is_full(enqueue_buffer)).

This code is similar to the code in the old sampler and ensures that the buffer is large enough.

> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.hpp line 28:
> 
>> 26: #define SHARE_JFR_RECORDER_STACKTRACE_JFRASYNCSTACKTRACE_HPP
>> 27: 
>> 28: #include "jfr/recorder/stacktrace/jfrStackTrace.hpp"
> 
> Including this header is not needed.

removed

> src/hotspot/share/runtime/javaThread.cpp line 27:
> 
>> 25: 
>> 26: #include "precompiled.hpp"
>> 27: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"
> 
> We try to channel all (most) VM code through the jfr.hpp as a single entry point to the JFR system. Can these hooks be incorporated in the JfrThreadLocal::on_start() and JfrThreadLocal::on_exit()?
> 
> If so, you don't need to touch anything in javaThread.cpp.

done

> src/hotspot/share/runtime/javaThread.cpp line 759:
> 
>> 757:     }
>> 758: 
>> 759:     JFR_ONLY(JfrCPUTimeThreadSampling::on_javathread_create(this));
> 
> See if you can move these into JfrThreadLocal::on_start() and JfrThreadLocal::on_exit().

Seems to work

> test/jdk/jdk/jfr/event/profiling/TestMultipleRecordings.java line 1:
> 
>> 1: /*
> 
> What is the purpose of this test?

Tests that restarting the sampler works.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2348807804
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1804543106
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756642656
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756750417
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756816348
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756645107
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756623496
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1804537662
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756712764
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756635808
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1752030136
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756636093
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1752031872
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756629453
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756817283
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756816729
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756634818

From mgronlun at openjdk.org  Tue Oct 29 11:00:22 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 11:00:22 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Changes requested by mgronlun (Reviewer).

Changes requested by mgronlun (Reviewer).

Changes requested by mgronlun (Reviewer).

src/hotspot/share/jfr/metadata/metadata.xml line 945:

> 943:   </Event>
> 944: 
> 945:   <Event name="CPUTimeExecutionSampleThrottles" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Dropped Samples" description="Records that the CPU time dropped samples because of internal throttling"

A better name for this event is "CPUTimeExecutionSampleLoss".

This is because JFR already has a general concept of "DataLoss," so this name would better align with it. 

Please update references to "dropped" -> "lost"

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 92:

> 90:     case _thread_blocked:
> 91:     case _thread_in_native:
> 92:     case _thread_in_vm: // walking in vm causes weird bugs (assertions in G1 fail), so don't

Is this comment still relevant?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 102:

> 100: static bool is_excluded(JavaThread* thread) {
> 101:   return thread->is_hidden_from_external_view() ||
> 102:     (os::is_readable_pointer(thread->jfr_thread_local()) && thread->jfr_thread_local()->is_excluded());

thread->jfr_thread_local() is always safe. Its a member struct of Thread.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 135:

> 133:   JfrTicks _start_time;
> 134:   JfrTicks _end_time;
> 135:   JavaThread* _sampled_thread;

You can store the thread's traceid (u8) here instead of the Thread* itself.

Then, later, you can skip using both JFRRecordSampledThreadCallback and crash protection.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 154:

> 152:   void set_end_time(JfrTicks end_time) { _end_time = end_time; }
> 153:   JfrTicks end_time() const { return _end_time; }
> 154:   void set_sampled_thread(JavaThread* thread) { Atomic::store(&_sampled_thread, thread); }

Why atomic store? Again, try to use the traceid of the thread (from the JfrThreadLocal (updated dynamically depending on vthread or regular thread).

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 197:

> 195:     } else {
> 196:       _error = ERROR_NO_TOPFRAME;
> 197:       return;

Can remove.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 29:

> 27: 
> 28: #include "jfr/utilities/jfrAllocation.hpp"
> 29: #include "runtime/javaThread.hpp"

You don't need to include the "runtime/javaThread.hpp" header.

Instead, please hoist the forward declaration of "class JavaThread" to outside the "#if defined(LINUX)"

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp line 102:

> 100: }
> 101: 
> 102: JfrBuffer* JfrTraceIdLoadBarrier::renew_sampler_enqueue_buffer(Thread* thread, size_t size) {

JfrCPUTimeThreadSampler should not need to take this specialized path because it does not suspend threads. It can be left as is.

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.hpp line 75:

> 73:   friend class JfrStackTrace;
> 74:   friend class JfrThreadSampler;
> 75:   friend class JfrCPUTimeThreadSampler;

Not needed.

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.hpp line 83:

> 81:   static void load_barrier(const Klass* klass);
> 82:   static JfrBuffer* get_sampler_enqueue_buffer(Thread* thread);
> 83:   static JfrBuffer* renew_sampler_enqueue_buffer(Thread* thread, size_t size = 0);

Leave as is.

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp line 92:

> 90:   auto holder = method->method_holder();
> 91:   auto res = load(holder, method);
> 92:   return res;

Why this change?

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.

Copyrights?

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 35:

> 33: 
> 34: JfrAsyncStackFrame::JfrAsyncStackFrame(const Method* method, int bci, u1 type, int lineno, const InstanceKlass* ik) :
> 35:   _klass(ik), _method(method), _line(lineno), _bci(bci), _type(type) {}

Might be possible to delay processing of line numbers.

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 49:

> 47: 
> 48: static inline bool is_full(const JfrBuffer* enqueue_buffer) {
> 49:   return enqueue_buffer->free_size() < min_valid_free_size_bytes;

The enqueue_buffer constructs can be removed from this code because the thread does not suspend other threads. Hence, it can rely on the regular JfrTraceId load barrier tagging mechanism (which renews and enqueues new buffers implicitly).

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 99:

> 97:       type = JfrStackFrame::FRAME_INLINE;
> 98:     }
> 99:     _frames[count] = JfrAsyncStackFrame(method, bci, type, method->line_number_from_bci(bci), method->method_holder());

Calculating line number information is expensive. There is no need to do it for the sampled thread; it can be done by the thread registering the trace into the stack trace repository (it ejects an attempt to store a JfrStackTrace with no line number information).

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 118:

> 116:   const JfrAsyncStackTrace* _asyncTrace;
> 117:   JfrStackTrace* _trace;
> 118:   const JfrBuffer* const _enqueue_buffer;

Remove, not necessary.

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 126:

> 124:   for (u4 i = 0; i < _nr_of_frames; i++) {
> 125:     const JfrAsyncStackFrame& frame = _frames[i];
> 126:     if (!Method::is_valid_method(frame._method) || is_full(enqueue_buffer)) {

We should try to remove is_full(enqueue_buffer)).

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.hpp line 28:

> 26: #define SHARE_JFR_RECORDER_STACKTRACE_JFRASYNCSTACKTRACE_HPP
> 27: 
> 28: #include "jfr/recorder/stacktrace/jfrStackTrace.hpp"

Including this header is not needed.

src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.hpp line 30:

> 28: #include "jfr/utilities/jfrAllocation.hpp"
> 29: #include "jfr/utilities/jfrTypes.hpp"
> 30: #include "runtime/vframe.inline.hpp"

Do not include an .inline.hpp into a .hpp.

src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.hpp line 41:

> 39:  private:
> 40:   bool _vthread;
> 41:   const ContinuationEntry* _cont_entry;

You need a fwd declaration for ContinuationEntry here?

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 76:

> 74:   bool _dead;
> 75:   LINUX_ONLY(bool _has_cpu_timer = false);
> 76:   LINUX_ONLY(timer_t _cpu_timer);

No include for timer_t?

src/hotspot/share/runtime/javaThread.cpp line 27:

> 25: 
> 26: #include "precompiled.hpp"
> 27: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

We try to channel all (most) VM code through the jfr.hpp as a single entry point to the JFR system. Can these hooks be incorporated in the JfrThreadLocal::on_start() and JfrThreadLocal::on_exit()?

If so, you don't need to touch anything in javaThread.cpp.

src/hotspot/share/runtime/javaThread.cpp line 759:

> 757:     }
> 758: 
> 759:     JFR_ONLY(JfrCPUTimeThreadSampling::on_javathread_create(this));

See if you can move these into JfrThreadLocal::on_start() and JfrThreadLocal::on_exit().

src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 419:

> 417: 
> 418: [application.cpu-time-overflowed-samples]
> 419: label = "CPU Time Samples not recorded because of internal throttling"

Align rename for CPUTimeSampleLoss

src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 420:

> 418: [application.cpu-time-overflowed-samples]
> 419: label = "CPU Time Samples not recorded because of internal throttling"
> 420: table = "COLUMN 'Dropped samples'

Lost samples

test/jdk/jdk/jfr/event/profiling/TestMultipleRecordings.java line 1:

> 1: /*

What is the purpose of this test?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20752#pullrequestreview-2279856307
PR Review: https://git.openjdk.org/jdk/pull/20752#pullrequestreview-2281421499
PR Review: https://git.openjdk.org/jdk/pull/20752#pullrequestreview-2282590777
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744364821
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1804541089
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744526731
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744529196
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744531604
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1745258406
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1743597903
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744368940
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744369131
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744369305
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1804534948
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744517980
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1745274936
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744512910
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1745270064
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744513289
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1745276007
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744371764
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744373520
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744374340
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744375984
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744488057
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1745272051
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744501220
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744502178
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1744506419

From mgronlun at openjdk.org  Tue Oct 29 11:00:23 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
Message-ID: <fYvc_xdiyvPFpc_DHEtfrrOASMjzo8e0vfkNf0hOoPc=.d07fcca9-d421-40e4-8d5e-214090390a51@github.com>

On Thu, 5 Sep 2024 13:16:22 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Changes requested by mgronlun (Reviewer).

> Regarding enqueue buffer handling (cc @mgronlun): we need to check regularly whether we need to renew the buffer. If we omit this, than it leads to many errors in the method resolve logic (catched by the ThreadCrashProtection).

How so?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2365139780

From jbechberger at openjdk.org  Tue Oct 29 11:00:23 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

I couldn't figure that out for now.

> Why are events with stack trace = null emitted? Isn't CPUTimeExecutionSampleLoss sufficient?

@egahlin CPUTimeExecutionSampleLoss is emitted when our internal queue is full and we cannot obtain any information for these samples (other than that they exist). On the other hand, `stackTrace=null,failed=null` is emitted when we can't walk the stack (or resolve any of the methods), but we still have enough space in the internal queue so that we can record the important thread and time information. As @jbachorik explained before, this is really important, as we know that the thread did some work at this point in time on the CPU.

We really want to capture as much information as possible. CPUTimeExecutionSampleLoss happens usually not that often (< 1% of the samples are typically lost), but stack walking is impossible in around 10% of the cases.

The semantics are different, as `maxRate` is just upper bounding, while `throttle` is used to sub-sample (not using the  throttle code under the hood), this is why I use a new name. Else I would have to check all over JFR which meaning `throttle` has for every event.

The only option for throttling (or rate-limiting) that I see is to upper bound the amount of events generated by lower-bounding the allowed interval, computing the lower-bound of the interval as `throttle/#cores` (as explained before). This is the only fast and unbiased way to upper-bounding the rate of CPU-time sample. Every time for the interval is set, it is checked against the computed lower-bound. This also happens when setting the throttle.

The two options for setting the throttle for this event are now:

1. Use the existing `throttle` setting: The semantics of upper-bounding the event emission rate are similar enough that this should not lead to confusion (description of `@Throttle`: "Event annotation, determines the event emission rate in events per time unit."). So we could use the pre-existing `throttle` setting and compute the lower-bound of the interval based on that. The main disadvantage is that the setting is currently bound to the [JfrEventThrottler](https://github.com/openjdk/jdk/blob/73ebb848fdb66861e912ea747c039ddd1f7a5f48/src/hotspot/share/jfr/recorder/service/jfrEventThrottler.hpp) (see [`JfrEvent#evaluate`](https://github.com/openjdk/jdk/blob/73ebb848fdb66861e912ea747c039ddd1f7a5f48/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp#L164). So we would have to modify the code to add a special case for the CPU-time-based even, because we can't use the throttler (biasing and more).
2. Use a new `maxRate` setting: This reduces the amount of existing functionality that is affected by this PR and signifies that `maxRate` and `throttle` have slightly different semantics.

I can see that the first option leads to less confusion. But I'm happy to hear whether the first option is ok for you.

I've settled for option 1, which significantly reduces the amount of code for this PR. Furthermore, there are now tests for the expected throttle behavior.

How should I treat the `off` setting? I disabled the rate setting for now because it doesn't make any sense when the period can be arbitrarily small. Of course, I could replace it with the smallest reasonable value of "1ms". Any opinions?

And how should I document the new behaviour? Add it to the documentation of the throttle annotation?

The only place where the current throttle syntax is defined seems to be the throttle annotation.

Ok, so is the following ok?


<Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Sample"
    description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units."
    period="everyChunk" throttle="true" experimental="true">
    <Field type="Thread" name="sampledThread" label="Thread" />
    <Field type="StackTrace" name="stackTrace" label="Stack Trace" />
    <Field type="boolean" name="failed" label="Failed" description="Failed to obtain the stack trace" />
    <Field type="Tickspan" name="sampleTime" label="CPU time sampling period for this event"/>
  </Event>

The tests failed because I forgot to add two files; I will do that this evening.

But the ergonomics of the throttle options feels good.

There are fewer changes in tools that already process the two existing events. But yes, we can of course change it. I never understood why the old events had a special thread property anyway.

Regarding the field `samplingPeriod`: @apangin mentioned in a recent meeting that naming it `cpuTime` and storing the thread's CPU time at the point of sampling would be better, giving us more flexibility. Not only does it convey more information, but it also allows profiler writers to merge adjacent traces if they are similar, making it possible to store the traces in a more compact format without breaking the API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2365140305
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2366890705
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2379712271
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2380550554
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2386016365
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416348809
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416409643
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416781819
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416994088
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2418868037
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2421954045
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2443890244

From egahlin at openjdk.org  Tue Oct 29 11:00:23 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
Message-ID: <KwXaIdSAe0kgo1b2wCsUNWwIlF4nQJ0OnO_AkeNilKE=.6aa16af1-151b-4048-b1e0-6eff77323ede@github.com>

On Tue, 10 Sep 2024 13:48:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> > How is throttling handled? We don't want buffers to be filled up with sample events?
> 
> By setting the internal queue size. The user can throttle by setting the interval, any other option would lead to bias.

Where can the queue size be set and how does a user know what is a reasonable value?

> Just to clarify, do you mean that you're against using "rate" as a setting name?

Name only, implementation as we discussed and I believe you have implemented.

>> src/jdk.jfr/share/classes/jdk/jfr/internal/util/ParsedCPUThrottle.java line 33:
>> 
>>> 31:  * A rate or fixed period, see {@link jdk.jfr.internal.Rate}
>>> 32:  */
>>> 33: public sealed interface ParsedCPUThrottle {
>> 
>> This seems complicated. Why isn't possible to keep the Rate class as is (no renaming) and then only create a TimespanRate class and do something like this:
>> 
>>     public record TimespanRate(double rate) {
>>     
>>         public static TimespanRate of(String text) {
>>            Rate r = Rate.of(text);
>>            if (r != null) {
>>               double rate = r.amount() * ...
>>               return new TimespanRate(rate)
>>            } else {
>>               long v = ValueParser.parseTimespanWithInfinity(text);
>>               double rate = v * ...
>>               return new TimespanRate(rate);
>>           }
>>       }
>>     
>>       public boolean isHigher(TimespanRate that) {
>>           return rate() > that.rate();
>>       }
>>     }
>
> I can try to implement. I thought it would be easier to comprehend this way.

Since you need custom logic in CPUThrottleSetting, it might be easier to just have two distinct types and skip the common interface?

I haven't looked at it closely, it's just my impression. Maybe there should be a ThrottlePeriod(double period, boolean autoAdapt) with a factory method where it first checks if it can be created from Rate.of(text).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2365155428
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416305503
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1807679939

From jbechberger at openjdk.org  Tue Oct 29 11:00:23 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <KwXaIdSAe0kgo1b2wCsUNWwIlF4nQJ0OnO_AkeNilKE=.6aa16af1-151b-4048-b1e0-6eff77323ede@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
 <KwXaIdSAe0kgo1b2wCsUNWwIlF4nQJ0OnO_AkeNilKE=.6aa16af1-151b-4048-b1e0-6eff77323ede@github.com>
Message-ID: <LcVKzoC1-Ppj5NP_mrVqCKtfjy91H1HsQ6_w2xNW3JQ=.4f089ab1-b7a6-4957-8f04-b9a9302a43b6@github.com>

On Sat, 21 Sep 2024 11:37:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > > How is throttling handled? We don't want buffers to be filled up with sample events?
> > 
> > 
> > By setting the internal queue size. The user can throttle by setting the interval, any other option would lead to bias.
> 
> Where can the queue size be set and how does a user know what is a reasonable value?

The queue size is pre-computed to a large value that shouldn't lead to many dropped samples. I don't think that making the queue size settable is really useful. Please ignore, therefore, my mentioning of the queue size for throttling; the real throttling is by setting the interval. There is no other way that is also understandable by the user.

>> I can try to implement. I thought it would be easier to comprehend this way.
>
> Since you need custom logic in CPUThrottleSetting, it might be easier to just have two distinct types and skip the common interface?
> 
> I haven't looked at it closely, it's just my impression. Maybe there should be a ThrottlePeriod(double period, boolean autoAdapt) with a factory method where it first checks if it can be created from Rate.of(text).

You were right, the code is now far simpler. I dropped the renaming of Rate and created a TimespanRate(double rate, boolean autoadapt).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2365165291
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1808564743

From egahlin at openjdk.org  Tue Oct 29 11:00:23 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <LcVKzoC1-Ppj5NP_mrVqCKtfjy91H1HsQ6_w2xNW3JQ=.4f089ab1-b7a6-4957-8f04-b9a9302a43b6@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
 <KwXaIdSAe0kgo1b2wCsUNWwIlF4nQJ0OnO_AkeNilKE=.6aa16af1-151b-4048-b1e0-6eff77323ede@github.com>
 <LcVKzoC1-Ppj5NP_mrVqCKtfjy91H1HsQ6_w2xNW3JQ=.4f089ab1-b7a6-4957-8f04-b9a9302a43b6@github.com>
Message-ID: <_jN89X3QTfTGXTc-24lrU_v72Y-nNfO9Ljf3xj_VjSM=.96e04b54-1df8-49d0-a890-00ba45690e8d@github.com>

On Sat, 21 Sep 2024 12:12:46 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> The queue size is pre-computed to a large value that shouldn't lead to many dropped samples. I don't think that making the queue size settable is really useful. Please ignore, therefore, my mentioning of the queue size for throttling; the real throttling is by setting the interval. There is no other way that is also understandable by the user.

Recording files could be filled with CPU Time Sample events, flushing out important data, making the feature not usable for continuous profiling. We can't demand that users set a period every time they use JFR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2365173899

From jbechberger at openjdk.org  Tue Oct 29 11:00:23 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
Message-ID: <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>

On Tue, 10 Sep 2024 13:26:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> How is throttling handled? We don't want buffers to be filled up with sample events?

By setting the internal queue size. The user can throttle by setting the interval, any other option would lead to bias.

> Markus and I discussed the naming, and we are leaning against using "throttle" as the setting name. It is easier for users to understand if allocation, exception, socket read, etc., can share the same name for a rate like 500/s.

Just to clarify, do you mean that you're against using "rate" as a setting name?

I like the idea of overriding the "throttle" setting for different event types, which reduces the PR's complexity.

Let's see how the implementation goes.

> src/hotspot/share/jfr/metadata/metadata.xml line 939:
> 
>> 937:   </Event>
>> 938: 
>> 939:   <Event name="CPUTimeExecutionSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Sample" description="Snapshot of a threads state from the CPU time sampler"
> 
> Maybe we should leave out "Execution" and only have CPUTimeSample?

Sounds like a good idea, because it combines both `ExecutionSample` and `NativeMethodSample`.

> src/jdk.jfr/share/classes/jdk/jfr/internal/util/ParsedCPUThrottle.java line 33:
> 
>> 31:  * A rate or fixed period, see {@link jdk.jfr.internal.Rate}
>> 32:  */
>> 33: public sealed interface ParsedCPUThrottle {
> 
> This seems complicated. Why isn't possible to keep the Rate class as is (no renaming) and then only create a TimespanRate class and do something like this:
> 
>     public record TimespanRate(double rate) {
>     
>         public static TimespanRate of(String text) {
>            Rate r = Rate.of(text);
>            if (r != null) {
>               double rate = r.amount() * ...
>               return new TimespanRate(rate)
>            } else {
>               long v = ValueParser.parseTimespanWithInfinity(text);
>               double rate = v * ...
>               return new TimespanRate(rate);
>           }
>       }
>     
>       public boolean isHigher(TimespanRate that) {
>           return rate() > that.rate();
>       }
>     }

I can try to implement. I thought it would be easier to comprehend this way.

> test/jdk/jdk/jfr/event/profiling/TestCPUTimeEventThrottling.java line 76:
> 
>> 74: 
>> 75:     private static EventCount countEvents(int timeMs, String rate) throws Exception {
>> 76:         Recording recording = new Recording();
> 
> Use try-with-resources.

Fixed

> test/jdk/jdk/jfr/event/profiling/TestFullStackTrace.java line 44:
> 
>> 42:  * @requires vm.hasJFR
>> 43:  * @library /test/lib
>> 44:  * @run main/othervm jdk.jfr.event.profiling.TestFullStackTrace wall-clock
> 
> Create separate tests for CPU time sampling events. It makes them easier to problem list and disable for specific platforms. If you want to share verification code, create  helper class.

I created two test classes and moved almost all code to `BaseTestFullStackTrace`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2340862057
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416252945
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1752018869
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1806470258
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1812860292
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756672272

From jbechberger at openjdk.org  Tue Oct 29 11:00:24 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <_jN89X3QTfTGXTc-24lrU_v72Y-nNfO9Ljf3xj_VjSM=.96e04b54-1df8-49d0-a890-00ba45690e8d@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
 <KwXaIdSAe0kgo1b2wCsUNWwIlF4nQJ0OnO_AkeNilKE=.6aa16af1-151b-4048-b1e0-6eff77323ede@github.com>
 <LcVKzoC1-Ppj5NP_mrVqCKtfjy91H1HsQ6_w2xNW3JQ=.4f089ab1-b7a6-4957-8f04-b9a9302a43b6@github.com>
 <_jN89X3QTfTGXTc-24lrU_v72Y-nNfO9Ljf3xj_VjSM=.96e04b54-1df8-49d0-a890-00ba45690e8d@github.com>
Message-ID: <Mux-glrdbvR457ZJteGyG8weE-PbA8QRCCUExDqGWeI=.ace16af1-6a12-43b1-a9a7-aeed483d1085@github.com>

On Sat, 21 Sep 2024 12:44:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > The queue size is pre-computed to a large value that shouldn't lead to many dropped samples. I don't think that making the queue size settable is really useful. Please ignore, therefore, my mentioning of the queue size for throttling; the real throttling is by setting the interval. There is no other way that is also understandable by the user.
> 
> Recording files could be filled with CPU Time Sample events, flushing out important data, making the feature not usable for continuous profiling. We can't demand that users set a period every time they use JFR.

That is a valid point, so I see three options:

1. The event is experimental and mostly meant for profiling. So we might just ignore it, till we see any problems and don't fix problems before they arise.
2. We replace `period` with a `rate` property which states the maximum number of emitted CPUTimeSample events per second. We then use the rate to compute the interval internally as `period=(number of cores) / rate`. This alleviates the issues with having to set the interval every time to not get swamped by events. As an example, the standard rate in the profiling configuration could be `500 events/second` which produces at maximum the same number of events as the current JFR sampler (assuming >= 5 cores). This rate would result in a period of 10ms on a 5 core machine and 20ms on a 10 core machine. This effectively allows us to use the feature in continuous profiling.
3. Combine the period setting and the rate setting. We take the rate as the maximum rate, calculating the period as `period=max(user-period, (number of cores) / rate)`. This has the advantage of effectively having a similar as the current JFR sampler, by adding a lower bound for the interval.

Personally, I would the 3. option, because it should be least surprising to the users of the existing JFR sampler.
I would suggest calling the rate property `maxRate` and setting the following values in the configurations.

configuration | interval | maxRate
------------- | ------- | ---------
default.jfc      | 20ms   | 500 events/second
profile.jfc       | 10ms   | 1000  events/second

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2366897901

From egahlin at openjdk.org  Tue Oct 29 11:00:24 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <Mux-glrdbvR457ZJteGyG8weE-PbA8QRCCUExDqGWeI=.ace16af1-6a12-43b1-a9a7-aeed483d1085@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
 <KwXaIdSAe0kgo1b2wCsUNWwIlF4nQJ0OnO_AkeNilKE=.6aa16af1-151b-4048-b1e0-6eff77323ede@github.com>
 <LcVKzoC1-Ppj5NP_mrVqCKtfjy91H1HsQ6_w2xNW3JQ=.4f089ab1-b7a6-4957-8f04-b9a9302a43b6@github.com>
 <_jN89X3QTfTGXTc-24lrU_v72Y-nNfO9Ljf3xj_VjSM=.96e04b54-1df8-49d0-a890-00ba45690e8d@github.com>
 <Mux-glrdbvR457ZJteGyG8weE-PbA8QRCCUExDqGWeI=.ace16af1-6a12-43b1-a9a7-aeed483d1085@github.com>
Message-ID: <j7X9Bb5rCvjugWiPFOetS_zYeM8vfgij2p1ZrApI-D8=.f8b6a4d6-014f-48fa-8e86-1de2164c410e@github.com>

On Sun, 22 Sep 2024 18:05:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> > > The queue size is pre-computed to a large value that shouldn't lead to many dropped samples. I don't think that making the queue size settable is really useful. Please ignore, therefore, my mentioning of the queue size for throttling; the real throttling is by setting the interval. There is no other way that is also understandable by the user.
> > 
> > 
> > Recording files could be filled with CPU Time Sample events, flushing out important data, making the feature not usable for continuous profiling. We can't demand that users set a period every time they use JFR.
> 
> That is a valid point, so I see three options:
> 
> 1. The event is experimental and mostly meant for profiling. So we might just ignore it, till we see any problems and don't fix problems before they arise.
> 2. We replace `period` with a `rate` property which states the maximum number of emitted CPUTimeSample events per second. We then use the rate to compute the interval internally as `period=(number of cores) / rate`. This alleviates the issues with having to set the interval every time to not get swamped by events. As an example, the standard rate in the profiling configuration could be `500 events/second` which produces at maximum the same number of events as the current JFR sampler (assuming >= 5 cores). This rate would result in a period of 10ms on a 5 core machine and 20ms on a 10 core machine. This effectively allows us to use the feature in continuous profiling.
> 3. Combine the period setting and the rate setting. We take the rate as the maximum rate, calculating the period as `period=max(user-period, (number of cores) / rate)`. This has the advantage of effectively having a similar as the current JFR sampler, by adding a lower bound for the interval.
> 
> Personally, I would the 3. option, because it should be least surprising to the users of the existing JFR sampler. I would suggest calling the rate property `maxRate` and setting the following values in the configurations.
> 
> configuration	interval	maxRate
> default.jfc	20ms	500 events/second
> profile.jfc	10ms	1000 events/second

How does maxRate differs from today's "throttle" and why is an additional setting needed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2379682254

From egahlin at openjdk.org  Tue Oct 29 11:00:24 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
Message-ID: <QCSlQxCYizG0OF1PmzngKbq_kzojlX6Z5BMh21O_ryY=.c5c32e48-1622-4129-87d2-0b782adb05f8@github.com>

On Fri, 27 Sep 2024 17:04:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> The semantics are different, as `maxRate` is just upper bounding, while `throttle` is used to sub-sample (not using the throttle code under the hood), this is why I use a new name. Else I would have to check all over JFR which meaning `throttle` has for every event.

The throttle setting sets an upper bound, i.e 100 events / second, and then drops event.

Is the difference that you don't drop events? Otherwise, they seem similar.

Period on the other hand seems a bit off as this is specified in cpu time (i assume) and not wall-clock time. It could take seconds before an event with period 20 ms is emitted.

The period we have today for the ExecutionSample event is mostly legacy. When JFR was created, there were only four settings supported in the JMX API and the file format: enabled, threshold, period, and stackTrace.

> And how should I document the new behaviour? Add it to the documentation of the throttle annotation?

The throttle annotation is not a public API. I would add it to the description of the event.

> How should I treat the `off` setting? I disabled the rate setting for now because it doesn't make any sense when the period can be arbitrarily small. Of course, I could replace it with the smallest reasonable value of "1ms". Any opinions?

Hmm, not sure. For now, keep it disabled.

> The only place where the current throttle syntax is defined seems to be the throttle annotation.

Long term, the correct place is jdk/jfr/package-info.java, but we haven't done it for "throttle" because we are not sure how it will behave with other features in the pipeline.

> Ok, so is the following ok?
> 
> ```
> <Event name="CPUTimeSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Sample"
>     description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units."
>     period="everyChunk" throttle="true" experimental="true">
>     <Field type="Thread" name="sampledThread" label="Thread" />
>     <Field type="StackTrace" name="stackTrace" label="Stack Trace" />
>     <Field type="boolean" name="failed" label="Failed" description="Failed to obtain the stack trace" />
>     <Field type="Tickspan" name="sampleTime" label="CPU time sampling period for this event"/>
>   </Event>
> ```

Looks reasonable, but the label for cpuTime needs to be fixed. We try to avoid using the word "event" in labels, and it should be short and use headline-style capitalization ([Label javadoc](https://docs.oracle.com/en/java/javase/23/docs/api/jdk.jfr/jdk/jfr/Label.html)).

Maybe we should call the field samplingPeriod? Hmm, need to think about this.

I also wonder if we should use the event thread as sampledThread. The plan is to move over to cooperative sampling, so the event will be emitted in the thread that was sampled. This is also true for ExecutionSample. We may need to keep the field name for compatibility reasons for that event, or have both.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2379731752
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416769842
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416780937
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2416953141
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2419043811

From jbechberger at openjdk.org  Tue Oct 29 11:00:24 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <QCSlQxCYizG0OF1PmzngKbq_kzojlX6Z5BMh21O_ryY=.c5c32e48-1622-4129-87d2-0b782adb05f8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
 <QCSlQxCYizG0OF1PmzngKbq_kzojlX6Z5BMh21O_ryY=.c5c32e48-1622-4129-87d2-0b782adb05f8@github.com>
Message-ID: <2yHqlvC-qGCRAPidrKHo5ZGKjVR2SD4hYe-EhSXiIME=.c9ff1fc5-72ab-4311-b909-e511d1129370@github.com>

On Fri, 27 Sep 2024 17:16:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Is the difference that you don't drop events? Otherwise, they seem similar.

Yes. We cannot drop samples, else we have sampling bias.

We use the period because this is the only thing that we can properly set with a cpu-time sampler. So the period is just lower-bounded by something that we compute from the `maxRate`.

Should I instead use the `throttle` setting and just let the behaviour differ as explained before?

> Maybe we should call the field samplingPeriod? Hmm, need to think about this.

Sounds good.

> I also wonder if we should use the event thread as sampledThread. The plan is to move over to cooperative sampling, so the event will be emitted in the thread that was sampled. This is also true for ExecutionSample. We may need to keep the field name for compatibility reasons for that event, or have both.

I would keep the sampledThread different for the mentioned compatibility reasons. But duplicating the thread into the eventThread is probably best for the future when it will be different without much additional cost.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2380003980
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2419069480

From egahlin at openjdk.org  Tue Oct 29 11:00:24 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <2yHqlvC-qGCRAPidrKHo5ZGKjVR2SD4hYe-EhSXiIME=.c9ff1fc5-72ab-4311-b909-e511d1129370@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
 <QCSlQxCYizG0OF1PmzngKbq_kzojlX6Z5BMh21O_ryY=.c5c32e48-1622-4129-87d2-0b782adb05f8@github.com>
 <2yHqlvC-qGCRAPidrKHo5ZGKjVR2SD4hYe-EhSXiIME=.c9ff1fc5-72ab-4311-b909-e511d1129370@github.com>
Message-ID: <muOm0n4AEcb0aRAlLvqHPixeMRtPqsuJGZEQlcpQoEA=.29525b41-5572-4412-8722-b6daf8f85f8f@github.com>

On Thu, 17 Oct 2024 09:48:08 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> I would keep the sampledThread different for the mentioned compatibility reasons. But duplicating the thread into the eventThread is probably best for the future when it will be different without much additional cost.

What are the compatibility concerns here? The event is new, where will it not work?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2421931879

From jbechberger at openjdk.org  Tue Oct 29 11:00:24 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <t7tnIx1j2_QoOXbL3H0XZx3vFwryuMhxznrmuN4SiNA=.d8901c4a-8ccf-416f-9a94-83db04ba3db0@github.com>
Message-ID: <tEWh8GkUBwDeY9NFjMGOZ-xPmhNx_uAduPz7uyKOatQ=.c9cf397f-d753-4afc-ba09-36cf0bc96284@github.com>

On Tue, 10 Sep 2024 13:49:30 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 939:
>> 
>>> 937:   </Event>
>>> 938: 
>>> 939:   <Event name="CPUTimeExecutionSample" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Sample" description="Snapshot of a threads state from the CPU time sampler"
>> 
>> Maybe we should leave out "Execution" and only have CPUTimeSample?
>
> Sounds like a good idea, because it combines both `ExecutionSample` and `NativeMethodSample`.

I renamed it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756656680

From jbachorik at openjdk.org  Tue Oct 29 11:00:24 2024
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
Message-ID: <rciLkGVRYNc-OgRxdVv6yYM1v1YEjp8F-SQ3XgKPWFU=.c5d695f7-34fa-4332-8f1d-e4f83a405250@github.com>

On Wed, 4 Sep 2024 20:19:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> src/hotspot/share/jfr/metadata/metadata.xml line 945:
> 
>> 943:   </Event>
>> 944: 
>> 945:   <Event name="CPUTimeExecutionSampleThrottles" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Dropped Samples" description="Records that the CPU time dropped samples because of internal throttling"
> 
> A better name for this event is "CPUTimeExecutionSampleLoss".
> 
> This is because JFR already has a general concept of "DataLoss," so this name would better align with it. 
> 
> Please update references to "dropped" -> "lost"

Done

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 29:
> 
>> 27: 
>> 28: #include "jfr/utilities/jfrAllocation.hpp"
>> 29: #include "runtime/javaThread.hpp"
> 
> You don't need to include the "runtime/javaThread.hpp" header.
> 
> Instead, please hoist the forward declaration of "class JavaThread" to outside the "#if defined(LINUX)"

Done

> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp line 102:
> 
>> 100: }
>> 101: 
>> 102: JfrBuffer* JfrTraceIdLoadBarrier::renew_sampler_enqueue_buffer(Thread* thread, size_t size) {
> 
> JfrCPUTimeThreadSampler should not need to take this specialized path because it does not suspend threads. It can be left as is.

Just to clarify - you mean that when we do `JfrTraceIdLoadBarrier::get_sampler_enqueue_buffer(this)` in `jfrCPUTimeThreadSampler.cpp` it may not return `nullptr`?
Or the whole part of the new code using the `enqueue_buffer` is not needed?

> src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.hpp line 41:
> 
>> 39:  private:
>> 40:   bool _vthread;
>> 41:   const ContinuationEntry* _cont_entry;
> 
> You need a fwd declaration for ContinuationEntry here?

I think it will be pulled in by `vframe.hpp` - at least JDK builds successfully even without adding the fwd declaration.

> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 76:
> 
>> 74:   bool _dead;
>> 75:   LINUX_ONLY(bool _has_cpu_timer = false);
>> 76:   LINUX_ONLY(timer_t _cpu_timer);
> 
> No include for timer_t?

Added

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1750269452
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1750270486
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751832161
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751867711
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1752127434

From mgronlun at openjdk.org  Tue Oct 29 11:00:24 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
Message-ID: <m_iq27g2X0Ean7KZNM719B4MTIEsr8Veb0JcryIdEw8=.229ffa81-3ab2-473e-b928-6364094e2455@github.com>

On Thu, 12 Sep 2024 12:20:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 135:
>> 
>>> 133:   JfrTicks _start_time;
>>> 134:   JfrTicks _end_time;
>>> 135:   JavaThread* _sampled_thread;
>> 
>> You can store the thread's traceid (u8) here instead of the Thread* itself.
>> 
>> Then, later, you can skip using both JFRRecordSampledThreadCallback and crash protection.
>
> No, we can't. This crashes the sampler. The problem is, that obtaining the traceid via `JfrThreadLocal::thread_id(jt)` acquires a lock (and more) when the traceid is not set already. So we can't use it in the signal handler.

Hmm. That's not good. We could eliminate the spinlock, but that will require a thread assigning its id early in thread_state_new to prevent our old sampler from hitting it (and also the new one from skipping new threads). However, this is complex because it involves reading the tid from a Java oop, so we need to investigate if that is a valid thing to do, in those states. 

I have to think some more about this. Too bad you need to do this complexity.

>> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 35:
>> 
>>> 33: 
>>> 34: JfrAsyncStackFrame::JfrAsyncStackFrame(const Method* method, int bci, u1 type, int lineno, const InstanceKlass* ik) :
>>> 35:   _klass(ik), _method(method), _line(lineno), _bci(bci), _type(type) {}
>> 
>> Might be possible to delay processing of line numbers.
>
> As explained above: I think this would not be a good idea, as this would lead to additional load in the queue consuming thread, especially bad when the profiled systems has lots of cores.

I see your point better now. Makes sense to distribute the load.

>> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 99:
>> 
>>> 97:       type = JfrStackFrame::FRAME_INLINE;
>>> 98:     }
>>> 99:     _frames[count] = JfrAsyncStackFrame(method, bci, type, method->line_number_from_bci(bci), method->method_holder());
>> 
>> Calculating line number information is expensive. There is no need to do it for the sampled thread; it can be done by the thread registering the trace into the stack trace repository (it ejects an attempt to store a JfrStackTrace with no line number information).
>
> Why wouldn't we then do this in parallel in the sampled threads? Especially on systems with lot's of cores, this could otherwise be an issue and drastically increase the amount of dropped samples.

Makes sense.

>> test/jdk/jdk/jfr/event/profiling/TestMultipleRecordings.java line 1:
>> 
>>> 1: /*
>> 
>> What is the purpose of this test?
>
> Tests that restarting the sampler works.

It should be named something related to the CPU sampler, then. We already have many tests for starting multiple recordings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769533459
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769530925
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769530945
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1773038807

From apangin at openjdk.org  Tue Oct 29 11:00:24 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Tue, 29 Oct 2024 11:00:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <8xJfmHogb3GxCgJyTY-_8cjo636Fkl_QaCDZtqruwOk=.eefa150b-87f4-40f9-9e0a-040ffa4e5811@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 457:

> 455:   int64_t new_value = 0;
> 456:   if (throttle < 0) { // off
> 457:     new_value = period_millis;

Here `new_value` can be set to `-1` thus causing an invalid interval passed to `timer_settime` later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1783615298

From jbechberger at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <8xJfmHogb3GxCgJyTY-_8cjo636Fkl_QaCDZtqruwOk=.eefa150b-87f4-40f9-9e0a-040ffa4e5811@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <8xJfmHogb3GxCgJyTY-_8cjo636Fkl_QaCDZtqruwOk=.eefa150b-87f4-40f9-9e0a-040ffa4e5811@github.com>
Message-ID: <nco7qElivLpEjMs9oKanl7GAOSREHOtmIeq1Szh0Mbg=.cf892ceb-c59d-4827-81de-ef6d7b324479@github.com>

On Tue, 1 Oct 2024 22:43:11 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 457:
> 
>> 455:   int64_t new_value = 0;
>> 456:   if (throttle < 0) { // off
>> 457:     new_value = period_millis;
> 
> Here `new_value` can be set to `-1` thus causing an invalid interval passed to `timer_settime` later.

Good catch, fixed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1784308182

From mgronlun at openjdk.org  Tue Oct 29 11:00:25 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <rciLkGVRYNc-OgRxdVv6yYM1v1YEjp8F-SQ3XgKPWFU=.c5d695f7-34fa-4332-8f1d-e4f83a405250@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <rciLkGVRYNc-OgRxdVv6yYM1v1YEjp8F-SQ3XgKPWFU=.c5d695f7-34fa-4332-8f1d-e4f83a405250@github.com>
Message-ID: <qGUu90B6H6MsW68hUBJ4Ug7L5-0WURDA-eJV858_wxk=.3b1ae138-d762-4f78-a1c3-50f4887892bc@github.com>

On Tue, 10 Sep 2024 12:13:15 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.cpp line 102:
>> 
>>> 100: }
>>> 101: 
>>> 102: JfrBuffer* JfrTraceIdLoadBarrier::renew_sampler_enqueue_buffer(Thread* thread, size_t size) {
>> 
>> JfrCPUTimeThreadSampler should not need to take this specialized path because it does not suspend threads. It can be left as is.
>
> Just to clarify - you mean that when we do `JfrTraceIdLoadBarrier::get_sampler_enqueue_buffer(this)` in `jfrCPUTimeThreadSampler.cpp` it may not return `nullptr`?
> Or the whole part of the new code using the `enqueue_buffer` is not needed?

The whole part of calling this special, preemptive handling of an enqueue buffer is only because the JfrSamplerThread will suspend another thread (whiich might hold the malloc lock). Since this approach does not suspend threads, it can be removed. This thread will never tag while it has another thread suspended.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751866247

From jbechberger at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <qGUu90B6H6MsW68hUBJ4Ug7L5-0WURDA-eJV858_wxk=.3b1ae138-d762-4f78-a1c3-50f4887892bc@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <rciLkGVRYNc-OgRxdVv6yYM1v1YEjp8F-SQ3XgKPWFU=.c5d695f7-34fa-4332-8f1d-e4f83a405250@github.com>
 <qGUu90B6H6MsW68hUBJ4Ug7L5-0WURDA-eJV858_wxk=.3b1ae138-d762-4f78-a1c3-50f4887892bc@github.com>
Message-ID: <XLXSr71S1xZlvV0KHTZK8xrXWLRVCgyl62GkhwJALRY=.2a01f783-dadb-40b5-8a46-e5c06fd7c2e3@github.com>

On Tue, 10 Sep 2024 12:35:21 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Just to clarify - you mean that when we do `JfrTraceIdLoadBarrier::get_sampler_enqueue_buffer(this)` in `jfrCPUTimeThreadSampler.cpp` it may not return `nullptr`?
>> Or the whole part of the new code using the `enqueue_buffer` is not needed?
>
> The whole part of calling this special, preemptive handling of an enqueue buffer is only because the JfrSamplerThread will suspend another thread (whiich might hold the malloc lock). Since this approach does not suspend threads, it can be removed. This thread will never tag while it has another thread suspended.

I removed all the checking of the buffer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756567025

From jbechberger at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
Message-ID: <W_vzZXaorjzoeQyZYnjDwlDcUMQ1jb_snPzrQugP3MU=.556d81c2-7bf2-47e9-9bf4-fa29d5e03a8e@github.com>

On Thu, 17 Oct 2024 10:44:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp line 92:
>> 
>>> 90:   auto holder = method->method_holder();
>>> 91:   auto res = load(holder, method);
>>> 92:   return res;
>> 
>> Why this change?
>
> Good catch, I'll remove it

I'll be cleaning up the changes tomorrow, I found two more.

>> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 126:
>> 
>>> 124:   for (u4 i = 0; i < _nr_of_frames; i++) {
>>> 125:     const JfrAsyncStackFrame& frame = _frames[i];
>>> 126:     if (!Method::is_valid_method(frame._method) || is_full(enqueue_buffer)) {
>> 
>> We should try to remove is_full(enqueue_buffer)).
>
> This code is similar to the code in the old sampler and ensures that the buffer is large enough.

I removed the code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1804541399
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756647218

From jbechberger at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <jTyu9ymX-Mxtw_WzJ0ZKHg4691E50_dmsY1nIsOipbI=.9e23c16d-012a-422e-98a4-cc1ab77230f3@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
 <jTyu9ymX-Mxtw_WzJ0ZKHg4691E50_dmsY1nIsOipbI=.9e23c16d-012a-422e-98a4-cc1ab77230f3@github.com>
Message-ID: <QZ7cA8xd8vsq6f81AlTc2R96J1EhxTNBCil6jwrNtPk=.68949e6e-459a-4105-839e-1d731849bebc@github.com>

On Tue, 10 Sep 2024 12:54:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 404:
>> 
>>> 402: 
>>> 403: [application.cpu-time-hot-methods]
>>> 404: label = "Java Methods that Executes the Most from CPU time sampler"
>> 
>> Use headline-style capitalization, capitalize the first and last words, and all nouns, pronouns, adjectives, verbs and adverbs.
>
> Include Experimental in the title

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1756650061

From egahlin at openjdk.org  Tue Oct 29 11:00:25 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <i65qqsmJu_GxTMKfNPNAL8cLlg1am32qYJyFFxkbztQ=.a60b2803-424e-4241-b2cd-378ad3c3aa06@github.com>
Message-ID: <jTyu9ymX-Mxtw_WzJ0ZKHg4691E50_dmsY1nIsOipbI=.9e23c16d-012a-422e-98a4-cc1ab77230f3@github.com>

On Tue, 10 Sep 2024 12:54:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 404:
> 
>> 402: 
>> 403: [application.cpu-time-hot-methods]
>> 404: label = "Java Methods that Executes the Most from CPU time sampler"
> 
> Use headline-style capitalization, capitalize the first and last words, and all nouns, pronouns, adjectives, verbs and adverbs.

Include Experimental in the title

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751895673

From egahlin at openjdk.org  Tue Oct 29 11:00:25 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
Message-ID: <2YV6zXlpF__WVt0dg6tT3ZwrTmDtB0n4-4wq8ugGrcM=.046852d6-232c-4caa-984a-4586ee17ca63@github.com>

On Wed, 4 Sep 2024 21:10:56 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 419:
> 
>> 417: 
>> 418: [application.cpu-time-overflowed-samples]
>> 419: label = "CPU Time Samples not recorded because of internal throttling"
> 
> Align rename for CPUTimeSampleLoss

Why are events with stack trace = null emitted? Isn't CPUTimeExecutionSampleLoss sufficient?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1751960662

From jbechberger at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <2YV6zXlpF__WVt0dg6tT3ZwrTmDtB0n4-4wq8ugGrcM=.046852d6-232c-4caa-984a-4586ee17ca63@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <2YV6zXlpF__WVt0dg6tT3ZwrTmDtB0n4-4wq8ugGrcM=.046852d6-232c-4caa-984a-4586ee17ca63@github.com>
Message-ID: <FJpUylT2o98X4znxWwn9ui1vKh7-oP-uF5Zyi4eV2E4=.1b32d088-35ec-43b3-84c0-d8be757beff5@github.com>

On Tue, 10 Sep 2024 13:24:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/query/view.ini line 419:
>> 
>>> 417: 
>>> 418: [application.cpu-time-overflowed-samples]
>>> 419: label = "CPU Time Samples not recorded because of internal throttling"
>> 
>> Align rename for CPUTimeSampleLoss
>
> Why are events with stack trace = null emitted? Isn't CPUTimeExecutionSampleLoss sufficient?

This happens when the JVM is unable to walk a specific stack trace, but the queues are not full, and when the JVM is unable to resolve `Method` pointers.

The main idea behind it is that we still record that the thread runs on the CPU at this point in time; we just don't have any proper information on the stack trace. Only knowing that a thread run is still valuable information.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1752025272

From egahlin at openjdk.org  Tue Oct 29 11:00:25 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <kFBIJCmNS8aZ0K3qZOOAGbQ-7Bu5MphID4GWRoKZY-4=.17470add-e6dc-4210-9f7c-8733eef78ed6@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <2YV6zXlpF__WVt0dg6tT3ZwrTmDtB0n4-4wq8ugGrcM=.046852d6-232c-4caa-984a-4586ee17ca63@github.com>
 <FJpUylT2o98X4znxWwn9ui1vKh7-oP-uF5Zyi4eV2E4=.1b32d088-35ec-43b3-84c0-d8be757beff5@github.com>
 <kFBIJCmNS8aZ0K3qZOOAGbQ-7Bu5MphID4GWRoKZY-4=.17470add-e6dc-4210-9f7c-8733eef78ed6@github.com>
Message-ID: <aLTB9w5vvXVb8b4BTgFZJ2S84y8xCWTUF2Sh4GLqMQc=.d425e6f0-4757-4b83-89b3-bdaf38e72561@github.com>

On Tue, 10 Sep 2024 14:57:22 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> This happens when the JVM is unable to walk a specific stack trace, but the queues are not full, and when the JVM is unable to resolve `Method` pointers.
>> 
>> The main idea behind it is that we still record that the thread runs on the CPU at this point in time; we just don't have any proper information on the stack trace. Only knowing that a thread run is still valuable information.
>
> Indeed. This is important for getting the correct distribution. Since we are sampling per thread cpu time, having one global 'event loss' is suboptimal as it is not possible to easily assign the lost events to threads proportionally.
> But because keeping the event loss per thread would be too expensive we settled for this solution. OTOH, for unwalkable samples we can 'cheaply' record them and maintain the distribution.

Could we add a field, i.e. "failed" and "Failed Stack Walk", to indicate failure instead of using null, which could be because stack trace has been disabled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769540699

From jbachorik at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <FJpUylT2o98X4znxWwn9ui1vKh7-oP-uF5Zyi4eV2E4=.1b32d088-35ec-43b3-84c0-d8be757beff5@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <2YV6zXlpF__WVt0dg6tT3ZwrTmDtB0n4-4wq8ugGrcM=.046852d6-232c-4caa-984a-4586ee17ca63@github.com>
 <FJpUylT2o98X4znxWwn9ui1vKh7-oP-uF5Zyi4eV2E4=.1b32d088-35ec-43b3-84c0-d8be757beff5@github.com>
Message-ID: <kFBIJCmNS8aZ0K3qZOOAGbQ-7Bu5MphID4GWRoKZY-4=.17470add-e6dc-4210-9f7c-8733eef78ed6@github.com>

On Tue, 10 Sep 2024 13:52:45 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Why are events with stack trace = null emitted? Isn't CPUTimeExecutionSampleLoss sufficient?
>
> This happens when the JVM is unable to walk a specific stack trace, but the queues are not full, and when the JVM is unable to resolve `Method` pointers.
> 
> The main idea behind it is that we still record that the thread runs on the CPU at this point in time; we just don't have any proper information on the stack trace. Only knowing that a thread run is still valuable information.

Indeed. This is important for getting the correct distribution. Since we are sampling per thread cpu time, having one global 'event loss' is suboptimal as it is not possible to easily assign the lost events to threads proportionally.
But because keeping the event loss per thread would be too expensive we settled for this solution. OTOH, for unwalkable samples we can 'cheaply' record them and maintain the distribution.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1752151261

From jbechberger at openjdk.org  Tue Oct 29 11:00:25 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:25 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <aLTB9w5vvXVb8b4BTgFZJ2S84y8xCWTUF2Sh4GLqMQc=.d425e6f0-4757-4b83-89b3-bdaf38e72561@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <2YV6zXlpF__WVt0dg6tT3ZwrTmDtB0n4-4wq8ugGrcM=.046852d6-232c-4caa-984a-4586ee17ca63@github.com>
 <FJpUylT2o98X4znxWwn9ui1vKh7-oP-uF5Zyi4eV2E4=.1b32d088-35ec-43b3-84c0-d8be757beff5@github.com>
 <kFBIJCmNS8aZ0K3qZOOAGbQ-7Bu5MphID4GWRoKZY-4=.17470add-e6dc-4210-9f7c-8733eef78ed6@github.com>
 <aLTB9w5vvXVb8b4BTgFZJ2S84y8xCWTUF2Sh4GLqMQc=.d425e6f0-4757-4b83-89b3-bdaf38e72561@github.com>
Message-ID: <C6stTIW6EhJVK7BWbjLAuWfRmaasKaptNoI6q2IlIwA=.ae71026d-020c-4dc4-aa52-30437b0b9518@github.com>

On Sat, 21 Sep 2024 11:30:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Indeed. This is important for getting the correct distribution. Since we are sampling per thread cpu time, having one global 'event loss' is suboptimal as it is not possible to easily assign the lost events to threads proportionally.
>> But because keeping the event loss per thread would be too expensive we settled for this solution. OTOH, for unwalkable samples we can 'cheaply' record them and maintain the distribution.
>
> Could we add a field, i.e. "failed" and "Failed Stack Walk", to indicate failure instead of using null, which could be because stack trace has been disabled.

That's a good idea. So a failed sample would have `failed=true,stackTrace=null`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1769548474

From jbechberger at openjdk.org  Tue Oct 29 11:00:26 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 11:00:26 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <m_iq27g2X0Ean7KZNM719B4MTIEsr8Veb0JcryIdEw8=.229ffa81-3ab2-473e-b928-6364094e2455@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
 <m_iq27g2X0Ean7KZNM719B4MTIEsr8Veb0JcryIdEw8=.229ffa81-3ab2-473e-b928-6364094e2455@github.com>
Message-ID: <eiKyr6LLkeBy5xtPaTEcpkvDNeNcQ4P9y3VRER9zCqo=.bb06100c-d350-44d1-bb44-433ae5876bc8@github.com>

On Tue, 24 Sep 2024 09:59:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Tests that restarting the sampler works.
>
> It should be named something related to the CPU sampler, then. We already have many tests for starting multiple recordings.

I removed it, as I split the test in two and `TestCPUTimeMultipleRecordings.java` therefore already exists.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1773446969

From mgronlun at openjdk.org  Tue Oct 29 11:13:20 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 11:13:20 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <m_iq27g2X0Ean7KZNM719B4MTIEsr8Veb0JcryIdEw8=.229ffa81-3ab2-473e-b928-6364094e2455@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
 <m_iq27g2X0Ean7KZNM719B4MTIEsr8Veb0JcryIdEw8=.229ffa81-3ab2-473e-b928-6364094e2455@github.com>
Message-ID: <NmIFfq_J6_ThxZJt9hMQuNuTRuM1nxLeKniRdTYJPkA=.2445c862-57a3-43ab-b5ee-154c39a36e82@github.com>

On Sat, 21 Sep 2024 11:02:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> No, we can't. This crashes the sampler. The problem is, that obtaining the traceid via `JfrThreadLocal::thread_id(jt)` acquires a lock (and more) when the traceid is not set already. So we can't use it in the signal handler.
>
> Hmm. That's not good. We could eliminate the spinlock, but that will require a thread assigning its id early in thread_state_new to prevent our old sampler from hitting it (and also the new one from skipping new threads). However, this is complex because it involves reading the tid from a Java oop, so we need to investigate if that is a valid thing to do, in those states. 
> 
> I have to think some more about this. Too bad you need to do this complexity.

I have created this to help reduce the amount of crash protection you need to use: https://github.com/openjdk/jdk/pull/21756

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1820595550

From mgronlun at openjdk.org  Tue Oct 29 11:16:16 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 11:16:16 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
Message-ID: <nuA3LBLO4IeEhkQ7TJtkXsStK246LEqxg5TIyQoEfLg=.ebe41af1-4293-430e-b6f0-c63451521332@github.com>

On Tue, 29 Oct 2024 10:56:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Regarding the field `samplingPeriod`: @apangin mentioned in a recent meeting that naming it `cpuTime` and storing the thread's CPU time at the point of sampling would be better, giving us more flexibility. Not only does it convey more information, but it also allows profiler writers to merge adjacent traces if they are similar, making it possible to store the traces in a more compact format without breaking the API.

Counterargument is that this might confuse in that it is not the 'cpuTime' duration of the method represented by the sample, which is something we are looking to introduce with dynamic instrumentation, not sampling.

We want to be clear that this is the samplingTime attributed, not the cpuTime for the sampled method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2443925556

From bulasevich at openjdk.org  Tue Oct 29 11:59:10 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 29 Oct 2024 11:59:10 GMT
Subject: RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment
 for ARM [v3]
In-Reply-To: <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
 <mUB9SrHWBjdt0_khgIHF2YGmlbDxFdhEplZmdLS2gw8=.894ebe4b-9e5e-43aa-a777-be4d545792bb@github.com>
Message-ID: <DoAsX54IbwwSqlDbS9GywTolD-2Do2y_SbVKWzeqjHA=.5c6d2c7d-426f-49d7-8fc5-3662b41a483c@github.com>

On Mon, 7 Oct 2024 13:21:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> With this change, I have adjusted the default settings for CodeCacheSegmentSize and CodeEntryAlignment for AARCH and ARM32. The main goal is to improve code density by reducing the number of wasted bytes (approximately **4%** waste). Improving code density may also have the side effect of boosting performance in large applications
>> 
>> Each nmethod occupies a number of code cache segments (minimum allocation blocks). Since the size of an nmethod is not aligned to 128 bytes, the last occupied segment is half empty. Reducing the size of the code cache segments correspondingly minimizes waste. However, we should be careful about reducing the CodeCacheSegmentSize too much, as smaller segment sizes will increase the overhead of the CodeHeap::_segmap bitmap. A CodeCacheSegmentSize of 64 seems to be an optimal balance.
>> 
>> The current large default value for CodeCacheSegmentSize (64+64) was historically introduced with the comment "Tiered compilation has large code-entry alignment" which doesn't make much sense to me. The history of this comment and value is as follows:
>> - The PPC port was introduced with CodeEntryAlignment=128 (recently reduced to 64: https://github.com/openjdk/jdk/commit/09a78b5d) and CodeCacheSegmentSize was adjusted accordingly for that platform.
>> - Soon after, the 128-byte alignment was applied to all platforms to hide a debug mode warning (https://github.com/openjdk/jdk/commit/e8bc971d). Despite the change (and Segmented Code Cache introduced later), the warning can still be reproduced today using the -XX:+VerifyCodeCache fastdebug option in large applications (10K nmethods ~ 10K free blocks in between them).
>> 
>> I believe it is time to remove the comment and update the default value.
>> 
>> I also suggest updating the default CodeEntryAlignment value for AARCH. The current setting is much larger than for x86 and was likely based on the typical cache line size of 64 bytes. Cortex-A57, A72 architecture software optimisation guides recommend a 32-byte alignment for subroutine entry points. Neoverse architecture software optimisation guides do not mention recommended entry point alignment.
>> 
>> For reference, the default [function_align setting in GCC](https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/cortexa72.h#L44) is typically 16 or 32 bytes, depending on the target architecture.
>> 
>> Hotspot performance tests with -XX:CodeCacheSegmentSize=64 and -XX:CodeEntryAlignment=16 options showed the following result...
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax CodeEntryAlignment. Default value is now 32B for Neoverse V1/V2, as recommended in the Optimization Guide.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20864#issuecomment-2444008175

From bulasevich at openjdk.org  Tue Oct 29 12:05:12 2024
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Tue, 29 Oct 2024 12:05:12 GMT
Subject: Integrated: 8339573: Update CodeCacheSegmentSize and
 CodeEntryAlignment for ARM
In-Reply-To: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
References: <2eVsVNQ1NsUA6GGcaztqwCs86hu4mh1XTbJUEQH9Its=.41837726-4bbf-44c2-9f7c-724ef656419a@github.com>
Message-ID: <fSGNdFwjCnyDTCK03vejr4S4oSMe1oFWfsdrrChpAns=.67245694-5e34-4034-87df-5c970d31f084@github.com>

On Thu, 5 Sep 2024 00:58:10 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> With this change, I have adjusted the default settings for CodeCacheSegmentSize and CodeEntryAlignment for AARCH and ARM32. The main goal is to improve code density by reducing the number of wasted bytes (approximately **4%** waste). Improving code density may also have the side effect of boosting performance in large applications
> 
> Each nmethod occupies a number of code cache segments (minimum allocation blocks). Since the size of an nmethod is not aligned to 128 bytes, the last occupied segment is half empty. Reducing the size of the code cache segments correspondingly minimizes waste. However, we should be careful about reducing the CodeCacheSegmentSize too much, as smaller segment sizes will increase the overhead of the CodeHeap::_segmap bitmap. A CodeCacheSegmentSize of 64 seems to be an optimal balance.
> 
> The current large default value for CodeCacheSegmentSize (64+64) was historically introduced with the comment "Tiered compilation has large code-entry alignment" which doesn't make much sense to me. The history of this comment and value is as follows:
> - The PPC port was introduced with CodeEntryAlignment=128 (recently reduced to 64: https://github.com/openjdk/jdk/commit/09a78b5d) and CodeCacheSegmentSize was adjusted accordingly for that platform.
> - Soon after, the 128-byte alignment was applied to all platforms to hide a debug mode warning (https://github.com/openjdk/jdk/commit/e8bc971d). Despite the change (and Segmented Code Cache introduced later), the warning can still be reproduced today using the -XX:+VerifyCodeCache fastdebug option in large applications (10K nmethods ~ 10K free blocks in between them).
> 
> I believe it is time to remove the comment and update the default value.
> 
> I also suggest updating the default CodeEntryAlignment value for AARCH. The current setting is much larger than for x86 and was likely based on the typical cache line size of 64 bytes. Cortex-A57, A72 architecture software optimisation guides recommend a 32-byte alignment for subroutine entry points. Neoverse architecture software optimisation guides do not mention recommended entry point alignment.
> 
> For reference, the default [function_align setting in GCC](https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/tuning_models/cortexa72.h#L44) is typically 16 or 32 bytes, depending on the target architecture.
> 
> Hotspot performance tests with -XX:CodeCacheSegmentSize=64 and -XX:CodeEntryAlignment=16 options showed the following results:
> - No performance impact on ...

This pull request has now been integrated.

Changeset: d8430efb
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8430efb5e159b8e08d2cac66b46cb4ff1112927
Stats:     5 lines in 3 files changed: 3 ins; 0 del; 2 mod

8339573: Update CodeCacheSegmentSize and CodeEntryAlignment for ARM

Reviewed-by: kvn, eastigeevich

-------------

PR: https://git.openjdk.org/jdk/pull/20864

From fyang at openjdk.org  Tue Oct 29 12:16:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 29 Oct 2024 12:16:08 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v10]
In-Reply-To: <kZgfhrFPOmp4q4urH__AgNWpnkQCzdaU75vGwFaehec=.78a55319-0c5a-4b63-b0d2-36b1721a609f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
 <CNQUc31lweSYNs2QsNuWqMavcG4mD5QozXd0FGDIoU4=.36893484-4130-446b-9b54-8128831c8a3e@github.com>
 <kZgfhrFPOmp4q4urH__AgNWpnkQCzdaU75vGwFaehec=.78a55319-0c5a-4b63-b0d2-36b1721a609f@github.com>
Message-ID: <6fJZ5wVxtfeoOsRVmKwBqRpy9gJJkOSrGLmHHGHUh1g=.76401a18-9433-4d2d-bc11-fca081abadc5@github.com>

On Mon, 28 Oct 2024 20:49:18 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2283:
>> 
>>> 2281:     for (int i = 0; i < rounds; i++) {
>>> 2282:       __ vle32_v(working_vregs[i], key);
>>> 2283:       __ vrev8_v(working_vregs[i], working_vregs[i]);
>> 
>> What's is this `vrev8_v` for? I wonder how this maps to the code-samples at [1]. Might deserve a code comment here. 
>> 
>> [1] https://github.com/riscv/riscv-crypto/blob/main/doc/vector/code-samples/zvkned.s
>
> I'm not very familiar with OpenSSL but I guess it is just uses different endianness when storing the result :shrug:  (compared to [big-endian](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.11) JVM). I'll left the note on it in the code

Hmm ... I didn't find a direct evidence about the endianness of the key required here. Was is documented anywhere? I prefer to add some more details in the code comment to make it more readable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1820683443

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 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 jbechberger at openjdk.org  Tue Oct 29 12:51:19 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 12:51:19 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <nuA3LBLO4IeEhkQ7TJtkXsStK246LEqxg5TIyQoEfLg=.ebe41af1-4293-430e-b6f0-c63451521332@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
 <nuA3LBLO4IeEhkQ7TJtkXsStK246LEqxg5TIyQoEfLg=.ebe41af1-4293-430e-b6f0-c63451521332@github.com>
Message-ID: <nj44Rb-mIsEMOsZCJGFyRw3N-aL0QioLF2BKlyNktns=.4017ba5f-e1b9-473a-a3e6-d156f099146b@github.com>

On Tue, 29 Oct 2024 11:13:41 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> which is something we are looking to introduce with dynamic instrumentation, not sampling.

Why not with sampling? We could even default to the sampling period and have the meaning that you described.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2444114364

From jbechberger at openjdk.org  Tue Oct 29 12:51:21 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 12:51:21 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <NmIFfq_J6_ThxZJt9hMQuNuTRuM1nxLeKniRdTYJPkA=.2445c862-57a3-43ab-b5ee-154c39a36e82@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <9_aERjvrDvDRmTtRX7F6KmUFb8vyLspr2fZ3YG8hlfQ=.ff9a4357-cd18-455a-b3c4-3a67382b116a@github.com>
 <9fvdL9a7ihE3A328_W4ZQnAoyzYjSInf-fRvr5PAG6Y=.f73aec33-386a-4cca-89e1-a5c4d20eb192@github.com>
 <m_iq27g2X0Ean7KZNM719B4MTIEsr8Veb0JcryIdEw8=.229ffa81-3ab2-473e-b928-6364094e2455@github.com>
 <NmIFfq_J6_ThxZJt9hMQuNuTRuM1nxLeKniRdTYJPkA=.2445c862-57a3-43ab-b5ee-154c39a36e82@github.com>
Message-ID: <PMfkGRHIbwFf8dbxpBg8ISw-W6qbAlk8WvL6w1DD8xI=.760fc469-3dde-4aeb-a775-21921bee5e1a@github.com>

On Tue, 29 Oct 2024 11:10:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Hmm. That's not good. We could eliminate the spinlock, but that will require a thread assigning its id early in thread_state_new to prevent our old sampler from hitting it (and also the new one from skipping new threads). However, this is complex because it involves reading the tid from a Java oop, so we need to investigate if that is a valid thing to do, in those states. 
>> 
>> I have to think some more about this. Too bad you need to do this complexity.
>
> I have created this to help reduce the amount of crash protection you need to use: https://github.com/openjdk/jdk/pull/21756

I'm happy to use this in the PR once it is merged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1820730402

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 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 egahlin at openjdk.org  Tue Oct 29 13:31:18 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 13:31:18 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <8zK1yBm4n1Z0eQkQ94_Nqhy625uCJJfj5HC95YHHLY8=.b0143dd9-11a8-4fdd-a708-84609ff3afbb@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRate.java line 41:

> 39:         boolean isPeriod = !text.contains("/");
> 40:         if (isPeriod) {
> 41:             var period = ValueParser.parseTimespanWithInfinity(text);

I think it would be good if the TimespanRate::of(String) method returns null if the value is not valid and let the CPUThrottleSetting deal with interpretation of an unparsable value.


var period = ValueParser.parseTimespanWithInfinity(text, Long.MAX_VALUE);
if (period == Long.MAX_VALUE) {
  return null;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1820800993

From mgronlun at openjdk.org  Tue Oct 29 13:40:13 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 13:40:13 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <nj44Rb-mIsEMOsZCJGFyRw3N-aL0QioLF2BKlyNktns=.4017ba5f-e1b9-473a-a3e6-d156f099146b@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
 <nuA3LBLO4IeEhkQ7TJtkXsStK246LEqxg5TIyQoEfLg=.ebe41af1-4293-430e-b6f0-c63451521332@github.com>
 <nj44Rb-mIsEMOsZCJGFyRw3N-aL0QioLF2BKlyNktns=.4017ba5f-e1b9-473a-a3e6-d156f099146b@github.com>
Message-ID: <CGOySqUjdY5Cny6LEC9ToeTP3miTZzKcyFHD1RvcFxM=.dfad67c1-74c6-45f2-acc1-e73204a19002@github.com>

On Tue, 29 Oct 2024 12:45:59 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> > which is something we are looking to introduce with dynamic instrumentation, not sampling.
> 
> Why not with sampling? We could even default to the sampling period and have the meaning that you described.

Thats why samplingPeriod is better. Remember, this is Linux only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2444259910

From egahlin at openjdk.org  Tue Oct 29 13:40:14 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 29 Oct 2024 13:40:14 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <6X8Dm36AoVunOUy6kXv7LIdH3lLWFQyroPZL5d_1t-A=.ea1ef36e-d108-4244-a28b-1346a88708ae@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java line 92:

> 90:     // Experimental events
> 91:     private static final Set<String> experimentalEvents = Set.of(
> 92:         "Flush", "SyncOnValueBasedClass", "CPUTimeSample", "CPUTimeSampleLoss");

I think the reason we added an exclusion list for experimental events is so developers wouldn't be forced to write a test. Since you have a test for CPUTimeSample event, I think you can remove it.

(If TestLookForUntestedEvents is not able to find the event test, write the event name in the test)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1820812002

From jbechberger at openjdk.org  Tue Oct 29 13:43:18 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 13:43:18 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <CGOySqUjdY5Cny6LEC9ToeTP3miTZzKcyFHD1RvcFxM=.dfad67c1-74c6-45f2-acc1-e73204a19002@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
 <nuA3LBLO4IeEhkQ7TJtkXsStK246LEqxg5TIyQoEfLg=.ebe41af1-4293-430e-b6f0-c63451521332@github.com>
 <nj44Rb-mIsEMOsZCJGFyRw3N-aL0QioLF2BKlyNktns=.4017ba5f-e1b9-473a-a3e6-d156f099146b@github.com>
 <CGOySqUjdY5Cny6LEC9ToeTP3miTZzKcyFHD1RvcFxM=.dfad67c1-74c6-45f2-acc1-e73204a19002@github.com>
Message-ID: <GxMNgJt4QXE_mygQ2_SsgfLyHCdLC1ZrKtLBZLXwn0k=.7a1cdb6a-d418-4026-a9bc-45d17901fa95@github.com>

On Tue, 29 Oct 2024 13:37:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Thats why samplingPeriod is better. Remember, this is Linux only.

I'm happy to agree to disagree. `cpuTime` would give us more flexibility and would restrain us less in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2444266313

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 phh at openjdk.org  Tue Oct 29 14:08:09 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 29 Oct 2024 14:08:09 GMT
Subject: RFR: 8343167: Unnecessary define checks in InterpreterRuntime
 after JDK-8199809
In-Reply-To: <m-4wfZWepMB6oXnGXWgh-OVCX6l5QSNU-kLsK63XbVc=.9629f202-bd5b-4b07-aa86-3338ecf548ef@github.com>
References: <m-4wfZWepMB6oXnGXWgh-OVCX6l5QSNU-kLsK63XbVc=.9629f202-bd5b-4b07-aa86-3338ecf548ef@github.com>
Message-ID: <fsvnHVWtoSZVaBEdaWD3k8W6pxb20AHKK9amexWOKsQ=.72354356-a0a4-456b-a522-afcc4e6cacc9@github.com>

On Mon, 28 Oct 2024 19:36:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `make bootcycle-images`
>  - [x] Linux x86_32 server fastdebug, `make bootcycle-images`
>  - [x] GHA

Lgtm, and trivial.

-------------

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21747#pullrequestreview-2402021873

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 mgronlun at openjdk.org  Tue Oct 29 14:23:23 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Oct 2024 14:23:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <GxMNgJt4QXE_mygQ2_SsgfLyHCdLC1ZrKtLBZLXwn0k=.7a1cdb6a-d418-4026-a9bc-45d17901fa95@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <eSiusDwQiTGX0z90cOrJBfdAIOeAseNFTFL_0uuVc44=.7c3a5ea9-86a4-4a0a-b067-16b5208e12eb@github.com>
 <nuA3LBLO4IeEhkQ7TJtkXsStK246LEqxg5TIyQoEfLg=.ebe41af1-4293-430e-b6f0-c63451521332@github.com>
 <nj44Rb-mIsEMOsZCJGFyRw3N-aL0QioLF2BKlyNktns=.4017ba5f-e1b9-473a-a3e6-d156f099146b@github.com>
 <CGOySqUjdY5Cny6LEC9ToeTP3miTZzKcyFHD1RvcFxM=.dfad67c1-74c6-45f2-acc1-e73204a19002@github.com>
 <GxMNgJt4QXE_mygQ2_SsgfLyHCdLC1ZrKtLBZLXwn0k=.7a1cdb6a-d418-4026-a9bc-45d17901fa95@github.com>
Message-ID: <p2EPir2LjUUdW7nvGpqi567iNfAoXC5yh7_70YYh3Jw=.feb94ffb-3708-4a7a-858c-6732489fbb4f@github.com>

On Tue, 29 Oct 2024 13:40:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> > Thats why samplingPeriod is better. Remember, this is Linux only.
> 
> I'm happy to agree to disagree. `cpuTime` would give us more flexibility and would restrain us less in the future

The reason is that cpuTime has "broader plans" than this little experiment. We don't want to mix the two concepts if we already know they will not refer to the same thing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2444413006

From jbechberger at openjdk.org  Tue Oct 29 14:28:18 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 29 Oct 2024 14:28:18 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <tG_YzSh78xCfPQd4MdWQtJGv-8X6l2f8J5-vETmyXIM=.8e730121-3580-4851-aee4-6d8b7c9aa660@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Ok, sure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2444426730

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: <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 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: <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 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 shade at openjdk.org  Tue Oct 29 14:50:07 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 14:50:07 GMT
Subject: RFR: 8343167: Unnecessary define checks in InterpreterRuntime
 after JDK-8199809
In-Reply-To: <m-4wfZWepMB6oXnGXWgh-OVCX6l5QSNU-kLsK63XbVc=.9629f202-bd5b-4b07-aa86-3338ecf548ef@github.com>
References: <m-4wfZWepMB6oXnGXWgh-OVCX6l5QSNU-kLsK63XbVc=.9629f202-bd5b-4b07-aa86-3338ecf548ef@github.com>
Message-ID: <i-7EDWPw9oekSZphXz0NnnuepM0u-X8zMslAkfTCtao=.2fd7b9de-b776-45c7-a207-803f6b6c5703@github.com>

On Mon, 28 Oct 2024 19:36:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `make bootcycle-images`
>  - [x] Linux x86_32 server fastdebug, `make bootcycle-images`
>  - [x] GHA

@coleenp -- take a look? This was the leftover from your earlier refactoring, I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21747#issuecomment-2444487251

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 duke at openjdk.org  Tue Oct 29 15:15:17 2024
From: duke at openjdk.org (duke)
Date: Tue, 29 Oct 2024 15:15:17 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v8]
In-Reply-To: <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
Message-ID: <wIEUk-jMnirJjVj6NqRr6ybVMj513CUF-BY6B2KylZg=.8eba803e-ea0a-49d8-9cda-a2c78a0ff07c@github.com>

On Fri, 25 Oct 2024 14:16:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

@ferakocz 
Your change (at version b9cc7dba7607fb4f586d961bfa17ed26eab3ad61) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2444558539

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 duke at openjdk.org  Tue Oct 29 15:21:29 2024
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Tue, 29 Oct 2024 15:21:29 GMT
Subject: Integrated: 8341527: AVX-512 intrinsic for SHA3
In-Reply-To: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
Message-ID: <3AVkHJLOxfcDMDj_CP3gimfbfWtx1kl17yN_NxOucTM=.27da1836-2e4f-44b4-8b39-0d1cf196468c@github.com>

On Fri, 4 Oct 2024 10:15:30 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.

This pull request has now been integrated.

Changeset: 9cfb0f7f
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cfb0f7f7ad31081c917be1eb0e39e2552e45382
Stats:     426 lines in 9 files changed: 421 ins; 0 del; 5 mod

8341527: AVX-512 intrinsic for SHA3

Reviewed-by: sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/21352

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 jwaters at openjdk.org  Tue Oct 29 15:59:22 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 15:59:22 GMT
Subject: RFR: 8341527: AVX-512 intrinsic for SHA3 [v8]
In-Reply-To: <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
References: <N9Mcn5qcleQHQQx1pYELLa1vi92hVYc4kO2Z1grdN4U=.ea812e0f-473b-441a-80be-ea33ad080d08@github.com>
 <pYzygz2lMkx5aoE-S2eIQ2tTKbq6CVCL5y2wmJJkzps=.20549d0a-1dd1-4252-8fc2-3c4e2cc9fbca@github.com>
Message-ID: <-tlrwkX7k8tVquPyknON7ApEGBsfIPY_cKfqzMb7Y8s=.5a354c9a-65a8-46b1-a5ec-c0d209309602@github.com>

On Fri, 25 Oct 2024 14:16:40 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> There is already an intrinsic for SHA-3 for aarch64, which gives significant speed improvement on that architecture, so this pull request is bringing similar improvement for tha x64 family of systems that have the AVX-512 extension. Rudimentary measurements show that 30-40% speed improvement can be achieved.
>
> Ferenc Rakoczi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments

I think this broke the x86 assembler, I'm getting multiple failures that look like the following:


/home/runner/work/jdk/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3646:6: error: redefinition of ?void Assembler::evmovdquw(XMMRegister, KRegister, XMMRegister, bool, int)?
 3646 | void Assembler::evmovdquw(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
      |      ^~~~~~~~~
/home/runner/work/jdk/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3593:6: note: ?void Assembler::evmovdquw(XMMRegister, KRegister, XMMRegister, bool, int)? previously defined here
 3593 | void Assembler::evmovdquw(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
      |      ^~~~~~~~~

src/hotspot/cpu/x86/stubGenerator_x86_64_sha3.cpp line 54:

> 52:     };
> 53: 
> 54: ATTRIBUTE_ALIGNED(64) static const uint64_t permsAndRots[] = {

It's too late for this now, but this should've used alignas directly instead of ATTRIBUTE_ALIGNED. No worries though, the macro ultimately expands to alignas

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21352#issuecomment-2444688417
PR Review Comment: https://git.openjdk.org/jdk/pull/21352#discussion_r1821116001

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 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: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 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 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 kvn at openjdk.org  Tue Oct 29 17:14:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Oct 2024 17:14:06 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData
In-Reply-To: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
Message-ID: <G01odHgiktCFiGDPcz97hnBHpBdYyzOtVNUfORsBi_E=.c13d56ee-5943-4648-a3a7-2cace742630f@github.com>

On Mon, 28 Oct 2024 19:13:28 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.

Looks fine, just one question.

src/hotspot/share/oops/methodData.cpp line 66:

> 64:   temp._header._struct._tag = tag;
> 65:   temp._header._struct._bci = bci;
> 66:   _header = temp._header;  // Write the cell atomtically

Should we use `Atomic::store()` here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21746#pullrequestreview-2402593637
PR Review Comment: https://git.openjdk.org/jdk/pull/21746#discussion_r1821230658

From coleenp at openjdk.org  Tue Oct 29 17:21:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 29 Oct 2024 17:21:17 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace
Message-ID: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>

Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
Tested with tier1-4.

-------------

Commit messages:
 - 8343218: Disable allocating interface and abstract classes in non-class metaspace

Changes: https://git.openjdk.org/jdk/pull/21769/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21769&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343218
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21769.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21769/head:pull/21769

PR: https://git.openjdk.org/jdk/pull/21769

From never at openjdk.org  Tue Oct 29 17:31:15 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 29 Oct 2024 17:31:15 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData
In-Reply-To: <G01odHgiktCFiGDPcz97hnBHpBdYyzOtVNUfORsBi_E=.c13d56ee-5943-4648-a3a7-2cace742630f@github.com>
References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
 <G01odHgiktCFiGDPcz97hnBHpBdYyzOtVNUfORsBi_E=.c13d56ee-5943-4648-a3a7-2cace742630f@github.com>
Message-ID: <JUOAFTiB8mNXJsilQ66eEbLdnDwGQW03QTFhL-8vZpY=.ffa22ead-c417-4ce5-a36e-2aa64f2ffd8c@github.com>

On Tue, 29 Oct 2024 17:05:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.
>
> src/hotspot/share/oops/methodData.cpp line 66:
> 
>> 64:   temp._header._struct._tag = tag;
>> 65:   temp._header._struct._bci = bci;
>> 66:   _header = temp._header;  // Write the cell atomtically
> 
> Should we use `Atomic::store()` here?

I don't think it's necessary.  It just needs to write the whole value once instead of performing 3 writes of differing sizes to the same cell.  The value being written is always that same as the value that was already there from the original initialization.  Maybe `atomically` is the wrong comment.  Maybe `Write the cell as an intptr_t unit`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21746#discussion_r1821274798

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 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 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 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 ihse at openjdk.org  Tue Oct 29 20:43:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 20:43:18 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <xMfGwygwvEEqpdyRINSpxEFWIgv_Rnu0ccet-vOITcA=.efa2cc8a-bb0e-43b4-bf3a-27fcd3367a38@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <xMfGwygwvEEqpdyRINSpxEFWIgv_Rnu0ccet-vOITcA=.efa2cc8a-bb0e-43b4-bf3a-27fcd3367a38@github.com>
Message-ID: <XC4yQ4PGLY6thvuzTwrx1DrJYaM3k0XYl79DpgVeVvs=.40d43002-ef5f-443c-af67-035f9e17b0a3@github.com>

On Thu, 24 Oct 2024 23:36:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't hardcode server variant
>
>> > > When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
>> > > I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
>> > > @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.
>> > 
>> > 
>> > @magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.
>> 
>> Sorry for the delay. I finally found some time to look into this today. Running the latest `static-jdk` `bin/java` built from your branch fails for me as well:
>> 
>> ```
>> $ bin/java
>> Error: failed , because bin/java: undefined symbol: JNI_CreateJavaVM
>> ```
>> 
>> I only took a quick look, but I think this looks like https://bugs.openjdk.org/browse/JDK-8339522 that I filed in September.
>> 
>> ```
>> $ nm bin/java | grep JNI_CreateJavaVM
>> 000000000162733c t JNI_CreateJavaVM
>> 0000000001626e75 t _ZL22JNI_CreateJavaVM_innerPP7JavaVM_PPvS2_
>> jianglizhou at leia:~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ nm -D bin/java | grep JNI_CreateJavaVM
>> ```
>> 
>> The VM dynamic symbols are not exported properly. This is related to the [#20837 (comment)](https://github.com/openjdk/jdk/pull/20837#discussion_r1744611776) discussion comment thread.
> 
> Checking the `ld` command line, I think it is indeed https://bugs.openjdk.org/browse/JDK-8339522 issue. `-Wl,--exclude-libs,ALL` is included in the command:
> 
> $ cat ./support/static-native/launcher/BUILD_LAUNCHER_java_run_ld.cmdline
> /usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,-z,noexecstack -m64 -pie -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -Wl,-rpath,$ORIGIN -Wl,--disable-new-dtags -Wl,-rpath,$ORIGIN/../lib -Wl,--disable-new-dtags -o /...jianglizhou/github/jdk_pull_20837/build/...

@jianglizhou I fixed the bug with `-Wl,--exclude-libs,ALL` not being properly filtered out.

However, I still get the jimage problem:


$ build/linux-x64/images/static-jdk/bin/java closed/make/scripts/GenerateSecureId.java 
Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin
Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2445284962

From ihse at openjdk.org  Tue Oct 29 20:43:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 20:43:16 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug in filtering out -Wl,--exclude-libs,ALL

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/03cd9171..1d375bb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

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 psandoz at openjdk.org  Tue Oct 29 20:48:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 29 Oct 2024 20:48:27 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
Message-ID: <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>

On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   [vectorapi] Refactor VectorShuffle implementation

This is a nice change. It's as if `VectorShuffle<E>` has a payload of `Vector<F>` of the same shape as the shuffle and where` F` is the bit size equivalent integral type of `E`, and where the lane elements of the vector are constrained to be within `[-VLENGTH, VLENGTH-1]` (I do wonder if we might be able to refactor towards that more explicit representation later on with Valhalla.)

That simplifies things and opens up more optimizations and complements the modifications we recently did to `rearrange`/`selectFrom`.

(Recommend you do a merge with master to get latest Vector API changes just in case there is some impact.)

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 228:

> 226:         }
> 227: 
> 228:         AbstractVector<?> iota = vspecies().asIntegral().iota();

I suspect the non-power of two code is more efficient. (Even better if the MUL could be transformed to a shift for power of two values.)

Separately, it makes me wonder if we should revisit the shuffle factories if it is now much more efficient to construct a shuffle from a vector.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java line 870:

> 868:         @Override
> 869:         public final Int256Shuffle rearrange(VectorShuffle<Integer> shuffle) {
> 870:             return (Int256Shuffle) toBitsVector().rearrange(((Int256Shuffle) shuffle)

I think the cast is redundant for all vector kinds. Similarly the explicit cast is redundant for the integral vectors, perhaps in the template separate out the expressions to avoid it where not needed?

We could also refer to `VSPECIES` directly rather than calling `vspecies()`, same applies in other methods in the concrete vector classes.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java line 908:

> 906:         }
> 907: 
> 908:         private static boolean indicesInRange(int[] indices) {

Since this method is only called from an assert statement in the constructor we could avoid the clever checking that assertions are enabled and the explicit throwing on an AssertionError by using a second expression that produces an error message when the assertion fails : e.g.,

            assert indicesInRange(indices) : outOfBoundsAssertMessage(indices);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java line 2392:

> 2390:             this, shuffle, null,
> 2391:             (v1, s_, m_) -> v1.uOp((i, a) -> {
> 2392:                 int ei = Integer.remainderUnsigned(s_.laneSource(i), v1.length());

Note to self - the intrinsic performs the wrapping of shuffle values using bitwise AND.
Nice use of method (equiv to `Math.floorMod` for the range on input arguments).

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java line 2473:

> 2471:     final <F>
> 2472:     VectorShuffle<F> toShuffle(AbstractSpecies<F> dsp, boolean wrap) {
> 2473:         assert(dsp.elementSize() == vspecies().elementSize());

Even though we force inline I cannot quite decide if it is better to forego the assert since it unduly increases method size. Regardless it may be useful to place the partial wrapping logic in a separate method, given it is less likely to be used.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template line 1150:

> 1148:         @Override
> 1149:         @ForceInline
> 1150:         public void intoArray(int[] a, int offset) {

Separately, we might consider optimizing `shuffleFromArray`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2402948659
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1821489034
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1821471669
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1821478372
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1821450485
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1821456333
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1821501842

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 lmesnik at openjdk.org  Tue Oct 29 22:06:55 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 29 Oct 2024 22:06:55 GMT
Subject: RFR: 8343173: Remove ZGC-specific non-JVMCI test groups
Message-ID: <Pi4NnowP97OycsrQNhqYKrx-ponv9Fcn6-l7PZGbAzk=.25064037-6535-400a-a063-c3d602be594f@github.com>

The JVMCI should be supported by all GCs and specific
hotspot_compiler_all_gcs
group is not needed anymore.

There are few failures of JVMCI tests with ZGC happened, the bug 
https://bugs.openjdk.org/browse/JDK-8343233
is filed and corresponding tests are problemlisted.

-------------

Commit messages:
 - 8343173: Remove ZGC-specific non-JVMCI test groups

Changes: https://git.openjdk.org/jdk/pull/21774/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343173
  Stats: 20 lines in 3 files changed: 16 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21774/head:pull/21774

PR: https://git.openjdk.org/jdk/pull/21774

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 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 fyang at openjdk.org  Wed Oct 30 01:38:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 30 Oct 2024 01:38:41 GMT
Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address
Message-ID: <N6GG9Rmbiv6TPtv1VjOgmBDvprBUvxWbjXXYzSFdtgs=.c4049de7-7e25-487d-8fea-c8daa7f9496d@github.com>

Hi, please consider this refactoring work.

Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address.
While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is
reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi
pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about
the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732).

I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the
`RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`.
Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check
whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)`
as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code
cache won't be affected. And I don't think the original distance check from code cache will benefit us much more.
Eyeballed all `la(Address)` callsites, I think we are fine.

Benefits:
1. We have a simpler `la(address)` which is kind of spec compatible;
2. We are consistent in address check when doing j(Address), la(Address), ld/st(Address) and rt_call;
3. We don't need explicit use of `relocate` with lambda for most of the places;

Note that there are several places where we want explicit `movptr` sequence:
1. In `SignatureHandlerGenerator::generate()` where the emitted code is copied without relocation [1];
2. In `movoop` and `mov_metadata` where we want patching afterwards;

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313

Testing on linux-riscv64:
- [x] hotspot:tier1 (fastdebug)
- [x] tier1-tier3, hotspot:tier4 (release)
- [x] specjbb2015, dacapo, renaissance (release)

-------------

Commit messages:
 - 8343242: RISC-V: Refactor materialization of literal address

Changes: https://git.openjdk.org/jdk/pull/21777/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21777&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343242
  Stats: 161 lines in 14 files changed: 28 ins; 87 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/21777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21777/head:pull/21777

PR: https://git.openjdk.org/jdk/pull/21777

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 dholmes at openjdk.org  Wed Oct 30 04:41:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 04:41:13 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Just a cursory look through with some drive-by comments.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 41:

> 39: #include "runtime/osThread.hpp"
> 40: 
> 41: #if defined(LINUX)

If this is all Linux specific then can't we put it in a linux-specific sourcefile instead of masquerading as shared code?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 57:

> 55: static bool thread_state_in_java(JavaThread* thread) {
> 56:   assert(thread != nullptr, "invariant");
> 57:   switch(thread->thread_state()) {

Why a full switch when only two states are of interest?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 78:

> 76: }
> 77: 
> 78: static bool thread_state_in_native(JavaThread* thread) {

Whatever this is checking it is not what we normally call "in native" so please come up with a different name.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 238:

> 236:     // Encodes generation of the element (to solve ABA problem)
> 237:     // along with full/empty flag in the highest bit
> 238:     u4 _state;

Can you add more commentary explaining the operation of the queue please and how this "state" interacts with enqueue/dequeue.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 505:

> 503:       autoadapt_period_if_needed();
> 504:       last_autoadapt_check = os::javaTimeMillis();
> 505:     }

Do you really want wall-clock time here ???

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 788:

> 786: 
> 787:   // create timers for all existing threads
> 788:   MutexLocker tlock(Threads_lock);

When exactly is this called? The direct use of the Threads_lock raises concerns. Should this not be done at a global safepoint?

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 56:

> 54:   }
> 55:   assert(current_thread->in_asgct(), "invariant");
> 56:   assert(jt != current_thread || current_thread->in_asgct(), "invariant");

The second clause of the second assert is redundant given the first assert.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20752#pullrequestreview-2403526518
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821844294
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821832345
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821832710
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821861186
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821840144
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821842412
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1821848326

From jwaters at openjdk.org  Wed Oct 30 05:29:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Oct 2024 05:29:04 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <QZkwjkTR2NERa2Y2tGIlY-Woq7igVGG5QNsqZENiRJk=.1bda1b01-63c4-436f-beaa-c1581c8f9c25@github.com>

On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Bumping, please advise how to proceed on the sharedRuntime issue. It potentially affects Windows/ARM64 in an unknown way

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2445891561

From dholmes at openjdk.org  Wed Oct 30 05:46:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 05:46:11 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace
In-Reply-To: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
Message-ID: <ZaBavwHKhuLCru6iAleDa-u9aOSZQs0qxuPKZHR_x74=.bd698e02-f3ea-41be-b94d-20ffa7672f1b@github.com>

On Tue, 29 Oct 2024 17:15:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
> Tested with tier1-4.

So this is just disabling [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) until other C2 changes are in place. Are they coming soon? If not shouldn't [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) be backed out?

src/hotspot/share/oops/instanceKlass.cpp line 459:

> 457:   // Only Klasses that aren't interface or abstract classes are found in oop headers so they
> 458:   // are the only ones that require compression and allocation in the limited class metaspace
> 459:   // region.  But ... there are C2 dependencies that all klasses are allocated to the class metaspace.

Suggestion:

  // region.  But ... there are C2 dependencies that all klasses are allocated to the class metaspace, so
  // always use the class metaspace until JDK-NNNNNNN is resolved.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21769#pullrequestreview-2403674772
PR Review Comment: https://git.openjdk.org/jdk/pull/21769#discussion_r1821915266

From dholmes at openjdk.org  Wed Oct 30 05:52:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 05:52:05 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <wMwWjjMPqyb7hYFdHRjnlUlvf8wOUPVt79RpYIV8vzk=.bf3d4c7f-0beb-4255-a56e-2292a23bcac8@github.com>

On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

You need to contact the Windows-Aarch64 port maintainers and get them to tell you what the correct thing for Aarch64 is. Paging @mo-beck , @luhenry and @lewurm (https://openjdk.org/jeps/388)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2445928951

From never at openjdk.org  Wed Oct 30 06:19:21 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 30 Oct 2024 06:19:21 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData [v2]
In-Reply-To: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
Message-ID: <C8Dn9QEoUNrB-pwj8wP0IQEToP1zwqQ0fIQAcamWIWQ=.77c77064-a39a-4fc5-876b-4cfac3854e78@github.com>

> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21746/files
  - new: https://git.openjdk.org/jdk/pull/21746/files/94915e57..86c1625c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21746&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21746&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21746.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21746/head:pull/21746

PR: https://git.openjdk.org/jdk/pull/21746

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 stuefe at openjdk.org  Wed Oct 30 07:09:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Oct 2024 07:09:05 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace
In-Reply-To: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
Message-ID: <1cd8NWsFN_gFJfJhOTh1T0Pe1X0iaDz_ww2pPKlLkRc=.5561c0bd-1955-420e-a30d-3829d3c24e43@github.com>

On Tue, 29 Oct 2024 17:15:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
> Tested with tier1-4.

Okay

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21769#pullrequestreview-2403809142

From stuefe at openjdk.org  Wed Oct 30 07:12:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Oct 2024 07:12:04 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace
In-Reply-To: <ZaBavwHKhuLCru6iAleDa-u9aOSZQs0qxuPKZHR_x74=.bd698e02-f3ea-41be-b94d-20ffa7672f1b@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
 <ZaBavwHKhuLCru6iAleDa-u9aOSZQs0qxuPKZHR_x74=.bd698e02-f3ea-41be-b94d-20ffa7672f1b@github.com>
Message-ID: <cGbZpWYqr21JwAwCgIYHWnGlDSWBhlv-8cizJuFyHZY=.9028b00d-c225-4951-8e7a-be6a9e87ef6d@github.com>

On Wed, 30 Oct 2024 05:43:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So this is just disabling [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) until other C2 changes are in place. Are they coming soon? If not shouldn't [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) be backed out?

[JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) cannot be backed out verbatim, since it has some follow-up fixes. But I also don't think this is necessary at this point. The changes supporting this feature were harmless and few. And we still may want this feature, especially when it comes to auto-generated classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21769#issuecomment-2446036051

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 jbechberger at openjdk.org  Wed Oct 30 07:39:22 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 07:39:22 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
Message-ID: <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>

On Wed, 30 Oct 2024 04:19:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 41:
> 
>> 39: #include "runtime/osThread.hpp"
>> 40: 
>> 41: #if defined(LINUX)
> 
> If this is all Linux specific then can't we put it in a linux-specific sourcefile instead of masquerading as shared code?

The idea is to place it close to the other method sampler.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 57:
> 
>> 55: static bool thread_state_in_java(JavaThread* thread) {
>> 56:   assert(thread != nullptr, "invariant");
>> 57:   switch(thread->thread_state()) {
> 
> Why a full switch when only two states are of interest?

Similarity to the other sampler.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 78:
> 
>> 76: }
>> 77: 
>> 78: static bool thread_state_in_native(JavaThread* thread) {
> 
> Whatever this is checking it is not what we normally call "in native" so please come up with a different name.

This is the same name the other sampler uses.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 238:
> 
>> 236:     // Encodes generation of the element (to solve ABA problem)
>> 237:     // along with full/empty flag in the highest bit
>> 238:     u4 _state;
> 
> Can you add more commentary explaining the operation of the queue please and how this "state" interacts with enqueue/dequeue.

@jbachorik and @apangin: can you take this?

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 505:
> 
>> 503:       autoadapt_period_if_needed();
>> 504:       last_autoadapt_check = os::javaTimeMillis();
>> 505:     }
> 
> Do you really want wall-clock time here ???

What else should I use? I want to check for the adaption of the sampling period every few seconds.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 788:
> 
>> 786: 
>> 787:   // create timers for all existing threads
>> 788:   MutexLocker tlock(Threads_lock);
> 
> When exactly is this called? The direct use of the Threads_lock raises concerns. Should this not be done at a global safepoint?

This is called transitively from the Java code whenever the event is first enabled. So this should lead to a safepoint?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822031772
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822033609
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822033128
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822034297
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822035486
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822036741

From dnsimon at openjdk.org  Wed Oct 30 08:30:10 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 30 Oct 2024 08:30:10 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData [v2]
In-Reply-To: <C8Dn9QEoUNrB-pwj8wP0IQEToP1zwqQ0fIQAcamWIWQ=.77c77064-a39a-4fc5-876b-4cfac3854e78@github.com>
References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
 <C8Dn9QEoUNrB-pwj8wP0IQEToP1zwqQ0fIQAcamWIWQ=.77c77064-a39a-4fc5-876b-4cfac3854e78@github.com>
Message-ID: <5kbBhCzN_WcQq4l-a69rXKaD9vyMdGNQV8_UhQRjlwg=.268e5af6-c639-4fc0-8d0f-2780c619db5a@github.com>

On Wed, 30 Oct 2024 06:19:21 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by dnsimon (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21746#pullrequestreview-2403981680

From jbachorik at openjdk.org  Wed Oct 30 08:51:15 2024
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Wed, 30 Oct 2024 08:51:15 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <1QaouFROtzaOOqxGKaCelOblvhz4peX6CV5_bgSM-tU=.1072bdd6-d515-46d0-92f9-6205e373af85@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Grrr ... the top level comments do not support threading, so let's quote ...

> Regarding the field samplingPeriod: @apangin mentioned in a recent meeting that naming it cpuTime and storing the thread's CPU time at the point of sampling would be better, giving us more flexibility. Not only does it convey more information, but it also allows profiler writers to merge adjacent traces if they are similar, making it possible to store the traces in a more compact format without breaking the API.

AFAIK, reading thread cpu time may incur unexpected overhead on older kernels (pre 5.1) where `clock_gettime` may not be virtualized (resulting in full syscall instead of VDSO) in a container environment. And I think we are not putting any restrictions on the kernel version where this sampler can run.

The second issue I see is that you would need to parse the events 'by thread' - eg. all events from one thread would need to be parsed sequentially in order to able to compute the delta to the previous sample from the same thread. And we need the deltas to assign them as the weight to the samples. But in real life the TLB chunks containing events from a single thread are interleaved in the recording - you can have events for T1->T2->T3->T1->T3->T2->....

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2446210928

From jbachorik at openjdk.org  Wed Oct 30 09:01:16 2024
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Wed, 30 Oct 2024 09:01:16 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
Message-ID: <nZoyPIrDbGpJJY8z_WmaPCHxAdu35C9oxTYiG4q5P24=.33d6fc3b-5975-42ab-989b-9506fd00d182@github.com>

On Wed, 30 Oct 2024 07:34:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 505:
>> 
>>> 503:       autoadapt_period_if_needed();
>>> 504:       last_autoadapt_check = os::javaTimeMillis();
>>> 505:     }
>> 
>> Do you really want wall-clock time here ???
>
> What else should I use? I want to check for the adaption of the sampling period every few seconds.

Perhaps `os::javaTimeNanos()` would be better? It provides global monotonic time.
OTOH, `os::javaTimeMillis()` can move unexpectedly - a good example is the daylight saving time where the millis would suddenly jump 1 hour to the past.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822154990

From jbechberger at openjdk.org  Wed Oct 30 09:14:15 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 09:14:15 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <nZoyPIrDbGpJJY8z_WmaPCHxAdu35C9oxTYiG4q5P24=.33d6fc3b-5975-42ab-989b-9506fd00d182@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <nZoyPIrDbGpJJY8z_WmaPCHxAdu35C9oxTYiG4q5P24=.33d6fc3b-5975-42ab-989b-9506fd00d182@github.com>
Message-ID: <L9C3etDoJwskX8Hbph--2Ru9fe0qS3bDwrsq803SWls=.8725e950-5407-4c51-9a1d-2ebacb1afc92@github.com>

On Wed, 30 Oct 2024 08:58:17 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> What else should I use? I want to check for the adaption of the sampling period every few seconds.
>
> Perhaps `os::javaTimeNanos()` would be better? It provides global monotonic time.
> OTOH, `os::javaTimeMillis()` can move unexpectedly - a good example is the daylight saving time where the millis would suddenly jump 1 hour to the past.

Good point, I totally forgot about the monotonicity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822176104

From jbachorik at openjdk.org  Wed Oct 30 09:14:15 2024
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Wed, 30 Oct 2024 09:14:15 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
Message-ID: <dfBuPHWXT2pvTFx3XlL2zTc9JRBw_TGMDmuPWZFp8BA=.0b9c131e-e032-4b0c-8abf-a8eaf465fc52@github.com>

On Wed, 30 Oct 2024 07:36:01 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 788:
>> 
>>> 786: 
>>> 787:   // create timers for all existing threads
>>> 788:   MutexLocker tlock(Threads_lock);
>> 
>> When exactly is this called? The direct use of the Threads_lock raises concerns. Should this not be done at a global safepoint?
>
> This is called transitively from the Java code whenever the event is first enabled. So this should lead to a safepoint?

AFAIK, we are removing the timers once all recordings with the cpu profiler event are closed. And would re-add them when another recording is started later, right?
In that case, if we force a global safepoint in order to init/remove timers we could get an unexpectly high amount of safepoints, dependent on the external factors starting/stopping/configuring JFR recordings.

@dholmes-ora What exactly is the concern here? I just want to understand if the concern really warrants increasing the number of global safepoints when using JFR with this sampler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822167799

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 thartmann at openjdk.org  Wed Oct 30 10:23:05 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 30 Oct 2024 10:23:05 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace
In-Reply-To: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
Message-ID: <LQeGeTmeEEVfRMvxw2K-1vRx-Akwmlyz4jZBzevDMLE=.8c5f7554-bdab-41e2-bccf-7077a81b8de0@github.com>

On Tue, 29 Oct 2024 17:15:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
> Tested with tier1-4.

FTR, I had a look at [JDK-8343206](https://bugs.openjdk.org/browse/JDK-8343206) and I don't think it's an issue in current code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21769#issuecomment-2446464827

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: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: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: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: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: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: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: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 coleenp at openjdk.org  Wed Oct 30 12:03:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 12:03:43 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace [v2]
In-Reply-To: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
Message-ID: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com>

> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/oops/instanceKlass.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21769/files
  - new: https://git.openjdk.org/jdk/pull/21769/files/a30081ad..b9df0326

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21769&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21769&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21769.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21769/head:pull/21769

PR: https://git.openjdk.org/jdk/pull/21769

From coleenp at openjdk.org  Wed Oct 30 12:09:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 12:09:05 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace [v2]
In-Reply-To: <cGbZpWYqr21JwAwCgIYHWnGlDSWBhlv-8cizJuFyHZY=.9028b00d-c225-4951-8e7a-be6a9e87ef6d@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
 <ZaBavwHKhuLCru6iAleDa-u9aOSZQs0qxuPKZHR_x74=.bd698e02-f3ea-41be-b94d-20ffa7672f1b@github.com>
 <cGbZpWYqr21JwAwCgIYHWnGlDSWBhlv-8cizJuFyHZY=.9028b00d-c225-4951-8e7a-be6a9e87ef6d@github.com>
Message-ID: <okPeiyrcjlzgQ0N3f3duhcHruJh2KLXTz5s-Ki_Y_wE=.9c76300d-b9c1-49e5-aba3-d810041ca4c7@github.com>

On Wed, 30 Oct 2024 07:09:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> So this is just disabling [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) until other C2 changes are in place. Are they coming soon? If not shouldn't [JDK-8338526](https://bugs.openjdk.org/browse/JDK-8338526) be backed out?

The changes for JDK-8338526 were minor refactoring and then there were nice follow up changes to test if klass pointers were encodable, as Thomas said above. The refactoring doesn't hurt anything and setting this way allows the opportunity for a comment explaining why, so we can repeat this change in the future.

> FTR, I had a look at [JDK-8343206](https://bugs.openjdk.org/browse/JDK-8343206) and I don't think it's an issue in current code.

Thank you Tobias for looking at this.  I'll answer in the bug report but I would feel better if the c2 code hit an assert or something if we tried to encode a Klass pointer that isn't in class-metaspace, so I think we should have my change to disable the allocation for now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21769#issuecomment-2446901596

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 coleenp at openjdk.org  Wed Oct 30 12:18:07 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 12:18:07 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace [v2]
In-Reply-To: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
 <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com>
Message-ID: <inZ060AEjEk51zNzU0Bg3Gy4zvW2btbqGo1YzpCLPQI=.adfd07d9-8142-4298-ad5b-af45bb9355d1@github.com>

On Wed, 30 Oct 2024 12:03:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/oops/instanceKlass.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

I answered before reading JDK-8343206 where you do add a test for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21769#issuecomment-2446941216

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 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 mgronlun at openjdk.org  Wed Oct 30 14:19:18 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 14:19:18 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 84:

> 82:             addControl(Threshold.NAME, defineThreshold(eventType));
> 83:         }
> 84:         if (eventType.hasStackTrace() && !eventType.isCPUTimeMethodSampling()) {

The second clause is not really needed, right? I don't think the CPUTimeMethodSampling event hasStacktrace() is true.

The event has a separate StackTrace field in the event, but that is not what is being checked here.

src/jdk.jfr/share/conf/jfr/profile.jfc line 195:

> 193:     <event name="jdk.CPUTimeSample">
> 194:       <setting name="enabled" control="method-sampling-enabled">false</setting>
> 195:       <setting name="throttle">10ms</setting>

Can a rate be given here instead of an absolute value? Otherwise, there is a mismatch between the default. jfc and the profile.jfc which seems quite unintuitive.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeAndExecutionSample.java line 35:

> 33:  * @test
> 34:  * @key jfr
> 35:  * @requires vm.hasJFR

@requires vm.hasJFR & os.family == "linux" ?

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSamplingLongPeriod.java line 35:

> 33:  * @test
> 34:  * @key jfr
> 35:  * @requires vm.hasJFR

@requires vm.hasJFR & os.family == "linux"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822726454
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822731716
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822734759
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822736281

From duke at openjdk.org  Wed Oct 30 14:23:42 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Wed, 30 Oct 2024 14:23:42 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v12]
In-Reply-To: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
Message-ID: <5CRRnynK_o74GMH0-cFZyieGaWn29hVsyZEuesaG-vg=.6795a4b1-322b-42d9-8df0-bf39d77a4075@github.com>

> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:

  Expand the comment on endian swap

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19960/files
  - new: https://git.openjdk.org/jdk/pull/19960/files/0f38182d..a620b6a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19960&range=10-11

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19960/head:pull/19960

PR: https://git.openjdk.org/jdk/pull/19960

From duke at openjdk.org  Wed Oct 30 14:23:42 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Wed, 30 Oct 2024 14:23:42 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v10]
In-Reply-To: <6fJZ5wVxtfeoOsRVmKwBqRpy9gJJkOSrGLmHHGHUh1g=.76401a18-9433-4d2d-bc11-fca081abadc5@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <NTVkRIT9u9EXikDAxNLTV2WT36TIAD3F0ywlXdx8lpM=.f3fe4192-67b2-4e4b-a974-c783369d92f4@github.com>
 <CNQUc31lweSYNs2QsNuWqMavcG4mD5QozXd0FGDIoU4=.36893484-4130-446b-9b54-8128831c8a3e@github.com>
 <kZgfhrFPOmp4q4urH__AgNWpnkQCzdaU75vGwFaehec=.78a55319-0c5a-4b63-b0d2-36b1721a609f@github.com>
 <6fJZ5wVxtfeoOsRVmKwBqRpy9gJJkOSrGLmHHGHUh1g=.76401a18-9433-4d2d-bc11-fca081abadc5@github.com>
Message-ID: <Gddpedmct12oh7B2xFgz8nhzYXDAySamtoggIke6FOM=.1b892d69-c980-4426-9dd4-525efe0f0db7@github.com>

On Tue, 29 Oct 2024 12:13:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I'm not very familiar with OpenSSL but I guess it is just uses different endianness when storing the result :shrug:  (compared to [big-endian](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.11) JVM). I'll left the note on it in the code
>
> Hmm ... I didn't find a direct evidence about the endianness of the key required here. Was is documented anywhere? I prefer to add some more details in the code comment to make it more readable.

All I was able to find is [this](https://stackoverflow.com/a/9455607) answer :shrug: Well if it is fully big-endian and in our case we store keys little-endian (as stated in the comment [here](https://github.com/openjdk/jdk/pull/19960/files#diff-97f199af6d1c8c17b2fa4f50eb1bbc0081858cc59a899f32792a2d31f933ccc4R2304)) then the difference in keys loading is expected (but again, it is just the guess ?). I'll expand the comment, no problem!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19960#discussion_r1822742476

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 mgronlun at openjdk.org  Wed Oct 30 16:48:15 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 16:48:15 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <X4SzfIT7G-3vZGmlEg2RRz9nhyIIvIELB35GRiX0epk=.dce082d1-85c3-4ce7-9cf0-b0cb5d4cf848@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Please make sure you test this also on non-Linux platforms:

Java HotSpot(TM) 64-Bit Server VM warning: CPU time method sampling not supported in JFR on your platform
java.lang.RuntimeException: Incorrect settings value for jdk.CPUTimeSample#throttle was 0/s, expected 500/s expected: 500/s but was: 0/s
	at jdk.test.lib.Asserts.fail(Asserts.java:691)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:204)
	at jdk.jfr.event.runtime.TestActiveSettingEvent.testSettingConfiguration(TestActiveSettingEvent.java:308)
	at jdk.jfr.event.runtime.TestActiveSettingEvent.testDefaultSettings(TestActiveSettingEvent.java:79)
	at jdk.jfr.event.runtime.TestActiveSettingEvent.main(TestActiveSettingEvent.java:65)
	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.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1576)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2447774654

From mgronlun at openjdk.org  Wed Oct 30 16:52:14 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 16:52:14 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <3nCUEfg4231kd9JNUwSiKvbcoVWo7XvWjfIO1ZhuK7I=.0836c683-debd-41af-9fa7-e8cc823c6e19@github.com>

On Wed, 28 Aug 2024 16:47:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

test/jdk/jdk/jfr/event/profiling/TestCPUTimeNative.java line 36:

> 34:  * @test
> 35:  * @key jfr
> 36:  * @requires vm.hasJFR

vm.hasJFR & os.family == "linux"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823030821

From jbechberger at openjdk.org  Wed Oct 30 16:57:11 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 16:57:11 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <X4SzfIT7G-3vZGmlEg2RRz9nhyIIvIELB35GRiX0epk=.dce082d1-85c3-4ce7-9cf0-b0cb5d4cf848@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <X4SzfIT7G-3vZGmlEg2RRz9nhyIIvIELB35GRiX0epk=.dce082d1-85c3-4ce7-9cf0-b0cb5d4cf848@github.com>
Message-ID: <iYzhaIkiL319jKbkp5M5FsPdlT_LPGA9I3_-xL2TKCg=.f257b1ef-d15c-496a-a69d-b5d4bb0f9acc@github.com>

On Wed, 30 Oct 2024 16:45:14 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Please make sure you test this also on non-Linux platforms:

I usually do test it on Mac, I probably just forgot it. I'm fixing the bug tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2447799611

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 jbechberger at openjdk.org  Wed Oct 30 17:50:14 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 17:50:14 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR
In-Reply-To: <6X8Dm36AoVunOUy6kXv7LIdH3lLWFQyroPZL5d_1t-A=.ea1ef36e-d108-4244-a28b-1346a88708ae@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <6X8Dm36AoVunOUy6kXv7LIdH3lLWFQyroPZL5d_1t-A=.ea1ef36e-d108-4244-a28b-1346a88708ae@github.com>
Message-ID: <exg90hBeEnf9GmnGNe2P4N7mQRg7-W_G2r4pxVS0pVY=.aa9558f5-9e0d-4684-abba-09cde37b6f2e@github.com>

On Tue, 29 Oct 2024 13:34:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java line 92:
> 
>> 90:     // Experimental events
>> 91:     private static final Set<String> experimentalEvents = Set.of(
>> 92:         "Flush", "SyncOnValueBasedClass", "CPUTimeSample", "CPUTimeSampleLoss");
> 
> The reason we added an exclusion list for experimental events is so developers wouldn't be forced to write a test. Since you have a test for the CPUTimeSample event, I think you can remove it.
> 
> (If TestLookForUntestedEvents is not able to find the event test, write the event name in the test)

But this leads to fails, because of the loop that initialized the `jfrEventTypes`:

       for (EventType type : FlightRecorder.getFlightRecorder().getEventTypes()) {
            if (type.getAnnotation(Experimental.class) == null) {
                jfrEventTypes.add(type.getName().replace("jdk.", ""));
            }
        }

Only events that not experimental are included. But `CPUTimeSample` is experimental.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823122743

From jbechberger at openjdk.org  Wed Oct 30 18:10:59 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:10:59 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v2]
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <8Wdt0RaAGm4kyUh6XfjyVRjPUv2oezOMcSLqTgzqXTY=.8e154cf0-1e91-40ca-b686-b4aa3489fd55@github.com>

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Improve TestLookForUntestedEvents and TimespanRate.of

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20752/files
  - new: https://git.openjdk.org/jdk/pull/20752/files/366aced5..9bfceee0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=00-01

  Stats: 20 lines in 6 files changed: 8 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752

PR: https://git.openjdk.org/jdk/pull/20752

From jbechberger at openjdk.org  Wed Oct 30 18:11:00 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:11:00 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v2]
In-Reply-To: <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
Message-ID: <uEjMq-544miu8dKkaQ7IBzkFt4IaDHfsNSFZZFpn8jM=.f0eebff9-0732-4d98-9f0e-ba5b9ed846b8@github.com>

On Wed, 30 Oct 2024 07:32:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 57:
>> 
>>> 55: static bool thread_state_in_java(JavaThread* thread) {
>>> 56:   assert(thread != nullptr, "invariant");
>>> 57:   switch(thread->thread_state()) {
>> 
>> Why a full switch when only two states are of interest?
>
> Similarity to the other sampler.

And it's far easier to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823152471

From jbechberger at openjdk.org  Wed Oct 30 18:11:01 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:11:01 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v2]
In-Reply-To: <exg90hBeEnf9GmnGNe2P4N7mQRg7-W_G2r4pxVS0pVY=.aa9558f5-9e0d-4684-abba-09cde37b6f2e@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <6X8Dm36AoVunOUy6kXv7LIdH3lLWFQyroPZL5d_1t-A=.ea1ef36e-d108-4244-a28b-1346a88708ae@github.com>
 <exg90hBeEnf9GmnGNe2P4N7mQRg7-W_G2r4pxVS0pVY=.aa9558f5-9e0d-4684-abba-09cde37b6f2e@github.com>
Message-ID: <uxQIm-veFr1Xx5V3EzC5PsvRhnwHKpozwdJv-j7BLvc=.6d437ec5-1c34-4b2f-ab4b-34a47a308143@github.com>

On Wed, 30 Oct 2024 17:47:11 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java line 92:
>> 
>>> 90:     // Experimental events
>>> 91:     private static final Set<String> experimentalEvents = Set.of(
>>> 92:         "Flush", "SyncOnValueBasedClass", "CPUTimeSample", "CPUTimeSampleLoss");
>> 
>> The reason we added an exclusion list for experimental events is so developers wouldn't be forced to write a test. Since you have a test for the CPUTimeSample event, I think you can remove it.
>> 
>> (If TestLookForUntestedEvents is not able to find the event test, write the event name in the test)
>
> But this leads to fails, because of the loop that initialized the `jfrEventTypes`:
> 
>        for (EventType type : FlightRecorder.getFlightRecorder().getEventTypes()) {
>             if (type.getAnnotation(Experimental.class) == null) {
>                 jfrEventTypes.add(type.getName().replace("jdk.", ""));
>             }
>         }
> 
> Only events that not experimental are included. But `CPUTimeSample` is experimental.

I update the test to check for CPUTimeSample events

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823151510

From jbechberger at openjdk.org  Wed Oct 30 18:13:17 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:13:17 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v2]
In-Reply-To: <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
Message-ID: <PHwwA1xVcaHi282Br5RmlYAGdGUSdooWvV9UCcBwzlE=.248231f8-b2be-4df6-88da-3c80cedc6c69@github.com>

On Wed, 30 Oct 2024 04:21:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve TestLookForUntestedEvents and TimespanRate.of
>
> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 56:
> 
>> 54:   }
>> 55:   assert(current_thread->in_asgct(), "invariant");
>> 56:   assert(jt != current_thread || current_thread->in_asgct(), "invariant");
> 
> The second clause of the second assert is redundant given the first assert.

The second assert is redundant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823157378

From jbechberger at openjdk.org  Wed Oct 30 18:22:35 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:22:35 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v3]
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <xp99LsO4eFcCv7Lvu8K8MmC2C8U2IO3OAItIJDfEANQ=.ed4a9443-0561-4f3b-8f50-158502ee1065@github.com>

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix tests and other minor improvements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20752/files
  - new: https://git.openjdk.org/jdk/pull/20752/files/9bfceee0..31452ce1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=01-02

  Stats: 7 lines in 5 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752

PR: https://git.openjdk.org/jdk/pull/20752

From jbechberger at openjdk.org  Wed Oct 30 18:22:35 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:22:35 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v3]
In-Reply-To: <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
Message-ID: <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>

On Wed, 30 Oct 2024 14:11:01 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tests and other minor improvements
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 84:
> 
>> 82:             addControl(Threshold.NAME, defineThreshold(eventType));
>> 83:         }
>> 84:         if (eventType.hasStackTrace() && !eventType.isCPUTimeMethodSampling()) {
> 
> The second clause is not really needed, right? I don't think the CPUTimeMethodSampling event hasStacktrace() is true.
> 
> The event has a separate StackTrace field, but that is not what is being checked here.

It is needed, because otherwise the `TestDefaultConfigurations` test fails:


java.lang.Exception: Setting 'stackTrace' in event 'jdk.CPUTimeSample' was not configured in the configuration 'default'
Setting 'stackTrace' in event 'jdk.CPUTimeSample' was not configured in the configuration 'profile'

        at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:115)
        at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:76)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1575)

> src/jdk.jfr/share/conf/jfr/profile.jfc line 195:
> 
>> 193:     <event name="jdk.CPUTimeSample">
>> 194:       <setting name="enabled" control="method-sampling-enabled">false</setting>
>> 195:       <setting name="throttle">10ms</setting>
> 
> Can a rate be given here instead of an absolute value? Otherwise, there is a mismatch between the default. jfc and the profile.jfc which seems quite unintuitive.

I wanted to give the user the info that both formats are usable (because this is documented nowhere else) and in profiling we usually don't care about having too many events.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823162724
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823164508

From jbechberger at openjdk.org  Wed Oct 30 18:26:14 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 18:26:14 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v3]
In-Reply-To: <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
Message-ID: <hwdzHQ26Yw6OfOjAl3y26tG23y_BnnvHG6IT11okXP8=.0655857e-f862-4f90-b7c6-e33a42076a0b@github.com>

On Wed, 30 Oct 2024 18:14:56 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 84:
>> 
>>> 82:             addControl(Threshold.NAME, defineThreshold(eventType));
>>> 83:         }
>>> 84:         if (eventType.hasStackTrace() && !eventType.isCPUTimeMethodSampling()) {
>> 
>> The second clause is not really needed, right? I don't think the CPUTimeMethodSampling event hasStacktrace() is true.
>> 
>> The event has a separate StackTrace field, but that is not what is being checked here.
>
> It is needed, because otherwise the `TestDefaultConfigurations` test fails:
> 
> 
> java.lang.Exception: Setting 'stackTrace' in event 'jdk.CPUTimeSample' was not configured in the configuration 'default'
> Setting 'stackTrace' in event 'jdk.CPUTimeSample' was not configured in the configuration 'profile'
> 
>         at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:115)
>         at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:76)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1575)

The problem is, is that `eventType.hasStackTrace()` checks for the existence of a field called `stackTrace`, which CPUTimeSample events have. We could of course rename the field to something like `recordedStackTrace`, but I don't think that this is helpful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823177332

From szaldana at openjdk.org  Wed Oct 30 19:10:28 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 30 Oct 2024 19:10:28 GMT
Subject: RFR: 8336874: WhiteBoxAPI: assert(!method->is_abstract() &&
 (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot
 compile abstract/native methods [v3]
In-Reply-To: <yZ61nJ6P8UVGVuHgFdz-GZsSDshM5mg8fLQdcLU2bxI=.1597cb1f-991e-40f3-8cf1-d20663c9977d@github.com>
References: <yZ61nJ6P8UVGVuHgFdz-GZsSDshM5mg8fLQdcLU2bxI=.1597cb1f-991e-40f3-8cf1-d20663c9977d@github.com>
Message-ID: <PEYhEsyxgHLBWLnZZZLjCFLNnjGbMdBJC53PYy73YK4=.40cfff2a-32fd-4d5e-ad90-6e6c40fef023@github.com>

> Hi all, 
> 
> This PR addresses [8336874](https://bugs.openjdk.org/browse/JDK-8336874) ensuring enqueuing an abstract method for compilation doesn't hit an assert with WhiteBox. 
> 
> Testing: 
> - [x] Added test case passes. 
> 
> 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 three additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336874
 - Adding enqueue check to be false
 - 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20973/files
  - new: https://git.openjdk.org/jdk/pull/20973/files/3cded521..5add3a0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20973&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20973&range=01-02

  Stats: 326417 lines in 3353 files changed: 240612 ins; 71068 del; 14737 mod
  Patch: https://git.openjdk.org/jdk/pull/20973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20973/head:pull/20973

PR: https://git.openjdk.org/jdk/pull/20973

From mgronlun at openjdk.org  Wed Oct 30 19:12:27 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 19:12:27 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v3]
In-Reply-To: <xp99LsO4eFcCv7Lvu8K8MmC2C8U2IO3OAItIJDfEANQ=.ed4a9443-0561-4f3b-8f50-158502ee1065@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <xp99LsO4eFcCv7Lvu8K8MmC2C8U2IO3OAItIJDfEANQ=.ed4a9443-0561-4f3b-8f50-158502ee1065@github.com>
Message-ID: <un7I2_6-8RRwUYFwyMihSyOJ4pKPG-gGFmZ3nsIw2BI=.b6c493fb-29ba-446b-b78f-59271cd921a1@github.com>

On Wed, 30 Oct 2024 18:22:35 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tests and other minor improvements

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 45:

> 43: 
> 44: 
> 45: static const size_t min_valid_free_size_bytes = 16;

This is not used anywhere? Does it mean you could remove the special handling of request_enqueue_buffer()?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823236275

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 szaldana at openjdk.org  Wed Oct 30 19:21:30 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 30 Oct 2024 19:21:30 GMT
Subject: RFR: 8300732: Whitebox functions for Metaspace test should use
 byte size [v4]
In-Reply-To: <eEn9XGR498GfiVBvO1hTvtfk6Fv1zfTxrAJ-_EP62AQ=.d2fa0e77-8af9-49e5-91f9-50cc8a29d0c6@github.com>
References: <eEn9XGR498GfiVBvO1hTvtfk6Fv1zfTxrAJ-_EP62AQ=.d2fa0e77-8af9-49e5-91f9-50cc8a29d0c6@github.com>
Message-ID: <VDFx-2hTSOOqCUbOdiTOFD0W3wB-0DTmQKANscsQJgk=.ec408168-37c9-4495-a8ad-adbb392a59ea@github.com>

> Hi all, 
> 
> This PR addresses [8300732](https://bugs.openjdk.org/browse/JDK-8300732) switching Whitebox Metaspace test functions to use bytes as opposed to words. 
> 
> Testing: 
> - [x] `test/hotspot/jtreg/runtime/Metaspace` tests pass. 
> 
> Thanks, 
> Sonia

Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' of github.com:openjdk/jdk into JDK-8300732
 - Feedback - updating Unit.valueOf to direct access
 - Hard coding values and adding Unit class
 - whitebox changes based on feedback. Using is_aligned and asserts
 - 8300732: Whitebox functions for Metaspace test should use byte size

-------------

Changes: https://git.openjdk.org/jdk/pull/20039/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20039&range=03
  Stats: 161 lines in 13 files changed: 71 ins; 0 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/20039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20039/head:pull/20039

PR: https://git.openjdk.org/jdk/pull/20039

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 jbechberger at openjdk.org  Wed Oct 30 19:34:23 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 19:34:23 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove min_valid_free_size_bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20752/files
  - new: https://git.openjdk.org/jdk/pull/20752/files/31452ce1..ddec72bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752

PR: https://git.openjdk.org/jdk/pull/20752

From jbechberger at openjdk.org  Wed Oct 30 19:34:24 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 19:34:24 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <un7I2_6-8RRwUYFwyMihSyOJ4pKPG-gGFmZ3nsIw2BI=.b6c493fb-29ba-446b-b78f-59271cd921a1@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <xp99LsO4eFcCv7Lvu8K8MmC2C8U2IO3OAItIJDfEANQ=.ed4a9443-0561-4f3b-8f50-158502ee1065@github.com>
 <un7I2_6-8RRwUYFwyMihSyOJ4pKPG-gGFmZ3nsIw2BI=.b6c493fb-29ba-446b-b78f-59271cd921a1@github.com>
Message-ID: <PPzYWE7qg2sln6_nBWy0NfP9Hsx3VWEl93_vedFEACQ=.cf91a6cc-0184-4b21-80f8-2c34c91321cb@github.com>

On Wed, 30 Oct 2024 19:09:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This is not used anywhere?

No, I removed it.

> Does it mean you could remove the special handling of request_enqueue_buffer()?

No, this is unrelated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823259491

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: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 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 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 kvn at openjdk.org  Wed Oct 30 20:15:18 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 20:15:18 GMT
Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash
 ciMethodData [v2]
In-Reply-To: <C8Dn9QEoUNrB-pwj8wP0IQEToP1zwqQ0fIQAcamWIWQ=.77c77064-a39a-4fc5-876b-4cfac3854e78@github.com>
References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com>
 <C8Dn9QEoUNrB-pwj8wP0IQEToP1zwqQ0fIQAcamWIWQ=.77c77064-a39a-4fc5-876b-4cfac3854e78@github.com>
Message-ID: <kRNWKyM1rzS4r2fbyh12VPs4FhPH6sPGKqhwct0ksTQ=.c7c26dd5-eed9-4889-9de6-7ca2f4186adc@github.com>

On Wed, 30 Oct 2024 06:19:21 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers.  Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21746#pullrequestreview-2406185452

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 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 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 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: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 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: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 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 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 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 egahlin at openjdk.org  Wed Oct 30 21:16:27 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 30 Oct 2024 21:16:27 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <hwdzHQ26Yw6OfOjAl3y26tG23y_BnnvHG6IT11okXP8=.0655857e-f862-4f90-b7c6-e33a42076a0b@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
 <hwdzHQ26Yw6OfOjAl3y26tG23y_BnnvHG6IT11okXP8=.0655857e-f862-4f90-b7c6-e33a42076a0b@github.com>
Message-ID: <PSryNsOqyQsoRUZKhODS5kEEi2Agf1-oX0tQjx9gWpU=.81b7db5a-6746-4f17-82ef-30a2d284e041@github.com>

On Wed, 30 Oct 2024 18:23:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> It is needed, because otherwise the `TestDefaultConfigurations` test fails:
>> 
>> 
>> java.lang.Exception: Setting 'stackTrace' in event 'jdk.CPUTimeSample' was not configured in the configuration 'default'
>> Setting 'stackTrace' in event 'jdk.CPUTimeSample' was not configured in the configuration 'profile'
>> 
>>         at jdk.jfr.event.metadata.TestDefaultConfigurations.throwExceptionWithErrors(TestDefaultConfigurations.java:115)
>>         at jdk.jfr.event.metadata.TestDefaultConfigurations.main(TestDefaultConfigurations.java:76)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:573)
>>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>>         at java.base/java.lang.Thread.run(Thread.java:1575)
>
> The problem is, is that `eventType.hasStackTrace()` checks for the existence of a field called `stackTrace`, which CPUTimeSample events have. We could of course rename the field to something like `recordedStackTrace`, but I don't think that this is helpful.

Shouldn't the event have a stackTrace setting and the setting be set to true in default.jfc, similar to ObjectAlllocationSample?

metadata.xml:
  <Event name="ObjectAllocationSample" thread="true" stackTrace="true" startTime="false" throttle="true">
    <Field type="Class" name="objectClass" label="Object Class" />
    <Field type="long" contentType="bytes" name="weight"  />
  </Event>

default.jfc:
  <event name="jdk.ObjectAllocationSample">
    <setting name="enabled">true</setting>
    <setting name="throttle">150/s</setting>
    <setting name="stackTrace">true</setting>
  </event>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823398616

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 jbechberger at openjdk.org  Wed Oct 30 21:29:19 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 30 Oct 2024 21:29:19 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <PSryNsOqyQsoRUZKhODS5kEEi2Agf1-oX0tQjx9gWpU=.81b7db5a-6746-4f17-82ef-30a2d284e041@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
 <hwdzHQ26Yw6OfOjAl3y26tG23y_BnnvHG6IT11okXP8=.0655857e-f862-4f90-b7c6-e33a42076a0b@github.com>
 <PSryNsOqyQsoRUZKhODS5kEEi2Agf1-oX0tQjx9gWpU=.81b7db5a-6746-4f17-82ef-30a2d284e041@github.com>
Message-ID: <NWcO9Gh_OdZtQ6BfEbdjhG7hTj2PazE7KxnqLH3GDl0=.d1e0e2ee-311e-49cd-8429-a456e4db3d03@github.com>

On Wed, 30 Oct 2024 21:11:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> The problem is, is that `eventType.hasStackTrace()` checks for the existence of a field called `stackTrace`, which CPUTimeSample events have. We could of course rename the field to something like `recordedStackTrace`, but I don't think that this is helpful.
>
> Shouldn't the event have a stackTrace setting and the setting be set to true in default.jfc, similar to ObjectAlllocationSample?
> 
> metadata.xml:
>   <Event name="ObjectAllocationSample" thread="true" stackTrace="true" startTime="false" throttle="true">
>     <Field type="Class" name="objectClass" label="Object Class" />
>     <Field type="long" contentType="bytes" name="weight"  />
>   </Event>
> 
> default.jfc:
>   <event name="jdk.ObjectAllocationSample">
>     <setting name="enabled">true</setting>
>     <setting name="throttle">150/s</setting>
>     <setting name="stackTrace">true</setting>
>   </event>

This would also be an option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823409449

From mgronlun at openjdk.org  Wed Oct 30 21:43:31 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 21:43:31 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <VPnIHJ_NNMj3FFT__70YGNveRxHdG_Ghsx6vGhO18qM=.d03f64ee-8fbf-4ff8-bb96-ad70fc431bf8@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #include "jfr/recorder/service/jfrOptionSet.hpp"

All includes except:

#include "precompiled.hpp"
#include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"
#include "utilities/debug.hpp"

Can be moved below #if defined(Linux) (to reduce compilation time on non-Linux platforms)

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 42:

> 40: 
> 41: #if defined(LINUX)
> 42: #include "signals_posix.hpp"

You will also need to include <sys/types.h> and change the type from OSThread::thread_id_t to pid_t, else you can get the following error:

"error: 'typedef pid_t OSThread::thread_id_t' is private within this context"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823419528
PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823424176

From mgronlun at openjdk.org  Wed Oct 30 21:48:32 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 21:48:32 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <NWcO9Gh_OdZtQ6BfEbdjhG7hTj2PazE7KxnqLH3GDl0=.d1e0e2ee-311e-49cd-8429-a456e4db3d03@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
 <hwdzHQ26Yw6OfOjAl3y26tG23y_BnnvHG6IT11okXP8=.0655857e-f862-4f90-b7c6-e33a42076a0b@github.com>
 <PSryNsOqyQsoRUZKhODS5kEEi2Agf1-oX0tQjx9gWpU=.81b7db5a-6746-4f17-82ef-30a2d284e041@github.com>
 <NWcO9Gh_OdZtQ6BfEbdjhG7hTj2PazE7KxnqLH3GDl0=.d1e0e2ee-311e-49cd-8429-a456e4db3d03@github.com>
Message-ID: <ZIbwbPPHHxXXcU6CWA95wO0mtGPiCqEk-M_HTd9WkCA=.a8c7814c-c9b1-4999-b723-f1bb462794d9@github.com>

On Wed, 30 Oct 2024 21:22:09 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Shouldn't the event have a stackTrace setting and the setting be set to true in default.jfc, similar to ObjectAlllocationSample?
>> 
>> metadata.xml:
>>   <Event name="ObjectAllocationSample" thread="true" stackTrace="true" startTime="false" throttle="true">
>>     <Field type="Class" name="objectClass" label="Object Class" />
>>     <Field type="long" contentType="bytes" name="weight"  />
>>   </Event>
>> 
>> default.jfc:
>>   <event name="jdk.ObjectAllocationSample">
>>     <setting name="enabled">true</setting>
>>     <setting name="throttle">150/s</setting>
>>     <setting name="stackTrace">true</setting>
>>   </event>
>> 
>>  OldObjectSample also works that way, but it has "cutoff" instead of "throttle".
>
> This would also be an option.

> The problem is, is that `eventType.hasStackTrace()` checks for the existence of a field called `stackTrace`, which CPUTimeSample events have. We could of course rename the field to something like `recordedStackTrace`, but I don't think that this is helpful.

Aha - so even if the event is not decorated with stackTrace=true in metadata.xml, it has an explicit field with the same name "StackTrace". Wonder why this should be handled differently from ExecutionSample?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823433881

From mgronlun at openjdk.org  Wed Oct 30 21:51:42 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Oct 2024 21:51:42 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
Message-ID: <fkVJsDI80bQZXxsaPLTCPsd-oek2Ln4hLA30HkWJdGM=.3aaa1a51-75bf-48f7-9145-8a8517003beb@github.com>

On Wed, 30 Oct 2024 18:16:25 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/jdk.jfr/share/conf/jfr/profile.jfc line 195:
>> 
>>> 193:     <event name="jdk.CPUTimeSample">
>>> 194:       <setting name="enabled" control="method-sampling-enabled">false</setting>
>>> 195:       <setting name="throttle">10ms</setting>
>> 
>> Can a rate be given here instead of an absolute value? Otherwise, there is a mismatch between the default. jfc and the profile.jfc which seems quite unintuitive.
>
> I wanted to give the user the info that both formats are usable (because this is documented nowhere else) and in profiling we usually don't care about having too many events.

We do care about having too many events, even for profiling.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823436294

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 duke at openjdk.org  Wed Oct 30 22:00:08 2024
From: duke at openjdk.org (hanklo6)
Date: Wed, 30 Oct 2024 22:00:08 GMT
Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor
 of instructions
Message-ID: <XAO3q0dE73dytIygykaXGEOFwCGuc1hQf_81UzUSssA=.e79b92a1-87e9-45f4-9801-c1bbd17f0d2f@github.com>

Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions.

Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html.

-------------

Commit messages:
 - Add popcnt feature
 - Add ndd and nf tests

Changes: https://git.openjdk.org/jdk/pull/21795/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343317
  Stats: 3415 lines in 5 files changed: 2272 ins; 285 del; 858 mod
  Patch: https://git.openjdk.org/jdk/pull/21795.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21795/head:pull/21795

PR: https://git.openjdk.org/jdk/pull/21795

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 jiangli at openjdk.org  Thu Oct 31 01:15:40 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 31 Oct 2024 01:15:40 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <xMfGwygwvEEqpdyRINSpxEFWIgv_Rnu0ccet-vOITcA=.efa2cc8a-bb0e-43b4-bf3a-27fcd3367a38@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <xMfGwygwvEEqpdyRINSpxEFWIgv_Rnu0ccet-vOITcA=.efa2cc8a-bb0e-43b4-bf3a-27fcd3367a38@github.com>
Message-ID: <bIpOEkf2v1o9kAHQ0A0If0TQM0vgV8r3hUsYjvYu3Dw=.7d9962d0-0693-4f10-86da-198988ddc178@github.com>

On Thu, 24 Oct 2024 23:36:19 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't hardcode server variant
>
>> > > When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
>> > > I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
>> > > @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.
>> > 
>> > 
>> > @magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.
>> 
>> Sorry for the delay. I finally found some time to look into this today. Running the latest `static-jdk` `bin/java` built from your branch fails for me as well:
>> 
>> ```
>> $ bin/java
>> Error: failed , because bin/java: undefined symbol: JNI_CreateJavaVM
>> ```
>> 
>> I only took a quick look, but I think this looks like https://bugs.openjdk.org/browse/JDK-8339522 that I filed in September.
>> 
>> ```
>> $ nm bin/java | grep JNI_CreateJavaVM
>> 000000000162733c t JNI_CreateJavaVM
>> 0000000001626e75 t _ZL22JNI_CreateJavaVM_innerPP7JavaVM_PPvS2_
>> jianglizhou at leia:~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ nm -D bin/java | grep JNI_CreateJavaVM
>> ```
>> 
>> The VM dynamic symbols are not exported properly. This is related to the [#20837 (comment)](https://github.com/openjdk/jdk/pull/20837#discussion_r1744611776) discussion comment thread.
> 
> Checking the `ld` command line, I think it is indeed https://bugs.openjdk.org/browse/JDK-8339522 issue. `-Wl,--exclude-libs,ALL` is included in the command:
> 
> $ cat ./support/static-native/launcher/BUILD_LAUNCHER_java_run_ld.cmdline
> /usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,-z,noexecstack -m64 -pie -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -Wl,-rpath,$ORIGIN -Wl,--disable-new-dtags -Wl,-rpath,$ORIGIN/../lib -Wl,--disable-new-dtags -o /...jianglizhou/github/jdk_pull_20837/build/...

> @jianglizhou I fixed the bug with `-Wl,--exclude-libs,ALL` not being properly filtered out.
> 
> However, I still get the jimage problem:
> 
> ```
> $ build/linux-x64/images/static-jdk/bin/java closed/make/scripts/GenerateSecureId.java 
> Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
> Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin
> Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
> ```

Hi @magicus, I applied your latest commit, https://github.com/openjdk/jdk/pull/20837/commits/1d375bb4060540930f119881e91dbc27154c493e. I built JDK images for `linux-x86_64-server-slowdebug` with the new change. `gcc` was used in my build.

I was able to run `HelloWorld` using the static-jdk/bin/java without failure. I think that's good news. 


~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ bin/java -cp ~/tests/hw.jar HelloWorld
HelloWorld


Do you want to try applying your patch from this PR in a clean github local branch to see if that makes any difference?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2448803294

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 fyang at openjdk.org  Thu Oct 31 01:35:36 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 31 Oct 2024 01:35:36 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v12]
In-Reply-To: <5CRRnynK_o74GMH0-cFZyieGaWn29hVsyZEuesaG-vg=.6795a4b1-322b-42d9-8df0-bf39d77a4075@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <5CRRnynK_o74GMH0-cFZyieGaWn29hVsyZEuesaG-vg=.6795a4b1-322b-42d9-8df0-bf39d77a4075@github.com>
Message-ID: <AdjDtm9X-wWUfSU9KUTSX4JLokj1GRUHx7Yb7pQCMu4=.022a4dcc-e41d-465b-995b-55fed24f5dfe@github.com>

On Wed, 30 Oct 2024 14:23:42 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand the comment on endian swap

Looks good. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19960#pullrequestreview-2406774617

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 dholmes at openjdk.org  Thu Oct 31 02:49:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:49:36 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <L9C3etDoJwskX8Hbph--2Ru9fe0qS3bDwrsq803SWls=.8725e950-5407-4c51-9a1d-2ebacb1afc92@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <nZoyPIrDbGpJJY8z_WmaPCHxAdu35C9oxTYiG4q5P24=.33d6fc3b-5975-42ab-989b-9506fd00d182@github.com>
 <L9C3etDoJwskX8Hbph--2Ru9fe0qS3bDwrsq803SWls=.8725e950-5407-4c51-9a1d-2ebacb1afc92@github.com>
Message-ID: <npMV8v-xHB1a9qUacb6yQ-jNzSXLA20vNc8BTB9KRjI=.eff7140b-046e-4b62-b6e7-5acad5cbe80a@github.com>

On Wed, 30 Oct 2024 09:11:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Perhaps `os::javaTimeNanos()` would be better? It provides global monotonic time.
>> OTOH, `os::javaTimeMillis()` can move unexpectedly - a good example is the daylight saving time where the millis would suddenly jump 1 hour to the past.
>
> Good point, I totally forgot about the monotonicity.

DST changes are not reflected in the low-level clocks, they come from higher-level API's that format times and account for TZ.

The clock underpinning `javaTimeMillis` can still jump due to NTP adjustments and so a monotonic clock source is preferable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823709080

From dholmes at openjdk.org  Thu Oct 31 02:53:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:53:35 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <dfBuPHWXT2pvTFx3XlL2zTc9JRBw_TGMDmuPWZFp8BA=.0b9c131e-e032-4b0c-8abf-a8eaf465fc52@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <dfBuPHWXT2pvTFx3XlL2zTc9JRBw_TGMDmuPWZFp8BA=.0b9c131e-e032-4b0c-8abf-a8eaf465fc52@github.com>
Message-ID: <aNi8tDTOvT2AFNYNz1LHPrn_UexQ68zvRutehJrL2dc=.045f35ed-cda1-40b1-94ae-979aa72b4e96@github.com>

On Wed, 30 Oct 2024 09:05:42 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> This is called transitively from the Java code whenever the event is first enabled. So this should lead to a safepoint?
>
> AFAIK, we are removing the timers once all recordings with the cpu profiler event are closed. And would re-add them when another recording is started later, right?
> In that case, if we force a global safepoint in order to init/remove timers we could get an unexpectly high amount of safepoints, dependent on the external factors starting/stopping/configuring JFR recordings.
> 
> @dholmes-ora What exactly is the concern here? I just want to understand if the concern really warrants increasing the number of global safepoints when using JFR with this sampler.

@jbachorik if you take out the `Threads_lock` you will delay real safepoints. Direct use of the Threads_lock is not desirable as it can lead to unexpected deadlocks and interferes with safepoints.

If all you want is to create timers for all existing threads then use of a ThreadsListIterator should suffice as a snapshot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823711090

From dholmes at openjdk.org  Thu Oct 31 02:59:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:59:34 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <uEjMq-544miu8dKkaQ7IBzkFt4IaDHfsNSFZZFpn8jM=.f0eebff9-0732-4d98-9f0e-ba5b9ed846b8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <uEjMq-544miu8dKkaQ7IBzkFt4IaDHfsNSFZZFpn8jM=.f0eebff9-0732-4d98-9f0e-ba5b9ed846b8@github.com>
Message-ID: <4UKrYUWVTFaWJOZ1vWneEnYodZs3leVoHyb8DWj0zec=.aa2eca4b-a49b-4c8d-bc16-62f81c3e38a4@github.com>

On Wed, 30 Oct 2024 18:07:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Similarity to the other sampler.
>
> And it's far easier to read.

I certainly disagree on the readability aspect. The switch means I have to look through each section to figure out what it does for each state. In contrast:

state = ...
return state == _thread_in_Java || state == _thread_in_Java_trans;
``
is IMO blindingly obvious.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823713022

From dholmes at openjdk.org  Thu Oct 31 02:59:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:59:35 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
Message-ID: <HdjxrMhyfrOnulrm0jjgADGssc5dXSybbkFm7G8-WkI=.017ca230-c78f-4eae-8a68-38205dc70de2@github.com>

On Wed, 30 Oct 2024 07:32:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 78:
>> 
>>> 76: }
>>> 77: 
>>> 78: static bool thread_state_in_native(JavaThread* thread) {
>> 
>> Whatever this is checking it is not what we normally call "in native" so please come up with a different name.
>
> This is the same name the other sampler uses.

Ugghh!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823713147

From dholmes at openjdk.org  Thu Oct 31 02:59:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:59:36 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <aNi8tDTOvT2AFNYNz1LHPrn_UexQ68zvRutehJrL2dc=.045f35ed-cda1-40b1-94ae-979aa72b4e96@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <dfBuPHWXT2pvTFx3XlL2zTc9JRBw_TGMDmuPWZFp8BA=.0b9c131e-e032-4b0c-8abf-a8eaf465fc52@github.com>
 <aNi8tDTOvT2AFNYNz1LHPrn_UexQ68zvRutehJrL2dc=.045f35ed-cda1-40b1-94ae-979aa72b4e96@github.com>
Message-ID: <DAOaqwbQPp8Tns9W1T7X_Iy_NPPcNbmXAv8RTMP-4uk=.c1d83cf2-6aed-43c2-ae44-c21e47f7c293@github.com>

On Thu, 31 Oct 2024 02:50:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> AFAIK, we are removing the timers once all recordings with the cpu profiler event are closed. And would re-add them when another recording is started later, right?
>> In that case, if we force a global safepoint in order to init/remove timers we could get an unexpectly high amount of safepoints, dependent on the external factors starting/stopping/configuring JFR recordings.
>> 
>> @dholmes-ora What exactly is the concern here? I just want to understand if the concern really warrants increasing the number of global safepoints when using JFR with this sampler.
>
> @jbachorik if you take out the `Threads_lock` you will delay real safepoints. Direct use of the Threads_lock is not desirable as it can lead to unexpected deadlocks and interferes with safepoints.
> 
> If all you want is to create timers for all existing threads then use of a ThreadsListIterator should suffice as a snapshot.

Of course you are racing with the execution of those other threads either way. In contrast if you do this at a safepoint you know the exact state of each thread and will know, for example, that the timer was created before the thread could terminate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823714552

From dholmes at openjdk.org  Thu Oct 31 03:02:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 03:02:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
Message-ID: <e44AOwz4rby858CKqhN0YHUMTOIdOPj_1Cu3iDlDn10=.65fb6863-dbc4-4e0f-9bfd-fc6b493ee534@github.com>

On Wed, 30 Oct 2024 07:31:02 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 41:
>> 
>>> 39: #include "runtime/osThread.hpp"
>>> 40: 
>>> 41: #if defined(LINUX)
>> 
>> If this is all Linux specific then can't we put it in a linux-specific sourcefile instead of masquerading as shared code?
>
> The idea is to place it close to the other method sampler.

Why? Large chunks of platform specific code should be in platform specific files. That is the way hotspot sources are arranged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823716347

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 dholmes at openjdk.org  Thu Oct 31 05:38:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 05:38:29 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace [v2]
In-Reply-To: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
 <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com>
Message-ID: <1xurMyjTB2XPkn57XaTDNUGXaTY614wIdQv1KfV-FpA=.4a31bef2-a80f-4749-95e9-ff41952f2a52@github.com>

On Wed, 30 Oct 2024 12:03:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/oops/instanceKlass.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/share/oops/instanceKlass.cpp line 460:

> 458:   // are the only ones that require compression and allocation in the limited class metaspace
> 459:   // region.  But ... there are C2 dependencies that all klasses are allocated to the class metaspace, so
> 460:   // always use the class metaspace until JDK-NNNNNNN is resolved.

JDK-NNNNNN was supposed to be replaced by an actual bug number. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21769#discussion_r1823791677

From jbechberger at openjdk.org  Thu Oct 31 06:46:36 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 06:46:36 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <4UKrYUWVTFaWJOZ1vWneEnYodZs3leVoHyb8DWj0zec=.aa2eca4b-a49b-4c8d-bc16-62f81c3e38a4@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <uEjMq-544miu8dKkaQ7IBzkFt4IaDHfsNSFZZFpn8jM=.f0eebff9-0732-4d98-9f0e-ba5b9ed846b8@github.com>
 <4UKrYUWVTFaWJOZ1vWneEnYodZs3leVoHyb8DWj0zec=.aa2eca4b-a49b-4c8d-bc16-62f81c3e38a4@github.com>
Message-ID: <cXi4ygmgUyPsdnFLD7SmpZboHQqhlsgcQRb5FAoU6l0=.bd90ca7c-8158-4f91-9876-21c47aa7533a@github.com>

On Thu, 31 Oct 2024 02:54:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> And it's far easier to read.
>
> I certainly disagree on the readability aspect. The switch means I have to look through each section to figure out what it does for each state. In contrast:
> 
> state = ...
> return state == _thread_in_Java || state == _thread_in_Java_trans;
> ``
> is IMO blindingly obvious.

But this doesn't check whether the state could be something new an unsupported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823830091

From jbechberger at openjdk.org  Thu Oct 31 06:46:36 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 06:46:36 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <HdjxrMhyfrOnulrm0jjgADGssc5dXSybbkFm7G8-WkI=.017ca230-c78f-4eae-8a68-38205dc70de2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <HdjxrMhyfrOnulrm0jjgADGssc5dXSybbkFm7G8-WkI=.017ca230-c78f-4eae-8a68-38205dc70de2@github.com>
Message-ID: <iNm5V8IrqTeKYrG5B8C2lBi9yXsGAoyApkpw9Er_XQ8=.e0cd1392-84ae-48e8-9534-f9f3846ff135@github.com>

On Thu, 31 Oct 2024 02:54:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the same name the other sampler uses.
>
> Ugghh!

Should I instead name it `non_java`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823829385

From jbechberger at openjdk.org  Thu Oct 31 06:46:37 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 06:46:37 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <npMV8v-xHB1a9qUacb6yQ-jNzSXLA20vNc8BTB9KRjI=.eff7140b-046e-4b62-b6e7-5acad5cbe80a@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <nZoyPIrDbGpJJY8z_WmaPCHxAdu35C9oxTYiG4q5P24=.33d6fc3b-5975-42ab-989b-9506fd00d182@github.com>
 <L9C3etDoJwskX8Hbph--2Ru9fe0qS3bDwrsq803SWls=.8725e950-5407-4c51-9a1d-2ebacb1afc92@github.com>
 <npMV8v-xHB1a9qUacb6yQ-jNzSXLA20vNc8BTB9KRjI=.eff7140b-046e-4b62-b6e7-5acad5cbe80a@github.com>
Message-ID: <IGp8hJb9wMvnt0z38UCy9ig9-JDAjkM87kHqZnTDS48=.9658b0a7-0660-4056-b187-eae96905d993@github.com>

On Thu, 31 Oct 2024 02:46:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Good point, I totally forgot about the monotonicity.
>
> DST changes are not reflected in the low-level clocks, they come from higher-level API's that format times and account for TZ.
> 
> The clock underpinning `javaTimeMillis` can still jump due to NTP adjustments and so a monotonic clock source is preferable.

So this issue is now resolved?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823830912

From jbechberger at openjdk.org  Thu Oct 31 06:46:38 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 06:46:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <DAOaqwbQPp8Tns9W1T7X_Iy_NPPcNbmXAv8RTMP-4uk=.c1d83cf2-6aed-43c2-ae44-c21e47f7c293@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <dfBuPHWXT2pvTFx3XlL2zTc9JRBw_TGMDmuPWZFp8BA=.0b9c131e-e032-4b0c-8abf-a8eaf465fc52@github.com>
 <aNi8tDTOvT2AFNYNz1LHPrn_UexQ68zvRutehJrL2dc=.045f35ed-cda1-40b1-94ae-979aa72b4e96@github.com>
 <DAOaqwbQPp8Tns9W1T7X_Iy_NPPcNbmXAv8RTMP-4uk=.c1d83cf2-6aed-43c2-ae44-c21e47f7c293@github.com>
Message-ID: <GLok80xUs-REbXEN8N2sfY7DwpDjope9oNqBMAxayRA=.0b5cd087-7981-45e9-ad9a-55a496e49bd3@github.com>

On Thu, 31 Oct 2024 02:56:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @jbachorik if you take out the `Threads_lock` you will delay real safepoints. Direct use of the Threads_lock is not desirable as it can lead to unexpected deadlocks and interferes with safepoints.
>> 
>> If all you want is to create timers for all existing threads then use of a ThreadsListIterator should suffice as a snapshot.
>
> Of course you are racing with the execution of those other threads either way. In contrast if you do this at a safepoint you know the exact state of each thread and will know, for example, that the timer was created before the thread could terminate.

How would I implement this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823828705

From jbechberger at openjdk.org  Thu Oct 31 06:46:38 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 06:46:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <fkVJsDI80bQZXxsaPLTCPsd-oek2Ln4hLA30HkWJdGM=.3aaa1a51-75bf-48f7-9145-8a8517003beb@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
 <fkVJsDI80bQZXxsaPLTCPsd-oek2Ln4hLA30HkWJdGM=.3aaa1a51-75bf-48f7-9145-8a8517003beb@github.com>
Message-ID: <8fM5N_qr8KP7heWmKun5JVBU095ELhn_cxYSwpb9O8U=.2419d2a6-4172-4b5d-bea6-2a2b13bb0ea5@github.com>

On Wed, 30 Oct 2024 21:48:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I wanted to give the user the info that both formats are usable (because this is documented nowhere else) and in profiling we usually don't care about having too many events.
>
> We do care about having too many events, even for profiling.

If you say so. Then I set the value to `2000/s` and we're fine?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1823839732

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 thartmann at openjdk.org  Thu Oct 31 07:00:44 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 07:00:44 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <MEWT4dAX_tM63K0EzVObCswZgzhZYRDvGy4EETOD9MM=.26e6b79d-5c0c-4b5b-96fd-6a5fd6b2ae77@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

This caused a regression: [JDK-8343246](https://bugs.openjdk.org/browse/JDK-8343246) Jatin, could you please have a look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2449161173

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 rehn at openjdk.org  Thu Oct 31 08:04:32 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 31 Oct 2024 08:04:32 GMT
Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address
In-Reply-To: <N6GG9Rmbiv6TPtv1VjOgmBDvprBUvxWbjXXYzSFdtgs=.c4049de7-7e25-487d-8fea-c8daa7f9496d@github.com>
References: <N6GG9Rmbiv6TPtv1VjOgmBDvprBUvxWbjXXYzSFdtgs=.c4049de7-7e25-487d-8fea-c8daa7f9496d@github.com>
Message-ID: <x0fdo-HqS573qX1WXGqX95OVZdlfwXe72hRPvkHUjQw=.b19c2041-dd22-4c92-aeea-65751a8e9d0d@github.com>

On Wed, 30 Oct 2024 00:28:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please consider this refactoring work.
> 
> Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address.
> While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is
> reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi
> pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about
> the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732).
> 
> I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the
> `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`.
> Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check
> whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)`
> as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code
> cache won't be affected. And I don't think the original distance check from code cache will benefit us much more.
> Eyeballed all `la(Address)` callsites, I think we are fine.
> 
> Benefits:
> 1. We have a simpler `la(address)` which is kind of spec compatible;
> 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`;
> 3. We don't need explicit use of `relocate` with lambda for most of the places;
> 
> Note that there are several places where we want explicit `movptr` sequence:
> 1. In `SignatureHandlerGenerator::generate()` where the emitted code is copied without relocation [1];
> 2. In `movoop` and `mov_metadata` where we want patching afterwards;
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313
> 
> Testing on linux-riscv64:
> - [x] hotspot:tier1 (fastdebug)
> - [x] tier1-tier3, hotspot:tier4 (release)
> - [x] specjbb2015, dacapo, renaissance (release)

Hi, I agree with the sentiment of the CR.

Thinking about the is_32bit_offset_from_codecache vs CodeCache::contains change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21777#issuecomment-2449265091

From fyang at openjdk.org  Thu Oct 31 08:19:28 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 31 Oct 2024 08:19:28 GMT
Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address
In-Reply-To: <x0fdo-HqS573qX1WXGqX95OVZdlfwXe72hRPvkHUjQw=.b19c2041-dd22-4c92-aeea-65751a8e9d0d@github.com>
References: <N6GG9Rmbiv6TPtv1VjOgmBDvprBUvxWbjXXYzSFdtgs=.c4049de7-7e25-487d-8fea-c8daa7f9496d@github.com>
 <x0fdo-HqS573qX1WXGqX95OVZdlfwXe72hRPvkHUjQw=.b19c2041-dd22-4c92-aeea-65751a8e9d0d@github.com>
Message-ID: <Q64NQJxFXGy8czJa2w5DhAZ4VdBvSTFyO1mPLqsPnss=.e7e03b1d-0bd5-4b1f-954b-52dda2014d08@github.com>

On Thu, 31 Oct 2024 08:02:19 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, I agree with the sentiment of the CR.
> 
> Thinking about the is_32bit_offset_from_codecache vs CodeCache::contains change.

Thanks! Note that I didn't remove this `is_32bit_offset_from_codecache` check as I am guessing that we might find a better way of using this check after this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21777#issuecomment-2449288236

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 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 mgronlun at openjdk.org  Thu Oct 31 09:58:51 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 09:58:51 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <8fM5N_qr8KP7heWmKun5JVBU095ELhn_cxYSwpb9O8U=.2419d2a6-4172-4b5d-bea6-2a2b13bb0ea5@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <EosTug8E_be7MeK1tFrtvNZbEfEllPuWOpzwVzvvgYI=.95200ebd-ee1a-4264-a500-6d8b7242f946@github.com>
 <FcjUX5AsU0HshTdZ8vCQnJ3r9PQsOitops_5LNVb2fY=.4c2f14f5-b91c-44e4-bd7f-cd6eeebbb7cd@github.com>
 <fkVJsDI80bQZXxsaPLTCPsd-oek2Ln4hLA30HkWJdGM=.3aaa1a51-75bf-48f7-9145-8a8517003beb@github.com>
 <8fM5N_qr8KP7heWmKun5JVBU095ELhn_cxYSwpb9O8U=.2419d2a6-4172-4b5d-bea6-2a2b13bb0ea5@github.com>
Message-ID: <81JToiHQF-r-a8nhfoZQcO50iIqnwIpEOqF-N7QyW_E=.46bbc341-94fb-4e20-a299-0750278fc1fc@github.com>

On Thu, 31 Oct 2024 06:43:26 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> We do care about having too many events, even for profiling.
>
> If you say so. Then I set the value to `2000/s` and we're fine?

If that is the recalculation from 10 ms according to the adjustments, then yes, this is preferable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824179982

From jbechberger at openjdk.org  Thu Oct 31 10:06:46 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 10:06:46 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <cXi4ygmgUyPsdnFLD7SmpZboHQqhlsgcQRb5FAoU6l0=.bd90ca7c-8158-4f91-9876-21c47aa7533a@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <uEjMq-544miu8dKkaQ7IBzkFt4IaDHfsNSFZZFpn8jM=.f0eebff9-0732-4d98-9f0e-ba5b9ed846b8@github.com>
 <4UKrYUWVTFaWJOZ1vWneEnYodZs3leVoHyb8DWj0zec=.aa2eca4b-a49b-4c8d-bc16-62f81c3e38a4@github.com>
 <cXi4ygmgUyPsdnFLD7SmpZboHQqhlsgcQRb5FAoU6l0=.bd90ca7c-8158-4f91-9876-21c47aa7533a@github.com>
Message-ID: <ukCDewDXzaO4LFZWrz9JE3pfGnDgn_OEoc4GXsnBsAI=.7168ce3b-5fd1-4633-9f4e-8ee78f1a3dea@github.com>

On Thu, 31 Oct 2024 06:40:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I certainly disagree on the readability aspect. The switch means I have to look through each section to figure out what it does for each state. In contrast:
>> 
>> state = ...
>> return state == _thread_in_Java || state == _thread_in_Java_trans;
>> ``
>> is IMO blindingly obvious.
>
> But this doesn't check whether the state could be something new an unsupported.

I changed it to your recommendation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824195469

From jbechberger at openjdk.org  Thu Oct 31 10:06:47 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 10:06:47 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <iNm5V8IrqTeKYrG5B8C2lBi9yXsGAoyApkpw9Er_XQ8=.e0cd1392-84ae-48e8-9534-f9f3846ff135@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <HdjxrMhyfrOnulrm0jjgADGssc5dXSybbkFm7G8-WkI=.017ca230-c78f-4eae-8a68-38205dc70de2@github.com>
 <iNm5V8IrqTeKYrG5B8C2lBi9yXsGAoyApkpw9Er_XQ8=.e0cd1392-84ae-48e8-9534-f9f3846ff135@github.com>
Message-ID: <SBXiG22H1Ei9Em6AZQMhqKrZak5WPUFtK7F3QhrrILI=.295516fb-ae96-43be-9265-83ff5caa162b@github.com>

On Thu, 31 Oct 2024 06:38:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Ugghh!
>
> Should I instead name it `non_java`?

I renamed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824194941

From mgronlun at openjdk.org  Thu Oct 31 10:06:48 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 10:06:48 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <LC9n8yyeiUTrZMfHZz8nEPHHGhv8_9xieEPuOekSa0I=.1ebbeb5e-a418-4e8a-ae22-a09692bc472e@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 45:

> 43: 
> 44: bool JfrAsyncStackTrace::record_async(JavaThread* jt, const frame& frame) {
> 45:   NoHandleMark nhm;

Stack: [0x00007f02ff2f4000,0x00007f02ff3f4000],  sp=0x00007f02ff3ed8e0,  free space=998k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xdf5649]  HandleArea::allocate_null_handle()+0x179  (handles.cpp:46)
V  [libjvm.so+0xc5259a]  RegisterMap::RegisterMap(JavaThread*, RegisterMap::UpdateMap, RegisterMap::ProcessFrames, RegisterMap::WalkContinuation)+0xaa  (frame.cpp:75)
V  [libjvm.so+0xf9ffb9]  JfrVframeStream::JfrVframeStream(JavaThread*, frame const&, bool, bool)+0x59  (jfrStackTrace.cpp:160)
V  [libjvm.so+0xf0940c]  JfrAsyncStackTrace::record_async(JavaThread*, frame const&)+0xac  (jfrAsyncStackTrace.cpp:58)
V  [libjvm.so+0xf0be3d]  JfrCPUTimeThreadSampler::handle_timer_signal(void*)+0x4fd  (jfrCPUTimeThreadSampler.cpp:231)
V  [libjvm.so+0xf0bf7f]  handle_timer_signal(int, siginfo*, void*)+0x4f  (jfrCPUTimeThreadSampler.cpp:723)

NoHandleMark will not work with with continuations. Please see how we do it in JfrStackTrace::record()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824190841

From burban at openjdk.org  Thu Oct 31 10:12:29 2024
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Thu, 31 Oct 2024 10:12:29 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken
In-Reply-To: <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com>
 <CuOj12vy1DIujX5OKFyYKCpkO4zeEvpYoc7FbODJQMk=.ad5296f2-0590-451d-942c-22fc3063a19f@github.com>
 <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com>
Message-ID: <PNSz5sVQdOLiJeNS0kwnpIPLHhhnA-whfsOEtANge48=.ea780c97-4068-4484-8731-7559cae0b17d@github.com>

On Tue, 22 Oct 2024 09:43:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> You mean the entire custom frem and drem implementation unique to x64 Windows, or just this block of constants here? These constants are used by the custom Windows implementation, so they have to be in the same file. Moving the entire definition for Windows x64 to sharedRuntime_x86_64.cpp seems to be duplicating code even more, and I still don't know whether this is the right solution. It may be that this custom implementation may not be needed anymore and should be removed, which is why I left it in the sharedRuntime_x86.cpp file for the time being
>
> I did mean the entire thing. I don't see any point in WIN64 code being in the x86 file when there is an x86_64 file. Of course I had forgotten about the Aarch64 Windows side, so maybe as I said this is really something for a os/windows file rather then `cpu/<arch>` ?

If it's needed on AArch64 too, this should move to something in `os/windows` as David said.

However, judging from the comment in https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/src/hotspot/os/windows/sharedRuntimeRem.cpp#L34-L38 this workaround might not be needed anymore.  The minimum version required for Windows-AArch64 is VS2017 (or even VS2019?), and for Windows-X64 apparently VS2022 is used (not sure what the minimum is): https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/make/conf/jib-profiles.js#L1105


So maybe this can be removed altogether?  Someone needs to check if this assumption is still true today.

Alas I don't have a Windows setup anymore.  @karianna who is the local HotSpot Windows expert these days who could have a look at this? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1824202682

From rehn at openjdk.org  Thu Oct 31 10:21:39 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 31 Oct 2024 10:21:39 GMT
Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address
In-Reply-To: <N6GG9Rmbiv6TPtv1VjOgmBDvprBUvxWbjXXYzSFdtgs=.c4049de7-7e25-487d-8fea-c8daa7f9496d@github.com>
References: <N6GG9Rmbiv6TPtv1VjOgmBDvprBUvxWbjXXYzSFdtgs=.c4049de7-7e25-487d-8fea-c8daa7f9496d@github.com>
Message-ID: <U_iEd1rtnCARTTPcJ_Y0cC57kirlwmVVOkpC10xDvg4=.1677e1bc-d888-458a-b638-56fd992410e3@github.com>

On Wed, 30 Oct 2024 00:28:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please consider this refactoring work.
> 
> Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address.
> While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is
> reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi
> pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about
> the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732).
> 
> I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the
> `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`.
> Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check
> whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)`
> as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code
> cache won't be affected. And I don't think the original distance check from code cache will benefit us much more.
> Eyeballed all `la(Address)` callsites, I think we are fine.
> 
> Benefits:
> 1. We have a simpler `la(address)` which is kind of spec compatible;
> 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`;
> 3. We don't need explicit use of `relocate` with lambda for most of the places;
> 
> Note that there are several places where we want explicit `movptr` sequence:
> 1. In `SignatureHandlerGenerator::generate()` where the emitted code is copied without relocation [1];
> 2. In `movoop` and `mov_metadata` where we want patching afterwards;
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313
> 
> Testing on linux-riscv64:
> - [x] hotspot:tier1 (fastdebug)
> - [x] tier1-tier3, hotspot:tier4 (release)
> - [x] specjbb2015, dacapo, renaissance (release)

Did you run any micro benchmarks? Maybe skynet just to check VTs.
And did you do any measurement on code cache size?

I can't find anything that would matter, but I'll look a bit more.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21777#issuecomment-2449507657

From mgronlun at openjdk.org  Thu Oct 31 10:30:47 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 10:30:47 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <LC9n8yyeiUTrZMfHZz8nEPHHGhv8_9xieEPuOekSa0I=.1ebbeb5e-a418-4e8a-ae22-a09692bc472e@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <LC9n8yyeiUTrZMfHZz8nEPHHGhv8_9xieEPuOekSa0I=.1ebbeb5e-a418-4e8a-ae22-a09692bc472e@github.com>
Message-ID: <2NwYW96LtQYBAH_mSxlo24yxc5IWMcy9Mql1TKTLpIs=.a8c69824-c239-473f-bec6-bbb678a90c39@github.com>

On Thu, 31 Oct 2024 10:02:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove min_valid_free_size_bytes
>
> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 45:
> 
>> 43: 
>> 44: bool JfrAsyncStackTrace::record_async(JavaThread* jt, const frame& frame) {
>> 45:   NoHandleMark nhm;
> 
> Stack: [0x00007f02ff2f4000,0x00007f02ff3f4000],  sp=0x00007f02ff3ed8e0,  free space=998k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xdf5649]  HandleArea::allocate_null_handle()+0x179  (handles.cpp:46)
> V  [libjvm.so+0xc5259a]  RegisterMap::RegisterMap(JavaThread*, RegisterMap::UpdateMap, RegisterMap::ProcessFrames, RegisterMap::WalkContinuation)+0xaa  (frame.cpp:75)
> V  [libjvm.so+0xf9ffb9]  JfrVframeStream::JfrVframeStream(JavaThread*, frame const&, bool, bool)+0x59  (jfrStackTrace.cpp:160)
> V  [libjvm.so+0xf0940c]  JfrAsyncStackTrace::record_async(JavaThread*, frame const&)+0xac  (jfrAsyncStackTrace.cpp:58)
> V  [libjvm.so+0xf0be3d]  JfrCPUTimeThreadSampler::handle_timer_signal(void*)+0x4fd  (jfrCPUTimeThreadSampler.cpp:231)
> V  [libjvm.so+0xf0bf7f]  handle_timer_signal(int, siginfo*, void*)+0x4f  (jfrCPUTimeThreadSampler.cpp:723)
> 
> NoHandleMark will not work with with continuations. Please see how we do it in JfrStackTrace::record()

Perhaps even more interesting is that I got this when running out-of-the-box with:

XX:StartFlightRecording:settings=profile.jfc

// profile.jfc

    <event name="jdk.CPUTimeSample">
      <setting name="enabled" control="method-sampling-enabled">false</setting>
      <setting name="throttle">10ms</setting>
    </event>
    
This indicates that the event is turned on, despite "enabled" being false. Is there a bug in the control / enable setting mechanism?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824224961

From jbechberger at openjdk.org  Thu Oct 31 12:05:42 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 12:05:42 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <2NwYW96LtQYBAH_mSxlo24yxc5IWMcy9Mql1TKTLpIs=.a8c69824-c239-473f-bec6-bbb678a90c39@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <LC9n8yyeiUTrZMfHZz8nEPHHGhv8_9xieEPuOekSa0I=.1ebbeb5e-a418-4e8a-ae22-a09692bc472e@github.com>
 <2NwYW96LtQYBAH_mSxlo24yxc5IWMcy9Mql1TKTLpIs=.a8c69824-c239-473f-bec6-bbb678a90c39@github.com>
Message-ID: <zz0K0pDqyF2QkmItlRRHCWGpGM6O4DsEYhmgW42I-wA=.58ff57d3-2ee0-49d7-9479-8afbe227de3a@github.com>

On Thu, 31 Oct 2024 10:27:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 45:
>> 
>>> 43: 
>>> 44: bool JfrAsyncStackTrace::record_async(JavaThread* jt, const frame& frame) {
>>> 45:   NoHandleMark nhm;
>> 
>> Stack: [0x00007f02ff2f4000,0x00007f02ff3f4000],  sp=0x00007f02ff3ed8e0,  free space=998k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0xdf5649]  HandleArea::allocate_null_handle()+0x179  (handles.cpp:46)
>> V  [libjvm.so+0xc5259a]  RegisterMap::RegisterMap(JavaThread*, RegisterMap::UpdateMap, RegisterMap::ProcessFrames, RegisterMap::WalkContinuation)+0xaa  (frame.cpp:75)
>> V  [libjvm.so+0xf9ffb9]  JfrVframeStream::JfrVframeStream(JavaThread*, frame const&, bool, bool)+0x59  (jfrStackTrace.cpp:160)
>> V  [libjvm.so+0xf0940c]  JfrAsyncStackTrace::record_async(JavaThread*, frame const&)+0xac  (jfrAsyncStackTrace.cpp:58)
>> V  [libjvm.so+0xf0be3d]  JfrCPUTimeThreadSampler::handle_timer_signal(void*)+0x4fd  (jfrCPUTimeThreadSampler.cpp:231)
>> V  [libjvm.so+0xf0bf7f]  handle_timer_signal(int, siginfo*, void*)+0x4f  (jfrCPUTimeThreadSampler.cpp:723)
>> 
>> NoHandleMark will not work with with continuations. Please see how we do it in JfrStackTrace::record()
>
> Perhaps even more interesting is that I got this when running out-of-the-box with:
> 
> XX:StartFlightRecording:settings=profile.jfc
> 
> // profile.jfc
> 
>     <event name="jdk.CPUTimeSample">
>       <setting name="enabled" control="method-sampling-enabled">false</setting>
>       <setting name="throttle">10ms</setting>
>     </event>
>     
> This indicates that the event is turned on, despite "enabled" being false. Is there a bug in the control / enable setting mechanism?

That is both interesting (and worrying). I'm going to write a test for the latter issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824337052

From duke at openjdk.org  Thu Oct 31 12:22:36 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 31 Oct 2024 12:22:36 GMT
Subject: RFR: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics [v12]
In-Reply-To: <5CRRnynK_o74GMH0-cFZyieGaWn29hVsyZEuesaG-vg=.6795a4b1-322b-42d9-8df0-bf39d77a4075@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
 <5CRRnynK_o74GMH0-cFZyieGaWn29hVsyZEuesaG-vg=.6795a4b1-322b-42d9-8df0-bf39d77a4075@github.com>
Message-ID: <Xa2vuT6gmaMz1_lUkgdJ8ZntncdD3lqexdl-HYz10Dk=.a162c2b3-5f43-45e8-8e79-f7d88b17c377@github.com>

On Wed, 30 Oct 2024 14:23:42 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

>> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.
>
> Arseny Bochkarev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand the comment on endian swap

Thanks everyone for all the comments and reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19960#issuecomment-2449709865

From duke at openjdk.org  Thu Oct 31 12:22:37 2024
From: duke at openjdk.org (Arseny Bochkarev)
Date: Thu, 31 Oct 2024 12:22:37 GMT
Subject: Integrated: 8334999: RISC-V: implement AES single block
 encryption/decryption intrinsics
In-Reply-To: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
References: <iltry713BDlJr1GffgMQl5nYUL6mAhTXp9t-nAnrdu8=.631de5af-05b9-42d3-a7df-b593ef81128f@github.com>
Message-ID: <5iQBsUughw20tTn9t7ZjUqApAiaLO63mkkpsvZHv1_M=.21a5cd9c-bdf2-4e2c-80ea-742711e06d56@github.com>

On Sun, 30 Jun 2024 14:02:00 GMT, Arseny Bochkarev <duke at openjdk.org> wrote:

> Hello everyone! Please review this port of vector AES single block encryption/decryption intrinsics. On my QEMU with `Zvkned` extension enabled the `test/hotspot/jtreg/compiler/codegen/aes/TestAESMain.java` test is OK. I know that currently hardware implementing this extension is not available on the market but I suppose this PR can be a good starting point on supporting AES intrinsics for RISC-V in OpenJDK.

This pull request has now been integrated.

Changeset: e5bbad05
Author:    Arseny Bochkarev <bochkarevarseny at gmail.com>
URL:       https://git.openjdk.org/jdk/commit/e5bbad059d5dc293288ac415c9f7d0fa89c64b74
Stats:     210 lines in 4 files changed: 197 ins; 11 del; 2 mod

8334999: RISC-V: implement AES single block encryption/decryption intrinsics

Reviewed-by: fyang, rehn, yzhu

-------------

PR: https://git.openjdk.org/jdk/pull/19960

From mgronlun at openjdk.org  Thu Oct 31 12:39:39 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 12:39:39 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <8ziHdjO8nrSJdL9zVITYy5vU1F67mlmyf72f_cIhhcI=.04c40b75-3d05-40b2-bec9-a7f763b056ce@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleThrottling.java line 65:

> 63:     private static void testThrottleSettingsPeriod() throws Exception {
> 64:         float rate = countEvents(1000, "1ms").rate();
> 65:         Asserts.assertTrue(rate > 950 && rate < 1050, "Expected around 1000 events per second, got " + rate);

Fails on linux-aarch64-debug builds:

----------System.out:(0/0)----------
----------System.err:(14/1061)----------
java.lang.RuntimeException: Expected around 1000 events per second, got 245.15503: expected true, was false
	at jdk.test.lib.Asserts.fail(Asserts.java:691)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:543)
	at jdk.jfr.event.profiling.TestCPUTimeEventThrottling.testThrottleSettingsPeriod(TestCPUTimeEventThrottling.java:65)
	at jdk.jfr.event.profiling.TestCPUTimeEventThrottling.main(TestCPUTimeEventThrottling.java:49)
	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.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1576)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected around 1000 events per second, got 245.15503: expected true, was false
JavaTest Message: shutting down test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824374656

From mgronlun at openjdk.org  Thu Oct 31 12:45:48 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 12:45:48 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <QFbA9XVg1VQAMQwV7XPD_RtfccSi6ylj4CdaIEcGJpA=.96dfcf3e-37fd-4e02-b0ea-fe009507cfe4@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

Test: jdk/jfr/jcmd/TestJcmdStartWithOptions.java seems to be timing out when the CPU Time Profiler is turned on.

Test: TestActiveSettingEvent also have problems on Linux, not only on non-Linux platforms.

Testing configuration default
----------System.err:(15/1230)----------
java.lang.RuntimeException: Incorrect settings value for jdk.CPUTimeSample#throttle was 0/s, expected 500/s expected: 500/s but was: 0/s
	at jdk.test.lib.Asserts.fail(Asserts.java:691)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:204)
	at jdk.jfr.event.runtime.TestActiveSettingEvent.testSettingConfiguration(TestActiveSettingEvent.java:308)
	at jdk.jfr.event.runtime.TestActiveSettingEvent.testDefaultSettings(TestActiveSettingEvent.java:79)
	at jdk.jfr.event.runtime.TestActiveSettingEvent.main(TestActiveSettingEvent.java:65)
	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.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1576)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449751577
PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449756140

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 mgronlun at openjdk.org  Thu Oct 31 12:54:42 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 12:54:42 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <iW9ynUC99oa5U7jcVGtO60GUFGqtZ_fjPmvY3hCgN9U=.e56662cb-1562-420a-9330-94cca43e124d@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

Test: jdk/jfr/event/profiling/TestNative.java times out on Linux. Could perhaps be an indication that event control/settings is getting mixed up between the two samplers?

jdk.jfr.event.profiling.TestNative
result: Error. Agent error: java.lang.Exception: Agent 21 timed out with a timeout of 480 seconds; check console log for any additional details

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449772623

From mgronlun at openjdk.org  Thu Oct 31 13:07:41 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 13:07:41 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <xnMUXojx-MvjlpummkJ8-KONGfA2mPiVaVICa0TbiFc=.b0caa6d8-8acb-4eb3-aa33-e8cd3d89e102@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

Linux AArch64-debug:

Are you enqueuing entries that have already been unloaded?

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x0000ffff898316e4, pid=458651, tid=458700

JRE version: Java(TM) SE Runtime Environment (24.0) (fastdebug build 24-internal-2024-10-30-2131063.markus.gronlund.jdkcopy)
Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-internal-2024-10-30-2131063.markus.gronlund.jdkcopy, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
 Problematic frame:
 V  [libjvm.so+0xe1b6e4]  module_id(PackageEntry const*, bool)+0x34

 If you would like to submit a bug report, please visit:
   https://bugreport.java.com/bugreport/crash.jsp

---------------  T H R E A D  ---------------

Current thread (0x0000fffef803f480):  JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=458700, stack(0x0000ffff05772000,0x0000ffff05970000) (2040K)]

Stack: [0x0000ffff05772000,0x0000ffff05970000],  sp=0x0000ffff0596e100,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe1b6e4]  module_id(PackageEntry const*, bool)+0x34  (moduleEntry.hpp:111)
V  [libjvm.so+0xe1b938]  package_id(Klass const*, bool)+0x48  (jfrTypeSet.cpp:219)
V  [libjvm.so+0xe1c6f4]  write_klass(JfrCheckpointWriter*, Klass const*, bool, int&)+0xf0  (jfrTypeSet.cpp:350)
V  [libjvm.so+0xe22c2c]  JfrArtifactCallbackHost<Klass const*, CompositeFunctor<Klass const*, JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Klass const*, SerializePredicate<Klass const*>, &(write__klass(JfrCheckpointWriter*, void const*))>, 183u>, KlassArtifactRegistrator> >::do_artifact(void const*)+0xcc  (jfrTypeSet.cpp:398)
V  [libjvm.so+0xe14fe0]  EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >::dispatch(bool, unsigned char const*, unsigned long)+0xd0  (jfrTraceIdKlassQueue.hpp:42)
V  [libjvm.so+0xe15574]  void JfrEpochQueue<JfrEpochQueueKlassPolicy>::iterate<KlassFunctor>(KlassFunctor&, bool)+0x324  (jfrStorageUtils.inline.hpp:160)
V  [libjvm.so+0xe13ad0]  JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x40  (jfrTraceIdKlassQueue.cpp:269)
V  [libjvm.so+0xe220bc]  JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0xf28  (jfrTypeSet.cpp:559)
V  [libjvm.so+0xd64b98]  flush_type_set(Thread*)+0x98  (jfrCheckpointManager.cpp:640)
V  [libjvm.so+0xd6a8e0]  JfrCheckpointManager::flush_type_set()+0x880  (jfrCheckpointManager.cpp:650)
V  [libjvm.so+0xde0d68]  JfrRecorderService::flush()+0xc8  (jfrRecorderService.cpp:158)
V  [libjvm.so+0xde1660]  JfrRecorderService::invoke_flush()+0xd0  (jfrRecorderService.cpp:158)
V  [libjvm.so+0xde25e0]  JfrRecorderService::flushpoint()+0x16c  (jfrRecorderService.cpp:680)
V  [libjvm.so+0xde3348]  recorderthread_entry(JavaThread*, JavaThread*)+0x2c8  (jfrRecorderThreadLoop.cpp:83)
V  [libjvm.so+0xd50400]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:759)
V  [libjvm.so+0x15e59e0]  Thread::call_run()+0xac  (thread.cpp:234)
V  [libjvm.so+0x131fae4]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:858)
C  [libpthread.so.0+0x7950]  start_thread+0x190

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449791321

From jbechberger at openjdk.org  Thu Oct 31 13:07:41 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 13:07:41 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <xnMUXojx-MvjlpummkJ8-KONGfA2mPiVaVICa0TbiFc=.b0caa6d8-8acb-4eb3-aa33-e8cd3d89e102@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <xnMUXojx-MvjlpummkJ8-KONGfA2mPiVaVICa0TbiFc=.b0caa6d8-8acb-4eb3-aa33-e8cd3d89e102@github.com>
Message-ID: <XJa1F05mW65Sonrj45dowZDW647QjMkmiEiyQaKenoc=.3de037ca-af32-42d6-b8a7-cd20e3ec178d@github.com>

On Thu, 31 Oct 2024 13:02:06 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Are you enqueuing entries that have already been unloaded?

Into the JFR buffers? It is possible that we access the methods of unloaded classes, when they are unloaded between the signal handler enqueue and the capture. I thought that this would crash in the method resolve, which would then be caught via the used ThreadCrashProtection. But apparently not. I'm unsure how to solve this. Maybe I could check whether the methods class is unloaded?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449797887

From stuefe at openjdk.org  Thu Oct 31 13:15:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Oct 2024 13:15:39 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <0Tt9vsmkfF621n34-MVeYlQJqDJk6bV1PmpN0Nt8UZU=.7c78e9b7-ddb6-4d80-a22c-1e2446583b8b@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

Is there any form design document? The description in the JEP is extremely sparse, and this PR carries no information at all.


The ability to accurately and precisely measure CPU consumption was added to Linux in 2.16.12 through a timer that emits signals at regular intervals of time spent on the CPU (as opposed to elapsed, or "wall-clock" time). Most profilers on Linux utilize this mechanism to produce CPU time profiles.

<snip>

This Linux capability should be employed by JFR to safely produce CPU time profilers on the JDK. This functionality will allow the wide audience of developers deploying Java applications on Linux to make them more efficient.


That is all I could find. Is there more?

I am mostly curious - and I admit, nervous - about reentrant safety. I see, again, use of setjmp/longjmp semantics here in combination with a mechanism that I believe stops the JVM at arbitrary(?) times, which to me is a warning sign.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449813561

From jbechberger at openjdk.org  Thu Oct 31 13:21:38 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 13:21:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <e44AOwz4rby858CKqhN0YHUMTOIdOPj_1Cu3iDlDn10=.65fb6863-dbc4-4e0f-9bfd-fc6b493ee534@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <V46_Cw9DTURMFxrqxX4VlYnZMNXENWohRGqEY4f2HdM=.f1adb7da-19c1-49a8-aefc-0be29f3db9bf@github.com>
 <TYW7Esaw6qPt1mEZJCHaN1IuW1OJG_OalGXq59hefR8=.2107a110-98a6-4667-a51b-152bab285023@github.com>
 <e44AOwz4rby858CKqhN0YHUMTOIdOPj_1Cu3iDlDn10=.65fb6863-dbc4-4e0f-9bfd-fc6b493ee534@github.com>
Message-ID: <wvF3MznxTCTob5IYtvikLmMDqzNfKJO86MWDAwUTT0U=.ee9d0ffa-8d1b-4975-bca5-dee8f563686f@github.com>

On Thu, 31 Oct 2024 02:59:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The idea is to place it close to the other method sampler.
>
> Why? Large chunks of platform specific code should be in platform specific files. That is the way hotspot sources are arranged.

Can we postpone this change to a later stage? This would possibly invalidate lot's of GitHub comments. I see the point of the change, but I think there are currently more pressing things.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824442236

From jbechberger at openjdk.org  Thu Oct 31 13:28:36 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 13:28:36 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <0Tt9vsmkfF621n34-MVeYlQJqDJk6bV1PmpN0Nt8UZU=.7c78e9b7-ddb6-4d80-a22c-1e2446583b8b@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <0Tt9vsmkfF621n34-MVeYlQJqDJk6bV1PmpN0Nt8UZU=.7c78e9b7-ddb6-4d80-a22c-1e2446583b8b@github.com>
Message-ID: <P7soCPaIAOZGiogZPYrehTZXtzb2YzXaizRI4hGUWp4=.a22ef6ae-0ea6-4961-90be-ff5ebca02fda@github.com>

On Thu, 31 Oct 2024 13:12:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I am mostly curious - and I admit, nervous - about reentrant safety. I see, again, use of setjmp/longjmp semantics here in combination with a mechanism that I believe stops the JVM at arbitrary(?) times, which to me is a warning sign.

ThreadCrashProtection is not used inside the signal handler but in a separate worker thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449840097

From egahlin at openjdk.org  Thu Oct 31 13:28:38 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 31 Oct 2024 13:28:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <CBNIG_35atzt-0qollW3Ttomg8UB4b37j3Oq8JYhYL0=.73a6bb33-37dd-46f2-a004-9455e528c240@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

test/jdk/jdk/jfr/event/profiling/TestNative.java line 43:

> 41: public class TestNative {
> 42: 
> 43:     static String nativeEvent = EventNames.NativeMethodSample;

Why is this change needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1824449983

From mgronlun at openjdk.org  Thu Oct 31 13:31:38 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 13:31:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <sXRoE5msYZe9OUX4sNj3pgyiLOt_DwuwqFA_mFg5fNA=.6776f957-4921-41bb-8bf0-626763ba5092@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

SIGILL on AArch64

Current thread (0x0000ffff783aa220):  JfrCPUTimeThreadSampler "JFR CPU Time Thread Sampler" [id=45622, stack(0x0000fffb01f6c000,0x0000fffb0216a000) (2040K)]

Stack: [0x0000fffb01f6c000,0x0000fffb0216a000],  sp=0x0000fffb021683a0,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 8439 c2 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base at 24-internal (98 bytes) @ 0x0000ffff68300b4c [0x0000ffff68300d00+0xfffffffffffffe4c]
V  [libjvm.so+0x816bd8]  JFRRecordSampledThreadCallback::call()+0x18  (jfrCPUTimeThreadSampler.cpp:550)
V  [libjvm.so+0xd2e598]  ThreadCrashProtection::call(CrashProtectionCallback&)+0x68  (threadCrashProtection_posix.cpp:49)
V  [libjvm.so+0x815238]  JfrCPUTimeThreadSampler::process_trace_queue()+0x278  (jfrCPUTimeThreadSampler.cpp:590)
V  [libjvm.so+0x8154e4]  JfrCPUTimeThreadSampler::run()+0x110  (jfrCPUTimeThreadSampler.cpp:530)
V  [libjvm.so+0xd2e208]  Thread::call_run()+0xa8  (thread.cpp:234)
V  [libjvm.so+0xb9ce90]  thread_native_entry(Thread*)+0xdc  (os_linux.cpp:858)
C  [libc.so.6+0x806b8]  start_thread+0x2d8

siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x0000ffff68300b4c

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449845140

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 mgronlun at openjdk.org  Thu Oct 31 13:38:41 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 13:38:41 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <ZnEsZbh6stvTiTaAMyAyPmip9UKb4zDOBfsicXOnrY4=.74bc5f0f-292e-4265-89c6-3ba6d6efcd10@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

Linux x64-debug:

jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp:190

assert(id > 0) failed: invariant

---------------  T H R E A D  ---------------

Current thread (0x00007efe60f3f280):  JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=3499556, stack(0x00007efeb13f5000,0x00007efeb14f5000) (1024K)]

Stack: [0x00007efeb13f5000,0x00007efeb14f5000],  sp=0x00007efeb14f37d0,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xfcd274]  EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >::dispatch(bool, unsigned char const*, unsigned long)+0x194  (jfrTraceIdKlassQueue.cpp:190)
V  [libjvm.so+0xfcd75e]  void JfrEpochQueue<JfrEpochQueueKlassPolicy>::iterate<KlassFunctor>(KlassFunctor&, bool)+0x37e  (jfrStorageUtils.inline.hpp:160)
V  [libjvm.so+0xfcbc88]  JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x38  (jfrTraceIdKlassQueue.cpp:269)
V  [libjvm.so+0xfda2f4]  JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0xfb4  (jfrTypeSet.cpp:559)
V  [libjvm.so+0xf11b6d]  flush_type_set(Thread*)+0x8d  (jfrCheckpointManager.cpp:640)
V  [libjvm.so+0xf16a36]  JfrCheckpointManager::flush_type_set()+0x116  (jfrCheckpointManager.cpp:650)
V  [libjvm.so+0xf944a6]  JfrRecorderService::flush()+0xe6  (jfrRecorderService.cpp:158)
V  [libjvm.so+0xf94e2a]  JfrRecorderService::invoke_flush()+0xba  (jfrRecorderService.cpp:158)
V  [libjvm.so+0xf95dfa]  JfrRecorderService::flushpoint()+0x10a  (jfrRecorderService.cpp:680)
V  [libjvm.so+0xf96b38]  recorderthread_entry(JavaThread*, JavaThread*)+0x178  (jfrRecorderThreadLoop.cpp:83)
V  [libjvm.so+0xefc16c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:759)
V  [libjvm.so+0x1836106]  Thread::call_run()+0xb6  (thread.cpp:234)
V  [libjvm.so+0x15144a8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:858)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449860694

From jbechberger at openjdk.org  Thu Oct 31 13:57:43 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 13:57:43 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <ZnEsZbh6stvTiTaAMyAyPmip9UKb4zDOBfsicXOnrY4=.74bc5f0f-292e-4265-89c6-3ba6d6efcd10@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <ZnEsZbh6stvTiTaAMyAyPmip9UKb4zDOBfsicXOnrY4=.74bc5f0f-292e-4265-89c6-3ba6d6efcd10@github.com>
Message-ID: <xJly6JZAQkBmeayEXWDwM3z1-vbzg3ls3CfPoCD_j6k=.0d5294b5-c258-4481-b1f4-a7618abb887a@github.com>

On Thu, 31 Oct 2024 13:35:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove min_valid_free_size_bytes
>
> Linux x64-debug:
> 
> jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp:190
> 
> assert(id > 0) failed: invariant
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x00007efe60f3f280):  JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=3499556, stack(0x00007efeb13f5000,0x00007efeb14f5000) (1024K)]
> 
> Stack: [0x00007efeb13f5000,0x00007efeb14f5000],  sp=0x00007efeb14f37d0,  free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xfcd274]  EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >::dispatch(bool, unsigned char const*, unsigned long)+0x194  (jfrTraceIdKlassQueue.cpp:190)
> V  [libjvm.so+0xfcd75e]  void JfrEpochQueue<JfrEpochQueueKlassPolicy>::iterate<KlassFunctor>(KlassFunctor&, bool)+0x37e  (jfrStorageUtils.inline.hpp:160)
> V  [libjvm.so+0xfcbc88]  JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x38  (jfrTraceIdKlassQueue.cpp:269)
> V  [libjvm.so+0xfda2f4]  JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0xfb4  (jfrTypeSet.cpp:559)
> V  [libjvm.so+0xf11b6d]  flush_type_set(Thread*)+0x8d  (jfrCheckpointManager.cpp:640)
> V  [libjvm.so+0xf16a36]  JfrCheckpointManager::flush_type_set()+0x116  (jfrCheckpointManager.cpp:650)
> V  [libjvm.so+0xf944a6]  JfrRecorderService::flush()+0xe6  (jfrRecorderService.cpp:158)
> V  [libjvm.so+0xf94e2a]  JfrRecorderService::invoke_flush()+0xba  (jfrRecorderService.cpp:158)
> V  [libjvm.so+0xf95dfa]  JfrRecorderService::flushpoint()+0x10a  (jfrRecorderService.cpp:680)
> V  [libjvm.so+0xf96b38]  recorderthread_entry(JavaThread*, JavaThread*)+0x178  (jfrRecorderThreadLoop.cpp:83)
> V  [libjvm.so+0xefc16c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:759)
> V  [libjvm.so+0x1836106]  Thread::call_run()+0xb6  (thread.cpp:234)
> V  [libjvm.so+0x15144a8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:858)

@mgronlun what is your reproducer? I didn't see these issues before in my own testing

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2449900673

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 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 mgronlun at openjdk.org  Thu Oct 31 16:07:46 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 16:07:46 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <ZnEsZbh6stvTiTaAMyAyPmip9UKb4zDOBfsicXOnrY4=.74bc5f0f-292e-4265-89c6-3ba6d6efcd10@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <ZnEsZbh6stvTiTaAMyAyPmip9UKb4zDOBfsicXOnrY4=.74bc5f0f-292e-4265-89c6-3ba6d6efcd10@github.com>
Message-ID: <qDycDPQRvI1RiD1RQHL-tw0KTDMhi4iDg-womeSd9Lw=.8d8cf0c5-d4aa-4e38-8289-4829d1fe9b43@github.com>

On Thu, 31 Oct 2024 13:35:43 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove min_valid_free_size_bytes
>
> Linux x64-debug:
> 
> jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp:190
> 
> assert(id > 0) failed: invariant
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x00007efe60f3f280):  JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=3499556, stack(0x00007efeb13f5000,0x00007efeb14f5000) (1024K)]
> 
> Stack: [0x00007efeb13f5000,0x00007efeb14f5000],  sp=0x00007efeb14f37d0,  free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0xfcd274]  EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >::dispatch(bool, unsigned char const*, unsigned long)+0x194  (jfrTraceIdKlassQueue.cpp:190)
> V  [libjvm.so+0xfcd75e]  void JfrEpochQueue<JfrEpochQueueKlassPolicy>::iterate<KlassFunctor>(KlassFunctor&, bool)+0x37e  (jfrStorageUtils.inline.hpp:160)
> V  [libjvm.so+0xfcbc88]  JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x38  (jfrTraceIdKlassQueue.cpp:269)
> V  [libjvm.so+0xfda2f4]  JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0xfb4  (jfrTypeSet.cpp:559)
> V  [libjvm.so+0xf11b6d]  flush_type_set(Thread*)+0x8d  (jfrCheckpointManager.cpp:640)
> V  [libjvm.so+0xf16a36]  JfrCheckpointManager::flush_type_set()+0x116  (jfrCheckpointManager.cpp:650)
> V  [libjvm.so+0xf944a6]  JfrRecorderService::flush()+0xe6  (jfrRecorderService.cpp:158)
> V  [libjvm.so+0xf94e2a]  JfrRecorderService::invoke_flush()+0xba  (jfrRecorderService.cpp:158)
> V  [libjvm.so+0xf95dfa]  JfrRecorderService::flushpoint()+0x10a  (jfrRecorderService.cpp:680)
> V  [libjvm.so+0xf96b38]  recorderthread_entry(JavaThread*, JavaThread*)+0x178  (jfrRecorderThreadLoop.cpp:83)
> V  [libjvm.so+0xefc16c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:759)
> V  [libjvm.so+0x1836106]  Thread::call_run()+0xb6  (thread.cpp:234)
> V  [libjvm.so+0x15144a8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:858)

> @mgronlun what is your reproducer? I didn't see these issues before in my own testing

Internal stress testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2450255693

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 mgronlun at openjdk.org  Thu Oct 31 16:12:55 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 16:12:55 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <dBDzTYUuXFTw0mECg5uRgtj_bzMkasdi_7s0yvf1F9c=.0ca75211-8e3c-46d0-a041-23169cd9c3a5@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

linux-aarch64-debug

---------------  T H R E A D  ---------------

Current thread (0x0000ffffac4222b0):  JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=144094, stack(0x0000ffff5e17a000,0x0000ffff5e378000) (2040K)]

Stack: [0x0000ffff5e17a000,0x0000ffff5e378000],  sp=0x0000ffff5e376110,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe19e54]  get_cld(Klass const*)+0x34  (klass.hpp:684)
V  [libjvm.so+0xe1c674]  write_klass(JfrCheckpointWriter*, Klass const*, bool, int&)+0x70  (jfrTypeSet.cpp:370)
V  [libjvm.so+0xe22d40]  JfrArtifactCallbackHost<Klass const*, CompositeFunctor<Klass const*, CompositeFunctor<Klass const*, JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Klass const*, LeakPredicate<Klass const*>, &(write__klass__leakp(JfrCheckpointWriter*, void const*))>, 183u>, JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Klass const*, SerializePredicate<Klass const*>, &(write__klass(JfrCheckpointWriter*, void const*))>, 183u> >, KlassArtifactRegistrator> >::do_artifact(void const*)+0x90  (jfrTypeSet.cpp:398)
V  [libjvm.so+0xe14fe0]  EpochDispatchOp<JfrEpochQueue<JfrEpochQueueKlassPolicy>::ElementDispatch<KlassFunctor> >::dispatch(bool, unsigned char const*, unsigned long)+0xd0  (jfrTraceIdKlassQueue.hpp:42)
V  [libjvm.so+0xe15328]  void JfrEpochQueue<JfrEpochQueueKlassPolicy>::iterate<KlassFunctor>(KlassFunctor&, bool)+0xd8  (jfrStorageUtils.inline.hpp:160)
V  [libjvm.so+0xe13ad0]  JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x40  (jfrTraceIdKlassQueue.cpp:269)
V  [libjvm.so+0xe21358]  JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0x1c4  (jfrTypeSet.cpp:565)
V  [libjvm.so+0xd6baf4]  JfrCheckpointManager::write_type_set()+0x1a0  (jfrCheckpointManager.cpp:617)
V  [libjvm.so+0xddfa54]  JfrRecorderService::post_safepoint_write()+0xb0  (jfrRecorderService.cpp:613)
V  [libjvm.so+0xde0bdc]  JfrRecorderService::chunk_rotation()+0x3c  (jfrRecorderService.cpp:573)
V  [libjvm.so+0xde2104]  JfrRecorderService::rotate(int)+0x100  (jfrRecorderService.cpp:539)
V  [libjvm.so+0xde332c]  recorderthread_entry(JavaThread*, JavaThread*)+0x2ac  (jfrRecorderThreadLoop.cpp:81)
V  [libjvm.so+0xd50400]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:759)
V  [libjvm.so+0x15e59e0]  Thread::call_run()+0xac  (thread.cpp:234)
V  [libjvm.so+0x131fae4]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:858)
C  [libc.so.6+0x806b8]  start_thread+0x2d8

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2450266807

From lmesnik at openjdk.org  Thu Oct 31 16:13:53 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 31 Oct 2024 16:13:53 GMT
Subject: RFR: 8343173: Remove ZGC-specific non-JVMCI test groups [v2]
In-Reply-To: <Pi4NnowP97OycsrQNhqYKrx-ponv9Fcn6-l7PZGbAzk=.25064037-6535-400a-a063-c3d602be594f@github.com>
References: <Pi4NnowP97OycsrQNhqYKrx-ponv9Fcn6-l7PZGbAzk=.25064037-6535-400a-a063-c3d602be594f@github.com>
Message-ID: <IzozsqPYFk9XAot7mVxUN9s2qtm0gDCWovHBrTeSm-8=.7d1c082c-1d86-4cd5-8fe9-7a3ac8d0fa89@github.com>

> The JVMCI should be supported by all GCs and specific
> hotspot_compiler_all_gcs
> group is not needed anymore.
> 
> There are few failures of JVMCI tests with ZGC happened, the bug 
> https://bugs.openjdk.org/browse/JDK-8343233
> is filed and corresponding tests are problemlisted.

Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - typo fixed
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8343173
 - 8343173: Remove ZGC-specific non-JVMCI test groups

-------------

Changes: https://git.openjdk.org/jdk/pull/21774/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21774&range=01
  Stats: 12 lines in 2 files changed: 8 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21774/head:pull/21774

PR: https://git.openjdk.org/jdk/pull/21774

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: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: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: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 coleenp at openjdk.org  Thu Oct 31 18:34:30 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 31 Oct 2024 18:34:30 GMT
Subject: RFR: 8343218: Disable allocating interface and abstract classes in
 non-class metaspace [v2]
In-Reply-To: <1xurMyjTB2XPkn57XaTDNUGXaTY614wIdQv1KfV-FpA=.4a31bef2-a80f-4749-95e9-ff41952f2a52@github.com>
References: <W7Y4KsZSv4ibsCCiF-71-Ylsd2BaDsp33BvwqZUMp6E=.bcf518bb-a282-480d-98c2-cd4b568d7111@github.com>
 <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com>
 <1xurMyjTB2XPkn57XaTDNUGXaTY614wIdQv1KfV-FpA=.4a31bef2-a80f-4749-95e9-ff41952f2a52@github.com>
Message-ID: <lIBhgPLMVPMV6bXFviBunnKHn2GQggbNLZkhXx_FBUk=.ee235e33-c113-4eee-b479-20030816c921@github.com>

On Thu, 31 Oct 2024 05:35:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/oops/instanceKlass.cpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/oops/instanceKlass.cpp line 460:
> 
>> 458:   // are the only ones that require compression and allocation in the limited class metaspace
>> 459:   // region.  But ... there are C2 dependencies that all klasses are allocated to the class metaspace, so
>> 460:   // always use the class metaspace until JDK-NNNNNNN is resolved.
> 
> JDK-NNNNNN was supposed to be replaced by an actual bug number. :)

I was wondering where the NNNN came from.  I do not want to put the number in the code, and there may be a performance problem that I'm working on.  I may or may not push this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21769#discussion_r1825002852

From jbechberger at openjdk.org  Thu Oct 31 18:40:41 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 18:40:41 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <QVz3CXn2ZO4MoBbIJfnM5_G-T2FWjZG1a3zvJUUop9g=.42aee59d-908c-4384-b1cd-be99ab9a7d8b@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

I see a pattern in the last two segfaults, it seems to conform to what I wrote before. So I probably need a test case that unloads a lot of classes.
Do you share my intuition?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2450578772

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 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 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 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 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 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 dlong at openjdk.org  Thu Oct 31 22:51:40 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 22:51:40 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
Message-ID: <jXvn8aJ5Ehrpf4OcsUIMEQpvoBX0Y4XDGczN588JwQM=.4592f462-9997-4ce3-b7a1-689f13eeeb00@github.com>

On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove min_valid_free_size_bytes

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 221:

> 219:       _error = ERROR_NO_TOPFRAME;
> 220:       return;
> 221:     }

Wouldn't we end up with the same top frame if we started at the anchor frame instead?  In fact, the frame we want should always be the immediate caller of the anchor frame.  But I guess we need to check that the anchor frame is walkable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825257546

From jbechberger at openjdk.org  Thu Oct 31 23:35:38 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 23:35:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <jXvn8aJ5Ehrpf4OcsUIMEQpvoBX0Y4XDGczN588JwQM=.4592f462-9997-4ce3-b7a1-689f13eeeb00@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <jXvn8aJ5Ehrpf4OcsUIMEQpvoBX0Y4XDGczN588JwQM=.4592f462-9997-4ce3-b7a1-689f13eeeb00@github.com>
Message-ID: <b_3y6vYaYmyoxjUPWgYFnq4eVtkUsjlJ-Bjr2hkfCUU=.b2249df9-4e86-4cde-8386-48ffeaaaec64@github.com>

On Thu, 31 Oct 2024 22:48:38 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove min_valid_free_size_bytes
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 221:
> 
>> 219:       _error = ERROR_NO_TOPFRAME;
>> 220:       return;
>> 221:     }
> 
> Wouldn't we end up with the same top frame if we started at the anchor frame instead?  In fact, the frame we want should always be the immediate caller of the anchor frame.  But I guess we need to check that the anchor frame is walkable.

This is not always the case, as far as I know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825280641

From jbechberger at openjdk.org  Thu Oct 31 23:35:38 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 31 Oct 2024 23:35:38 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <b_3y6vYaYmyoxjUPWgYFnq4eVtkUsjlJ-Bjr2hkfCUU=.b2249df9-4e86-4cde-8386-48ffeaaaec64@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <jXvn8aJ5Ehrpf4OcsUIMEQpvoBX0Y4XDGczN588JwQM=.4592f462-9997-4ce3-b7a1-689f13eeeb00@github.com>
 <b_3y6vYaYmyoxjUPWgYFnq4eVtkUsjlJ-Bjr2hkfCUU=.b2249df9-4e86-4cde-8386-48ffeaaaec64@github.com>
Message-ID: <rzkDlANQsscCFuDoA5W9WScqapsu7ea2sB662wXbE-c=.745e81a0-28fa-4426-bc31-51e0455904fd@github.com>

On Thu, 31 Oct 2024 23:32:48 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 221:
>> 
>>> 219:       _error = ERROR_NO_TOPFRAME;
>>> 220:       return;
>>> 221:     }
>> 
>> Wouldn't we end up with the same top frame if we started at the anchor frame instead?  In fact, the frame we want should always be the immediate caller of the anchor frame.  But I guess we need to check that the anchor frame is walkable.
>
> This is not always the case, as far as I know.

This is not always the case, as far as I know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825280768

From mgronlun at openjdk.org  Thu Oct 31 23:54:37 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Oct 2024 23:54:37 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4]
In-Reply-To: <rzkDlANQsscCFuDoA5W9WScqapsu7ea2sB662wXbE-c=.745e81a0-28fa-4426-bc31-51e0455904fd@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <WHBHS6RlFvwfkBULLrIZeh7Rys4f3FB6oY9gbCNJ_Kg=.35d5f86a-cde4-460b-a29e-28858dd7d4e8@github.com>
 <jXvn8aJ5Ehrpf4OcsUIMEQpvoBX0Y4XDGczN588JwQM=.4592f462-9997-4ce3-b7a1-689f13eeeb00@github.com>
 <b_3y6vYaYmyoxjUPWgYFnq4eVtkUsjlJ-Bjr2hkfCUU=.b2249df9-4e86-4cde-8386-48ffeaaaec64@github.com>
 <rzkDlANQsscCFuDoA5W9WScqapsu7ea2sB662wXbE-c=.745e81a0-28fa-4426-bc31-51e0455904fd@github.com>
Message-ID: <ooezU-xklQ4MFbj1GcEM17TrNwW0EvkvufwpErkiSoY=.b72759b1-a524-452e-97b2-795f1c98ff05@github.com>

On Thu, 31 Oct 2024 23:33:02 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is not always the case, as far as I know.
>
> This is not always the case, as far as I know.

It should be ok to start from the anchor frame.

Please see JfrNativeSamplerCallback::call().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825289670