From azafari at openjdk.org  Sun Jun  1 06:53:58 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Sun, 1 Jun 2025 06:53:58 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v33]
In-Reply-To: <OzrvaB3Hgy_KPBWBadQtAWYlUFBFViIYCTUVGO679IU=.cb6bebfb-669f-4b7e-8a15-572f0b4b3f3b@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com>
 <OzrvaB3Hgy_KPBWBadQtAWYlUFBFViIYCTUVGO679IU=.cb6bebfb-669f-4b7e-8a15-572f0b4b3f3b@github.com>
Message-ID: <lDWlp-2sXlHPqVvEwtjU8neP7qaSXpWDS4ZDut_bbMg=.0bd6e513-bb4b-4f9b-a3da-54f5262c02fe@github.com>

On Fri, 30 May 2025 17:37:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   visualizations added. 1st try.
>
> src/hotspot/share/nmt/vmatree.hpp line 249:
> 
>> 247:   };
>> 248: 
>> 249:   enum Operation {Release, Reserve, Commit, Uncommit, Invalid};
> 
> Can we drop `Invalid` and simplify the code?
> 
>  ```
>  enum Operation {Release, Reserve, Commit, Uncommit};
>   struct RequestInfo {
>     position A, B;
>     StateType _op;
>     MemTag tag;
>     SIndex callstack;
>     bool use_tag_inplace;
>     Operation op() const {
>       return
>             _op == StateType::Reserved && !use_tag_inplace  ? Operation::Reserve  :
>             _op == StateType::Committed                     ? Operation::Commit   :
>             _op == StateType::Reserved &&  use_tag_inplace  ? Operation::Uncommit :
>              Operation::Release;
>     }
> 
>     size_t op_to_index() const {
>       return
>             _op == StateType::Reserved && !use_tag_inplace  ? 1 :
>             _op == StateType::Committed                     ? 2 :
>             _op == StateType::Reserved &&  use_tag_inplace  ? 3 :
>             0;
>     }

We need some invalid checking in the impl of register_mapping. How do we detect and report invalid values then?

> test/hotspot/gtest/nmt/test_vmatree.cpp line 3211:
> 
>> 3209:     //            1         2         3         4         5
>> 3210:     //  012345678901234567890123456789012345678901234567890
>> 3211:     //  rrrrrrrrrr..........rrrrrrrrrr
> 
> What is this comment supposed to show?
> 
> I cleaned up, some comments and created a branch https://github.com/openjdk/jdk/compare/master...gerard-ziemski:jdk:gerard-8351661 in case you want to see it.

In the branch you sent the link, almost all of the new format comments are removed. Is that correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2118810649
PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2118809808

From dholmes at openjdk.org  Mon Jun  2 03:54:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 03:54:57 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2]
In-Reply-To: <A07X-cSemN0bCCWopt1a1OPuMwG9KjCVYw8aPL1blzA=.c29f63ed-729d-4072-b78c-3d055ddd8e63@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <lIUS9Dmi6eF4lwGSkH0jXyIR-rNR2pKWrlscSpXNhDo=.c1f1cfa6-8d0d-4c06-8844-92533b0f6eb6@github.com>
 <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com>
 <A07X-cSemN0bCCWopt1a1OPuMwG9KjCVYw8aPL1blzA=.c29f63ed-729d-4072-b78c-3d055ddd8e63@github.com>
Message-ID: <ijBORSmuJPjAx7m5uMZjWmKYT_KUlon3b8NH_PBKDWk=.c82feb5c-ac5a-406d-92e3-3e91989956a7@github.com>

On Fri, 30 May 2025 09:28:56 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3
>
> Thanks @pchilano, I agree that the refactoring I proposed is adding an extra layer. What you propose is moving the functionality to JavaThread. I think we need to come to an agreement on where it should belong to. @dholmes-ora do you have an opinion on that?

@toxaart All the suspend/resume code used to live in JavaThread so we are coming full-circle. :) I don't quite recall the path that led to it being taken out of JavaThread. No objections from me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2928623550

From dholmes at openjdk.org  Mon Jun  2 04:55:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:55:52 GMT
Subject: RFR: 8357924: Remove
 runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for
 macosx-x64
In-Reply-To: <oDxyr-4C9Y2u-Q3HgzU9zpk77pixtHyVYi9eD3u4fEI=.acfbec01-817c-4fd4-816b-10cd6029333b@github.com>
References: <oDxyr-4C9Y2u-Q3HgzU9zpk77pixtHyVYi9eD3u4fEI=.acfbec01-817c-4fd4-816b-10cd6029333b@github.com>
Message-ID: <Nmc97BwWyglQLBst66r0OXCySbb5tY_eFgPPsXarMtY=.950b5bed-e8c2-4857-8dc8-5561750b840e@github.com>

On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed.
> 
> Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes.

Thanks for fixing this.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25556#pullrequestreview-2886708994

From eosterlund at openjdk.org  Mon Jun  2 07:31:54 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 07:31:54 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent
In-Reply-To: <BglJQQCTkacLJR8lcp8pvbA5XmN1Bit6FB1Ea9TNX_I=.35ad2917-e1c5-43e9-909c-3eda5a8ffd24@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
 <CrcRNroJJHxyiJTcnBI6oM-Ee4nwx1l5kPfEDYuCtgg=.81096e37-4425-497e-89b2-e49e7666cf4a@github.com>
 <gL2bZJkVGSFfk0S1hJ811kmaKFPjMY0rLsnILV7c0rM=.f12af57b-ab79-477d-9b18-62bfad29653e@github.com>
 <Jl3TDXAYy6dH97AVDctOrkjkCY2mUW8zJqEPouGesfk=.67c23d27-6dd7-4aa4-9690-a0edc5acb538@github.com>
 <BglJQQCTkacLJR8lcp8pvbA5XmN1Bit6FB1Ea9TNX_I=.35ad2917-e1c5-43e9-909c-3eda5a8ffd24@github.com>
Message-ID: <xd4Z3qLEcOs_A_ZEZBAayObP3kp6P9cwzAk6kbSE-sw=.f159519c-0b5c-4d74-b40b-668ce078aefa@github.com>

On Fri, 30 May 2025 09:40:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > It would surely be better if this evil were expunged from JDK 21 as well, lest it also confuse a backporter.
> > 
> > 
> > Maybe a "here be dragons" warning would suffice.
> 
> If you add the following comment above every call to `do_oop_store()` I'll approve this patch:
> 
> `// Clobbers: r10, r11, r3`

Hmm yes that feels like a good compromise. I added the comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2929209038

From eosterlund at openjdk.org  Mon Jun  2 07:48:39 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 07:48:39 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent [v2]
In-Reply-To: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
Message-ID: <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>

> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
> 
> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
> 
> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about clobbered registers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25483/files
  - new: https://git.openjdk.org/jdk/pull/25483/files/44f7e092..c9440f68

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

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

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

From shade at openjdk.org  Mon Jun  2 08:25:00 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 08:25:00 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent [v2]
In-Reply-To: <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
 <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
Message-ID: <TWX5m3E0bxyIVB3ew3Yw5Hg0dDems-8SMAwvzdRNFSQ=.d5cd1e4a-60a1-4ad2-b611-09b941f881ab@github.com>

On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
>> 
>> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
>> 
>> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about clobbered registers

Well, since we are introducing the hunks near `do_oop_store`-s, and thus extending the scope of the patch. At this point, we can just inline `do_oop_store` (and maybe `do_oop_load`?), like Andrew initially suggested. This will also match what RISC-V already did: https://github.com/openjdk/jdk/commit/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e

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

PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2887283595

From azafari at openjdk.org  Mon Jun  2 08:27:36 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Jun 2025 08:27:36 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v2]
In-Reply-To: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
Message-ID: <WewOYkcVm6DQNiZD1z33icG0nt2AZEIIbR6pA_qPTLQ=.81cf1a3e-e1c4-42be-ab25-7b53cd52bfb2@github.com>

> Renamed usage of 'category' for 'MemTag' cases.

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

  user-facing terms remained as 'category'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25226/files
  - new: https://git.openjdk.org/jdk/pull/25226/files/b7666c38..05ca64d3

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

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

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

From azafari at openjdk.org  Mon Jun  2 08:27:36 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Jun 2025 08:27:36 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
In-Reply-To: <vQgwocz8YWurTflj_EJ4CGqvJ7U0PqvhEBv_FW9Yw4Y=.11bacdb3-bf13-41ba-a9d6-c194872864d4@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <vQgwocz8YWurTflj_EJ4CGqvJ7U0PqvhEBv_FW9Yw4Y=.11bacdb3-bf13-41ba-a9d6-c194872864d4@github.com>
Message-ID: <oqjD2PkMdrMz6jZ1KCKPjQWLjOphClEhn9iuw4Zuqis=.75abcec7-aff2-4b10-a4ad-330f46f77585@github.com>

On Fri, 30 May 2025 12:16:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Can we use `category` as the term for any user-facing things? I'm thinking output from tooling, input options, docs, etc.

Thanks for this nice point.
User-facing terms reverted back to category.

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2929397073

From eosterlund at openjdk.org  Mon Jun  2 08:56:56 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 08:56:56 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent [v2]
In-Reply-To: <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
 <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
Message-ID: <KIsOeJ-s3soubSWaxh7wgwcUzOl78hkan9sta9imCuU=.537debad-6c3b-4882-acd8-b3a4568c0468@github.com>

On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
>> 
>> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
>> 
>> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about clobbered registers

> Well, since we are introducing the hunks near `do_oop_store`-s, and thus extending the scope of the patch. At this point, we can just inline `do_oop_store` (and maybe `do_oop_load`?), like Andrew initially suggested. This will also match what RISC-V already did: [c5a1543](https://github.com/openjdk/jdk/commit/c5a1543ee3e68775f09ca29fb07efd9aebfdb33e)

RISC-V doesn't really have the backporting until JDK 8 problem. I'd really like to make that cosmetic change in the next follow-up PR instead, as previously discussed. The comments hold true all the way back to JDK 8 and don't change the logic, so I can go along with that. And I'd rather take the risk of getting some comment wrong on the way back to JDK 8, than fiddling with the guts of all this unrelated code, that has changed substantially since back then. Does that sound okay?

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

PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2929515436

From aph at openjdk.org  Mon Jun  2 09:06:59 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Jun 2025 09:06:59 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent [v2]
In-Reply-To: <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
 <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
Message-ID: <yu_EQ2jkV1cnOG3sRo0eWCA8ZbhRUbTQJOSh7EHMw2g=.81c7f95c-4a14-4684-9be5-124e6d7ac95e@github.com>

On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
>> 
>> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
>> 
>> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about clobbered registers

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2887436174

From shade at openjdk.org  Mon Jun  2 09:11:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 09:11:55 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent [v2]
In-Reply-To: <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
 <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
Message-ID: <l1MhlTaOR3ZQVxFXAqU9fyjDOJp6xc1eedzKT9Ue7ZM=.d31f31a9-3dc3-47ef-91c8-92478809d035@github.com>

On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
>> 
>> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
>> 
>> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about clobbered registers

For me, straight-up inlining:


  __ store_heap_oop(dst, val, r10, r11, r3, decorators);


...conveys the similar message as `// Clobbers: r10, r11, r3`. 

But I shall not quibble.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2887454204

From azafari at openjdk.org  Mon Jun  2 09:15:00 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Jun 2025 09:15:00 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v33]
In-Reply-To: <lDWlp-2sXlHPqVvEwtjU8neP7qaSXpWDS4ZDut_bbMg=.0bd6e513-bb4b-4f9b-a3da-54f5262c02fe@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com>
 <OzrvaB3Hgy_KPBWBadQtAWYlUFBFViIYCTUVGO679IU=.cb6bebfb-669f-4b7e-8a15-572f0b4b3f3b@github.com>
 <lDWlp-2sXlHPqVvEwtjU8neP7qaSXpWDS4ZDut_bbMg=.0bd6e513-bb4b-4f9b-a3da-54f5262c02fe@github.com>
Message-ID: <V6Y73ZN9OCxmArzLYyLbGf41DV3r-6qqwGQsnZnvMfc=.bc9892b3-45b5-4c74-aa86-bdc924053d8e@github.com>

On Sun, 1 Jun 2025 06:49:39 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> test/hotspot/gtest/nmt/test_vmatree.cpp line 3211:
>> 
>>> 3209:     //            1         2         3         4         5
>>> 3210:     //  012345678901234567890123456789012345678901234567890
>>> 3211:     //  rrrrrrrrrr..........rrrrrrrrrr
>> 
>> What is this comment supposed to show?
>> 
>> I cleaned up, some comments and created a branch https://github.com/openjdk/jdk/compare/master...gerard-ziemski:jdk:gerard-8351661 in case you want to see it.
>
> The comment is removed.
> 
> In the branch you sent the link, almost all of the new format comments are removed. Is that correct?

The extra grabage-like comments are all removed. They came after running a script for putting comments in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2120528237

From duke at openjdk.org  Mon Jun  2 09:24:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 2 Jun 2025 09:24:35 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v3]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <XL-jiRdFCMiBUyIKY3WY2QLrlbyqWTRFUa6KFV3xVuQ=.7de3b3a5-ecc8-4f1c-bae1-0bcf4e093e2d@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

Anton Artemov 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 11 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - 8265754: Refactoring to static methods.
 - 8265754: Fixed indentation.
 - 8265754: Fixed indentation
 - 8265754: Fixed indentation and lost newline.
 - 8265754: Fixed whitespaces errors.
 - 8265754: More work.
 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a08f1c1d...3b0fffab

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/0ee1abf2..3b0fffab

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

  Stats: 51935 lines in 783 files changed: 26618 ins; 15706 del; 9611 mod
  Patch: https://git.openjdk.org/jdk/pull/25407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407

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

From duke at openjdk.org  Mon Jun  2 09:39:54 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 2 Jun 2025 09:39:54 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2]
In-Reply-To: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <lIUS9Dmi6eF4lwGSkH0jXyIR-rNR2pKWrlscSpXNhDo=.c1f1cfa6-8d0d-4c06-8844-92533b0f6eb6@github.com>
 <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com>
Message-ID: <9lLuwDnA6g2x7expvCqvt8XaolPYHz5KBwdpJMEVqQ0=.7081023e-b5f7-4bc7-817b-6e46dcec2374@github.com>

On Wed, 28 May 2025 18:36:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov 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:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265754
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265754
>>  - 8265754: Refactoring to static methods.
>>  - 8265754: Fixed indentation.
>>  - 8265754: Fixed indentation
>>  - 8265754: Fixed indentation and lost newline.
>>  - 8265754: Fixed whitespaces errors.
>>  - 8265754: More work.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265754
>>  - 8265754: Refactoring suspend/resume in the HandshakeState away
>
> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3

@pchilano Do you expect to have any performance impact of having an indirection layer? 

Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`. 

An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach?

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

PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2929698192

From eosterlund at openjdk.org  Mon Jun  2 10:11:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 10:11:53 GMT
Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with
 G1 are not sequentially consistent [v2]
In-Reply-To: <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
 <JSFP-5aePBNKVQ8RWjau71DnYnNDuuegheus3FFmPH8=.9aabecd7-b613-4e36-8563-aa64b9f6bb1e@github.com>
Message-ID: <gG6yDANKR2N-M-BGtdenFdO8NwBp67bxuuRpB85Sm2o=.674a387d-74be-4dde-8aaa-f9fc7fec4fab@github.com>

On Mon, 2 Jun 2025 07:48:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
>> 
>> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
>> 
>> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about clobbered registers

Thanks for the reviews everyone!

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

PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2929825222

From azafari at openjdk.org  Mon Jun  2 10:42:34 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Jun 2025 10:42:34 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v34]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <D7LJ2OXQR1GGHv5tUNA7tfRvKSbmepDgCOT299E2CGo=.10d5d4ef-9ea3-414d-b2bd-dc10129942ef@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

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

  old format comments are removed. Redundant tests are removed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/14bfe06f..b68495bd

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

  Stats: 1523 lines in 1 file changed: 94 ins; 1361 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

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

From azafari at openjdk.org  Mon Jun  2 11:56:58 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Jun 2025 11:56:58 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v29]
In-Reply-To: <J188imCQjQx2kRegwWq8ad82g8Zx5hnvY_tlaaG17ig=.8efa0640-a840-41c5-acee-3fd4d7bae69c@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <JNLjfTGhYLLTVFi_R7-8jFj1ZmycsfAv8S7OTzKNb3Y=.825a0441-f01a-446d-9cf5-88276b91030c@github.com>
 <J188imCQjQx2kRegwWq8ad82g8Zx5hnvY_tlaaG17ig=.8efa0640-a840-41c5-acee-3fd4d7bae69c@github.com>
Message-ID: <s9ylwMmNZNPICJAYMZYqM1UO-VV31fHjfl9eHhRsBaI=.9070c26a-5dbb-472f-855a-e56d29726bbe@github.com>

On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a missed change in test.
>
> For this case:
> 
> 
>   {// Check committing into a reserved region inherits the call stacks
>     VMATree::RegionData call_stack_test(si_1, mtTest);
>     VMATree::RegionData call_stack_none(si_2, mtNone);
>     VMATree::RegionData call_stack_nmt(si_2, mtNMT);
>     Tree tree;
>     tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree
>     tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region
>     tree.print_timeline_on();
>   }
> 
> 
> I know that we are passing `true` for `use_tag_inplace` here,  but it just does not feel right to get this:
> 
>  ```
>            1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC....................
> Legend:
> A - Test (reserved)
> b - Test (committed)
> C - Test (reserved)
> . - None (free/released)
> 
> 
> I was expecting this:
> 
>  ```
>            1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC....................
> Legend:
> A - Test (reserved)
> b - Native Memory Tracking (committed)
> C - Test (reserved)
> . - None (free/released)
> 
> 
> I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter?

@gerard-ziemski and @jdksjolen, new commit is ready for another round of reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2930318938

From eosterlund at openjdk.org  Mon Jun  2 12:28:58 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 12:28:58 GMT
Subject: Integrated: 8351997: AArch64: Interpreter volatile reference stores
 with G1 are not sequentially consistent
In-Reply-To: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
References: <p1Wiud6P1XQuhZo13sMFORQmdlVU7-ZgaYyKM8K8Kfw=.074de60c-487c-4d24-90dc-7d493c498c88@github.com>
Message-ID: <jZDW5sOj0DC6PN_v2xwrfU6Ck-j6r3XTsII2FmbmdNo=.99ba1f77-8e09-458d-a2e2-431dac0a75e6@github.com>

On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken.
> 
> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits.
> 
> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times.

This pull request has now been integrated.

Changeset: 83b15da2
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83b15da2eb3cb6c8937f517c9b75eaa9eeece314
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent

Reviewed-by: shade, aph, fbredberg

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

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

From cstein at openjdk.org  Mon Jun  2 13:52:15 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 13:52:15 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with trailing
 comment
Message-ID: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>

Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.

The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):

Use the number sign `#` in the argument file to identify comments.
All characters following the `#` are ignored until the end of line.

There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

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

Commit messages:
 - 8357862: Java argument file is parsed unexpectedly with trailing comment

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

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

From cstein at openjdk.org  Mon Jun  2 13:52:16 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 13:52:16 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>

On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

src/java.base/share/native/libjli/args.c line 276:

> 274:                     }
> 275:                     pctx->cptr = nextc + 1;
> 276:                     return token;

This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121214111

From pchilanomate at openjdk.org  Mon Jun  2 14:24:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 2 Jun 2025 14:24:10 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
Message-ID: <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>

> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. 
> 
> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
> 
> Thanks,
> Patricio

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

  Add WhiteBox back + typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25496/files
  - new: https://git.openjdk.org/jdk/pull/25496/files/2fc8d84c..c65e036b

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

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

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

From pchilanomate at openjdk.org  Mon Jun  2 14:24:13 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 2 Jun 2025 14:24:13 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <Xb7zRy5fXOcRjP6fu_yiW4UuYIdB6t1_f3ZrwIC_miM=.a982010b-77d4-481a-9c13-411c1175ccb2@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <Xb7zRy5fXOcRjP6fu_yiW4UuYIdB6t1_f3ZrwIC_miM=.a982010b-77d4-481a-9c13-411c1175ccb2@github.com>
Message-ID: <AUcW8_7irN_VfqLdGI55dOoboQtFpW5ZzUnNmEIy-kk=.3341b650-18f5-4bce-a631-dda21bef89da@github.com>

On Thu, 29 May 2025 07:11:36 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:
>> 
>>   Add WhiteBox back + typo
>
> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 53:
> 
>> 51:             ClassLoader cl = ClassUnloadCommon.newClassLoader();
>> 52:             Class<?> c = cl.loadClass("test.Empty");
>> 53:             // Causes class test.Emtpy to be linked, which triggers the
> 
> Suggestion:
> 
>             // Causes class test.Empty to be linked, which triggers the

Fixed.

> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 66:
> 
>> 64:         Collections.addAll(argsList, args);
>> 65:         Collections.addAll(argsList, "-Xmn8m");
>> 66:         Collections.addAll(argsList, "-Xbootclasspath/a:.");
> 
> Without use of `WhiteBox`, you don't need this. And this is probably what caused the class to be loaded by the boot-loader instead of the custom loader as expected. But the use of WB is needed by `ClassUnloadCommon` and these instructions are present to ensure it works - as added by JDK-8289184.

Added back the use of `WhiteBox`. As to `test.Empty`, it was always loaded by the `app` classloader regardless of `-Xbootclasspath/a:.`, i.e that?s only needed for loading `WhiteBox`. The issue was the missing `test.class.path` property. Class `test.Empty` resides in directory `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/classes/0/runtime/logging/classes/test/` but the process?s current working directory?is `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/scratch/0`, so setting the custom classloader classpath as `.` meant it wasn?t able to find it. So we ended up delegating to the parent classloader (`app`) which already had the correct directories in the classpath.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2121295912
PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2121299488

From nbenalla at openjdk.org  Mon Jun  2 14:46:15 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 14:46:15 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>

> Get JDK 26 underway.

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

 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 23
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
 - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=05
  Stats: 1824 lines in 59 files changed: 1734 ins; 16 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

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

From shade at openjdk.org  Mon Jun  2 14:52:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 14:52:54 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation
In-Reply-To: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
Message-ID: <FsT7LybDIJZ1nmpWDX0cdvA_TlWK1rQonKJQz_6RRp4=.c1baf51e-8162-4870-8ccd-797bf2066f98@github.com>

On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
> 
> Passed tiers 1 - 4 testing.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2888787180

From nbenalla at openjdk.org  Mon Jun  2 14:52:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 14:52:55 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <ipx1oPnsQNo4Anlo64ABbMwZoAeHFQk0bOIp4kyo5ew=.4b73443a-0ba4-48e7-bf77-ffe1e502ac10@github.com>

On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

I have bumped the ASM version in [0dbdde7](https://github.com/openjdk/jdk/pull/25008/commits/0dbdde7bf6a0343acca74b284a8114c60919dd25) because various HotSpot tests use ASM fail under JDK 26 without this change.

This can be rolled back later after [JDK-8356548](https://bugs.openjdk.org/browse/JDK-8356548)

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931105555

From pchilanomate at openjdk.org  Mon Jun  2 15:01:29 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 2 Jun 2025 15:01:29 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual
In-Reply-To: <Zekxp5mbYloANHyyd7j5dpjmOTKmrEzYGy__fVOfaN0=.aa132031-d13a-447f-942f-995c55e1608a@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com>
 <Zekxp5mbYloANHyyd7j5dpjmOTKmrEzYGy__fVOfaN0=.aa132031-d13a-447f-942f-995c55e1608a@github.com>
Message-ID: <PPBD6kqmb__UpcqqvwJGaX11GkSSnHWLH2wRTXSexLw=.d468093a-1de7-4b85-8ecd-bf758f7b066a@github.com>

On Thu, 29 May 2025 22:47:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58:
>> 
>>> 56:         output.shouldNotContain("java.lang.ClassFormatError");
>>> 57:         output.shouldHaveExitValue(1);
>>> 58:         if (Thread.currentThread().isVirtual()) {
>> 
>> Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual.
>> 
>> FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works.
>
> Yes, the the main is executed in virtual thread and also it runs all forked processes with wrapper that run main in virtual thread. 
> The another, might be more clear solution would to check it with
> `static final boolean vthreadMode = "Virtual".equals(System.getProperty("test.thread.factory"));`
> 
> or even make library method for this in the future.

Yes, this check looks a bit better. How about checking that on the child's VM args directly to avoid assumptions between parent/child?
`boolean vthreadMode = pb.command().toString().contains("test.thread.factory=Virtual");`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2121415781

From nbenalla at openjdk.org  Mon Jun  2 15:05:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 2 Jun 2025 15:05:54 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <-CUDiWjPLN2ywVxx5RQWUpmsjgkPLb0AmtnLi3MACP4=.d2aebd91-1220-4a2a-acf2-fb3dc953d908@github.com>

On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

There were no API changes in JDK 25 build 25.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2931159736

From gziemski at openjdk.org  Mon Jun  2 15:07:00 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 2 Jun 2025 15:07:00 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v34]
In-Reply-To: <D7LJ2OXQR1GGHv5tUNA7tfRvKSbmepDgCOT299E2CGo=.10d5d4ef-9ea3-414d-b2bd-dc10129942ef@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <D7LJ2OXQR1GGHv5tUNA7tfRvKSbmepDgCOT299E2CGo=.10d5d4ef-9ea3-414d-b2bd-dc10129942ef@github.com>
Message-ID: <8sr5gvYZaYz_EbxnE_vWOxD-PIrKwfCU6e37BNY18tI=.d7d64ab7-f13d-483e-ad0b-6ea4c6c66852@github.com>

On Mon, 2 Jun 2025 10:42:34 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   old format comments are removed. Redundant tests are removed.

src/hotspot/share/nmt/vmatree.cpp line 116:

> 114:   const int op_index = req.op_to_index();
> 115:   const Operation op = req.op();
> 116:   assert(op != Operation::Invalid && op_index >= 0 && op_index < 4, "should be");

RE: "op_index >= 0 && op_index < 4"
Can we use the class constants here, instead of hardcoding to int values?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2121439751

From gziemski at openjdk.org  Mon Jun  2 15:07:01 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 2 Jun 2025 15:07:01 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v33]
In-Reply-To: <lDWlp-2sXlHPqVvEwtjU8neP7qaSXpWDS4ZDut_bbMg=.0bd6e513-bb4b-4f9b-a3da-54f5262c02fe@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com>
 <OzrvaB3Hgy_KPBWBadQtAWYlUFBFViIYCTUVGO679IU=.cb6bebfb-669f-4b7e-8a15-572f0b4b3f3b@github.com>
 <lDWlp-2sXlHPqVvEwtjU8neP7qaSXpWDS4ZDut_bbMg=.0bd6e513-bb4b-4f9b-a3da-54f5262c02fe@github.com>
Message-ID: <WpK6oXuRsa3Pfm9pCfj4PZL953ggo6_3YGBuy-8BRkc=.bd1e975f-8ced-425a-a693-36e23f512caa@github.com>

On Sun, 1 Jun 2025 06:51:22 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/vmatree.hpp line 249:
>> 
>>> 247:   };
>>> 248: 
>>> 249:   enum Operation {Release, Reserve, Commit, Uncommit, Invalid};
>> 
>> Can we drop `Invalid` and simplify the code?
>> 
>>  ```
>>  enum Operation {Release, Reserve, Commit, Uncommit};
>>   struct RequestInfo {
>>     position A, B;
>>     StateType _op;
>>     MemTag tag;
>>     SIndex callstack;
>>     bool use_tag_inplace;
>>     Operation op() const {
>>       return
>>             _op == StateType::Reserved && !use_tag_inplace  ? Operation::Reserve  :
>>             _op == StateType::Committed                     ? Operation::Commit   :
>>             _op == StateType::Reserved &&  use_tag_inplace  ? Operation::Uncommit :
>>              Operation::Release;
>>     }
>> 
>>     size_t op_to_index() const {
>>       return
>>             _op == StateType::Reserved && !use_tag_inplace  ? 1 :
>>             _op == StateType::Committed                     ? 2 :
>>             _op == StateType::Reserved &&  use_tag_inplace  ? 3 :
>>             0;
>>     }
>
> We need some invalid checking in the impl of register_mapping. How do we detect and report invalid values then?

There is no way an `Operation` can be set `Invalid`, unless we start with a default value, and in this case, instead of `Invalid` we can (should?) be using `Release`, which really does represent the default value.

This is the opposite of my other argument about nmtNone, where I think we could use another value to tell apart default never-set from don't care :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2121434114

From matsaave at openjdk.org  Mon Jun  2 15:11:29 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 2 Jun 2025 15:11:29 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should
 accept VM flags or be marked as flagless
Message-ID: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>

Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.

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

Commit messages:
 - Disabled ZGC on all subtests
 - 8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless

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

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

From vromero at openjdk.org  Mon Jun  2 15:12:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Jun 2025 15:12:53 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
Message-ID: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>

On Mon, 2 Jun 2025 13:48:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
>> 
>> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
>> 
>> Use the number sign `#` in the argument file to identify comments.
>> All characters following the `#` are ignored until the end of line.
>> 
>> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.
>
> src/java.base/share/native/libjli/args.c line 276:
> 
>> 274:                     }
>> 275:                     pctx->cptr = nextc + 1;
>> 276:                     return token;
> 
> This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted?

right I agree that if there is common code we should extract it in a helper method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121454132

From stefank at openjdk.org  Mon Jun  2 15:27:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 2 Jun 2025 15:27:51 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless
In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
Message-ID: <4MH6Hg4tHenfGii_PwxPKbCzWR4d8rntWkho97jxmn0=.7aef9234-f457-479e-b65e-3bc5bda08284@github.com>

On Mon, 2 Jun 2025 14:39:55 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.

We already have this property that is used for some tests:

@requires vm.cds.write.archived.java.heap


Should this be used here instead of explicitly excluding ZGC?

This property boils down to:

// If an incompatible VM options is found, return a text message that explains why
static const char* check_options_incompatible_with_dumping_heap() {
#if INCLUDE_CDS_JAVA_HEAP
  if (!UseCompressedClassPointers) {
    return "UseCompressedClassPointers must be true";
  }

  // Almost all GCs support heap region dump, except ZGC (so far).
  if (UseZGC) {
    return "ZGC is not supported";
  }

  return nullptr;
#else
  return "JVM not configured for writing Java heap objects";
#endif
}

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2888935605

From vromero at openjdk.org  Mon Jun  2 15:37:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Jun 2025 15:37:52 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <rsAtUNjzub-hXleCBRNaWWE8dHweVkY-L38ZO8LCuZY=.0787403b-7484-4d44-9f0f-46a6c9f9e50c@github.com>

On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

the fact that not including a space between the comment and the previous element created havoc seems to indicate that the scanner is pretty fragile and could break again in the future. We should probably file a follow up to make this code more reliable

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

PR Comment: https://git.openjdk.org/jdk/pull/25589#issuecomment-2931287541

From cstein at openjdk.org  Mon Jun  2 15:43:50 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 15:43:50 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <rsAtUNjzub-hXleCBRNaWWE8dHweVkY-L38ZO8LCuZY=.0787403b-7484-4d44-9f0f-46a6c9f9e50c@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <rsAtUNjzub-hXleCBRNaWWE8dHweVkY-L38ZO8LCuZY=.0787403b-7484-4d44-9f0f-46a6c9f9e50c@github.com>
Message-ID: <oGGWZgLD87FOepbwE2uFL-zxzuxD8ShEejVf-BxHkYE=.78fcd216-efaf-4790-853c-fc9f7b8eb498@github.com>

On Mon, 2 Jun 2025 15:35:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the fact that not including a space between the comment and the previous element created havoc seems to indicate that the scanner is pretty fragile and could break again in the future. We should probably file a follow up to make this code more reliable

Yes, seems reasonable.  My initial solution was to try to make use of the shared [CommandLine](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java) class, but the parsing of the launcher is too early in the game.

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

PR Comment: https://git.openjdk.org/jdk/pull/25589#issuecomment-2931306833

From rkennke at openjdk.org  Mon Jun  2 15:49:02 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 2 Jun 2025 15:49:02 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers (Production)
Message-ID: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>

Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

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

Commit messages:
 - 8355319: Update Manpage for Compact Object Headers (Production)

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

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

From rkennke at openjdk.org  Mon Jun  2 15:49:02 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 2 Jun 2025 15:49:02 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <vQdLispy4MZG23474AtTu9texAmSvLeGMflBoiQ-bjI=.983877f1-880f-4267-8728-5580a0f2cfdc@github.com>

On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

@coleenp should this be sent to any mailing list? The Skara bot has not assigned it to any list.

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

PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2931194656

From pchilanomate at openjdk.org  Mon Jun  2 15:58:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 2 Jun 2025 15:58:58 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2]
In-Reply-To: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <lIUS9Dmi6eF4lwGSkH0jXyIR-rNR2pKWrlscSpXNhDo=.c1f1cfa6-8d0d-4c06-8844-92533b0f6eb6@github.com>
 <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com>
Message-ID: <pZ5YuzpePBjgHo0AsGBN14XMyaZDJyCiovq0PDj6hf4=.43af0edb-8618-4a2c-9de0-2a6f8398ba13@github.com>

On Wed, 28 May 2025 18:36:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov 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:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265754
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265754
>>  - 8265754: Refactoring to static methods.
>>  - 8265754: Fixed indentation.
>>  - 8265754: Fixed indentation
>>  - 8265754: Fixed indentation and lost newline.
>>  - 8265754: Fixed whitespaces errors.
>>  - 8265754: More work.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265754
>>  - 8265754: Refactoring suspend/resume in the HandshakeState away
>
> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3

> @pchilano Do you expect to have any performance impact of having an indirection layer?
> 
No concern about performance, just where the code should be for better design and simplicity.

> Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`.
> 
The reason is the interaction with the `HandshakeState` lock. Before, each `JavaThread` had a suspend/resume monitor (`_SR_lock`), but now we are directly using the one from the `HandshakeState` since that?s what the `JavaThread` is holding already when suspending.  

> An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach?
> 
The issue is that you would have to keep those methods that need access to it in `HandshakeState`.

> Another option is to keep things in `HandhshakeSuspender` and give it access to the `HandshakeState `lock , but move `_suspended`/`_async_suspend_handshake` in the suspender. Then, methods should no longer be static, and the suspender itself would be owned by JavaThread, similarly to `HandshakeState `instance.
>
That sounds better. I would personally leave it in `JavaThread` but encapsulating the implementation like that in a new class looks good too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2931371874

From cstein at openjdk.org  Mon Jun  2 16:06:50 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 2 Jun 2025 16:06:50 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
 <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
Message-ID: <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>

On Mon, 2 Jun 2025 15:08:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/java.base/share/native/libjli/args.c line 276:
>> 
>>> 274:                     }
>>> 275:                     pctx->cptr = nextc + 1;
>>> 276:                     return token;
>> 
>> This code duplicates a large part of the block of the previous case. Perhaps an internal helper method could be extracted?
>
> right I agree that if there is common code we should extract it in a helper method

Or the handling of `#` can be merged with the previous case ... somehow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2121594206

From jiangli at openjdk.org  Mon Jun  2 16:00:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 2 Jun 2025 16:00:56 GMT
Subject: RFR: 8357632: CDS test failures on static JDK
In-Reply-To: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
Message-ID: <nOyGVnbXZCNfYzmLltLuw2WdAIcVAXd5fkxgNPvtEds=.346537a4-9c66-4b45-8c7b-8e28ce88721f@github.com>

On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
> 
> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
> 
> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
> 
> Testing:
> Tested the affected tests locally on static-jdk. 
> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.

@calvinccheung @shipilev Could you please review the fix? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2931379145

From matsaave at openjdk.org  Mon Jun  2 16:41:07 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 2 Jun 2025 16:41:07 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
Message-ID: <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>

> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Stefan comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25591/files
  - new: https://git.openjdk.org/jdk/pull/25591/files/3e41fdef..9ef0863f

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

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

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

From matsaave at openjdk.org  Mon Jun  2 16:41:07 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 2 Jun 2025 16:41:07 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <4MH6Hg4tHenfGii_PwxPKbCzWR4d8rntWkho97jxmn0=.7aef9234-f457-479e-b65e-3bc5bda08284@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <4MH6Hg4tHenfGii_PwxPKbCzWR4d8rntWkho97jxmn0=.7aef9234-f457-479e-b65e-3bc5bda08284@github.com>
Message-ID: <XFd7sIGgEBJHwRiYPNuKuVCGcWtrN8pVXt8FIFxSo2E=.b677a627-8705-4b4b-b2d7-170c4742ff8e@github.com>

On Mon, 2 Jun 2025 15:25:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We already have this property that is used for some tests:
> 
> ```
> @requires vm.cds.write.archived.java.heap
> ```
> 
> Should this be used here instead of explicitly excluding ZGC?
> 
> This property boils down to:
> 
> ```
> // If an incompatible VM options is found, return a text message that explains why
> static const char* check_options_incompatible_with_dumping_heap() {
> #if INCLUDE_CDS_JAVA_HEAP
>   if (!UseCompressedClassPointers) {
>     return "UseCompressedClassPointers must be true";
>   }
> 
>   // Almost all GCs support heap region dump, except ZGC (so far).
>   if (UseZGC) {
>     return "ZGC is not supported";
>   }
> 
>   return nullptr;
> #else
>   return "JVM not configured for writing Java heap objects";
> #endif
> }
> ```

I forgot this existed, thanks for pointing it out!

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

PR Comment: https://git.openjdk.org/jdk/pull/25591#issuecomment-2931529934

From ccheung at openjdk.org  Mon Jun  2 16:50:14 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 2 Jun 2025 16:50:14 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation [v2]
In-Reply-To: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
Message-ID: <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>

> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - place the new test in a new file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25562/files
  - new: https://git.openjdk.org/jdk/pull/25562/files/abeb7b6f..e694a720

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

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

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

From shade at openjdk.org  Mon Jun  2 16:50:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 16:50:14 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation [v2]
In-Reply-To: <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
 <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>
Message-ID: <b3n2NU2bIT9Dj3aePVw2-SfryTHkbjrUxSSVCwdGc1k=.83cb28e1-cb2a-4cbc-bd80-17d04f70af9d@github.com>

On Mon, 2 Jun 2025 16:46:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
>> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - place the new test in a new file

Marked as reviewed by shade (Reviewer).

Marked as reviewed by shade (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java line 44:

> 42: public class ManagementAgent {
> 43:     public static void main(String... args) throws Exception {
> 44:         SimpleCDSAppTester.of("HelloAOTCache-with-manangment-agent")

Suggestion:

        SimpleCDSAppTester.of("HelloAOTCache-with-management-agent")

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

PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2889202582
PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2889216659
PR Review Comment: https://git.openjdk.org/jdk/pull/25562#discussion_r2121669853

From iklam at openjdk.org  Mon Jun  2 16:50:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 2 Jun 2025 16:50:14 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation [v2]
In-Reply-To: <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
 <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>
Message-ID: <jJCuyA3ns_Ij3-gUORu_dv2toJBlQLhug8TQc1QenN8=.4921226c-77a9-45ef-9f69-3c2678df95ad@github.com>

On Mon, 2 Jun 2025 16:46:51 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
>> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - place the new test in a new file

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2889210530

From ccheung at openjdk.org  Mon Jun  2 16:50:14 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 2 Jun 2025 16:50:14 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation
In-Reply-To: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
Message-ID: <fVurrkjawCR7yUKB7XXnZBPiQiReONYF3toc-Q3UC0c=.f48fa003-b22c-42ad-9ac5-748d90b58901@github.com>

On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
> 
> Passed tiers 1 - 4 testing.

After discussion with Ioi offline, I've move the new test to a new file `aotCache/ManagementAgent.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25562#issuecomment-2931541114

From phh at openjdk.org  Mon Jun  2 16:53:52 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 2 Jun 2025 16:53:52 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <go4R6Usg4pzH6AB_baFnqXIrFwpz8ktgUkD7-fFgTKo=.4bd7ef18-7b2a-4952-8580-21dda68269dd@github.com>

On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2889236068

From iklam at openjdk.org  Mon Jun  2 16:55:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 2 Jun 2025 16:55:05 GMT
Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an
 empty element
In-Reply-To: <V5XxzdvstcyqC3q4oU3yuTKcSPJKKhO3GvmbnkZmDXA=.c09eaca1-56d9-480a-93dd-d623c8b53bc4@github.com>
References: <MwGR6FigE_0XBrGOlCmXd1PTLYx-l9xN6XEbQKko1M4=.da2602a5-fd4e-42b1-91ae-b88bebfacbdc@github.com>
 <V5XxzdvstcyqC3q4oU3yuTKcSPJKKhO3GvmbnkZmDXA=.c09eaca1-56d9-480a-93dd-d623c8b53bc4@github.com>
Message-ID: <3ryl7wuwna7opBPceC3bznDWxJ5PcgDItddehrCp0HI=.9bd191da-f574-4926-bbcd-29c6d99c5b0d@github.com>

On Thu, 22 May 2025 09:48:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When the classpath has an element that's the empty string (e.g., `java  -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts.
>> 
>> The bug happens because `ClasspathStream` does not correctly omit the empty elements at the beginning of the classpath.
>> 
>> I also improved the logs to help debugging classpath mismatches when using the AOT cache.
>
> This sounds like a bug in `-cp` parsing to me!

Thanks @dholmes-ora @calvinccheung for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25372#issuecomment-2931572656

From ccheung at openjdk.org  Mon Jun  2 16:55:08 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 2 Jun 2025 16:55:08 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation [v2]
In-Reply-To: <Ebgl4K6l98m9RLPS6pqp0L5g0TYTcJ4gFuTa9QHPRIw=.748f6ad2-cf0d-4a22-8e53-438aa4987f6b@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
 <Ebgl4K6l98m9RLPS6pqp0L5g0TYTcJ4gFuTa9QHPRIw=.748f6ad2-cf0d-4a22-8e53-438aa4987f6b@github.com>
Message-ID: <y49dPHPqAk5J0lros66pM6K75iTQJfxiBNfgbfuCnj8=.f9dcaef2-dcb5-435e-b523-87cdac93298a@github.com>

On Sat, 31 May 2025 01:05:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java
>>    
>>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>>  - place the new test in a new file
>
> Good.

Thank you @vnkozlov @shipilev @iklam

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

PR Comment: https://git.openjdk.org/jdk/pull/25562#issuecomment-2931569924

From iklam at openjdk.org  Mon Jun  2 16:55:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 2 Jun 2025 16:55:06 GMT
Subject: Integrated: 8356308: Assert with -Xlog:class+path when classpath has
 an empty element
In-Reply-To: <MwGR6FigE_0XBrGOlCmXd1PTLYx-l9xN6XEbQKko1M4=.da2602a5-fd4e-42b1-91ae-b88bebfacbdc@github.com>
References: <MwGR6FigE_0XBrGOlCmXd1PTLYx-l9xN6XEbQKko1M4=.da2602a5-fd4e-42b1-91ae-b88bebfacbdc@github.com>
Message-ID: <tdo6CvrzMLMHn7iqDeJzigsGiZiie5i267hJb6m4jAQ=.1e3461bc-3e3e-427d-955d-692114460b65@github.com>

On Wed, 21 May 2025 21:28:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When the classpath has an element that's the empty string (e.g., `java  -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts.
> 
> The bug happens because `ClasspathStream` does not correctly omit the empty elements at the beginning of the classpath.
> 
> I also improved the logs to help debugging classpath mismatches when using the AOT cache.

This pull request has now been integrated.

Changeset: bce2bd24
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bce2bd24ef64e71d895bbf4d91693b30a285746b
Stats:     149 lines in 7 files changed: 114 ins; 11 del; 24 mod

8356308: Assert with -Xlog:class+path when classpath has an empty element

Reviewed-by: dholmes, ccheung

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

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

From ccheung at openjdk.org  Mon Jun  2 16:55:09 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 2 Jun 2025 16:55:09 GMT
Subject: Integrated: 8352187: Don't start management agent during AOT cache
 creation
In-Reply-To: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
Message-ID: <oNPRZebkEkCNUVwmIKRJPa1TPzfzWxeMpMwQjfIuMMU=.0f91863b-5cc5-415c-98d7-13cb3255b982@github.com>

On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
> 
> Passed tiers 1 - 4 testing.

This pull request has now been integrated.

Changeset: 8b6a11f7
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b6a11f7e05ee0cece798c5ff6646bddbee04900
Stats:     80 lines in 2 files changed: 73 ins; 0 del; 7 mod

8352187: Don't start management agent during AOT cache creation

Reviewed-by: shade, iklam, kvn

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

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

From ccheung at openjdk.org  Mon Jun  2 16:55:54 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 2 Jun 2025 16:55:54 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
Message-ID: <iD5iQQ5EGETpDQmBB1xyAwblQg4EmBbZaIxsGN9kqzY=.2a6dbd9b-8310-4d04-8338-3300107375d4@github.com>

On Mon, 2 Jun 2025 16:41:07 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan comment

LGTM.

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2889243196

From iveresov at openjdk.org  Mon Jun  2 17:58:15 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 2 Jun 2025 17:58:15 GMT
Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator
 new(size_t, MemTag)
Message-ID: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>

Remove unnecessary no throw

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

Commit messages:
 - Remove unnessesary nothrow

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

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

From kvn at openjdk.org  Mon Jun  2 18:20:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 2 Jun 2025 18:20:51 GMT
Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator
 new(size_t, MemTag)
In-Reply-To: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
References: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
Message-ID: <7cEPkB3RSInsElJHCKjLinZNFktQRGaXt0hOmn7Srno=.b79769db-ef89-4f2d-9b6b-5ef5e5769c20@github.com>

On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove unnecessary no throw

Please, run our testing before integration.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25596#pullrequestreview-2889482857

From cjplummer at openjdk.org  Mon Jun  2 19:09:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:09:57 GMT
Subject: RFR: 8357924: Remove
 runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for
 macosx-x64
In-Reply-To: <oDxyr-4C9Y2u-Q3HgzU9zpk77pixtHyVYi9eD3u4fEI=.acfbec01-817c-4fd4-816b-10cd6029333b@github.com>
References: <oDxyr-4C9Y2u-Q3HgzU9zpk77pixtHyVYi9eD3u4fEI=.acfbec01-817c-4fd4-816b-10cd6029333b@github.com>
Message-ID: <fcCMGy09T1_qHUmOvB3Btfin4bRAtYFt525fTDHCgfI=.733a99d8-36b9-4fc4-9ec0-442b5ab34ea3@github.com>

On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed.
> 
> Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes.

Thank you for the reviews David and Sandao!

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

PR Comment: https://git.openjdk.org/jdk/pull/25556#issuecomment-2932084298

From cjplummer at openjdk.org  Mon Jun  2 19:09:58 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:09:58 GMT
Subject: Integrated: 8357924: Remove
 runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for
 macosx-x64
In-Reply-To: <oDxyr-4C9Y2u-Q3HgzU9zpk77pixtHyVYi9eD3u4fEI=.acfbec01-817c-4fd4-816b-10cd6029333b@github.com>
References: <oDxyr-4C9Y2u-Q3HgzU9zpk77pixtHyVYi9eD3u4fEI=.acfbec01-817c-4fd4-816b-10cd6029333b@github.com>
Message-ID: <fYxKKifQjpXziMav4t0AH1qff5rolnS8AoOC9xMxhAw=.9c8e7077-fe4b-4b84-9d04-f9ff8f4cf4c8@github.com>

On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed.
> 
> Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes.

This pull request has now been integrated.

Changeset: 5243f385
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5243f3851b0345b874ff51ea3a07e82f73741546
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64

Reviewed-by: syan, dholmes

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

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

From coleenp at openjdk.org  Mon Jun  2 20:25:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Jun 2025 20:25:51 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <8fEZlbiG4Ch3GtdFD_Bac4Xd2WUh00ujxDQZKuFYQ_k=.46f69672-6885-43c7-a5b2-0df1af358e51@github.com>

On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

Looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2889827516

From dholmes at openjdk.org  Mon Jun  2 21:45:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 21:45:51 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
Message-ID: <Q3oWS9S_9Lhi1oE0ymhIwFkDzL4LQvZG-9u-GuPxtQ4=.86ced673-b5fd-411f-b747-1e944c9fbbc1@github.com>

On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. 
>> 
>> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add WhiteBox back + typo

test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56:

> 54:             Class<?> c = cl.loadClass(className);
> 55:             cl = null; c = null;
> 56:             ClassUnloadCommon.triggerUnloading();

So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2122215783

From pchilanomate at openjdk.org  Mon Jun  2 22:47:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 2 Jun 2025 22:47:53 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <Q3oWS9S_9Lhi1oE0ymhIwFkDzL4LQvZG-9u-GuPxtQ4=.86ced673-b5fd-411f-b747-1e944c9fbbc1@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
 <Q3oWS9S_9Lhi1oE0ymhIwFkDzL4LQvZG-9u-GuPxtQ4=.86ced673-b5fd-411f-b747-1e944c9fbbc1@github.com>
Message-ID: <ackthzJsrAe2G1yW4z70STGFrA-guQ5Bew56X_lCGWg=.fc2c8453-14ec-4b63-8ad1-de81796f874f@github.com>

On Mon, 2 Jun 2025 21:43:11 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:
>> 
>>   Add WhiteBox back + typo
>
> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56:
> 
>> 54:             Class<?> c = cl.loadClass(className);
>> 55:             cl = null; c = null;
>> 56:             ClassUnloadCommon.triggerUnloading();
> 
> So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved?

Yes, the unloading part is not needed. Before this patch, the only line needed was `ClassLoader cl = ClassUnloadCommon.newClassLoader();`. That would already trigger the constraint we checked for in the parent. But it doesn't work for virtual threads, so I changed it to check for a constraint on the created `ClassUnloadCommonClassLoader` instead to avoid dependencies on previously executed code like with the `app` classloader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2122286788

From dholmes at openjdk.org  Tue Jun  3 00:34:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:34:52 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <Og8KZohzQOS8lrPbAaxDUEdzxrezZIrH5eSeNOMhsUQ=.b48cb2cc-97be-44b6-9767-36a524bf4dc6@github.com>

On Wed, 28 May 2025 11:30:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

Changes requested by dholmes (Reviewer).

src/java.base/share/man/java.md line 1026:

> 1024: :   Enables compact object headers. By default, this option is disabled.
> 1025:     Enabling this option reduces memory footprint in the Java heap by
> 1026:     4 bytes per object (on average).

The options are (with 3 exceptions) in alphabetical order - please move this to  where the other `UseXXX` flags are.

This does not explain at all why someone would want to use, or not use, COH. What are the trade-offs for turning it on? Please explain the usage.

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

PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2890254926
PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2122379295

From dholmes at openjdk.org  Tue Jun  3 00:44:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:44:51 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
Message-ID: <YwqkaGlO74Wg-2vF8-4jPKuHOXyYfDq2yjdq97t5RJg=.2928b160-cf02-4915-90fd-535359d559c6@github.com>

On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. 
>> 
>> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add WhiteBox back + typo

Okay. This test really has me puzzled as to what it was trying to test, but that isn't your doing.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25496#pullrequestreview-2890268037

From qxing at openjdk.org  Tue Jun  3 01:37:54 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 3 Jun 2025 01:37:54 GMT
Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in
 `ClassFileStream`
In-Reply-To: <XRZbCvqCvOVEioVCaz4N6Zuamt-HzzpVS6zrQL_y3J0=.375aeeb4-938b-4119-824e-59cb78b6eef8@github.com>
References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com>
 <XRZbCvqCvOVEioVCaz4N6Zuamt-HzzpVS6zrQL_y3J0=.375aeeb4-938b-4119-824e-59cb78b6eef8@github.com>
Message-ID: <rY__aJuteZaDqZSNuwhjh2f7wGVlFHMPTGPPdWXilSA=.9e5e3ef5-44a5-47f9-b424-44c809d055dc@github.com>

On Thu, 29 May 2025 18:54:09 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration.
>
> Looks good.

@calvinccheung @iklam Thank you for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25518#issuecomment-2933066645

From duke at openjdk.org  Tue Jun  3 01:37:54 2025
From: duke at openjdk.org (duke)
Date: Tue, 3 Jun 2025 01:37:54 GMT
Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in
 `ClassFileStream`
In-Reply-To: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com>
References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com>
Message-ID: <lV7_Eta9VgOO8AZtp85-JFTWtgMhvrniYMSrMQsxCto=.15398f1a-b6f8-42c7-b791-aacf1cdcc5d4@github.com>

On Thu, 29 May 2025 08:09:14 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25518#issuecomment-2933067884

From qxing at openjdk.org  Tue Jun  3 03:13:56 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 3 Jun 2025 03:13:56 GMT
Subject: Integrated: 8358035: Remove unused `compute_fingerprint` declaration
 in `ClassFileStream`
In-Reply-To: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com>
References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com>
Message-ID: <3Drpn9VbtlX8Rw_Cm30hh5sdoRMWz_o-0zCmKAnbig4=.ce8e8ca4-47f5-46f2-9e03-2e5e6b6c6980@github.com>

On Thu, 29 May 2025 08:09:14 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration.

This pull request has now been integrated.

Changeset: c96803dc
Author:    Qizheng Xing <qxing at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c96803dc8b480427bca5b1c6b8c4e8693bc90b92
Stats:     3 lines in 2 files changed: 0 ins; 3 del; 0 mod

8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream`

Reviewed-by: ccheung, iklam

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

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

From kbarrett at openjdk.org  Tue Jun  3 04:10:50 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 3 Jun 2025 04:10:50 GMT
Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator
 new(size_t, MemTag)
In-Reply-To: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
References: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
Message-ID: <ncsRdApmzrxSCXhM_TKp4_1uE3AumeiQLfh7zS1d8oc=.541bf20d-22e4-417a-a2f3-f0f6f7ec9c12@github.com>

On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove unnecessary no throw

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25596#pullrequestreview-2890544108

From stefank at openjdk.org  Tue Jun  3 06:11:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 3 Jun 2025 06:11:52 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
Message-ID: <qaufnMYMPHm47xe42cZvWWAtZ4kyIzHcMrgw57gmi00=.2537d177-bae6-40df-8230-0f909fc1f1f0@github.com>

On Mon, 2 Jun 2025 16:41:07 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan comment

Looks good!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2890821652

From rkennke at openjdk.org  Tue Jun  3 07:04:55 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jun 2025 07:04:55 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <Og8KZohzQOS8lrPbAaxDUEdzxrezZIrH5eSeNOMhsUQ=.b48cb2cc-97be-44b6-9767-36a524bf4dc6@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <Og8KZohzQOS8lrPbAaxDUEdzxrezZIrH5eSeNOMhsUQ=.b48cb2cc-97be-44b6-9767-36a524bf4dc6@github.com>
Message-ID: <Fn-6LkiO9LOslZI78w706zeQoZBdQxTTojMaoew8NlY=.dca6f2c5-f004-462e-8e2c-dc7b181e4e42@github.com>

On Tue, 3 Jun 2025 00:32:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.
>
> src/java.base/share/man/java.md line 1026:
> 
>> 1024: :   Enables compact object headers. By default, this option is disabled.
>> 1025:     Enabling this option reduces memory footprint in the Java heap by
>> 1026:     4 bytes per object (on average).
> 
> The options are (with 3 exceptions) in alphabetical order - please move this to  where the other `UseXXX` flags are.
> 
> This does not explain at all why someone would want to use, or not use, COH. What are the trade-offs for turning it on? Please explain the usage.

I put it there because @coleenp said in the JBS issue: "Since UseCompactObjectHeaders seems more useful than some of the other options in the list (except the JFR and NMT options), I think it should go first." - I can move it down, though.

I don't know what you mean by 'This does not explain at all why someone would want to use, or not use, COH' - I explain right there "Enabling this option reduces memory footprint in the Java heap by 4 bytes per object (on average)." Is this not enough? There is no trade-off (loss of performance or any such issue would be considered a bug, tbh).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2122911362

From dholmes at openjdk.org  Tue Jun  3 07:42:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 07:42:51 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <Fn-6LkiO9LOslZI78w706zeQoZBdQxTTojMaoew8NlY=.dca6f2c5-f004-462e-8e2c-dc7b181e4e42@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <Og8KZohzQOS8lrPbAaxDUEdzxrezZIrH5eSeNOMhsUQ=.b48cb2cc-97be-44b6-9767-36a524bf4dc6@github.com>
 <Fn-6LkiO9LOslZI78w706zeQoZBdQxTTojMaoew8NlY=.dca6f2c5-f004-462e-8e2c-dc7b181e4e42@github.com>
Message-ID: <I1lBEWUXE-qyrI5wOKZwVVPi8br3E3UZLbfgcuTC17c=.802893be-a929-49ff-bfec-48035bfc5f5c@github.com>

On Tue, 3 Jun 2025 07:02:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/java.base/share/man/java.md line 1026:
>> 
>>> 1024: :   Enables compact object headers. By default, this option is disabled.
>>> 1025:     Enabling this option reduces memory footprint in the Java heap by
>>> 1026:     4 bytes per object (on average).
>> 
>> The options are (with 3 exceptions) in alphabetical order - please move this to  where the other `UseXXX` flags are.
>> 
>> This does not explain at all why someone would want to use, or not use, COH. What are the trade-offs for turning it on? Please explain the usage.
>
> I put it there because @coleenp said in the JBS issue: "Since UseCompactObjectHeaders seems more useful than some of the other options in the list (except the JFR and NMT options), I think it should go first." - I can move it down, though.
> 
> I don't know what you mean by 'This does not explain at all why someone would want to use, or not use, COH' - I explain right there "Enabling this option reduces memory footprint in the Java heap by 4 bytes per object (on average)." Is this not enough? There is no trade-off (loss of performance or any such issue would be considered a bug, tbh).

If the flag is off by default but apparently only has the benefit of reducing footprint, then the reader will wonder why it is off by default. At the moment this reads like we have a flag that will benefit everyone and yet we expect them to turn it on themselves because for some reason we chose not to. If this is really a no-lose situation we can say something like I did in the Release Note JBS issue i.e. something like "this is a good thing to do but still under evaluation so is off by default for now".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2122998105

From rkennke at openjdk.org  Tue Jun  3 08:03:50 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jun 2025 08:03:50 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production)
In-Reply-To: <I1lBEWUXE-qyrI5wOKZwVVPi8br3E3UZLbfgcuTC17c=.802893be-a929-49ff-bfec-48035bfc5f5c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <Og8KZohzQOS8lrPbAaxDUEdzxrezZIrH5eSeNOMhsUQ=.b48cb2cc-97be-44b6-9767-36a524bf4dc6@github.com>
 <Fn-6LkiO9LOslZI78w706zeQoZBdQxTTojMaoew8NlY=.dca6f2c5-f004-462e-8e2c-dc7b181e4e42@github.com>
 <I1lBEWUXE-qyrI5wOKZwVVPi8br3E3UZLbfgcuTC17c=.802893be-a929-49ff-bfec-48035bfc5f5c@github.com>
Message-ID: <LCg-09HLBY1hp2ciFWDDPDmakOa0WhfYNYWc-h77NFM=.0a5581f3-f4d6-4835-90c5-c3630269894e@github.com>

On Tue, 3 Jun 2025 07:40:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I put it there because @coleenp said in the JBS issue: "Since UseCompactObjectHeaders seems more useful than some of the other options in the list (except the JFR and NMT options), I think it should go first." - I can move it down, though.
>> 
>> I don't know what you mean by 'This does not explain at all why someone would want to use, or not use, COH' - I explain right there "Enabling this option reduces memory footprint in the Java heap by 4 bytes per object (on average)." Is this not enough? There is no trade-off (loss of performance or any such issue would be considered a bug, tbh).
>
> If the flag is off by default but apparently only has the benefit of reducing footprint, then the reader will wonder why it is off by default. At the moment this reads like we have a flag that will benefit everyone and yet we expect them to turn it on themselves because for some reason we chose not to. If this is really a no-lose situation we can say something like I did in the Release Note JBS issue i.e. something like "this is a good thing to do but still under evaluation so is off by default for now".

Yes this is really a bit odd. 'Still under evaluation' is also weird considering that we just removed the 'experimental' status, which basically saying 'still under evaluation'. Anyway, I will adopt your wording from the release note and move the text down as you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25491#discussion_r2123054321

From syan at openjdk.org  Tue Jun  3 08:12:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Jun 2025 08:12:03 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
Message-ID: <lnpKmP5OhDCWxwC-8EmTHnP2Uk3V2Key8wuGo1waKHA=.bea13fdd-2201-42d5-89b4-8497b1354488@github.com>

On Mon, 2 Jun 2025 16:41:07 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan comment

test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 29:

> 27:  * @summary Test Loading of default archives in all configurations
> 28:  * @requires vm.cds
> 29:  * @requires vm.cds.write.archived.java.heap

Should we update the copyright year from `2024` to `2024, 2025`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25591#discussion_r2123077288

From alanb at openjdk.org  Tue Jun  3 09:41:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 09:41:59 GMT
Subject: RFR: 8352187: Don't start management agent during AOT cache
 creation [v2]
In-Reply-To: <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>
References: <t_jj4S8tTIzgwEwtls5mywREI3HmXaMXkNj5-bPESFg=.a3787534-9afd-46da-bdc1-b40342440738@github.com>
 <rLE_bT4XvQjY3Dq6-BtqOyd3kGNmhPmtuRO0cSqrxVQ=.e31543cc-7df8-4446-870d-763fb1c5b537@github.com>
Message-ID: <gYNwOHnz1o8tnnpsQrQAh4ZZGwmhg0tujxhaTY9FNAA=.fcb1bd4e-f597-4b7c-bc8b-d52293aa4f2a@github.com>

On Mon, 2 Jun 2025 16:50:14 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`.
>> To avoid the exception, this fix is not to start the management agent when creating an AOT cache.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update test/hotspot/jtreg/runtime/cds/appcds/aotCache/ManagementAgent.java
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - place the new test in a new file

> this fix is not to start the management agent when creating an AOT cache.

I think this is good. The initial processing of -Dcom.sun.management will add the jdk.management.agent module to the root set so the set of modules when creating the AOT cache will be the same as runtime, even through the JMX agent isn't started.

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

PR Comment: https://git.openjdk.org/jdk/pull/25562#issuecomment-2934387476

From rkennke at openjdk.org  Tue Jun  3 09:49:41 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jun 2025 09:49:41 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v2]
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <5xhgFtWdz6wuiOiO5SHE_grRpqPvEP3x9Ox4LBgx7IA=.2b1bac77-9c23-4f96-bed2-0a35ba7d0275@github.com>

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

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

  Move text down and add a note about future plans to enable by default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25491/files
  - new: https://git.openjdk.org/jdk/pull/25491/files/d189f600..3ffeaaee

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

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

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

From azafari at openjdk.org  Tue Jun  3 09:58:58 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 3 Jun 2025 09:58:58 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v34]
In-Reply-To: <8sr5gvYZaYz_EbxnE_vWOxD-PIrKwfCU6e37BNY18tI=.d7d64ab7-f13d-483e-ad0b-6ea4c6c66852@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <D7LJ2OXQR1GGHv5tUNA7tfRvKSbmepDgCOT299E2CGo=.10d5d4ef-9ea3-414d-b2bd-dc10129942ef@github.com>
 <8sr5gvYZaYz_EbxnE_vWOxD-PIrKwfCU6e37BNY18tI=.d7d64ab7-f13d-483e-ad0b-6ea4c6c66852@github.com>
Message-ID: <7X_9DmBjEwctV2MXSQVkFLTi4wrp2ZtjYjHSSLVrWKY=.491f1118-82e8-428e-9752-11278959d02d@github.com>

On Mon, 2 Jun 2025 15:04:41 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   old format comments are removed. Redundant tests are removed.
>
> src/hotspot/share/nmt/vmatree.cpp line 116:
> 
>> 114:   const int op_index = req.op_to_index();
>> 115:   const Operation op = req.op();
>> 116:   assert(op != Operation::Invalid && op_index >= 0 && op_index < 4, "should be");
> 
> RE: "op_index >= 0 && op_index < 4"
> Can we use the class constants here, instead of hardcoding to int values?

The constant values are index and I intentionally name the variable as `op_index`. Since the index is used for accessing elements of an array later,  the range of valid values are checked, `0` and  the size of the array.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2123330373

From azafari at openjdk.org  Tue Jun  3 10:18:47 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 3 Jun 2025 10:18:47 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v35]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <I0GU9F9F_3XCwI7b2zla278aey6VgPZYZXO6dv33aWQ=.d29e6f07-cfac-40b1-9e0e-02328e3de0b8@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

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

  invalid -> release.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24028/files
  - new: https://git.openjdk.org/jdk/pull/24028/files/b68495bd..176629bd

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

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

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

From nbenalla at openjdk.org  Tue Jun  3 11:14:36 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:14:36 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>

> Get JDK 26 underway.

Nizar Benalla 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 jdk.8355746
 - Problemlist JavaBaseCheckSince
 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - problem list some failing tests
 - Merge branch 'master' into jdk.8355746
 - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=06
  Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

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

From nbenalla at openjdk.org  Tue Jun  3 11:14:37 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:14:37 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
Message-ID: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>

On Mon, 2 Jun 2025 14:46:15 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 23
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/83cb0c6d...0dbdde7b

I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2934728105

From duke at openjdk.org  Tue Jun  3 11:19:07 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 3 Jun 2025 11:19:07 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v4]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <tUT8zTVevaROU6iw38G-fVzq_Nlpsq749Vv37c3X6Fs=.eb2aaf27-ddeb-4ec9-bb59-75af4c9c997e@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

Anton Artemov has updated the pull request incrementally with six additional commits since the last revision:

 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - 8265754: Refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/3b0fffab..2f6a26d4

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

  Stats: 113 lines in 5 files changed: 20 ins; 34 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/25407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407

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

From duke at openjdk.org  Tue Jun  3 11:19:07 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 3 Jun 2025 11:19:07 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2]
In-Reply-To: <pZ5YuzpePBjgHo0AsGBN14XMyaZDJyCiovq0PDj6hf4=.43af0edb-8618-4a2c-9de0-2a6f8398ba13@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <lIUS9Dmi6eF4lwGSkH0jXyIR-rNR2pKWrlscSpXNhDo=.c1f1cfa6-8d0d-4c06-8844-92533b0f6eb6@github.com>
 <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com>
 <pZ5YuzpePBjgHo0AsGBN14XMyaZDJyCiovq0PDj6hf4=.43af0edb-8618-4a2c-9de0-2a6f8398ba13@github.com>
Message-ID: <4xBAv1XcsxmagkgcP6KyD6lW3-n6vyIDpmvcU0dyaa4=.8a020e6d-1f9a-4fe6-b6b9-0194aa420112@github.com>

On Mon, 2 Jun 2025 15:56:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3
>
>> @pchilano Do you expect to have any performance impact of having an indirection layer?
>> 
> No concern about performance, just where the code should be for better design and simplicity.
> 
>> Since we found out that the suspend/resume code used to belong to JavaThread and then was moved out of there for (some) reason, I do not see a good explanation of why one should bring it back there. JavaThread class is already huge and from maintainability perspective I think it is better to have the suspend/resume API separated. At the same time it is clearly not a part of `HandshakeState`.
>> 
> The reason is the interaction with the `HandshakeState` lock. Before, each `JavaThread` had a suspend/resume monitor (`_SR_lock`), but now we are directly using the one from the `HandshakeState` since that?s what the `JavaThread` is holding already when suspending.  
> 
>> An option might be, if I understand correctly, to do a less straightforward refactoring as suggested above, i.e. without giving `HandshakeState` lock access to `HandshakeSuspender`. I do not yet know if it is doable. Would be a compromise approach?
>> 
> The issue is that you would have to keep those methods that need access to it in `HandshakeState`.
> 
>> Another option is to keep things in `HandhshakeSuspender` and give it access to the `HandshakeState `lock , but move `_suspended`/`_async_suspend_handshake` in the suspender. Then, methods should no longer be static, and the suspender itself would be owned by JavaThread, similarly to `HandshakeState `instance.
>>
> That sounds better. I would personally leave it in `JavaThread` but encapsulating the implementation like that in a new class looks good too.

@pchilano I refactored the code, please take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2934752961

From duke at openjdk.org  Tue Jun  3 11:24:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 3 Jun 2025 11:24:39 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v5]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <5v5EYlx2v0r3jZot9wGYcig_nFC1MpXczWyyIRJhSdQ=.9f44cbaf-bdc8-4a88-8157-5b7acebff9f1@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

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

  8265754: Refactoring.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/2f6a26d4..425ec18e

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

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

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

From sgehwolf at openjdk.org  Tue Jun  3 11:54:52 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Jun 2025 11:54:52 GMT
Subject: RFR: 8356868: Not all cgroup parameters are made available
In-Reply-To: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
References: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
Message-ID: <PVill8Hw43DucAaQmqBwFA9_9-HxEHbn7Y9u-D_aFLQ=.95cd07ba-934f-4206-b2f9-98a36f8cb6e5@github.com>

On Thu, 22 May 2025 09:06:15 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data.
> 
> The new parameters are:
> 
> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time.
> 
> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed.
> 
> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems.
> 
> Testing:
> - All container tests under `/test/hotspot/jtreg/containers/`
> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied.

This looks fine to me. One suggestion as I think the cpu usage might be 0 and greater.

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

> 2492:   st->print("cpu_usage_in_micros: ");
> 2493:   if (j > 0) {
> 2494:     st->print_cr(JLONG_FORMAT, j);

Suggestion:

  if (j >= 0) {
    st->print_cr(JLONG_FORMAT, j);

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25388#pullrequestreview-2891786092
PR Review Comment: https://git.openjdk.org/jdk/pull/25388#discussion_r2123443807

From coleenp at openjdk.org  Tue Jun  3 12:07:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 12:07:53 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v2]
In-Reply-To: <5xhgFtWdz6wuiOiO5SHE_grRpqPvEP3x9Ox4LBgx7IA=.2b1bac77-9c23-4f96-bed2-0a35ba7d0275@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <5xhgFtWdz6wuiOiO5SHE_grRpqPvEP3x9Ox4LBgx7IA=.2b1bac77-9c23-4f96-bed2-0a35ba7d0275@github.com>
Message-ID: <xAsVGw-Lz1x4rm_SfeAEN3mMq57mLzHxHXbv8Z1o4to=.38caf81e-344d-4b08-902f-f37af215d472@github.com>

On Tue, 3 Jun 2025 09:49:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move text down and add a note about future plans to enable by default

I didn't realize they were in alphabetical order, so maybe someone will scroll down and see this option.  The last paragraph sounds odd and whilst is a weird word.  Maybe simply adding a sentence to the main block like, "This option may become the default in a future release."

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

PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2892047473

From coleenp at openjdk.org  Tue Jun  3 12:21:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 12:21:55 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
Message-ID: <D6FVyklHWTc1tQHZNI_VdTuEKA_bLWtS-hEuWMsZ0Q4=.d92ff4e3-9db5-4b1f-a03d-3190e949c8fb@github.com>

On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. 
>> 
>> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add WhiteBox back + typo

Looks good, thank you for fixing this test!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25496#pullrequestreview-2892085800

From coleenp at openjdk.org  Tue Jun  3 12:21:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 12:21:56 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <ackthzJsrAe2G1yW4z70STGFrA-guQ5Bew56X_lCGWg=.fc2c8453-14ec-4b63-8ad1-de81796f874f@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
 <Q3oWS9S_9Lhi1oE0ymhIwFkDzL4LQvZG-9u-GuPxtQ4=.86ced673-b5fd-411f-b747-1e944c9fbbc1@github.com>
 <ackthzJsrAe2G1yW4z70STGFrA-guQ5Bew56X_lCGWg=.fc2c8453-14ec-4b63-8ad1-de81796f874f@github.com>
Message-ID: <f-WViRcRZ53xBuyAOM74xn6b9xFXNgHT9-IDJ6Q93x0=.4ac04df7-d7c1-42e3-9ddb-d9a604258d05@github.com>

On Mon, 2 Jun 2025 22:44:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 56:
>> 
>>> 54:             Class<?> c = cl.loadClass(className);
>>> 55:             cl = null; c = null;
>>> 56:             ClassUnloadCommon.triggerUnloading();
>> 
>> So the unloading is not part of this test? Are we just using the ClassUnloadCommon utility as a convenient way to get an additional classloader involved?
>
> Yes, the unloading part is not needed. Before this patch, the only line needed was `ClassLoader cl = ClassUnloadCommon.newClassLoader();`. That would already trigger the constraint we checked for in the parent. But it doesn't work for virtual threads, so I changed it to check for a constraint on the created `ClassUnloadCommonClassLoader` instead to avoid dependencies on previously executed code like with the `app` classloader.

I think we added the class unloading so that we can see the -Xlog output for that.  But it's not reliable enough so we might have removed it.  This is fine to remove it.

>> test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 66:
>> 
>>> 64:         Collections.addAll(argsList, args);
>>> 65:         Collections.addAll(argsList, "-Xmn8m");
>>> 66:         Collections.addAll(argsList, "-Xbootclasspath/a:.");
>> 
>> Without use of `WhiteBox`, you don't need this. And this is probably what caused the class to be loaded by the boot-loader instead of the custom loader as expected. But the use of WB is needed by `ClassUnloadCommon` and these instructions are present to ensure it works - as added by JDK-8289184.
>
> Added back the use of `WhiteBox`. As to `test.Empty`, it was always loaded by the `app` classloader regardless of `-Xbootclasspath/a:.`, i.e that?s only needed for loading `WhiteBox`. The issue was the missing `test.class.path` property. Class `test.Empty` resides in directory `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/classes/0/runtime/logging/classes/test/` but the process?s current working directory?is `jtreg_test_hotspot_jtreg_runtime_logging_LoaderConstraintsTest_java/scratch/0`, so setting the custom classloader classpath as `.` meant it wasn?t able to find it. So we ended up delegating to the parent classloader (`app`) which already had the correct directories in the classpath.

Good work figuring that out.  yes, ClassUnloadCommon needs this because it uses WhiteBox for class unloading.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2123643517
PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2123640939

From rkennke at openjdk.org  Tue Jun  3 12:55:38 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jun 2025 12:55:38 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v3]
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

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

  Refine text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25491/files
  - new: https://git.openjdk.org/jdk/pull/25491/files/3ffeaaee..2e96057d

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

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

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

From coleenp at openjdk.org  Tue Jun  3 13:03:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 13:03:56 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v3]
In-Reply-To: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>
Message-ID: <WEpOygijeDqiSHAsZYYrSBFsDcu1FYg1Gatq_HHBJSM=.0c3e5cd8-dd16-4b0f-8a66-ae1819f344bd@github.com>

On Tue, 3 Jun 2025 12:55:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine text

Approve again.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2892257447

From rkennke at openjdk.org  Tue Jun  3 13:17:58 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Jun 2025 13:17:58 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v3]
In-Reply-To: <WEpOygijeDqiSHAsZYYrSBFsDcu1FYg1Gatq_HHBJSM=.0c3e5cd8-dd16-4b0f-8a66-ae1819f344bd@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>
 <WEpOygijeDqiSHAsZYYrSBFsDcu1FYg1Gatq_HHBJSM=.0c3e5cd8-dd16-4b0f-8a66-ae1819f344bd@github.com>
Message-ID: <7IzWhcHrNIJhARy1OewtjiUZvf0Okzz6943Pk3lwjBA=.7aff950a-07d7-4f76-8fdc-62d7721b121f@github.com>

On Tue, 3 Jun 2025 13:01:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Approve again.

Thanks!
I'll wait for @dholmes-ora to also approve it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2935180820

From kevinw at openjdk.org  Tue Jun  3 14:13:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 3 Jun 2025 14:13:53 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default
In-Reply-To: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
Message-ID: <C3Qxi-av3wmKBjNhoMlSZNi60fBXYHo5i7RBTNbrmBI=.f31a2feb-cc00-49de-a4ad-bf82c6f6eb3c@github.com>

On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix turns on streaming output for attach operations.
> Change in HotSpotVirtualMachine.java sets attach client property.
> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
> 
> Testing: tier1..tier8

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 66:

> 64:         String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
> 65:         ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
> 66:         // For now the default is false.

Shall we remove the comment?  It was not obvious whether it applied to the code above, or below. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25192#discussion_r2123964340

From matsaave at openjdk.org  Tue Jun  3 15:22:55 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 3 Jun 2025 15:22:55 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <lnpKmP5OhDCWxwC-8EmTHnP2Uk3V2Key8wuGo1waKHA=.bea13fdd-2201-42d5-89b4-8497b1354488@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
 <lnpKmP5OhDCWxwC-8EmTHnP2Uk3V2Key8wuGo1waKHA=.bea13fdd-2201-42d5-89b4-8497b1354488@github.com>
Message-ID: <lySDKooOAnGFaUQYZNxJsD-FnaJad3L4kuVFTK-POuI=.fd84066e-776b-4431-8dba-4a10ea5429b0@github.com>

On Tue, 3 Jun 2025 08:08:49 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Stefan comment
>
> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 29:
> 
>> 27:  * @summary Test Loading of default archives in all configurations
>> 28:  * @requires vm.cds
>> 29:  * @requires vm.cds.write.archived.java.heap
> 
> Should we update the copyright year from `2024` to `2024, 2025`

Do I need to update the Red Hat copyright as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25591#discussion_r2124215598

From matsaave at openjdk.org  Tue Jun  3 15:31:37 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 3 Jun 2025 15:31:37 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v3]
In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
Message-ID: <eQ7Z4lQy3vyzgKerm2q7L0MudkF-Zk5HWa02wzK0pQs=.6d3b38cd-2697-465d-a33e-eb9d6224964a@github.com>

> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25591/files
  - new: https://git.openjdk.org/jdk/pull/25591/files/9ef0863f..12c5a5df

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

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

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

From iveresov at openjdk.org  Tue Jun  3 15:33:57 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 3 Jun 2025 15:33:57 GMT
Subject: RFR: 8358283: Inconsistent failure mode for MetaspaceObj::operator
 new(size_t, MemTag)
In-Reply-To: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
References: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
Message-ID: <awg_xyuFrJheRitufOSO6Vmmgo0CgPxSs3LRS1ehDTU=.239868f1-5d94-4681-b0b1-3e26db09820f@github.com>

On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove unnecessary no throw

Testing was good.

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

PR Comment: https://git.openjdk.org/jdk/pull/25596#issuecomment-2935992831

From iveresov at openjdk.org  Tue Jun  3 15:33:57 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Tue, 3 Jun 2025 15:33:57 GMT
Subject: Integrated: 8358283: Inconsistent failure mode for
 MetaspaceObj::operator new(size_t, MemTag)
In-Reply-To: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
References: <ShKazZOKAxfJplYgtGW_w5QnLiomFP7dQ8hrbcUOXs0=.15ffa8fa-8c1f-4a69-828b-f8ac77dfc21f@github.com>
Message-ID: <C2aAPwS_D8HSF12Oy96ooFEePC9afBNv5EPakYYdcZY=.6f24e863-b185-4b20-a093-86247647ca26@github.com>

On Mon, 2 Jun 2025 17:54:05 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Remove unnecessary no throw

This pull request has now been integrated.

Changeset: 01f01b6f
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01f01b6f7b8a2f0dbe940bffd567ff2b46732787
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8358283: Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag)

Reviewed-by: kvn, kbarrett

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

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

From pchilanomate at openjdk.org  Tue Jun  3 16:16:01 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 3 Jun 2025 16:16:01 GMT
Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
 <zkopfOLdgLdsX_5Q5yIY4oVO6Mvrt4N_vpGrFEN_1GE=.3f627dd1-6dd6-4b70-b781-baa7c3f83e50@github.com>
Message-ID: <IRWwqviMYGer4qmXD84U97GcuA5AKRxSLtgWttXrUN8=.e191f11c-1ce0-413f-90cf-44900963b840@github.com>

On Mon, 2 Jun 2025 14:24:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. 
>> 
>> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add WhiteBox back + typo

Thanks for the reviews David and Coleen!

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

PR Comment: https://git.openjdk.org/jdk/pull/25496#issuecomment-2936164319

From pchilanomate at openjdk.org  Tue Jun  3 16:16:03 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 3 Jun 2025 16:16:03 GMT
Subject: Integrated: 8357910: LoaderConstraintsTest.java fails when run with
 TEST_THREAD_FACTORY=Virtual
In-Reply-To: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
References: <c53x0MLYwJ40PMRC2XTHb0o5JpfWG0fOiPy8CLatE9s=.2d0a7292-0750-462a-a3c5-f24b72abe22b@github.com>
Message-ID: <E139GMfpEGVKCI5A9IVzaNLifVz94dszpRpTzZZ2ZfM=.984e8aa0-5ddd-4d25-ab98-dda3831eb678@github.com>

On Wed, 28 May 2025 14:42:10 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. 
> 
> The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 16e120b0
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16e120b00842e340401b6930354edfb1515f6ca4
Stats:     13 lines in 2 files changed: 5 ins; 3 del; 5 mod

8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual

Reviewed-by: dholmes, coleenp

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

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

From lmesnik at openjdk.org  Tue Jun  3 16:37:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 3 Jun 2025 16:37:52 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v3]
In-Reply-To: <eQ7Z4lQy3vyzgKerm2q7L0MudkF-Zk5HWa02wzK0pQs=.6d3b38cd-2697-465d-a33e-eb9d6224964a@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <eQ7Z4lQy3vyzgKerm2q7L0MudkF-Zk5HWa02wzK0pQs=.6d3b38cd-2697-465d-a33e-eb9d6224964a@github.com>
Message-ID: <QpJ1u9dRiwesHQIabYPrfTF8PFD9s1GjO-HqlvAcctw=.4cbe56f7-0bf5-4d96-ad6b-6773ccca0464@github.com>

On Tue, 3 Jun 2025 15:31:37 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25591#pullrequestreview-2893297395

From dcubed at openjdk.org  Tue Jun  3 18:44:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
Message-ID: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>

A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

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

Commit messages:
 - 8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java

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

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

From ayang at openjdk.org  Tue Jun  3 18:44:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
Message-ID: <xM9tjMvvRjUwvvavZxJOFbj30Dgivl7JsGHLI2nVwJM=.00da6a7d-b41c-4df4-b851-6e83ad2d46c0@github.com>

On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25626#pullrequestreview-2893678505

From bpb at openjdk.org  Tue Jun  3 18:44:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
Message-ID: <N71g2QDwsfhI8pU7JSvEL5J36GH8w6OHhmvzxO-RRW0=.05d7363b-6b35-4fba-851b-1f28d50b8cd1@github.com>

On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25626#pullrequestreview-2893679060

From dcubed at openjdk.org  Tue Jun  3 18:44:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <xM9tjMvvRjUwvvavZxJOFbj30Dgivl7JsGHLI2nVwJM=.00da6a7d-b41c-4df4-b851-6e83ad2d46c0@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
 <xM9tjMvvRjUwvvavZxJOFbj30Dgivl7JsGHLI2nVwJM=.00da6a7d-b41c-4df4-b851-6e83ad2d46c0@github.com>
Message-ID: <InzKQUgEHxnwc_o90oRW31ge7zHQcU5-mNVQlb_v23o=.7352fdce-5e15-4f5b-8a4c-a7fd28f7e824@github.com>

On Tue, 3 Jun 2025 18:39:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk and @bplb - Thanks for the lightning fast reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25626#issuecomment-2936702783

From dcubed at openjdk.org  Tue Jun  3 18:44:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 3 Jun 2025 18:44:37 GMT
Subject: Integrated: 8358539: ProblemList
 jdk/jfr/api/consumer/TestRecordingFileWrite.java
In-Reply-To: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
References: <paMvDag4VjTCDYeO0JO0UVIR0D5NksHZulsPS1wqqy4=.1bbff988-b541-4a1f-a7b4-f3190a8246d2@github.com>
Message-ID: <PEBAzSLzd6k1MwauM-uJFOC7DIT6Y8T_6paBGR_gZuE=.dcdf91d9-a764-41f1-92a9-bde09b8215d2@github.com>

On Tue, 3 Jun 2025 18:35:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java on all platforms.

This pull request has now been integrated.

Changeset: e984fa79
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e984fa7997dda922708edf556d1839b866e44e55
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8358539: ProblemList jdk/jfr/api/consumer/TestRecordingFileWrite.java

Reviewed-by: ayang, bpb

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

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

From amenkov at openjdk.org  Tue Jun  3 18:52:53 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 3 Jun 2025 18:52:53 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default [v2]
In-Reply-To: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
Message-ID: <dELj6Wgfh8fTTpwVeSqY2F8Z12V0Pfqr997nGtvOqaU=.8b2b13a5-2de1-4b0b-a8fb-d9d661263b43@github.com>

> The fix turns on streaming output for attach operations.
> Change in HotSpotVirtualMachine.java sets attach client property.
> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
> 
> Testing: tier1..tier8

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

  removed comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25192/files
  - new: https://git.openjdk.org/jdk/pull/25192/files/076e6e86..1bda79ad

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

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

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

From amenkov at openjdk.org  Tue Jun  3 18:52:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 3 Jun 2025 18:52:54 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default [v2]
In-Reply-To: <C3Qxi-av3wmKBjNhoMlSZNi60fBXYHo5i7RBTNbrmBI=.f31a2feb-cc00-49de-a4ad-bf82c6f6eb3c@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
 <C3Qxi-av3wmKBjNhoMlSZNi60fBXYHo5i7RBTNbrmBI=.f31a2feb-cc00-49de-a4ad-bf82c6f6eb3c@github.com>
Message-ID: <sswBT6GVauvOtsCfvtOHNVwA-KaZNWIvQaOFekwuHcY=.542a9c31-0628-4a70-8eda-d0bec8bc8767@github.com>

On Tue, 3 Jun 2025 14:10:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed comment
>
> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 66:
> 
>> 64:         String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
>> 65:         ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
>> 66:         // For now the default is false.
> 
> Shall we remove the comment?  It was not obvious whether it applied to the code above, or below. 8-)

Yes, it's obsoleted.
Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25192#discussion_r2124652335

From sspitsyn at openjdk.org  Tue Jun  3 19:44:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Jun 2025 19:44:17 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default [v2]
In-Reply-To: <dELj6Wgfh8fTTpwVeSqY2F8Z12V0Pfqr997nGtvOqaU=.8b2b13a5-2de1-4b0b-a8fb-d9d661263b43@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
 <dELj6Wgfh8fTTpwVeSqY2F8Z12V0Pfqr997nGtvOqaU=.8b2b13a5-2de1-4b0b-a8fb-d9d661263b43@github.com>
Message-ID: <7N47_nU8XdHQWJ80QYjApknoFywVnUBNe6arK8eJdtU=.ebf43bc4-a80b-4463-8b0d-eeebb38965de@github.com>

On Tue, 3 Jun 2025 18:52:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix turns on streaming output for attach operations.
>> Change in HotSpotVirtualMachine.java sets attach client property.
>> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
>> 
>> Testing: tier1..tier8
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed comment

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25192#pullrequestreview-2893864149

From kevinw at openjdk.org  Tue Jun  3 20:16:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 3 Jun 2025 20:16:17 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default [v2]
In-Reply-To: <dELj6Wgfh8fTTpwVeSqY2F8Z12V0Pfqr997nGtvOqaU=.8b2b13a5-2de1-4b0b-a8fb-d9d661263b43@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
 <dELj6Wgfh8fTTpwVeSqY2F8Z12V0Pfqr997nGtvOqaU=.8b2b13a5-2de1-4b0b-a8fb-d9d661263b43@github.com>
Message-ID: <JvCkEs_zUoM4EL135scMSxS2ViaP1dqIRmCWXkQ2xqY=.c5717816-95ac-4c1c-8807-9c5a432f2c40@github.com>

On Tue, 3 Jun 2025 18:52:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix turns on streaming output for attach operations.
>> Change in HotSpotVirtualMachine.java sets attach client property.
>> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
>> 
>> Testing: tier1..tier8
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed comment

thanks Alex.
Apologies for looking at this so late 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25192#pullrequestreview-2893995465

From amenkov at openjdk.org  Tue Jun  3 20:51:25 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 3 Jun 2025 20:51:25 GMT
Subject: RFR: 8354460: Streaming output for attach API should be turned on
 by default [v2]
In-Reply-To: <7N47_nU8XdHQWJ80QYjApknoFywVnUBNe6arK8eJdtU=.ebf43bc4-a80b-4463-8b0d-eeebb38965de@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
 <dELj6Wgfh8fTTpwVeSqY2F8Z12V0Pfqr997nGtvOqaU=.8b2b13a5-2de1-4b0b-a8fb-d9d661263b43@github.com>
 <7N47_nU8XdHQWJ80QYjApknoFywVnUBNe6arK8eJdtU=.ebf43bc4-a80b-4463-8b0d-eeebb38965de@github.com>
Message-ID: <u1p6frYtgWc1mvgpX8qXIWeQODJWDbwo9nlViQz0Nnc=.5d90f179-4e28-4d69-8dfc-ef9b4f1b193d@github.com>

On Tue, 3 Jun 2025 19:41:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed comment
>
> Marked as reviewed by sspitsyn (Reviewer).

Thank for the review @sspitsyn and @kevinjwalls

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

PR Comment: https://git.openjdk.org/jdk/pull/25192#issuecomment-2937141735

From amenkov at openjdk.org  Tue Jun  3 20:51:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 3 Jun 2025 20:51:26 GMT
Subject: Integrated: 8354460: Streaming output for attach API should be turned
 on by default
In-Reply-To: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
References: <rG1xUwW8SH05KAL5tFN67thoCPBJpIMlmveQvF_pUv0=.b07e30be-d361-49b8-97d4-548d54b13d27@github.com>
Message-ID: <B42hZFftUlqgDu6JaigqpCj7CeGI59T_9RSI7Ib9kqA=.b91c1a16-2230-408f-a93f-5d5d0c1df185@github.com>

On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix turns on streaming output for attach operations.
> Change in HotSpotVirtualMachine.java sets attach client property.
> Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM).
> 
> Testing: tier1..tier8

This pull request has now been integrated.

Changeset: da49fa5e
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da49fa5e15b137c086ad8fd438bf448da42121cb
Stats:     4 lines in 2 files changed: 0 ins; 1 del; 3 mod

8354460: Streaming output for attach API should be turned on by default

Reviewed-by: sspitsyn, kevinw

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

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

From dholmes at openjdk.org  Tue Jun  3 20:58:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 20:58:22 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v3]
In-Reply-To: <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>
Message-ID: <KNKBTtZWszT0UQ8q7VzE9HsVQAH1dou-k3258NUHfRA=.b9f94ca2-3d15-46d8-a3a9-1f2670ab8618@github.com>

On Tue, 3 Jun 2025 12:55:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine text

I still find it an uninformative piece of documentation I'm afraid. It just begs the question "why isn't this on by default now?". The fact we haven't turned it on means we are still evaluating it. The move from experimental to product just means we are increasing the scope of the evaluation.

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

PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2937169017

From matsaave at openjdk.org  Tue Jun  3 22:49:17 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 3 Jun 2025 22:49:17 GMT
Subject: RFR: 8350029: Illegal invokespecial interface not caught by
 verification
In-Reply-To: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
Message-ID: <NrMIZubO081eg0PDp_Q_v4zTZvqs7QG3x7bDxj9p-3I=.905f1244-e131-4a99-a10a-94d56d9cd1c0@github.com>

On Fri, 30 May 2025 06:31:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check.
> 
> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering.
> 
> Testing:
>  - new test case
>  - tiers 1-3
> 
> Thanks

The changes make sense and look good to me!

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25538#pullrequestreview-2894313447

From dholmes at openjdk.org  Wed Jun  4 01:12:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 01:12:20 GMT
Subject: RFR: 8350029: Illegal invokespecial interface not caught by
 verification
In-Reply-To: <NrMIZubO081eg0PDp_Q_v4zTZvqs7QG3x7bDxj9p-3I=.905f1244-e131-4a99-a10a-94d56d9cd1c0@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
 <NrMIZubO081eg0PDp_Q_v4zTZvqs7QG3x7bDxj9p-3I=.905f1244-e131-4a99-a10a-94d56d9cd1c0@github.com>
Message-ID: <gWu-WSowTeUG0A90X0kv-BlW8Qck07N5SihDRwWr758=.72b021fd-b87d-4bf6-9235-76070583498b@github.com>

On Tue, 3 Jun 2025 22:46:20 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check.
>> 
>> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering.
>> 
>> Testing:
>>  - new test case
>>  - tiers 1-3
>> 
>> Thanks
>
> The changes make sense and look good to me!

Thanks for the review @matias9927 !

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

PR Comment: https://git.openjdk.org/jdk/pull/25538#issuecomment-2937940091

From syan at openjdk.org  Wed Jun  4 01:37:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 4 Jun 2025 01:37:23 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v2]
In-Reply-To: <lySDKooOAnGFaUQYZNxJsD-FnaJad3L4kuVFTK-POuI=.fd84066e-776b-4431-8dba-4a10ea5429b0@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <R0aF9rlAkScK29hMMUPyioKfT6OremX6E0tomf7YBQ0=.72d026fb-72de-4809-963a-f234c6a30d03@github.com>
 <lnpKmP5OhDCWxwC-8EmTHnP2Uk3V2Key8wuGo1waKHA=.bea13fdd-2201-42d5-89b4-8497b1354488@github.com>
 <lySDKooOAnGFaUQYZNxJsD-FnaJad3L4kuVFTK-POuI=.fd84066e-776b-4431-8dba-4a10ea5429b0@github.com>
Message-ID: <fXyZ58oOmgcAT5DIIHz1hAEMiNaykFvRVAm3D-T2bxw=.8590566e-58e6-46a3-9875-2b78c2356eaa@github.com>

On Tue, 3 Jun 2025 15:20:01 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java line 29:
>> 
>>> 27:  * @summary Test Loading of default archives in all configurations
>>> 28:  * @requires vm.cds
>>> 29:  * @requires vm.cds.write.archived.java.heap
>> 
>> Should we update the copyright year from `2024` to `2024, 2025`
>
> Do I need to update the Red Hat copyright as well?

Maybe not need I think

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25591#discussion_r2125250303

From rkennke at openjdk.org  Wed Jun  4 06:08:09 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 4 Jun 2025 06:08:09 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v3]
In-Reply-To: <KNKBTtZWszT0UQ8q7VzE9HsVQAH1dou-k3258NUHfRA=.b9f94ca2-3d15-46d8-a3a9-1f2670ab8618@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <4MGQSQTrD1ZPHad4my6CfI67P-RQzDIcOT18klaiYPs=.aea26867-fe18-4484-a53c-df057ad8ecbb@github.com>
 <KNKBTtZWszT0UQ8q7VzE9HsVQAH1dou-k3258NUHfRA=.b9f94ca2-3d15-46d8-a3a9-1f2670ab8618@github.com>
Message-ID: <dloltJLF-Phzk3oHjaf1NW65Sqr0jsD7qa3M_PxbDcA=.699d1418-ea01-43ea-ba35-f570922d055a@github.com>

On Tue, 3 Jun 2025 20:56:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I still find it an uninformative piece of documentation I'm afraid. It just begs the question "why isn't this on by default now?". The fact we haven't turned it on means we are still evaluating it. The move from experimental to product just means we are increasing the scope of the evaluation.

I restored the explanatory paragraph with slightly rephrased wording, and also added a note about performance in the first part. I hope it's good now? Otherwise please suggest changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2938689671

From rkennke at openjdk.org  Wed Jun  4 06:08:09 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 4 Jun 2025 06:08:09 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v4]
In-Reply-To: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
Message-ID: <XvYg-mIzjmE77h0_6cyzVFiEwz-VfudHQ9PVEVpbwaE=.d9143767-4dc3-458c-9dac-bf2517e994ac@github.com>

> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.

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

  Refine text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25491/files
  - new: https://git.openjdk.org/jdk/pull/25491/files/2e96057d..78ffb12a

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

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

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

From duke at openjdk.org  Wed Jun  4 10:57:47 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 4 Jun 2025 10:57:47 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v6]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <ZM8BMHkhX8MZjipYy4rOluEGBp1QhBiG_TbST4g8Ftk=.17a810d3-65e9-4fa6-913b-baef40338c68@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8265754: Refactoring into separate file.
 - 8265754: Refactoring.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/425ec18e..93b87cfa

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

  Stats: 407 lines in 7 files changed: 229 ins; 168 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407

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

From duke at openjdk.org  Wed Jun  4 11:04:28 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 4 Jun 2025 11:04:28 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v7]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <aay7TcE_SG-4ztMSg0kXCEmpdukbnVkLsmENkwQ1GjA=.1abdede2-58f8-4fe6-9fdb-f6b21b5ae4fc@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8265754: Fixed typo.
 - 8265754: Fixing spaces.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/93b87cfa..4c984b2e

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

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

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

From cnorrbin at openjdk.org  Wed Jun  4 11:33:03 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 4 Jun 2025 11:33:03 GMT
Subject: RFR: 8356868: Not all cgroup parameters are made available [v2]
In-Reply-To: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
References: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
Message-ID: <HyFOvrbl6NwTMMODnCxZnQ_RgHy-sVZYcMgaI74pEEc=.d7b33069-3921-47a6-856a-bb2438c695be@github.com>

> Hi everyone,
> 
> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data.
> 
> The new parameters are:
> 
> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time.
> 
> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed.
> 
> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems.
> 
> Testing:
> - All container tests under `/test/hotspot/jtreg/containers/`
> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied.

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

  update cpu usage to use >=
  
  Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25388/files
  - new: https://git.openjdk.org/jdk/pull/25388/files/cd113cba..878327c5

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

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

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

From cnorrbin at openjdk.org  Wed Jun  4 11:33:03 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 4 Jun 2025 11:33:03 GMT
Subject: RFR: 8356868: Not all cgroup parameters are made available [v2]
In-Reply-To: <PVill8Hw43DucAaQmqBwFA9_9-HxEHbn7Y9u-D_aFLQ=.95cd07ba-934f-4206-b2f9-98a36f8cb6e5@github.com>
References: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
 <PVill8Hw43DucAaQmqBwFA9_9-HxEHbn7Y9u-D_aFLQ=.95cd07ba-934f-4206-b2f9-98a36f8cb6e5@github.com>
Message-ID: <Oac60DIflf1mFHbMD5dfv8t3JPRjz8h_RnmbKKqQvtk=.ffc047d1-45ff-4730-beb4-4a42af435e66@github.com>

On Tue, 3 Jun 2025 11:52:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This looks fine to me. One suggestion as I think the cpu usage might be 0 and greater.

Thank you for reviewing! Have changed the check to use `>=` instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25388#issuecomment-2939664463

From sgehwolf at openjdk.org  Wed Jun  4 12:49:43 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 4 Jun 2025 12:49:43 GMT
Subject: RFR: 8356868: Not all cgroup parameters are made available [v2]
In-Reply-To: <HyFOvrbl6NwTMMODnCxZnQ_RgHy-sVZYcMgaI74pEEc=.d7b33069-3921-47a6-856a-bb2438c695be@github.com>
References: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
 <HyFOvrbl6NwTMMODnCxZnQ_RgHy-sVZYcMgaI74pEEc=.d7b33069-3921-47a6-856a-bb2438c695be@github.com>
Message-ID: <rbvGFzjPMnc9Wj5ukeboKiLyIiW1xySujmtOBONFSHs=.02b75883-8a2f-4fe8-9e69-8c67d51d4102@github.com>

On Wed, 4 Jun 2025 11:33:03 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data.
>> 
>> The new parameters are:
>> 
>> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time.
>> 
>> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed.
>> 
>> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems.
>> 
>> Testing:
>> - All container tests under `/test/hotspot/jtreg/containers/`
>> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update cpu usage to use >=
>   
>   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25388#pullrequestreview-2896597343

From duke at openjdk.org  Wed Jun  4 13:17:45 2025
From: duke at openjdk.org (snake66)
Date: Wed, 4 Jun 2025 13:17:45 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
Message-ID: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>

This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp.

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

Commit messages:
 - Add ucontext accessors for *BSD on Aarch64
 - Remove unused define in os_bsd_aarch64.cpp

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

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

From matsaave at openjdk.org  Wed Jun  4 14:19:00 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 4 Jun 2025 14:19:00 GMT
Subject: RFR: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless [v3]
In-Reply-To: <eQ7Z4lQy3vyzgKerm2q7L0MudkF-Zk5HWa02wzK0pQs=.6d3b38cd-2697-465d-a33e-eb9d6224964a@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
 <eQ7Z4lQy3vyzgKerm2q7L0MudkF-Zk5HWa02wzK0pQs=.6d3b38cd-2697-465d-a33e-eb9d6224964a@github.com>
Message-ID: <GKvgLkdICv3wnk9ARqW1hrsweS6ezgl1988G24uVzhA=.84096df8-9dbb-43bc-a9c9-b525733df37c@github.com>

On Tue, 3 Jun 2025 15:31:37 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright

Thank you for the reviews @sendaoYan, @lmesnik, @calvinccheung, and @stefank!

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

PR Comment: https://git.openjdk.org/jdk/pull/25591#issuecomment-2940210365

From matsaave at openjdk.org  Wed Jun  4 14:19:02 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 4 Jun 2025 14:19:02 GMT
Subject: Integrated: 8345347: Test runtime/cds/TestDefaultArchiveLoading.java
 should accept VM flags or be marked as flagless
In-Reply-To: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
References: <8v5NBYlc_ejkwkF-ma7y6t9QhjWlnoVYUEr9_toQnD8=.2ee17294-f343-43a3-b12e-d05f8bf21766@github.com>
Message-ID: <VHBnzZIi6U7VG1ZhBO2XKv43ukqV3-eY46PzpNFrCec=.06520c6d-5325-4106-b3b8-fcdae7ed41a4@github.com>

On Mon, 2 Jun 2025 14:39:55 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Currently this test uses `ProcessTools.createLimitedTestJavaProcessBuilder()` to ignore vm flags, so this patch changes the method to `ProcessTools.createTestJavaProcessBuilder()` to allow for more extensive training. Because ZGC is incompatible with heap dumping, is is disabled on this test. Verified locally and through tiered testing.

This pull request has now been integrated.

Changeset: a2723d91
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2723d91dfba2850e3070083fa94dc3fecc46a00
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8345347: Test runtime/cds/TestDefaultArchiveLoading.java should accept VM flags or be marked as flagless

Reviewed-by: lmesnik, stefank, ccheung

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

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

From pavel.rappo at gmail.com  Wed Jun  4 17:17:54 2025
From: pavel.rappo at gmail.com (Pavel Rappo)
Date: Wed, 4 Jun 2025 18:17:54 +0100
Subject: Can nanoTime be non-monotonic?
Message-ID: <CAChcVunzrxy8MNBYEDaQ+yoiULf4yVd=WKjkRXcqHn=TyzePsA@mail.gmail.com>

I was reading a book that refers to this 2015 post claiming that
nanoTime can be non-monotonic:
https://steveloughran.blogspot.com/2015/09/time-on-multi-core-multi-socket-servers.html

In fact, I'm not sure what the claim actually is, as the author is a
bit vague. It's unclear whether they say that they have actually
observed it, or they just strongly suspect that it's possible.

Has non-monotonicity ever been observed by hotspot developers? Can it
be observed on a modern hardware + JVM?

Thanks,
-Pavel

From pchilanomate at openjdk.org  Wed Jun  4 20:02:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 20:02:56 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual
In-Reply-To: <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com>
Message-ID: <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com>

On Thu, 29 May 2025 07:28:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
>> 
>> 
>> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>>    public static void main(String[] args)
>> or a JavaFX application class must extend javafx.application.Application
>> 
>> 
>> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
>> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
>> 
>> 
>> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
>> at java.base/java.lang.Class.getMethod(Class.java:2166)
>> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
>> 
>> 
>> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
>> 
>> Thanks,
>> Patricio
>
> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58:
> 
>> 56:         output.shouldNotContain("java.lang.ClassFormatError");
>> 57:         output.shouldHaveExitValue(1);
>> 58:         if (Thread.currentThread().isVirtual()) {
> 
> Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual.
> 
> FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works.

@dholmes-ora @lmesnik are you okay with my suggestion above?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2127344064

From darcy at openjdk.org  Wed Jun  4 20:13:56 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Jun 2025 20:13:56 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <TtJhT2d8gCxXyqE4Do-VMnz1G-4c4yZEw_Bmsw7UWog=.48da9ef3-ebd5-4f08-8ee6-d372d213fd32@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla 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 jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2897980100

From coleenp at openjdk.org  Wed Jun  4 20:14:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Jun 2025 20:14:52 GMT
Subject: RFR: 8350029: Illegal invokespecial interface not caught by
 verification
In-Reply-To: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
Message-ID: <Iv2FEK__XspqIFAsmxYCmgdBMVfAxzYe5YqtnXedF-g=.775d1fc2-30a5-4252-ad47-4b81a110ae89@github.com>

On Fri, 30 May 2025 06:31:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check.
> 
> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering.
> 
> Testing:
>  - new test case
>  - tiers 1-3
> 
> Thanks

Looks good, apart from a couple of file format errors that jcheck doesn't apparently catch.

test/hotspot/jtreg/runtime/verifier/invokespecial/UseInterfaceMethodRef.jasm line 37:

> 35:         return;
> 36:     }
> 37: }

end of file is funny here.

test/hotspot/jtreg/runtime/verifier/invokespecial/UseMethodRef.jasm line 37:

> 35:         return;
> 36:     }
> 37: }

end of file also broken here.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25538#pullrequestreview-2897978478
PR Review Comment: https://git.openjdk.org/jdk/pull/25538#discussion_r2127359997
PR Review Comment: https://git.openjdk.org/jdk/pull/25538#discussion_r2127360392

From iris at openjdk.org  Wed Jun  4 20:37:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jun 2025 20:37:51 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <35K5iPJmI7-SaswDGvLtPKD87st1QJcFgfka38TsImQ=.b8f56c80-d2c6-4282-8b85-eca97880dfe0@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla 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 jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898034878

From kcr at openjdk.org  Wed Jun  4 20:37:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 20:37:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v6]
In-Reply-To: <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <DM7w5oHNTzatkXoLvseezz5CyfYSNNGfwZNvg27uvzM=.82ada683-1b08-4198-aa5a-2472bf6630c9@github.com>
 <_yRRFog3hl3dV5bNvkT2t8vPwaPqOPtzz-JY9_fozKs=.fa645a72-84f9-4736-8ae8-a719302a2f24@github.com>
Message-ID: <_Vfw9XCw0xZe8UevwOD5UOW4dZHoT2VzKC4_PT5nIGI=.9f6c8119-c437-49b1-90f5-740793992c20@github.com>

On Tue, 3 Jun 2025 11:10:30 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I have problemlisted `tools/sincechecker/modules/java.base/JavaBaseCheckSince.java` as it is failing due to the symbol information lagging behind.

What is your plan for addressing this? In its current state, that problem list entry will prevent integration. If you intend to integrate this PR with that test problem listed, you will need to file a new bug and use that bug ID in the problem list.

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

PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2941383168

From kcr at openjdk.org  Wed Jun  4 20:46:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 20:46:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla 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 jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

test/jdk/ProblemList.txt line 843:

> 841: # jdk_since_checks
> 842: 
> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all

You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127408934

From dholmes at openjdk.org  Wed Jun  4 21:13:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 21:13:43 GMT
Subject: RFR: 8350029: Illegal invokespecial interface not caught by
 verification [v2]
In-Reply-To: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
Message-ID: <vHNuIMlf89NLIYtQyn1ly6I4gr4CQWI_JXY1vt4Fx18=.62c8fcc9-bb57-42d7-a555-10f71558221b@github.com>

> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check.
> 
> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering.
> 
> Testing:
>  - new test case
>  - tiers 1-3
> 
> Thanks

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

  Fix new-line at end-of-file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25538/files
  - new: https://git.openjdk.org/jdk/pull/25538/files/1540b0aa..d3f540cc

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

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

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

From dholmes at openjdk.org  Wed Jun  4 21:13:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 21:13:44 GMT
Subject: RFR: 8350029: Illegal invokespecial interface not caught by
 verification [v2]
In-Reply-To: <Iv2FEK__XspqIFAsmxYCmgdBMVfAxzYe5YqtnXedF-g=.775d1fc2-30a5-4252-ad47-4b81a110ae89@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
 <Iv2FEK__XspqIFAsmxYCmgdBMVfAxzYe5YqtnXedF-g=.775d1fc2-30a5-4252-ad47-4b81a110ae89@github.com>
Message-ID: <HRh1EgUpw1A88OP6yqUViLQmsBlkMt1NZngfGq4R4Bw=.2935a7ce-58d2-4c20-8a2e-cc4e6ee7d70d@github.com>

On Wed, 4 Jun 2025 20:12:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix new-line at end-of-file
>
> Looks good, apart from a couple of file format errors that jcheck doesn't apparently catch.

Thanks for the review @coleenp . I have fixed the new-line at end-of-file issue in the jasm files.

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

PR Comment: https://git.openjdk.org/jdk/pull/25538#issuecomment-2941484385

From nbenalla at openjdk.org  Wed Jun  4 21:36:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 21:36:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
 <mjQQ6ZCQWERIdNo17Fcy-PDJJF06I2sPaWMNb6l5E_M=.40e02f60-30eb-46c2-932e-3943f1e456d5@github.com>
Message-ID: <LPUpmFAwsEr9okQ2_9nJfDQNXtD6VX6CI5qi8TEf_-k=.0d220f12-4685-4681-9ea6-ac6f5e8a1d0f@github.com>

On Wed, 4 Jun 2025 20:44:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Nizar Benalla 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 jdk.8355746
>>  - Problemlist JavaBaseCheckSince
>>  - Revert "feedback: never bump ASM version"
>>    
>>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>>  - Merge branch 'master' into jdk.8355746
>>  - Merge branch 'master' into jdk.8355746
>>  - Merge branch 'master' into jdk.8355746
>>  - Update --release 25 symbol information for JDK 25 build 24
>>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>>  - Merge branch 'master' into jdk.8355746
>>  - problem list some failing tests
>>  - Merge branch 'master' into jdk.8355746
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496
>
> test/jdk/ProblemList.txt line 843:
> 
>> 841: # jdk_since_checks
>> 842: 
>> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all
> 
> You will need a different bug ID in order to problem list this test. It is an integration blocker to use the bug ID of a bug being fixed in the problem list.

Will update this in a couple of hours. Thanks Kevin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127478174

From kcr at openjdk.org  Wed Jun  4 21:51:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 4 Jun 2025 21:51:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v7]
In-Reply-To: <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <U7uW5sApFXD7mnEdPc1YOSVN96LpCDCyi4xnnqUw6Jo=.fdea18e4-286d-4711-a27d-81500c0f87b8@github.com>
Message-ID: <CT4PKK-7N0z92vGQulU36AwsHzHnASR0frsvU4kJUkM=.eb614b2e-51b2-437d-bbc0-a8d7ebdd7c84@github.com>

On Tue, 3 Jun 2025 11:14:36 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla 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 jdk.8355746
>  - Problemlist JavaBaseCheckSince
>  - Revert "feedback: never bump ASM version"
>    
>    This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Merge branch 'master' into jdk.8355746
>  - Update --release 25 symbol information for JDK 25 build 24
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
>  - Merge branch 'master' into jdk.8355746
>  - problem list some failing tests
>  - Merge branch 'master' into jdk.8355746
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/c1a81cfb...7b1e1496

test/jdk/ProblemList.txt line 843:

> 841: # jdk_since_checks
> 842: 
> 843: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8355746 generic-all

Suggestion:

tools/sincechecker/modules/java.base/JavaBaseCheckSince.java 8358627 generic-all


@nizarbenalla Per our offline discussion, I created [JDK-8358627](https://bugs.openjdk.org/browse/JDK-8358627) to track this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2127497730

From jaromir.hamala at gmail.com  Wed Jun  4 22:16:01 2025
From: jaromir.hamala at gmail.com (Jaromir Hamala)
Date: Thu, 5 Jun 2025 00:16:01 +0200
Subject: Can nanoTime be non-monotonic?
In-Reply-To: <CAChcVunzrxy8MNBYEDaQ+yoiULf4yVd=WKjkRXcqHn=TyzePsA@mail.gmail.com>
References: <CAChcVunzrxy8MNBYEDaQ+yoiULf4yVd=WKjkRXcqHn=TyzePsA@mail.gmail.com>
Message-ID: <CAMxXA6-fbhDPNG+RVZD_w7SeP_6h0c_+TPg4tOiteaA_M_ZVPQ@mail.gmail.com>

A few years ago, I was wondering the same, so I did some research and wrote
a blog:
https://www.javaadvent.com/2019/12/measuring-time-from-java-to-kernel-and-back.html

tl;dr: you should be good. tsc is sync'ed across cores since Nehalem

On Wed, Jun 4, 2025 at 7:48?PM Pavel Rappo <pavel.rappo at gmail.com> wrote:

> I was reading a book that refers to this 2015 post claiming that
> nanoTime can be non-monotonic:
>
> https://steveloughran.blogspot.com/2015/09/time-on-multi-core-multi-socket-servers.html
>
> In fact, I'm not sure what the claim actually is, as the author is a
> bit vague. It's unclear whether they say that they have actually
> observed it, or they just strongly suspect that it's possible.
>
> Has non-monotonicity ever been observed by hotspot developers? Can it
> be observed on a modern hardware + JVM?
>
> Thanks,
> -Pavel
>


-- 
?Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.?
Antoine de Saint Exup?ry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250605/44ab4d1f/attachment-0001.htm>

From coleenp at openjdk.org  Wed Jun  4 22:44:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Jun 2025 22:44:51 GMT
Subject: RFR: 8350029: Illegal invokespecial interface not caught by
 verification [v2]
In-Reply-To: <vHNuIMlf89NLIYtQyn1ly6I4gr4CQWI_JXY1vt4Fx18=.62c8fcc9-bb57-42d7-a555-10f71558221b@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
 <vHNuIMlf89NLIYtQyn1ly6I4gr4CQWI_JXY1vt4Fx18=.62c8fcc9-bb57-42d7-a555-10f71558221b@github.com>
Message-ID: <Q5ipkU_M3wO1sY2ldtKtH9Pc0fgXEfP-bmai5NU26jw=.9bb9e2de-e04b-4ba8-b1b9-5b5b928d49bf@github.com>

On Wed, 4 Jun 2025 21:13:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check.
>> 
>> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering.
>> 
>> Testing:
>>  - new test case
>>  - tiers 1-3
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix new-line at end-of-file

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25538#pullrequestreview-2898283076

From nbenalla at openjdk.org  Wed Jun  4 23:01:14 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 23:01:14 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v8]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <0wD_TZCgYfWRZurWBE_yoLoNtP7xlUUUPxJ3Stqi5Cs=.42b298e3-bbd7-4d9e-bdfd-ae9176ffc9b5@github.com>

> Get JDK 26 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - use a different bug ID to problemlist `kevinrushforth `
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Problemlist JavaBaseCheckSince
 - Revert "feedback: never bump ASM version"
   
   This reverts commit 7f6e8a8cb305183bc2090dce1f89dc456d181cb5.
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Merge branch 'master' into jdk.8355746
 - Update --release 25 symbol information for JDK 25 build 24
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/
 - Merge branch 'master' into jdk.8355746
 - ... and 12 more: https://git.openjdk.org/jdk/compare/5b27e9c2...09df3b66

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

Changes: https://git.openjdk.org/jdk/pull/25008/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=07
  Stats: 1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/25008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008

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

From nbenalla at openjdk.org  Wed Jun  4 23:09:08 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 4 Jun 2025 23:09:08 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v9]
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>

> Get JDK 26 underway.

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

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25008/files
  - new: https://git.openjdk.org/jdk/pull/25008/files/09df3b66..9929da7b

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

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

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

From iris at openjdk.org  Wed Jun  4 23:56:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 4 Jun 2025 23:56:52 GMT
Subject: RFR: 8355746: Start of release updates for JDK 26 [v9]
In-Reply-To: <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
 <gFIWry-KmlCjSbUQfbXZDS1Vu9XdAgesfId6WktB3EM=.749bcbf5-a04e-4694-a67c-3913ecd68a42@github.com>
Message-ID: <SKr7_DxXZshmrjnCr9TN17KU-5ziqCGNDQCpFY4LmvM=.755c3425-adbb-48a0-8cb0-453601ae7c0e@github.com>

On Wed, 4 Jun 2025 23:09:08 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 26 underway.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2898378068

From dholmes at openjdk.org  Thu Jun  5 00:38:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 00:38:58 GMT
Subject: Integrated: 8350029: Illegal invokespecial interface not caught by
 verification
In-Reply-To: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
References: <X4VDFTmqy9QbkfCedtHdM2VpgSkkEBgjStDCp8FY7cc=.1cffd985-befa-4ea9-863e-bcd7c7081e3d@github.com>
Message-ID: <mfQxQjhqMD-pCzwaiYRSJuQC6FCS-0PeRdyM-l1tKYs=.0140b50b-846b-413f-9c85-6b5d38edbb9b@github.com>

On Fri, 30 May 2025 06:31:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check.
> 
> The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering.
> 
> Testing:
>  - new test case
>  - tiers 1-3
> 
> Thanks

This pull request has now been integrated.

Changeset: 8f8b367a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f8b367ae3c9afca3581f6aced7f9855ef0d541d
Stats:     263 lines in 8 files changed: 209 ins; 1 del; 53 mod

8350029: Illegal invokespecial interface not caught by verification

Reviewed-by: coleenp, matsaave

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

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

From syan at openjdk.org  Thu Jun  5 02:54:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Jun 2025 02:54:49 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <KMGKpPe89OVnFMIp89pagD1SAmQ8kfTmUjVKvQlw1cc=.44f500c3-249d-4886-bb2d-ad6c6dde4984@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

Does this PR remove the file `test/hotspot/jtreg/applications/scimark/Scimark.java` or remove the directory `test/hotspot/jtreg/applications/scimark`

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

PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-2942579847

From dholmes at openjdk.org  Thu Jun  5 03:52:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 03:52:49 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual
In-Reply-To: <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com>
 <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com>
Message-ID: <dh53jG-DMpwUNsz5Gad9_JKscLgjGfidR1lNR9XIbQI=.c93f264e-0df4-4e91-b9c5-226c354aaec8@github.com>

On Wed, 4 Jun 2025 20:00:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58:
>> 
>>> 56:         output.shouldNotContain("java.lang.ClassFormatError");
>>> 57:         output.shouldHaveExitValue(1);
>>> 58:         if (Thread.currentThread().isVirtual()) {
>> 
>> Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual.
>> 
>> FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works.
>
> @dholmes-ora @lmesnik are you okay with my suggestion above?

As long as `command()` returns the information reliably (could it be set via an env-var instead?) then it seems reasonable to check the child process directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2127883503

From pchilanomate at openjdk.org  Thu Jun  5 04:43:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 5 Jun 2025 04:43:47 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
Message-ID: <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>

> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
> 
> 
> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>    public static void main(String[] args)
> or a JavaFX application class must extend javafx.application.Application
> 
> 
> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
> 
> 
> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
> at java.base/java.lang.Class.getMethod(Class.java:2166)
> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
> 
> 
> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
> 
> Thanks,
> Patricio

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

  Check vthread case on child's VM command

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25509/files
  - new: https://git.openjdk.org/jdk/pull/25509/files/0c39d822..73c1ad2e

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

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

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

From pchilanomate at openjdk.org  Thu Jun  5 04:43:48 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 5 Jun 2025 04:43:48 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <dh53jG-DMpwUNsz5Gad9_JKscLgjGfidR1lNR9XIbQI=.c93f264e-0df4-4e91-b9c5-226c354aaec8@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com>
 <7b7imBzQ_XCr7D74UFdg1tN_I9LcPJLAQ4Ib-3SpVgM=.b11a0260-d0c6-43a7-8e23-95b0127204e2@github.com>
 <dh53jG-DMpwUNsz5Gad9_JKscLgjGfidR1lNR9XIbQI=.c93f264e-0df4-4e91-b9c5-226c354aaec8@github.com>
Message-ID: <-5JjT6htJXex0OODLO0eVntppX-Vj5pEWU8Pvm4GoGA=.5eecb2d6-8566-4722-a56a-43eac62fb518@github.com>

On Thu, 5 Jun 2025 03:50:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dholmes-ora @lmesnik are you okay with my suggestion above?
>
> As long as `command()` returns the information reliably (could it be set via an env-var instead?) then it seems reasonable to check the child process directly.

Yes, it?s the full command executed when running the child. If running with the main thread as virtual thread `-Dtest.thread.factory=Virtual` will be included in the command, as added by `ProcessTools.addTestThreadFactoryArgs`. In that case we run `ProcessTools.main` and pass the test name as argument. For this test `pb.command().toString()` would be something like:


[/home/xyz/open/build/linux-x64/images/jdk/bin/java, -cp, ..., -Duser.language=en, -Duser.country=US, -Dtest.thread.factory=Virtual, jdk.test.lib.process.ProcessTools, Virtual, emptynumbootstrapmethods1]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2127933457

From david.holmes at oracle.com  Thu Jun  5 05:08:21 2025
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jun 2025 15:08:21 +1000
Subject: Can nanoTime be non-monotonic?
In-Reply-To: <CAChcVunzrxy8MNBYEDaQ+yoiULf4yVd=WKjkRXcqHn=TyzePsA@mail.gmail.com>
References: <CAChcVunzrxy8MNBYEDaQ+yoiULf4yVd=WKjkRXcqHn=TyzePsA@mail.gmail.com>
Message-ID: <25e92600-28f1-4678-9276-a09664dc6c69@oracle.com>

Hi Pavel,

On 5/06/2025 3:17 am, Pavel Rappo wrote:
> I was reading a book that refers to this 2015 post claiming that
> nanoTime can be non-monotonic:
> https://steveloughran.blogspot.com/2015/09/time-on-multi-core-multi-socket-servers.html
> 
> In fact, I'm not sure what the claim actually is, as the author is a
> bit vague. It's unclear whether they say that they have actually
> observed it, or they just strongly suspect that it's possible.

The article is mainly referring to the unreliable use of the TSC for the 
nanoTime clock on x86 architecture. This has been mostly addressed at 
the hardware level with frequency-invariant TSC, better coordination 
across cores/processors etc. Though virtualization still messes things 
up from time to time.

> Has non-monotonicity ever been observed by hotspot developers? Can it
> be observed on a modern hardware + JVM?

Yes it has been observed many times over the years on different OS, 
different hardware, and importantly different virtualization 
technologies. At different times all of the virtualization technologies 
have "broken" the system clocks in one way or another.

Hotspot relies on the operating system to provide a well behaved clock 
source for nanoTime (and for other timing related functionality). 
Luckily for us the OS clock source support is much better today than 
2015 (and much much better than in 2006 when I wrote my blog article on 
this topic :) [1] ), and the OS tends to deal with many (but not all 
virtualization issues).

At different times we have had logic in hotspot to ensure that nanoTime 
(really the underlying javaTimeNanos in the VM) does not go backwards, 
but with poorly behaving clocks even that has issues as it can cause 
time to appear to freeze until we catch up. Currently only the 
implementation for macOS has a check to stop time from going backwards 
(I don't recall the history on that one).

Cheers,
David

[1] 
https://web.archive.org/web/20160308031939/https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks

> Thanks,
> -Pavel


From dholmes at openjdk.org  Thu Jun  5 05:15:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 05:15:57 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
Message-ID: <uiBXyMmi__JO_ZK1ZJYoCdHrZAQimDUaIhpRVwPf-T0=.0a337933-20f5-47b7-9d43-d1c5bb564c08@github.com>

On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
>> 
>> 
>> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>>    public static void main(String[] args)
>> or a JavaFX application class must extend javafx.application.Application
>> 
>> 
>> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
>> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
>> 
>> 
>> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
>> at java.base/java.lang.Class.getMethod(Class.java:2166)
>> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
>> 
>> 
>> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check vthread case on child's VM command

This seems reasonable to me, but please confirm with @lmesnik that this property is actually set via the command-line args and not an environment variable (or other indirect means).

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2898895476

From duke at openjdk.org  Thu Jun  5 07:49:37 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 5 Jun 2025 07:49:37 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v8]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <N9E5W7R_iigYoyReQF3HtVGqb7TE5Li7MWz8tX_11Nk=.fe0a6474-a085-441a-8dc2-8371512d224a@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

Anton Artemov 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 25 additional commits since the last revision:

 - 8265754: Added a comment.
 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - 8265754: Fixed build problem
 - 8265754: Fixed typo.
 - 8265754: Fixing spaces.
 - 8265754: Refactoring into separate file.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - ... and 15 more: https://git.openjdk.org/jdk/compare/b18dbfea...c07b29ea

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/4c984b2e..c07b29ea

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

  Stats: 18166 lines in 446 files changed: 15049 ins; 1382 del; 1735 mod
  Patch: https://git.openjdk.org/jdk/pull/25407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407

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

From mbaesken at openjdk.org  Thu Jun  5 08:01:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 08:01:50 GMT
Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too low
 values
Message-ID: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>

Currently os::Bsd::available_memory() returns on macOS
`vmstat.free_count * os::vm_page_size();`
But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories 
There is a bit of additional information here https://developer.apple.com/forums/thread/118867
that confirms that free memory / free_count is only a fraction of what is available.

There is also some info here
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB
containing this relevant info :
"The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them."

and also about purgeable memory at
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1

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

Commit messages:
 - JDK-8357570

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

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

From aph at openjdk.org  Thu Jun  5 08:32:51 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 5 Jun 2025 08:32:51 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
Message-ID: <coUcbRM8717-30G5WkDfeAGNiKOwl07lWyCUAHkTC4M=.e4f4f63b-0b7c-4025-83b6-8fb705766b89@github.com>

On Wed, 4 Jun 2025 12:58:57 GMT, snake66 <duke at openjdk.org> wrote:

> This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp.

That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK.

It's nice to see someone fixing things for BSD systems.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25640#pullrequestreview-2899355731

From duke at openjdk.org  Thu Jun  5 08:48:37 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 5 Jun 2025 08:48:37 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v9]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <JOBwClViXWJArlvdyygiGkosysjDviA__yWo6Q78jvU=.34cd7278-11ed-4cb2-9a03-c26ba8c9145e@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

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

  8265754: Changed handshakee to target.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/c07b29ea..272b0293

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

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

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

From sspitsyn at openjdk.org  Thu Jun  5 08:52:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 5 Jun 2025 08:52:52 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
Message-ID: <ZDyPveLbCdl0gQzolt28_pvRUMRnIz7Rz9GSih5sDec=.3c5520fa-a5bf-4656-81d4-1116cc74403b@github.com>

On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
>> 
>> 
>> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>>    public static void main(String[] args)
>> or a JavaFX application class must extend javafx.application.Application
>> 
>> 
>> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
>> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
>> 
>> 
>> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
>> at java.base/java.lang.Class.getMethod(Class.java:2166)
>> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
>> 
>> 
>> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check vthread case on child's VM command

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2899415498

From duke at openjdk.org  Thu Jun  5 09:25:35 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 5 Jun 2025 09:25:35 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process output
 as it happens
Message-ID: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>

The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.

I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

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

Commit messages:
 - Update test/lib/jdk/test/lib/process/OutputBuffer.java
 - Initial working solution

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

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

From liach at openjdk.org  Thu Jun  5 09:25:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 09:25:35 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens
In-Reply-To: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
Message-ID: <I76DIn_uy0FZM6kmFZ_3bCR9CSAAycWYH7AbF3qliQ0=.3a5c4a5f-0dd2-4d2e-af92-23049ddf703e@github.com>

On Mon, 2 Jun 2025 11:54:10 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
> 
> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:       this.p = p;
> 149:       logProgress("Gathering output");
> 150:       boolean verbose = Boolean.valueOf(System.getProperty("outputanalyzer.verbose", "false"));

Suggestion:

      boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2121483594

From duke at openjdk.org  Thu Jun  5 09:36:37 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 5 Jun 2025 09:36:37 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
Message-ID: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>

> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
> 
> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.

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

 - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
 - Update test/lib/jdk/test/lib/process/OutputBuffer.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Initial working solution

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25587/files
  - new: https://git.openjdk.org/jdk/pull/25587/files/db559d20..7cfbec22

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

  Stats: 20245 lines in 457 files changed: 17183 ins; 1318 del; 1744 mod
  Patch: https://git.openjdk.org/jdk/pull/25587.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25587/head:pull/25587

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

From duke at openjdk.org  Thu Jun  5 09:43:50 2025
From: duke at openjdk.org (snake66)
Date: Thu, 5 Jun 2025 09:43:50 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <coUcbRM8717-30G5WkDfeAGNiKOwl07lWyCUAHkTC4M=.e4f4f63b-0b7c-4025-83b6-8fb705766b89@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
 <coUcbRM8717-30G5WkDfeAGNiKOwl07lWyCUAHkTC4M=.e4f4f63b-0b7c-4025-83b6-8fb705766b89@github.com>
Message-ID: <O_vMITSkfa1x3w7oLbBbyaDcC9z7FayIzTXIZRHuG8c=.c60ba80a-eb8a-4506-aefa-f854bffb48c7@github.com>

On Thu, 5 Jun 2025 08:30:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK.

Thanks a lot for the review! My main concern is to not break OSX at this point.

> It's nice to see someone fixing things for BSD systems.

It's part of a long journey, but hopefully we can get all the changes upstreamed at some point. This patch helps reduce the out-of-tree patches we have for now. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2943476942

From duke at openjdk.org  Thu Jun  5 10:01:53 2025
From: duke at openjdk.org (duke)
Date: Thu, 5 Jun 2025 10:01:53 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
Message-ID: <eTDiFXSZAPaSEzISnTGGlurXPL7KDYaG13910SdnwNU=.b8715725-df02-47b2-b506-48db2f5cee53@github.com>

On Wed, 4 Jun 2025 12:58:57 GMT, snake66 <duke at openjdk.org> wrote:

> This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp.

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2943539159

From mli at openjdk.org  Thu Jun  5 11:17:39 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 5 Jun 2025 11:17:39 GMT
Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log
 message
Message-ID: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>

Hi,

Can you help to review this patch?
AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr"
But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added.

Some warning message above is:
"[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)"

Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log.

Thanks!

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

Commit messages:
 - initial commit

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

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

From dholmes at openjdk.org  Thu Jun  5 13:06:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 13:06:55 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v4]
In-Reply-To: <XvYg-mIzjmE77h0_6cyzVFiEwz-VfudHQ9PVEVpbwaE=.d9143767-4dc3-458c-9dac-bf2517e994ac@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <XvYg-mIzjmE77h0_6cyzVFiEwz-VfudHQ9PVEVpbwaE=.d9143767-4dc3-458c-9dac-bf2517e994ac@github.com>
Message-ID: <_vOTNksT3C8ub01teyiw4VhhxoqsVMZiwqKq4P13Qzw=.f347d3a2-0258-4487-b0f1-b620221523bc@github.com>

On Wed, 4 Jun 2025 06:08:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Adds an entry for -XX:+UseCompactObjectHeaders in the manpage for the java command, under 'Advanced runtime options'.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine text

That works for me. Thanls.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25491#pullrequestreview-2900253736

From dholmes at openjdk.org  Thu Jun  5 13:13:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 13:13:52 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

I'm not sure I really understand the proposal here. To where is the output going "as it happens"? If you use OutputAnalyzer  correctly then on failure all output to stdout and stderr is printed via reportDiagnosticSummary. Could you give a concrete example of a test with a problem and how this change fixes it? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2944254033

From duke at openjdk.org  Thu Jun  5 13:51:50 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Thu, 5 Jun 2025 13:51:50 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <9tUh13m9k4GC-CYZiu5hF1kgO_TdnN6y0TmNsc5Al-Q=.c063df53-0f61-45fd-9a42-cbea51c80e47@github.com>
Message-ID: <EPKVCgkLdEirDRfFjjwYZKZ_CFXVvrc_PLRIdDMrI60=.5f09faf1-9904-42cd-8f13-0f1bcc3f7df5@github.com>

On Thu, 5 Jun 2025 13:11:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To where is the output going "as it happens"?

If the `outputanalyzer.verbose` flag is set, the output is going to be printed to the console, in addition to being stored in the buffer

> If you use OutputAnalyzer correctly then on failure all output to stdout and stderr is printed via reportDiagnosticSummary. Could you give a concrete example of a test with a problem and how this change fixes it?

As far as I understand, the creator of the issue would like debugging to be easier; they'd like, while debugging (so having paused) the execution of a test, to be able to see the output of whatever tool is wrapper by `OutputBuffer` in the console, **before** hitting the failure, looking at the output so far in the console, while being able to examine the state of the program being debugged.

As far as an example, I defer to the poster @mpdonova in case they have a more concrete example.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2944467386

From lmesnik at openjdk.org  Thu Jun  5 14:57:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 5 Jun 2025 14:57:52 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
Message-ID: <0HEaPhtvRcMJovgWBGSV7ywLP5OHkDEakO9igLML18w=.a9252a57-0e68-4ab0-aba6-383f3154c6b5@github.com>

On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
>> 
>> 
>> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>>    public static void main(String[] args)
>> or a JavaFX application class must extend javafx.application.Application
>> 
>> 
>> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
>> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
>> 
>> 
>> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
>> at java.base/java.lang.Class.getMethod(Class.java:2166)
>> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
>> 
>> 
>> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check vthread case on child's VM command

I think to add support in test library to find the mode. 
So I'll replace checks along the test code test.thread.factory with library method later.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2900688005

From mdonovan at openjdk.org  Thu Jun  5 15:00:56 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Thu, 5 Jun 2025 15:00:56 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:       this.p = p;
> 149:       logProgress("Gathering output");
> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");

Putting a system property at this level of the code kind of hides the functionality.

An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2129066907

From rkennke at openjdk.org  Thu Jun  5 15:02:01 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 5 Jun 2025 15:02:01 GMT
Subject: RFR: 8355319: Update Manpage for Compact Object Headers
 (Production) [v4]
In-Reply-To: <_vOTNksT3C8ub01teyiw4VhhxoqsVMZiwqKq4P13Qzw=.f347d3a2-0258-4487-b0f1-b620221523bc@github.com>
References: <N6Stut3IilQwZKK0l7407OCsotocof65rwRaJa7PFaI=.f4e494bd-d1ba-4f97-8c4b-a8245898670c@github.com>
 <XvYg-mIzjmE77h0_6cyzVFiEwz-VfudHQ9PVEVpbwaE=.d9143767-4dc3-458c-9dac-bf2517e994ac@github.com>
 <_vOTNksT3C8ub01teyiw4VhhxoqsVMZiwqKq4P13Qzw=.f347d3a2-0258-4487-b0f1-b620221523bc@github.com>
Message-ID: <8s3CRFAS0G2tc5ZdgefdjueZD_o6liZ3XiMBx0wT9AY=.86280e0d-a69d-4782-becf-65882e725bb8@github.com>

On Thu, 5 Jun 2025 13:03:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> That works for me. Thanls.

Great, thank you! @coleenp still good for you?

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

PR Comment: https://git.openjdk.org/jdk/pull/25491#issuecomment-2944897556

From pchilanomate at openjdk.org  Thu Jun  5 15:04:56 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 5 Jun 2025 15:04:56 GMT
Subject: Integrated: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual
In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
Message-ID: <z67hDYAFPe80V73IZxMZnVL1WXBkBK18IA_oQ_KDZIU=.c84097c6-8626-4091-9169-f59c7793a39f@github.com>

On Wed, 28 May 2025 19:31:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
> 
> 
> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>    public static void main(String[] args)
> or a JavaFX application class must extend javafx.application.Application
> 
> 
> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
> 
> 
> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
> at java.base/java.lang.Class.getMethod(Class.java:2166)
> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
> 
> 
> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: c59e44a7
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c59e44a7aa2aeff0823830b698d524523b996650
Stats:     16 lines in 2 files changed: 12 ins; 3 del; 1 mod

8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual

Reviewed-by: lmesnik, dholmes, sspitsyn, syan

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

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

From pchilanomate at openjdk.org  Thu Jun  5 15:04:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 5 Jun 2025 15:04:55 GMT
Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run
 with TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com>
 <LfI16JOe2ZakS5i2dgwecZNLMipdx5F1z-2mAV81AQk=.89166def-c8ac-4800-aae1-24b21e2ff316@github.com>
Message-ID: <9O0XROuy5gDTNkb4H_OpHLW4m1MHEKFZp-NVdd84K-w=.a22aff6c-bc37-4cd9-ba04-975605530453@github.com>

On Thu, 5 Jun 2025 04:43:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output:
>> 
>> 
>> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as:
>>    public static void main(String[] args)
>> or a JavaFX application class must extend javafx.application.Application
>> 
>> 
>> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses
>> `Method mainMethod = c.getMethod("main", new Class<?>[] { String[].class });` which throws an exception instead and the test exits with the following error message:
>> 
>> 
>> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;)
>> at java.base/java.lang.Class.getMethod(Class.java:2166)
>> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984)
>> 
>> 
>> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check vthread case on child's VM command

Thanks everyone for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25509#issuecomment-2944905681

From iklam at openjdk.org  Thu Jun  5 15:13:50 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 5 Jun 2025 15:13:50 GMT
Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log
 message
In-Reply-To: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
References: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
Message-ID: <QzLh8hreJzxItKVLqp6gwCZmGLH9QeIeqtDPjAUjVlY=.3a69cc9f-ea85-4503-85f0-569020b87031@github.com>

On Thu, 5 Jun 2025 11:12:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> 
> Can you help to review this patch?
> AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr"
> But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added.
> 
> Some warning message above is:
> "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)"
> 
> Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly.
> 
> Thanks!

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25658#pullrequestreview-2900745642

From shade at openjdk.org  Thu Jun  5 15:50:50 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 15:50:50 GMT
Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log
 message
In-Reply-To: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
References: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
Message-ID: <2PlHhIe5OhddHV69toGz4qQXy0le8k0lUtByf3q8pc0=.fd0d3689-3c0f-4474-aa6b-8187d28971a1@github.com>

On Thu, 5 Jun 2025 11:12:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> 
> Can you help to review this patch?
> AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr"
> But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added.
> 
> Some warning message above is:
> "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)"
> 
> Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly.
> 
> Thanks!

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25658#pullrequestreview-2900869160

From nbenalla at openjdk.org  Thu Jun  5 16:03:58 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Jun 2025 16:03:58 GMT
Subject: Integrated: 8355746: Start of release updates for JDK 26
In-Reply-To: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
References: <oahQjTMpTGZrhD7WGV7L_7-C2N5YsOKHVdnBd-UcJrU=.9174eda7-8adb-4091-afd0-59cdc99a56aa@github.com>
Message-ID: <-TeQIT9Gmt8CLUcMmPfOQzcPTIGyMpqqVsuEloBx6x8=.55986278-6168-4eff-9784-d91ed7768650@github.com>

On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 26 underway.

This pull request has now been integrated.

Changeset: af87035b
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af87035b713f8bfe05a007a4d4670cefc6a6aaf2
Stats:     1830 lines in 60 files changed: 1740 ins; 16 del; 74 mod

8355746: Start of release updates for JDK 26
8355748: Add SourceVersion.RELEASE_26
8355751: Add source 26 and target 26 to javac

Co-authored-by: Joe Darcy <darcy at openjdk.org>
Reviewed-by: iris, coleenp, darcy

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

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

From iklam at openjdk.org  Fri Jun  6 03:51:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Jun 2025 03:51:37 GMT
Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826
Message-ID: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>

CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js.

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

Commit messages:
 - 8357591: Re-enable CDS test cases for jvmci after JDK-8345826

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

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

From duke at openjdk.org  Fri Jun  6 08:20:00 2025
From: duke at openjdk.org (snake66)
Date: Fri, 6 Jun 2025 08:20:00 GMT
Subject: Integrated: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
Message-ID: <lvnM0ZVhGfbXDO6uC2bzfCsMk4w9btKfKNkiwNRsYqc=.5302cb35-afbe-4eaf-8680-5c67f46154af@github.com>

On Wed, 4 Jun 2025 12:58:57 GMT, snake66 <duke at openjdk.org> wrote:

> This adds macros for non-OSX BSD variants to access the required fields from ucontext_t in os_bsd_aarch64.cpp, similar to how it's already done for x86_64 in os_bsd_x86.cpp.

This pull request has now been integrated.

Changeset: 65fda5c0
Author:    Harald Eilertsen <haraldei at anduin.net>
Committer: Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65fda5c02aeb1832bc88dc83ee8465cd8ad89179
Stats:     29 lines in 1 file changed: 27 ins; 2 del; 0 mod

8358593: Add ucontext accessors for *BSD on Aarch64

Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
Co-authored-by: Kurt Miller <bsdkurt at gmail.com>
Reviewed-by: aph

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

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

From ktakakuri at openjdk.org  Fri Jun  6 08:21:08 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Fri, 6 Jun 2025 08:21:08 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
Message-ID: <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>

> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
> After this fix, I verified that the test passed.
> 
> https://github.com/openjdk/jdk/pull/22142
> I refer to this fix.
> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
> 
> Thanks.

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

  8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23536/files
  - new: https://git.openjdk.org/jdk/pull/23536/files/b2d8284b..363c5a39

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

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

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

From ktakakuri at openjdk.org  Fri Jun  6 08:21:08 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Fri, 6 Jun 2025 08:21:08 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v7]
In-Reply-To: <AMkDCvuJcjXrf_oTpr5QmTUC1QzrPj_3s4gZ9MQtKMw=.2ff5d85a-5e75-4049-a6e1-d673488d6843@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com>
 <AMkDCvuJcjXrf_oTpr5QmTUC1QzrPj_3s4gZ9MQtKMw=.2ff5d85a-5e75-4049-a6e1-d673488d6843@github.com>
Message-ID: <naX144T6WVoe4hEEGBfH28rn_U9hlLfdhZvMoJ59YJQ=.2bea047f-17fa-41df-97bf-608cdd1047b3@github.com>

On Thu, 8 May 2025 10:35:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform
>
> test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 72:
> 
>> 70:             System.getenv("WINDIR")     != null ? new File(System.getenv ("WINDIR")) :
>> 71:             null;
>> 72:         String systemDirW = new File(systemRoot, "System32").getPath();
> 
> If `SystemRoot` is null this will just throw `NullPointerException`. You should check for null and throw a more meaningful exception

I'm sorry for being extremely late.
According to the [API documentation](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/io/File.html#%3Cinit%3E(java.io.File,java.lang.String)) , it seems that NullPointerException is not thrown even if parent(systemRoot) is null. However, I believe that a null check is necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2131740823

From clanger at openjdk.org  Fri Jun  6 11:00:59 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 6 Jun 2025 11:00:59 GMT
Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too
 low values
In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
Message-ID: <-Xzby9ixx_ilXsC5VYTqrbG5XlLf9Ig7eH-JlZPpeoE=.33941345-7c45-4a63-bfff-a49e70d70f9b@github.com>

On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently os::Bsd::available_memory() returns on macOS
> `vmstat.free_count * os::vm_page_size();`
> But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories 
> There is a bit of additional information here https://developer.apple.com/forums/thread/118867
> that confirms that free memory / free_count is only a fraction of what is available.
> 
> There is also some info here
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB
> containing this relevant info :
> "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them."
> 
> and also about purgeable memory at
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1

Looking at the linked documentation this seems to make sense, although I have no means to check plausibility.

Maybe the comment before os::Bsd::available_memory could be modified/weakened a little bit because with the updated gathering it might be of some more use now... ?

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25657#pullrequestreview-2904580999

From mli at openjdk.org  Fri Jun  6 14:01:54 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 6 Jun 2025 14:01:54 GMT
Subject: RFR: 8358685: [TEST] AOTLoggingTag.java failed with missing log
 message
In-Reply-To: <QzLh8hreJzxItKVLqp6gwCZmGLH9QeIeqtDPjAUjVlY=.3a69cc9f-ea85-4503-85f0-569020b87031@github.com>
References: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
 <QzLh8hreJzxItKVLqp6gwCZmGLH9QeIeqtDPjAUjVlY=.3a69cc9f-ea85-4503-85f0-569020b87031@github.com>
Message-ID: <F7Wx5RChTq8gA02dmi9FoB0rBPTqEC2xrLbu0c_ku4k=.dba53dc6-ad27-45f0-8735-2a5aae844f7d@github.com>

On Thu, 5 Jun 2025 15:10:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi,
>> 
>> Can you help to review this patch?
>> AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr"
>> But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added.
>> 
>> Some warning message above is:
>> "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)"
>> 
>> Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly.
>> 
>> Thanks!
>
> LGTM

Thank you @iklam @shipilev for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25658#issuecomment-2949357340

From mli at openjdk.org  Fri Jun  6 14:01:54 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 6 Jun 2025 14:01:54 GMT
Subject: Integrated: 8358685: [TEST] AOTLoggingTag.java failed with missing log
 message
In-Reply-To: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
References: <CB4VAtMVhE5_kJU8HQiA3EU1sT7FYSq8Mr7hIj0zGys=.c1360238-515a-4a1c-9974-afcf3272f028@github.com>
Message-ID: <3pprVkm8iLcGVsPbUpeZr0O7qP-Jk6RhZwv9dPHNqqQ=.27ef010e-4f94-4e41-af10-e8eefca90450@github.com>

On Thu, 5 Jun 2025 11:12:30 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> 
> Can you help to review this patch?
> AOTLoggingTag.java failed with "'[info][aot] Writing binary AOTConfiguration file:' missing from stdout/stderr"
> But in fact there is such log, but it looks like "[info ][aot] Writing binary AOTConfiguration file: hello.aotconfig", because there is some [warning] message above it, so there space indent added.
> 
> Some warning message above is:
> "[warning][aot] Method in original class is missing from regenerated class: 0x00007f14c04653b0 double java.lang.invoke.LambdaForm$Holder.zero_D(java.lang.Object)"
> 
> Seems it's enough to just verify `[aot] Writing binary AOTConfiguration file:` exist in the log, I hope I'm understanding the original intention of this test correctly.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 9658cecd
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9658cecde34a6e9cd39656d21a4ae8bc42da5956
Stats:     6 lines in 1 file changed: 0 ins; 1 del; 5 mod

8358685: [TEST] AOTLoggingTag.java failed with missing log message

Reviewed-by: iklam, shade

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

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

From ccheung at openjdk.org  Fri Jun  6 16:40:25 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 6 Jun 2025 16:40:25 GMT
Subject: RFR: 8358799: Refactor os::jvm_path()
Message-ID: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>

The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.

Passed tiers 1 - 3 tests.
However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.

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

Commit messages:
 - 8358799: Refactor os::jvm_path()

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

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

From jiangli at openjdk.org  Fri Jun  6 19:03:49 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 6 Jun 2025 19:03:49 GMT
Subject: RFR: 8357632: CDS test failures on static JDK
In-Reply-To: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
Message-ID: <6SqIq4AyBPM50gxQoPlquoIO89ydrBfnc_dfEStbcNk=.ff4fa1c3-c128-43a7-bf0e-0221c435dc8c@github.com>

On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
> 
> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
> 
> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
> 
> Testing:
> Tested the affected tests locally on static-jdk. 
> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.

Friendly ping, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2950258698

From ccheung at openjdk.org  Fri Jun  6 19:25:53 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 6 Jun 2025 19:25:53 GMT
Subject: RFR: 8357632: CDS test failures on static JDK
In-Reply-To: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
Message-ID: <a7GTvJjNGRgfJ84EoqMWV7HMcoU_b2G3EOzvPZadpU0=.666bcac7-1d6b-4c41-827e-78e3de6cabd7@github.com>

On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
> 
> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
> 
> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
> 
> Testing:
> Tested the affected tests locally on static-jdk. 
> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.

Looks good. Thanks!

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

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25516#pullrequestreview-2905953462

From duke at openjdk.org  Fri Jun  6 20:48:01 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 6 Jun 2025 20:48:01 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic
Message-ID: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>

This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags.

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

Commit messages:
 - Fix assertion failures for libm math intrinsics that don't have shared runtime implementations

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

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

From duke at openjdk.org  Fri Jun  6 20:48:01 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 6 Jun 2025 20:48:01 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <U-FbeW9fBlz-tgsGtxL9nhtdD7_WHgj-X3CmC8frzOE=.29cef8ac-7503-4ea1-ad7e-096a26709c55@github.com>

On Fri, 6 Jun 2025 20:40:49 GMT, Mohamed Issa <duke at openjdk.org> wrote:

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags.

@dholmes-ora Does this fix the _-XX:-InlineIntrinsics_ assertion failures when running CubeRootTests.java and HyperbolicTests.java? I couldn't reproduce those, but I could reproduce the one with `java -XX:-UseLibmIntrinsic -version`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2950752859

From duke at openjdk.org  Fri Jun  6 21:10:11 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 6 Jun 2025 21:10:11 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v2]
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <nDd9m9SeREPKVMePAzt0g5ThH8qqZZnoPwJs_bsOfWk=.c42f0325-eb65-409b-9c40-ad180f5a4630@github.com>

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags.

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

  Move UseLibmIntrinsic flag to x86 portion of code base to avoid build breaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25680/files
  - new: https://git.openjdk.org/jdk/pull/25680/files/21cda33d..c11f54e1

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

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

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

From sviswanathan at openjdk.org  Fri Jun  6 23:03:50 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Jun 2025 23:03:50 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v2]
In-Reply-To: <nDd9m9SeREPKVMePAzt0g5ThH8qqZZnoPwJs_bsOfWk=.c42f0325-eb65-409b-9c40-ad180f5a4630@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <nDd9m9SeREPKVMePAzt0g5ThH8qqZZnoPwJs_bsOfWk=.c42f0325-eb65-409b-9c40-ad180f5a4630@github.com>
Message-ID: <kuGnQ5UZYt6dtx8Fd1wrs7eym5aElJNb5NlEZo6WDY8=.2506a3e1-c474-4caa-a396-e3304cac6ce0@github.com>

On Fri, 6 Jun 2025 21:10:11 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move UseLibmIntrinsic flag to x86 portion of code base to avoid build breaks

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

> 261:     switch (id) {
> 262:     case vmIntrinsics::_dtanh:
> 263:     case vmIntrinsics::_dcbrt:

You could also move _floatToFloat16 and _float16ToFloat to here from the switch below to make it consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133035942

From jiangli at openjdk.org  Fri Jun  6 23:15:51 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 6 Jun 2025 23:15:51 GMT
Subject: RFR: 8357632: CDS test failures on static JDK
In-Reply-To: <a7GTvJjNGRgfJ84EoqMWV7HMcoU_b2G3EOzvPZadpU0=.666bcac7-1d6b-4c41-827e-78e3de6cabd7@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
 <a7GTvJjNGRgfJ84EoqMWV7HMcoU_b2G3EOzvPZadpU0=.666bcac7-1d6b-4c41-827e-78e3de6cabd7@github.com>
Message-ID: <8wttXy_J0jZpDKDEStSxXt1rNzBmkF8BAz9w_vix3pA=.c5a0fa63-ae0b-4d33-bc25-a2a9dc72b37b@github.com>

On Fri, 6 Jun 2025 19:22:47 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
>> 
>> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
>> 
>> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
>> 
>> Testing:
>> Tested the affected tests locally on static-jdk. 
>> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.
>
> Looks good. Thanks!

@calvinccheung Thanks for the review!

Can I have a second review for the PR, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2951175735

From duke at openjdk.org  Fri Jun  6 23:33:05 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 6 Jun 2025 23:33:05 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v3]
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <qsUWN4D-_jpQq_t-Eo4x78GZUNGYiEy3OLMvyBqvl4g=.a12c778d-2076-4818-a74b-3aa1ac8a5cef@github.com>

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by the _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_ flags.

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

  Re-structure logic to avoid reliance on UseLibmIntrinsic flag as others could be used later on

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25680/files
  - new: https://git.openjdk.org/jdk/pull/25680/files/c11f54e1..8dadb41c

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

  Stats: 35 lines in 2 files changed: 10 ins; 21 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25680/head:pull/25680

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

From duke at openjdk.org  Fri Jun  6 23:33:05 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Fri, 6 Jun 2025 23:33:05 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v2]
In-Reply-To: <kuGnQ5UZYt6dtx8Fd1wrs7eym5aElJNb5NlEZo6WDY8=.2506a3e1-c474-4caa-a396-e3304cac6ce0@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <nDd9m9SeREPKVMePAzt0g5ThH8qqZZnoPwJs_bsOfWk=.c42f0325-eb65-409b-9c40-ad180f5a4630@github.com>
 <kuGnQ5UZYt6dtx8Fd1wrs7eym5aElJNb5NlEZo6WDY8=.2506a3e1-c474-4caa-a396-e3304cac6ce0@github.com>
Message-ID: <lKXfZAZajljeMOfsi4vStPOVYu2_o-EPOkj4PBCP6tI=.c0610415-23f0-4861-bae3-c853587d06b1@github.com>

On Fri, 6 Jun 2025 22:58:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move UseLibmIntrinsic flag to x86 portion of code base to avoid build breaks
>
> src/hotspot/share/classfile/vmIntrinsics.cpp line 263:
> 
>> 261:     switch (id) {
>> 262:     case vmIntrinsics::_dtanh:
>> 263:     case vmIntrinsics::_dcbrt:
> 
> You could also move _floatToFloat16 and _float16ToFloat to here from the switch below to make it consistent.

Ok, I moved them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133072865

From sviswanathan at openjdk.org  Fri Jun  6 23:43:50 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 6 Jun 2025 23:43:50 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v3]
In-Reply-To: <qsUWN4D-_jpQq_t-Eo4x78GZUNGYiEy3OLMvyBqvl4g=.a12c778d-2076-4818-a74b-3aa1ac8a5cef@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <qsUWN4D-_jpQq_t-Eo4x78GZUNGYiEy3OLMvyBqvl4g=.a12c778d-2076-4818-a74b-3aa1ac8a5cef@github.com>
Message-ID: <ihrfDXIA-cMj34MgY13QZTbq5L9dLhOBoxHqa66sx00=.f26cf569-1c7f-4446-a3a2-1f405e63061f@github.com>

On Fri, 6 Jun 2025 23:33:05 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-structure logic to avoid reliance on UseLibmIntrinsic flag as others could be used later on

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

> 317:   case vmIntrinsics::_dtanh:
> 318:   case vmIntrinsics::_dcbrt:
> 319:     if (!InlineMathNatives) return true;

Ah, looks like you missed !InlineIntrinsic check here:
if (!InlineMathNatives || !InlineIntrinsics) return true;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133077192

From duke at openjdk.org  Sat Jun  7 00:57:25 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Sat, 7 Jun 2025 00:57:25 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v4]
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <YJOOB4562wFpiETMejrcCdz7VKHtm5pibhBaxqMkf_w=.3c37a717-a8d8-4988-ad56-d2a06c83d8b6@github.com>

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.

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

  Add extra check for InlineIntrinscs flag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25680/files
  - new: https://git.openjdk.org/jdk/pull/25680/files/8dadb41c..b887243c

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

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

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

From duke at openjdk.org  Sat Jun  7 01:01:02 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Sat, 7 Jun 2025 01:01:02 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v3]
In-Reply-To: <ihrfDXIA-cMj34MgY13QZTbq5L9dLhOBoxHqa66sx00=.f26cf569-1c7f-4446-a3a2-1f405e63061f@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <qsUWN4D-_jpQq_t-Eo4x78GZUNGYiEy3OLMvyBqvl4g=.a12c778d-2076-4818-a74b-3aa1ac8a5cef@github.com>
 <ihrfDXIA-cMj34MgY13QZTbq5L9dLhOBoxHqa66sx00=.f26cf569-1c7f-4446-a3a2-1f405e63061f@github.com>
Message-ID: <_Ymsgw5KNgELRZ3j9iH4ayCyVZn1O8erwAp20HuDs8Q=.a8c44f8e-5888-4f1a-9a74-c955cb7f508a@github.com>

On Fri, 6 Jun 2025 23:41:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-structure logic to avoid reliance on UseLibmIntrinsic flag as others could be used later on
>
> src/hotspot/share/classfile/vmIntrinsics.cpp line 319:
> 
>> 317:   case vmIntrinsics::_dtanh:
>> 318:   case vmIntrinsics::_dcbrt:
>> 319:     if (!InlineMathNatives) return true;
> 
> Ah, looks like you missed !InlineIntrinsic check here:
> if (!InlineMathNatives || !InlineIntrinsics) return true;

Yes, I was thinking to fall through to the cases below, but I missed the break statement. It's clearer with the extra check anyway, so I added it in now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2133135956

From duke at openjdk.org  Sun Jun  8 20:22:58 2025
From: duke at openjdk.org (snake66)
Date: Sun, 8 Jun 2025 20:22:58 GMT
Subject: RFR: 8358799: Refactor os::jvm_path()
In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
Message-ID: <gd1QgKZTShDJBXGS3aQupkNZf_XMI4OpA1ThfZxU3eI=.cef866e6-a70d-45d5-b56e-3a090b02d45b@github.com>

On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
> 
> Passed tiers 1 - 3 tests.
> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.

Not a reviewer or anything, but I'm all for this change. It will help my BSD porting efforts as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/25675#issuecomment-2954260065

From dholmes at openjdk.org  Mon Jun  9 00:42:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 00:42:14 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26
Message-ID: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>

Please review these trivial start-of-release updates in relation to expired flags:

- the expired flag table is updated to remove entries for expired flags (2 this time)
-  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)

Thanks

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

Commit messages:
 - 8355792: Remove expired flags in JDK 26

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

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

From dholmes at openjdk.org  Mon Jun  9 02:08:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 02:08:45 GMT
Subject: RFR: 8346237: Obsolete the UseOprofile flag
Message-ID: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>

The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code.

Testing:
 - tiers 1-3 sanity

Thanks

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

Commit messages:
 - 8346237: Obsolete the UseOprofile flag

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

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

From dholmes at openjdk.org  Mon Jun  9 03:42:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 03:42:00 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
Message-ID: <Bq1sxynDRzCevmyip1ixBoa_AtEQ_JsZhFfpdFLymCc=.9bf28eb2-f145-4aa1-ba0d-239543e1e1a9@github.com>

On Fri, 6 Jun 2025 08:21:08 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

Thanks for update. Nothing further from me.

As we are passed RDP1 this will get commited into JDK 26, but as a test fix it is also eligible to be backported to JDK 25 if you chose.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23536#pullrequestreview-2908848940

From dholmes at openjdk.org  Mon Jun  9 04:06:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 04:06:55 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <HKWEHqFFRe96b0Hd_cnbIcArNoJx6Uw6ou9eJudG81w=.954f2e0a-95ef-47fe-9a11-d61064f9ae0a@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

Given jtreg buffers everything anyway, does this even help the outlined usecase?

To be blunt if I were debugging the process launched via ProcessTools, I'd be doing that directly without jtreg and the test libraries getting in the way. That said the proposed change doesn't seem to cause any harm so I'm not totally against it. Just not sure how effective it actually is, nor the best way for the person running the test to turn it on.

test/lib/jdk/test/lib/process/OutputBuffer.java line 150:

> 148:       this.p = p;
> 149:       logProgress("Gathering output");
> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");

"verbose" is not really the right word here either. This does not change the amount of output only where it also gets sent to, and that is hard-wired to stdout/err so the name should reflect that e.g. `printToStdStreams` ?

I'm not at all sure how to expose this to the top-level API's though.

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

PR Review: https://git.openjdk.org/jdk/pull/25587#pullrequestreview-2908864741
PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2134992541

From dholmes at openjdk.org  Mon Jun  9 04:06:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 04:06:56 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
Message-ID: <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>

On Thu, 5 Jun 2025 14:58:40 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>>    
>>    Co-authored-by: Chen Liang <liach at openjdk.org>
>>  - Initial working solution
>
> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
> 
>> 148:       this.p = p;
>> 149:       logProgress("Gathering output");
>> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");
> 
> Putting a system property at this level of the code kind of hides the functionality.
> 
> An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests.

But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2134994847

From dholmes at openjdk.org  Mon Jun  9 04:40:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 04:40:50 GMT
Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826
In-Reply-To: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
References: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
Message-ID: <dYv3JzK30xasptFVdsyLKJ33qaKNBXmIdkGCSFf7NGY=.879b6acb-7116-4d75-9257-cd355d39e612@github.com>

On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js.

LGTM

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25667#pullrequestreview-2908897771

From dholmes at openjdk.org  Mon Jun  9 04:46:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 04:46:00 GMT
Subject: RFR: 8357632: CDS test failures on static JDK
In-Reply-To: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
Message-ID: <L5Z1ROz3cyEMaWOYhOMRDu0_akNNtYgZkLY6b7GdNUk=.8ccf452c-62d4-4191-9d6d-58eea5bf5a88@github.com>

On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
> 
> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
> 
> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
> 
> Testing:
> Tested the affected tests locally on static-jdk. 
> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.

Seems reasonable.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25516#pullrequestreview-2908903210

From dholmes at openjdk.org  Mon Jun  9 05:15:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 05:15:58 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic
In-Reply-To: <U-FbeW9fBlz-tgsGtxL9nhtdD7_WHgj-X3CmC8frzOE=.29cef8ac-7503-4ea1-ad7e-096a26709c55@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <U-FbeW9fBlz-tgsGtxL9nhtdD7_WHgj-X3CmC8frzOE=.29cef8ac-7503-4ea1-ad7e-096a26709c55@github.com>
Message-ID: <mHoO_sOuJc0gzBBm9parOBj06KJPW-VTvXyPWcFHqUw=.33115e9b-0ca7-47ed-ac41-0ac671352459@github.com>

On Fri, 6 Jun 2025 20:45:32 GMT, Mohamed Issa <duke at openjdk.org> wrote:

> @dholmes-ora Does this fix the _-XX:-InlineIntrinsics_ assertion failures when running CubeRootTests.java and HyperbolicTests.java? I couldn't reproduce those, but I could reproduce the one with `java -XX:-UseLibmIntrinsic -version`.

Yes it does - thanks. Though I'm still unclear why only a couple of these math intrinsics are affected by `-XX:-InineIntrinsics` ??

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2954654449

From dholmes at openjdk.org  Mon Jun  9 05:18:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 05:18:54 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <O_vMITSkfa1x3w7oLbBbyaDcC9z7FayIzTXIZRHuG8c=.c60ba80a-eb8a-4506-aefa-f854bffb48c7@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
 <coUcbRM8717-30G5WkDfeAGNiKOwl07lWyCUAHkTC4M=.e4f4f63b-0b7c-4025-83b6-8fb705766b89@github.com>
 <O_vMITSkfa1x3w7oLbBbyaDcC9z7FayIzTXIZRHuG8c=.c60ba80a-eb8a-4506-aefa-f854bffb48c7@github.com>
Message-ID: <-21kRnEDwCp11EeJB-9Qt_mYQjxJqQJSvNrQfUWZzps=.110eb6aa-521c-4d0b-b6e4-c91ed9a6be11@github.com>

On Thu, 5 Jun 2025 09:41:04 GMT, snake66 <duke at openjdk.org> wrote:

>> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK.
>> 
>> It's nice to see someone fixing things for BSD systems.
>
>> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK.
> 
> Thanks a lot for the review! My main concern is to not break OSX at this point.
> 
>> It's nice to see someone fixing things for BSD systems.
> 
> It's part of a long journey, but hopefully we can get all the changes upstreamed at some point. This patch helps reduce the out-of-tree patches we have for now. :)

@snake66  and @theRealAph  please remember that non-trivial hotspot changes require two reviews. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2954659840

From dholmes at openjdk.org  Mon Jun  9 05:35:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 05:35:51 GMT
Subject: RFR: 8358799: Refactor os::jvm_path()
In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
Message-ID: <gu6z-Qgak3CFXFjLAmdSgzgjF4r6XltQEVQDr4yKfd4=.12525371-16ae-4cd9-997b-088b8d95588c@github.com>

On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
> 
> Passed tiers 1 - 3 tests.
> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.

Good idea but I think we can go further.

Thanks

src/hotspot/os/posix/os_posix.cpp line 1099:

> 1097:     return;
> 1098:   }
> 1099: #endif // AIX

Given both chunks use `os::realpath` and otherwise only differ in error handling around `realpath`, I think you can reduce this further. E.g. something like

  char* fname;
#ifdef AIX
  Dl_info dlinfo;
  int ret = dladdr(CAST_FROM_FN_PTR(void *, os::jvm_path), &dlinfo);
  assert(ret != 0, "cannot locate libjvm");
  fname = dlinfo.dli_fname;
#else
  char dli_fname[MAXPATHLEN];
  dli_fname[0] = '\0';
  bool ret = dll_address_to_library_name(
                                         CAST_FROM_FN_PTR(address, os::jvm_path),
                                         dli_fname, sizeof(dli_fname), nullptr);
  assert(ret, "cannot locate libjvm");
  fname = dli_fname;
#endif
  char* rp = nullprtr;
  ...


I would also be asking the AIX folk if there is a reason they use `dladdr` directly instead of `os::dll_address_to_library_name`?

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25675#pullrequestreview-2908958390
PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2135057338

From duke at openjdk.org  Mon Jun  9 06:43:01 2025
From: duke at openjdk.org (snake66)
Date: Mon, 9 Jun 2025 06:43:01 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <O_vMITSkfa1x3w7oLbBbyaDcC9z7FayIzTXIZRHuG8c=.c60ba80a-eb8a-4506-aefa-f854bffb48c7@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
 <coUcbRM8717-30G5WkDfeAGNiKOwl07lWyCUAHkTC4M=.e4f4f63b-0b7c-4025-83b6-8fb705766b89@github.com>
 <O_vMITSkfa1x3w7oLbBbyaDcC9z7FayIzTXIZRHuG8c=.c60ba80a-eb8a-4506-aefa-f854bffb48c7@github.com>
Message-ID: <S6L7PyUrAnBngfZ0GNKeuB8-HMGXL9UZ8ilal9wnh5E=.5136a45f-33fc-4260-9845-90090249ab10@github.com>

On Thu, 5 Jun 2025 09:41:04 GMT, snake66 <duke at openjdk.org> wrote:

>> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK.
>> 
>> It's nice to see someone fixing things for BSD systems.
>
>> That looks fine, thanks. I'm not in a position to check all the BSDs, but I guess it's OK.
> 
> Thanks a lot for the review! My main concern is to not break OSX at this point.
> 
>> It's nice to see someone fixing things for BSD systems.
> 
> It's part of a long journey, but hopefully we can get all the changes upstreamed at some point. This patch helps reduce the out-of-tree patches we have for now. :)

> @snake66 and @theRealAph please remember that non-trivial hotspot changes require two reviews. Thanks.

Aye, thanks for pointing that out. I'll remember next time!

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

PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2954821182

From duke at openjdk.org  Mon Jun  9 06:48:49 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 9 Jun 2025 06:48:49 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic
In-Reply-To: <mHoO_sOuJc0gzBBm9parOBj06KJPW-VTvXyPWcFHqUw=.33115e9b-0ca7-47ed-ac41-0ac671352459@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <U-FbeW9fBlz-tgsGtxL9nhtdD7_WHgj-X3CmC8frzOE=.29cef8ac-7503-4ea1-ad7e-096a26709c55@github.com>
 <mHoO_sOuJc0gzBBm9parOBj06KJPW-VTvXyPWcFHqUw=.33115e9b-0ca7-47ed-ac41-0ac671352459@github.com>
Message-ID: <8tX9TnkpkilsmgNU0JuZ6M7NP-4fuXlqeYKW2Vo8zAc=.10bf1eb8-667d-4402-854d-2e38fd94159b@github.com>

On Mon, 9 Jun 2025 05:13:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > @dholmes-ora Does this fix the _-XX:-InlineIntrinsics_ assertion failures when running CubeRootTests.java and HyperbolicTests.java? I couldn't reproduce those, but I could reproduce the one with `java -XX:-UseLibmIntrinsic -version`.
> 
> Yes it does - thanks. Though I'm still unclear why only a couple of these math intrinsics are affected by `-XX:-InineIntrinsics` ??

The unaffected math intrinsics (_dsin_, _dcos_, _dexp_, ...) can fall back to alternate C++ implementations in the shared runtime when the stubs aren't generated by `-XX:-InlineIntrinsics` or `-XX:-UseLibmIntrinsic`. This isn't the case for the _dtanh_ and _dcbrt_ intrinsics.

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2954835770

From aph at openjdk.org  Mon Jun  9 09:13:16 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 9 Jun 2025 09:13:16 GMT
Subject: RFR: 8358593: Add ucontext accessors for *BSD on Aarch64
In-Reply-To: <S6L7PyUrAnBngfZ0GNKeuB8-HMGXL9UZ8ilal9wnh5E=.5136a45f-33fc-4260-9845-90090249ab10@github.com>
References: <IZLsCzVQypeJKRosDS2AxAYI_lDHhT9CQv5qvPUvxR8=.9aa4cb12-b561-45e7-b99e-7842e0cbe161@github.com>
 <coUcbRM8717-30G5WkDfeAGNiKOwl07lWyCUAHkTC4M=.e4f4f63b-0b7c-4025-83b6-8fb705766b89@github.com>
 <O_vMITSkfa1x3w7oLbBbyaDcC9z7FayIzTXIZRHuG8c=.c60ba80a-eb8a-4506-aefa-f854bffb48c7@github.com>
 <S6L7PyUrAnBngfZ0GNKeuB8-HMGXL9UZ8ilal9wnh5E=.5136a45f-33fc-4260-9845-90090249ab10@github.com>
Message-ID: <E8HBAo4qltWMpzVx19n5jSOy7WbknEar37xBGc-WAC0=.bb7f7712-8861-4952-af0a-8eff9ef17d5b@github.com>

On Mon, 9 Jun 2025 06:39:52 GMT, snake66 <duke at openjdk.org> wrote:

> > @snake66 and @theRealAph please remember that non-trivial hotspot changes require two reviews. Thanks.
> 
> Aye, thanks for pointing that out. I'll remember next time!

Was my fault, not yours. I suppose it wasn't quite trivial enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/25640#issuecomment-2955166351

From jsjolen at openjdk.org  Mon Jun  9 10:06:50 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 10:06:50 GMT
Subject: RFR: 8358799: Refactor os::jvm_path()
In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
Message-ID: <HJHuzmYBqltQjpw09JBU3SEshHXFThkiKqvBhUICg3I=.b365851e-8802-4e63-b739-bd0d57949d3b@github.com>

On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
> 
> Passed tiers 1 - 3 tests.
> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.

src/hotspot/os/posix/os_posix.cpp line 1084:

> 1082:   assert(ret != 0, "cannot locate libjvm");
> 1083:   char* rp = os::realpath((char *)dlinfo.dli_fname, buf, buflen);
> 1084:   assert(rp != nullptr, "error in realpath(): maybe the 'path' argument is too long?");

Pre-existing: We should return if `ret == 0` and `rp == nullptr`, not continue as if it didn't fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2135405198

From me at xdark.dev  Sun Jun  8 18:29:33 2025
From: me at xdark.dev (me at xdark.dev)
Date: Sun, 08 Jun 2025 21:29:33 +0300
Subject: AbstractInterpreter::is_not_reached wrongfully assumes reachability
 for invokedynamic
Message-ID: <955a583d795914024aaa0d78ef35e274@xdark.dev>

Greetings,
Since JDK-8301995 [1], the code to in 
AbstractInterpreter::is_not_reached(...) for invokedynamic looks like 
this:
```
       case Bytecodes::_invokedynamic: {
         assert(invoke_bc.has_index_u4(code), "sanity");
         int method_index = invoke_bc.get_index_u4(code);
         return 
cpool->resolved_indy_entry_at(method_index)->is_resolved();
       }
```
Is this a bug? Before the change, the code looked like this:
```
       case Bytecodes::_invokedynamic: {
         assert(invoke_bc.has_index_u4(code), "sanity");
         int method_index = invoke_bc.get_index_u4(code);
         return 
cpool->invokedynamic_cp_cache_entry_at(method_index)->is_f1_null();
       }
```
The comment for this method says:
```
// Return true if the interpreter can prove that the given bytecode has
// not yet been executed (in Java semantics, not in actual operation).
```
Shouldn't the is_resolved check be negated? The code is two years old 
since this change, and it seems like a regression. I'm unable to submit 
a patch if that is the case, so, if this is a bug, It would be great if 
someone would fix this.
Thanks!

Links:
------
[1] https://bugs.openjdk.org/browse/JDK-8301995
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250608/a66870e9/attachment.htm>

From coleenp at openjdk.org  Mon Jun  9 11:54:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 11:54:49 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26
In-Reply-To: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
Message-ID: <aXWzttwqyN0k9uu1QX6XcMCJeaS_B3vAfcPHPOxygu4=.47f93711-e8a1-4b26-a156-2b1dcccf2424@github.com>

On Mon, 9 Jun 2025 00:37:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these trivial start-of-release updates in relation to expired flags:
> 
> - the flag table is updated to remove entries for expired flags (2 this time)
> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
> 
> Thanks

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25686#pullrequestreview-2909834539

From coleenp at openjdk.org  Mon Jun  9 12:02:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 12:02:51 GMT
Subject: RFR: 8346237: Obsolete the UseOprofile flag
In-Reply-To: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
References: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
Message-ID: <tKHV9QiGy7Io8qKBThXC8lUznisXh4e8GIHtKfnrYdc=.1f3385cc-7dc1-4f1c-98c3-469094476680@github.com>

On Mon, 9 Jun 2025 02:03:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code.
> 
> Testing:
>  - tiers 1-3 sanity
> 
> Thanks

This comes from JDK-6265868.  Nice to remove this.  Looks like we obsoleted this code a long time ago.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25687#pullrequestreview-2909850997

From dholmes at openjdk.org  Mon Jun  9 12:10:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 12:10:51 GMT
Subject: RFR: 8346237: Obsolete the UseOprofile flag
In-Reply-To: <tKHV9QiGy7Io8qKBThXC8lUznisXh4e8GIHtKfnrYdc=.1f3385cc-7dc1-4f1c-98c3-469094476680@github.com>
References: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
 <tKHV9QiGy7Io8qKBThXC8lUznisXh4e8GIHtKfnrYdc=.1f3385cc-7dc1-4f1c-98c3-469094476680@github.com>
Message-ID: <ec9xOGsC9qxpQCJCy0RNw2f2LEzS2Gs1_wi4w_ggZuw=.eb555185-f385-410e-aaaa-d959aed9d6d6@github.com>

On Mon, 9 Jun 2025 11:59:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code.
>> 
>> Testing:
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> This comes from JDK-6265868.  Nice to remove this.  Looks like we obsoleted this code a long time ago.

Thanks for the review @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/25687#issuecomment-2955605247

From dholmes at openjdk.org  Mon Jun  9 12:12:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 12:12:50 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26
In-Reply-To: <aXWzttwqyN0k9uu1QX6XcMCJeaS_B3vAfcPHPOxygu4=.47f93711-e8a1-4b26-a156-2b1dcccf2424@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
 <aXWzttwqyN0k9uu1QX6XcMCJeaS_B3vAfcPHPOxygu4=.47f93711-e8a1-4b26-a156-2b1dcccf2424@github.com>
Message-ID: <0Tw0V0EDT1xcyI7lFEntJ7pswQxb_Uk7LKIhE1hBsSA=.88936a7c-e41f-4bb3-8d2e-b79bd4edb872@github.com>

On Mon, 9 Jun 2025 11:51:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review these trivial start-of-release updates in relation to expired flags:
>> 
>> - the flag table is updated to remove entries for expired flags (2 this time)
>> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
>> 
>> Thanks
>
> Looks good.

Thanks for the review @coleenp !

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

PR Comment: https://git.openjdk.org/jdk/pull/25686#issuecomment-2955607760

From jsjolen at openjdk.org  Mon Jun  9 14:05:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 14:05:41 GMT
Subject: RFR: 8355298: Increase timeout for StressAsyncUL
Message-ID: <HNNV413pNib7S4m5hfHqaGDQXnlts6jbFvgkYonRZbs=.be82315d-65cc-4c2a-a128-7a54d5fb1c37@github.com>

Hi,

Running async UL with stalling mode enabled is very slow if your buffer is very small. This turns out to become an issue on slow machines, where we run the risk of the test timing out.

The ticket's suggestion (and title) is to increase the timeout. I think that it'd be fine to reduce the logging level to 'debug' instead, thus reducing the time required to run the test.

Obviously, if we go with this solution then the ticket name and description must be adjusted.

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

Commit messages:
 - Decrease number of logs

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

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

From kvn at openjdk.org  Mon Jun  9 14:33:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 9 Jun 2025 14:33:53 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26
In-Reply-To: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
Message-ID: <pW95LZ5VVvR2qbSrPRqrAQtpjCLVNOeL3fM_q8Yk25U=.b2682708-2b09-421d-a1bb-90d746289ddb@github.com>

On Mon, 9 Jun 2025 00:37:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these trivial start-of-release updates in relation to expired flags:
> 
> - the flag table is updated to remove entries for expired flags (2 this time)
> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
> 
> Thanks

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25686#pullrequestreview-2910264916

From kvn at openjdk.org  Mon Jun  9 14:35:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 9 Jun 2025 14:35:51 GMT
Subject: RFR: 8346237: Obsolete the UseOprofile flag
In-Reply-To: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
References: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
Message-ID: <Rm0RkA0UEc1QnsXFtYWgE4WHXT5wz-7DU4FUnvDKvQg=.263b6099-e805-41f2-8f57-f1f7adf6b696@github.com>

On Mon, 9 Jun 2025 02:03:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code.
> 
> Testing:
>  - tiers 1-3 sanity
> 
> Thanks

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25687#pullrequestreview-2910271058

From jiangli at openjdk.org  Mon Jun  9 16:11:03 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 9 Jun 2025 16:11:03 GMT
Subject: RFR: 8357632: CDS test failures on static JDK
In-Reply-To: <L5Z1ROz3cyEMaWOYhOMRDu0_akNNtYgZkLY6b7GdNUk=.8ccf452c-62d4-4191-9d6d-58eea5bf5a88@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
 <L5Z1ROz3cyEMaWOYhOMRDu0_akNNtYgZkLY6b7GdNUk=.8ccf452c-62d4-4191-9d6d-58eea5bf5a88@github.com>
Message-ID: <YLicbq31VUYrzR8QO8ysL4Y7ZzwxbTMz393woTNJt7I=.ed12b9c5-f25b-4e14-ab94-b724ede82480@github.com>

On Mon, 9 Jun 2025 04:43:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
>> 
>> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
>> 
>> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
>> 
>> Testing:
>> Tested the affected tests locally on static-jdk. 
>> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.
>
> Seems reasonable.
> 
> Thanks.

@dholmes-ora Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25516#issuecomment-2956240660

From jiangli at openjdk.org  Mon Jun  9 16:11:03 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 9 Jun 2025 16:11:03 GMT
Subject: Integrated: 8357632: CDS test failures on static JDK
In-Reply-To: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
References: <gUWZhbSMbOvmRL1p2hx-_j9GrclDu171orMevXHqfPY=.d1e1261b-1fef-48fb-9503-5b0c1879983f@github.com>
Message-ID: <veZCAuK7vSmbsiBdQY1ssYnuOZz0PKM6cLViFJgarwM=.73d4cb92-879e-4acb-9852-96785c28f726@github.com>

On Thu, 29 May 2025 00:24:40 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK.
> 
> The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. 
> 
> It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk.
> 
> Testing:
> Tested the affected tests locally on static-jdk. 
> https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress.

This pull request has now been integrated.

Changeset: cae1fd33
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cae1fd3385e0635beeac34a2287627e556155783
Stats:     31 lines in 3 files changed: 17 ins; 13 del; 1 mod

8357632: CDS test failures on static JDK

Reviewed-by: ccheung, dholmes

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

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

From pchilanomate at openjdk.org  Mon Jun  9 16:34:01 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 9 Jun 2025 16:34:01 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v9]
In-Reply-To: <JOBwClViXWJArlvdyygiGkosysjDviA__yWo6Q78jvU=.34cd7278-11ed-4cb2-9a03-c26ba8c9145e@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <JOBwClViXWJArlvdyygiGkosysjDviA__yWo6Q78jvU=.34cd7278-11ed-4cb2-9a03-c26ba8c9145e@github.com>
Message-ID: <C4icuHCr9n6ptJ3JDAgI18X9vl-DvfYixMK5O2_zGEE=.c4966923-da97-4059-8e18-83d7fca725d9@github.com>

On Thu, 5 Jun 2025 08:48:37 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
>> 
>> Tested in tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8265754: Changed handshakee to target.

src/hotspot/share/runtime/handshake.hpp line 187:

> 185: 
> 186:   bool suspend(bool register_vthread_SR);
> 187:   bool resume(bool register_vthread_SR);

We should also remove the class and friend declarations for `ThreadSelfSuspensionHandshake`
 and `SuspendThreadHandshake`.

src/hotspot/share/runtime/suspendResumeManager.hpp line 27:

> 25: #ifndef SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP
> 26: #define SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP
> 27: 

We need to add `class SuspendThreadHandshake;` and `class ThreadSelfSuspensionHandshake;` here (currently relying on the declarations in handshake.hpp).

src/hotspot/share/runtime/suspendResumeManager.hpp line 37:

> 35: 
> 36: public:
> 37:   SuspendResumeManager(JavaThread* thread, Monitor* state_lock);

Maybe this should also be private given that `JavaThread` is a friend already?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2136016839
PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2136025270
PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2136029358

From kvn at openjdk.org  Mon Jun  9 16:55:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 9 Jun 2025 16:55:52 GMT
Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826
In-Reply-To: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
References: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
Message-ID: <yOm4uB2HJ249muErUdHL5Qa_H9rCrTDd_ZTE6CEvVBw=.c63676fc-ce2d-402b-9230-93e6b777bf6a@github.com>

On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js.

Fix it here too (used by aotCode/ tests)
https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482

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

PR Review: https://git.openjdk.org/jdk/pull/25667#pullrequestreview-2910657100

From kvn at openjdk.org  Mon Jun  9 17:01:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 9 Jun 2025 17:01:54 GMT
Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826
In-Reply-To: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
References: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
Message-ID: <nkjZOIIhANz0hTFOiXwcHwX40Ho78WzGEXfNSD49d7U=.2e4fd8de-fe8a-4c52-bd47-2dfcaa29c859@github.com>

On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25667#pullrequestreview-2910668967

From kvn at openjdk.org  Mon Jun  9 17:01:55 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 9 Jun 2025 17:01:55 GMT
Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826
In-Reply-To: <yOm4uB2HJ249muErUdHL5Qa_H9rCrTDd_ZTE6CEvVBw=.c63676fc-ce2d-402b-9230-93e6b777bf6a@github.com>
References: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
 <yOm4uB2HJ249muErUdHL5Qa_H9rCrTDd_ZTE6CEvVBw=.c63676fc-ce2d-402b-9230-93e6b777bf6a@github.com>
Message-ID: <JwVFlDMLtQHjaub0mB5x34O9B5eqTHStrRulP_iFwNE=.33ce5ebc-a103-4eeb-bfe2-a7058230af85@github.com>

On Mon, 9 Jun 2025 16:53:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Fix it here too (used by aotCode/ tests) https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482

Actually no. We do not want to run these tests with Graal for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25667#issuecomment-2956365431

From ihse at openjdk.org  Mon Jun  9 17:50:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 17:50:52 GMT
Subject: RFR: 8358799: Refactor os::jvm_path()
In-Reply-To: <gu6z-Qgak3CFXFjLAmdSgzgjF4r6XltQEVQDr4yKfd4=.12525371-16ae-4cd9-997b-088b8d95588c@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <gu6z-Qgak3CFXFjLAmdSgzgjF4r6XltQEVQDr4yKfd4=.12525371-16ae-4cd9-997b-088b8d95588c@github.com>
Message-ID: <n0AFAET7J4Km6RM2xRryVV5fwx4GU2OJlN-QBCE_3P4=.6f7e8034-2445-431c-b5c0-e4d6d45dc84c@github.com>

On Mon, 9 Jun 2025 05:33:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
>> 
>> Passed tiers 1 - 3 tests.
>> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.
>
> src/hotspot/os/posix/os_posix.cpp line 1099:
> 
>> 1097:     return;
>> 1098:   }
>> 1099: #endif // AIX
> 
> Given both chunks use `os::realpath` and otherwise only differ in error handling around `realpath`, I think you can reduce this further. E.g. something like
> 
>   char* fname;
> #ifdef AIX
>   Dl_info dlinfo;
>   int ret = dladdr(CAST_FROM_FN_PTR(void *, os::jvm_path), &dlinfo);
>   assert(ret != 0, "cannot locate libjvm");
>   fname = dlinfo.dli_fname;
> #else
>   char dli_fname[MAXPATHLEN];
>   dli_fname[0] = '\0';
>   bool ret = dll_address_to_library_name(
>                                          CAST_FROM_FN_PTR(address, os::jvm_path),
>                                          dli_fname, sizeof(dli_fname), nullptr);
>   assert(ret, "cannot locate libjvm");
>   fname = dli_fname;
> #endif
>   char* rp = nullprtr;
>   ...
> 
> 
> I would also be asking the AIX folk if there is a reason they use `dladdr` directly instead of `os::dll_address_to_library_name`?

AIX is very different in this regard. There is a hand-crafted partial implementation of `dladdr` in `src/hotspot/os/aix/porting_aix.cpp`. I'm not sure this is the reason, just pointing out that this is a typical weakness of AIX where it differs from other unix systems wrt to `dladdr`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2136188895

From sviswanathan at openjdk.org  Mon Jun  9 18:34:52 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 9 Jun 2025 18:34:52 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v4]
In-Reply-To: <YJOOB4562wFpiETMejrcCdz7VKHtm5pibhBaxqMkf_w=.3c37a717-a8d8-4988-ad56-d2a06c83d8b6@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <YJOOB4562wFpiETMejrcCdz7VKHtm5pibhBaxqMkf_w=.3c37a717-a8d8-4988-ad56-d2a06c83d8b6@github.com>
Message-ID: <EE-i2sY_WaQOY5oFhmxbjtTMSvjY4TVY_NBVB3pon08=.c3cd00a3-999c-4b8d-8030-9311603142d4@github.com>

On Sat, 7 Jun 2025 00:57:25 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add extra check for InlineIntrinscs flag

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

> 317:   case vmIntrinsics::_dtanh:
> 318:   case vmIntrinsics::_dcbrt:
> 319:     if (!InlineMathNatives || !InlineIntrinsics) return true;

You also need to add check for UseLibmIntrinsic here:
#ifdef AMD64
    if (!UseLibmIntrinsic)  return true;
#endif

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2136250496

From duke at openjdk.org  Mon Jun  9 20:42:55 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 9 Jun 2025 20:42:55 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v5]
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <rd9HgwRj86jFVN1Qbpt0N8uUn-cgh7ADCrjjPvNCS_k=.a190012d-af42-440c-baa2-29679d16bcc4@github.com>

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.

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

  Include check for UseLibmIntrinsic flag but restrict to x86 platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25680/files
  - new: https://git.openjdk.org/jdk/pull/25680/files/b887243c..aff9ca09

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

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

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

From duke at openjdk.org  Mon Jun  9 20:42:56 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Mon, 9 Jun 2025 20:42:56 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v4]
In-Reply-To: <EE-i2sY_WaQOY5oFhmxbjtTMSvjY4TVY_NBVB3pon08=.c3cd00a3-999c-4b8d-8030-9311603142d4@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <YJOOB4562wFpiETMejrcCdz7VKHtm5pibhBaxqMkf_w=.3c37a717-a8d8-4988-ad56-d2a06c83d8b6@github.com>
 <EE-i2sY_WaQOY5oFhmxbjtTMSvjY4TVY_NBVB3pon08=.c3cd00a3-999c-4b8d-8030-9311603142d4@github.com>
Message-ID: <Rfc1RLkuvTFn28p6AoWqNbsLO0gD2oHU8J4uP_sbarQ=.11949f5c-0f1f-45b2-832f-57f0959d19fc@github.com>

On Mon, 9 Jun 2025 18:31:47 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add extra check for InlineIntrinscs flag
>
> src/hotspot/share/classfile/vmIntrinsics.cpp line 319:
> 
>> 317:   case vmIntrinsics::_dtanh:
>> 318:   case vmIntrinsics::_dcbrt:
>> 319:     if (!InlineMathNatives || !InlineIntrinsics) return true;
> 
> You also need to add check for UseLibmIntrinsic here:
> #ifdef AMD64
>     if (!UseLibmIntrinsic)  return true;
> #endif

Added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25680#discussion_r2136471294

From sviswanathan at openjdk.org  Mon Jun  9 20:49:32 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 9 Jun 2025 20:49:32 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v5]
In-Reply-To: <rd9HgwRj86jFVN1Qbpt0N8uUn-cgh7ADCrjjPvNCS_k=.a190012d-af42-440c-baa2-29679d16bcc4@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <rd9HgwRj86jFVN1Qbpt0N8uUn-cgh7ADCrjjPvNCS_k=.a190012d-af42-440c-baa2-29679d16bcc4@github.com>
Message-ID: <rb2J13XI40cQn4cu1vfYoYxYj3oPVQW0bNwMbDWO6jE=.be29e7ce-f636-46d8-b3c9-9739d4332fb5@github.com>

On Mon, 9 Jun 2025 20:42:55 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include check for UseLibmIntrinsic flag but restrict to x86 platforms

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25680#pullrequestreview-2911328752

From dholmes at openjdk.org  Mon Jun  9 21:01:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 21:01:44 GMT
Subject: RFR: 8346237: Obsolete the UseOprofile flag
In-Reply-To: <Rm0RkA0UEc1QnsXFtYWgE4WHXT5wz-7DU4FUnvDKvQg=.263b6099-e805-41f2-8f57-f1f7adf6b696@github.com>
References: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
 <Rm0RkA0UEc1QnsXFtYWgE4WHXT5wz-7DU4FUnvDKvQg=.263b6099-e805-41f2-8f57-f1f7adf6b696@github.com>
Message-ID: <7cX6wNSS_ze3bSOXL22dFH1o0EnIkJ8jw6w2sAUBEdc=.e795a413-7cc5-452e-9427-5ad045c13bca@github.com>

On Mon, 9 Jun 2025 14:33:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code.
>> 
>> Testing:
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> Good.

Thanks for the review @vnkozlov !

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

PR Comment: https://git.openjdk.org/jdk/pull/25687#issuecomment-2957019040

From dholmes at openjdk.org  Mon Jun  9 21:01:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 21:01:32 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26
In-Reply-To: <pW95LZ5VVvR2qbSrPRqrAQtpjCLVNOeL3fM_q8Yk25U=.b2682708-2b09-421d-a1bb-90d746289ddb@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
 <pW95LZ5VVvR2qbSrPRqrAQtpjCLVNOeL3fM_q8Yk25U=.b2682708-2b09-421d-a1bb-90d746289ddb@github.com>
Message-ID: <r6Va-EnRmeMEMG_U4wSrN6ALig0vdwx9ULhvSJ8d72c=.b5e5e298-c098-4ff8-be48-313ae9b04ead@github.com>

On Mon, 9 Jun 2025 14:31:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Please review these trivial start-of-release updates in relation to expired flags:
>> 
>> - the flag table is updated to remove entries for expired flags (2 this time)
>> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
>> 
>> Thanks
>
> Good.

Thanks for the review @vnkozlov !

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

PR Comment: https://git.openjdk.org/jdk/pull/25686#issuecomment-2957020476

From dholmes at openjdk.org  Mon Jun  9 21:01:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 21:01:44 GMT
Subject: Integrated: 8346237: Obsolete the UseOprofile flag
In-Reply-To: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
References: <H5bJFCEG3Jq5I5MGH8T-bHDKl7viwHAswIGpy8EmNQ4=.5434da0d-1e27-47fe-96bb-951333acea5f@github.com>
Message-ID: <DVLnoK_bioIgsdhUz_wobcLXLsZoxjHZ17_bYBDTbDA=.1f6ccf54-882c-4ce4-b043-e9cf38bbc2cf@github.com>

On Mon, 9 Jun 2025 02:03:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The `UseOprofile` flag is obsoleted in JDK 26 and so the code associated with it is removed. That means `linux_wrap_code` is dead code and consequently `CodeHeap::on_code_mapping` is also dead code.
> 
> Testing:
>  - tiers 1-3 sanity
> 
> Thanks

This pull request has now been integrated.

Changeset: ef45c815
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef45c8154cea2ec910788d3c19e91d3eed75708e
Stats:     60 lines in 5 files changed: 3 ins; 55 del; 2 mod

8346237: Obsolete the UseOprofile flag

Reviewed-by: coleenp, kvn

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

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

From dholmes at openjdk.org  Mon Jun  9 21:10:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 21:10:48 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26 [v2]
In-Reply-To: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
Message-ID: <VCaAqOXpSHUTFWgx-ZdKt3p4VZgaV8ds0LX71AsmG9k=.9999845d-4cd8-42d7-832b-50520fe80934@github.com>

> Please review these trivial start-of-release updates in relation to expired flags:
> 
> - the flag table is updated to remove entries for expired flags (2 this time)
> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
> 
> Thanks

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into 8355792-expired-flags
 - 8355792: Remove expired flags in JDK 26

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

Changes: https://git.openjdk.org/jdk/pull/25686/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25686&range=01
  Stats: 68 lines in 2 files changed: 2 ins; 65 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25686/head:pull/25686

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

From iklam at openjdk.org  Mon Jun  9 21:57:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 9 Jun 2025 21:57:31 GMT
Subject: RFR: 8357591: Re-enable CDS test cases for jvmci after JDK-8345826
In-Reply-To: <JwVFlDMLtQHjaub0mB5x34O9B5eqTHStrRulP_iFwNE=.33ce5ebc-a103-4eeb-bfe2-a7058230af85@github.com>
References: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
 <yOm4uB2HJ249muErUdHL5Qa_H9rCrTDd_ZTE6CEvVBw=.c63676fc-ce2d-402b-9230-93e6b777bf6a@github.com>
 <JwVFlDMLtQHjaub0mB5x34O9B5eqTHStrRulP_iFwNE=.33ce5ebc-a103-4eeb-bfe2-a7058230af85@github.com>
Message-ID: <qykrHOzJCZjG_bJUyxdE8D50An5amjUWI7qGBsRUIEI=.10bf7647-3e4c-4792-b543-741267e94d9c@github.com>

On Mon, 9 Jun 2025 16:58:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Fix it here too (used by aotCode/ tests)
>> https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482
>
>> Fix it here too (used by aotCode/ tests) https://github.com/openjdk/jdk/blob/master/test/jtreg-ext/requires/VMProps.java#L482
> 
> Actually no. We do not want to run these tests with Graal for now.

Thanks @vnkozlov @dholmes-ora for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25667#issuecomment-2957123781

From iklam at openjdk.org  Mon Jun  9 21:57:32 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 9 Jun 2025 21:57:32 GMT
Subject: Integrated: 8357591: Re-enable CDS test cases for jvmci after
 JDK-8345826
In-Reply-To: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
References: <Y4kssWYePYc7sW42ULYHS2-esWpvYtfjIjlGcOgqogw=.7f882a6c-005f-4963-b588-d548c58e2116@github.com>
Message-ID: <cEX_MIaUgnYZTHR5hKJgSuWcNRp1yWjvRjZIT-9yI0Q=.32099b1a-b6a8-478a-aaef-d4688ef365db@github.com>

On Fri, 6 Jun 2025 03:46:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> CDS tests should be re-enabled for graal. I tested with hs-tier9-graal.js, hs-tier11-graal.js and hs-tier12-graal.js.

This pull request has now been integrated.

Changeset: d186dacd
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d186dacdb7b91dc9a28b703ce3c8ea007fc450b6
Stats:     72 lines in 34 files changed: 0 ins; 72 del; 0 mod

8357591: Re-enable CDS test cases for jvmci after JDK-8345826

Reviewed-by: dholmes, kvn

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

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

From coleenp at openjdk.org  Mon Jun  9 22:14:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 22:14:33 GMT
Subject: RFR: 8355792: Remove expired flags in JDK 26 [v2]
In-Reply-To: <VCaAqOXpSHUTFWgx-ZdKt3p4VZgaV8ds0LX71AsmG9k=.9999845d-4cd8-42d7-832b-50520fe80934@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
 <VCaAqOXpSHUTFWgx-ZdKt3p4VZgaV8ds0LX71AsmG9k=.9999845d-4cd8-42d7-832b-50520fe80934@github.com>
Message-ID: <q5Z-0nQcXDs4BajcIfNatl0FE-7oiSCJq602kIHlM1c=.207b00b3-2f8d-407d-b6b1-40a16163ffdb@github.com>

On Mon, 9 Jun 2025 21:10:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these trivial start-of-release updates in relation to expired flags:
>> 
>> - the flag table is updated to remove entries for expired flags (2 this time)
>> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
>> 
>> Thanks
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8355792-expired-flags
>  - 8355792: Remove expired flags in JDK 26

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25686#pullrequestreview-2911478853

From dholmes at openjdk.org  Mon Jun  9 22:28:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Jun 2025 22:28:32 GMT
Subject: Integrated: 8355792: Remove expired flags in JDK 26
In-Reply-To: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
References: <ydB3Rg5cWIfmDhxHthyCvKcW85A2CcEQ2M2q00gIMEI=.f4b98fca-74f5-4bc7-ae33-b2d97136d3c6@github.com>
Message-ID: <k0UYkJSZrM8EfULmkqbaaH_aN0NqBkrKUk-09R33eeg=.a58acd7a-43cc-420c-a30c-62a4560ece1c@github.com>

On Mon, 9 Jun 2025 00:37:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these trivial start-of-release updates in relation to expired flags:
> 
> - the flag table is updated to remove entries for expired flags (2 this time)
> -  the Java man page "Removed options" section is updated (none are being removed (expired) in JDK 26)
> 
> Thanks

This pull request has now been integrated.

Changeset: bcf86070
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bcf860703dc0244fef1d380cb7323282de76970c
Stats:     68 lines in 2 files changed: 2 ins; 65 del; 1 mod

8355792: Remove expired flags in JDK 26

Reviewed-by: coleenp, kvn

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

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

From syan at openjdk.org  Tue Jun 10 00:41:37 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Jun 2025 00:41:37 GMT
Subject: RFR: 8358799: Refactor os::jvm_path() [v2]
In-Reply-To: <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
Message-ID: <ZeTDDsF0ZOV7H__8mNjIP90PuBKSH_Eq2ySuwWz5oxo=.c722a383-e9e2-47eb-8ff9-e0a303f6a244@github.com>

On Mon, 9 Jun 2025 19:01:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
>> 
>> Passed tiers 1 - 3 tests.
>> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.
>
> Calvin Cheung 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:
> 
>  - review comments from @dholmes-ora and @jdksjolen
>  - Merge branch 'master' into 8358799-refactor-jvm-path
>  - 8358799: Refactor os::jvm_path()

src/hotspot/os/posix/os_posix.cpp line 1071:

> 1069:     assert(false, "must use a large-enough buffer");
> 1070:     buf[0] = '\0';
> 1071:     return;

Do we need release the memory of `buf` before return, such like


free(buf);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2136714406

From duke at openjdk.org  Tue Jun 10 00:53:23 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Tue, 10 Jun 2025 00:53:23 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6]
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.

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

  Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25680/files
  - new: https://git.openjdk.org/jdk/pull/25680/files/aff9ca09..fa21605f

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

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

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

From ccheung at openjdk.org  Tue Jun 10 01:31:31 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 10 Jun 2025 01:31:31 GMT
Subject: RFR: 8358799: Refactor os::jvm_path() [v2]
In-Reply-To: <ZeTDDsF0ZOV7H__8mNjIP90PuBKSH_Eq2ySuwWz5oxo=.c722a383-e9e2-47eb-8ff9-e0a303f6a244@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
 <ZeTDDsF0ZOV7H__8mNjIP90PuBKSH_Eq2ySuwWz5oxo=.c722a383-e9e2-47eb-8ff9-e0a303f6a244@github.com>
Message-ID: <OqUHdELCz6kNwkWyCuSMoOR-7J17ORoAKyR_kfywvkw=.9ea9b19f-0471-4cf6-be7a-da5e6fdc111b@github.com>

On Tue, 10 Jun 2025 00:39:06 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Calvin Cheung 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:
>> 
>>  - review comments from @dholmes-ora and @jdksjolen
>>  - Merge branch 'master' into 8358799-refactor-jvm-path
>>  - 8358799: Refactor os::jvm_path()
>
> src/hotspot/os/posix/os_posix.cpp line 1071:
> 
>> 1069:     assert(false, "must use a large-enough buffer");
>> 1070:     buf[0] = '\0';
>> 1071:     return;
> 
> Do we need release the memory of `buf` before return, such like
> 
> 
> free(buf);

No, because the caller of the function still references `buf` after the function returns, e.g. in `os::init_system_properties_values()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2136751058

From duke at openjdk.org  Tue Jun 10 03:54:27 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Tue, 10 Jun 2025 03:54:27 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v5]
In-Reply-To: <rb2J13XI40cQn4cu1vfYoYxYj3oPVQW0bNwMbDWO6jE=.be29e7ce-f636-46d8-b3c9-9739d4332fb5@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <rd9HgwRj86jFVN1Qbpt0N8uUn-cgh7ADCrjjPvNCS_k=.a190012d-af42-440c-baa2-29679d16bcc4@github.com>
 <rb2J13XI40cQn4cu1vfYoYxYj3oPVQW0bNwMbDWO6jE=.be29e7ce-f636-46d8-b3c9-9739d4332fb5@github.com>
Message-ID: <SmVfiHge1JvxZNnStxGGLshjO0qDk6bBiTdfYH1lYk8=.0d92aee9-4b86-434a-ab8d-866b29aeb467@github.com>

On Mon, 9 Jun 2025 20:47:01 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Looks good to me.

@sviswa7 I had to make some more changes to cover the _linux-x64-hs-zero_ build.

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2957600031

From duke at openjdk.org  Tue Jun 10 07:43:28 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 10 Jun 2025 07:43:28 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v10]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <34u9bhO_tpy_1IsaqU5VsoKbD7M3nFt9HsKuO3fW_8E=.8c5ce31c-0015-44c6-897a-b73339b332cb@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

Anton Artemov 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 27 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - 8265754: Changed handshakee to target.
 - 8265754: Added a comment.
 - Merge remote-tracking branch 'origin/master' into JDK-8265754
 - 8265754: Fixed build problem
 - 8265754: Fixed typo.
 - 8265754: Fixing spaces.
 - 8265754: Refactoring into separate file.
 - 8265754: Refactoring.
 - 8265754: Refactoring.
 - ... and 17 more: https://git.openjdk.org/jdk/compare/d5575c1a...8d24cd75

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/272b0293..8d24cd75

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

  Stats: 11155 lines in 390 files changed: 7807 ins; 2524 del; 824 mod
  Patch: https://git.openjdk.org/jdk/pull/25407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407

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

From duke at openjdk.org  Tue Jun 10 07:52:29 2025
From: duke at openjdk.org (Alice Pellegrini)
Date: Tue, 10 Jun 2025 07:52:29 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
 <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
Message-ID: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>

On Mon, 9 Jun 2025 04:03:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/lib/jdk/test/lib/process/OutputBuffer.java line 150:
>> 
>>> 148:       this.p = p;
>>> 149:       logProgress("Gathering output");
>>> 150:       boolean verbose = Boolean.getBoolean("outputanalyzer.verbose");
>> 
>> Putting a system property at this level of the code kind of hides the functionality.
>> 
>> An alternative solution would be to have `OutputAnalyzer` constructor(s) that takes a boolean argument. That boolean could be set as needed by individual tests using the `test.debug` property already used by a lot of tests.
>
> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ??

To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command)`


git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l
     351


Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about)


I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2137161838

From cstein at openjdk.org  Tue Jun 10 08:18:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Jun 2025 08:18:34 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
 <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
 <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>
Message-ID: <IqvVkOj7xntKKswD9SJsGwSyI7gDgHYHWfCrkgh1zjY=.0dbce17a-81e5-41e5-8bfd-a95d01230b3e@github.com>

On Mon, 2 Jun 2025 16:03:49 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> right I agree that if there is common code we should extract it in a helper method
>
> Or the handling of `#` can be merged with the previous case ... somehow.

Extracting a method wouldn't really simplify the code, as many local variables are in play.

Merging the cases also ends up in more if-else constructs in the case block that counter-act readability.

So, perhaps, the duplication is goog-enough here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2137227216

From duke at openjdk.org  Tue Jun 10 08:40:53 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 10 Jun 2025 08:40:53 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

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

  8265754: Addressed reviewers comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/8d24cd75..1d34f5ad

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

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

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

From duke at openjdk.org  Tue Jun 10 08:40:53 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 10 Jun 2025 08:40:53 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <C4icuHCr9n6ptJ3JDAgI18X9vl-DvfYixMK5O2_zGEE=.c4966923-da97-4059-8e18-83d7fca725d9@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <JOBwClViXWJArlvdyygiGkosysjDviA__yWo6Q78jvU=.34cd7278-11ed-4cb2-9a03-c26ba8c9145e@github.com>
 <C4icuHCr9n6ptJ3JDAgI18X9vl-DvfYixMK5O2_zGEE=.c4966923-da97-4059-8e18-83d7fca725d9@github.com>
Message-ID: <CP7QYCF9HdMOQVWQm0pVvcEBxFLWi1tAdZQGcKYXCsc=.7f9f9e9c-deb7-455f-9c4c-b0e3a27d082c@github.com>

On Mon, 9 Jun 2025 16:13:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8265754: Addressed reviewers comments.
>
> src/hotspot/share/runtime/handshake.hpp line 187:
> 
>> 185: 
>> 186:   bool suspend(bool register_vthread_SR);
>> 187:   bool resume(bool register_vthread_SR);
> 
> We should also remove the class and friend declarations for `ThreadSelfSuspensionHandshake`
>  and `SuspendThreadHandshake`.

Right, those classes now have nothing to do with this file. Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2137276716

From duke at openjdk.org  Tue Jun 10 08:40:53 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 10 Jun 2025 08:40:53 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v9]
In-Reply-To: <C4icuHCr9n6ptJ3JDAgI18X9vl-DvfYixMK5O2_zGEE=.c4966923-da97-4059-8e18-83d7fca725d9@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <JOBwClViXWJArlvdyygiGkosysjDviA__yWo6Q78jvU=.34cd7278-11ed-4cb2-9a03-c26ba8c9145e@github.com>
 <C4icuHCr9n6ptJ3JDAgI18X9vl-DvfYixMK5O2_zGEE=.c4966923-da97-4059-8e18-83d7fca725d9@github.com>
Message-ID: <klMdvRsUMn-0vv8sX5Y58F8rBh9g_kwazmQlNjNxcRI=.90ae0d19-ca08-4e3b-bf6a-07bb2b90f101@github.com>

On Mon, 9 Jun 2025 16:18:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8265754: Changed handshakee to target.
>
> src/hotspot/share/runtime/suspendResumeManager.hpp line 27:
> 
>> 25: #ifndef SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP
>> 26: #define SHARE_RUNTIME_SUSPENDRESUMEMANAGER_HPP
>> 27: 
> 
> We need to add `class SuspendThreadHandshake;` and `class ThreadSelfSuspensionHandshake;` here (currently relying on the declarations in handshake.hpp).

Addressed in the latest commit.

> src/hotspot/share/runtime/suspendResumeManager.hpp line 37:
> 
>> 35: 
>> 36: public:
>> 37:   SuspendResumeManager(JavaThread* thread, Monitor* state_lock);
> 
> Maybe this should also be private given that `JavaThread` is a friend already?

Makes sense. Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2137277127
PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2137277820

From azafari at openjdk.org  Tue Jun 10 11:29:42 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 10 Jun 2025 11:29:42 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
Message-ID: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>

The problem here stems from the following facts:
1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. 
2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.
3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above.

So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue).

Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings.

Tests:
linux-x64: runtime/NMT jtreg tests passed
linux-aarch64: tier1 to tier3 passed

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

Commit messages:
 - 8356228: NMT does not record reserved memory base address correctly

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

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

From dholmes at openjdk.org  Tue Jun 10 12:08:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Jun 2025 12:08:32 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
Message-ID: <G1AAiiMFdo2C4nnHBRfh_Eko-7XMWUC2pxXAaRZV2zM=.65d349d6-b912-4e6c-9af8-8f457c7dda0b@github.com>

On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
>> 
>> Tested in tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8265754: Addressed reviewers comments.

I am okay with this refactoring. I will let you and Patricio iron out any further wrinkles.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2913266110

From cnorrbin at openjdk.org  Tue Jun 10 12:39:38 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 10 Jun 2025 12:39:38 GMT
Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code
Message-ID: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>

Hi everyone,

#24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function.

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

Commit messages:
 - Remove PerfDataSamplingInterval constraint check

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

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

From dholmes at openjdk.org  Tue Jun 10 13:01:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Jun 2025 13:01:29 GMT
Subject: RFR: 8358799: Refactor os::jvm_path() [v2]
In-Reply-To: <OqUHdELCz6kNwkWyCuSMoOR-7J17ORoAKyR_kfywvkw=.9ea9b19f-0471-4cf6-be7a-da5e6fdc111b@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
 <ZeTDDsF0ZOV7H__8mNjIP90PuBKSH_Eq2ySuwWz5oxo=.c722a383-e9e2-47eb-8ff9-e0a303f6a244@github.com>
 <OqUHdELCz6kNwkWyCuSMoOR-7J17ORoAKyR_kfywvkw=.9ea9b19f-0471-4cf6-be7a-da5e6fdc111b@github.com>
Message-ID: <IlJjnJ8kfwRrJyKg0MEEUZyqShhxYqqjwFNH44GP_4g=.be89ed04-d4c3-4501-89b6-61675cba5c5b@github.com>

On Tue, 10 Jun 2025 01:29:06 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/hotspot/os/posix/os_posix.cpp line 1071:
>> 
>>> 1069:     assert(false, "must use a large-enough buffer");
>>> 1070:     buf[0] = '\0';
>>> 1071:     return;
>> 
>> Do we need release the memory of `buf` before return, such like
>> 
>> 
>> free(buf);
>
> No, because the caller of the function still references `buf` after the function returns, e.g. in `os::init_system_properties_values()`.

More specifically, `buf` is owned by the caller and we have no idea what it is so we have no business "releasing" it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25675#discussion_r2137839159

From coleenp at openjdk.org  Tue Jun 10 13:04:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Jun 2025 13:04:13 GMT
Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to
 uncommit metaspace'
Message-ID: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>

Make the fatal error a log warning and return. The metaspace commit accounting is done after this return.  Tested with this always returning here, and it seems okay.  Tested with this change tier 1-4 and 8.

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

Commit messages:
 - 8357662: applications/runthese/RunThese8H.java Crash: 'Failed to uncommit metaspace'

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

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

From dholmes at openjdk.org  Tue Jun 10 13:04:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Jun 2025 13:04:32 GMT
Subject: RFR: 8358799: Refactor os::jvm_path() [v2]
In-Reply-To: <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
Message-ID: <ujQTADYmL4khjnm3vSsM_KQHyFMnoQfKnvsGhE-oSUk=.73380b1c-8515-44f0-a95c-718a674db5a0@github.com>

On Mon, 9 Jun 2025 19:01:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
>> 
>> Passed tiers 1 - 3 tests.
>> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.
>
> Calvin Cheung 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:
> 
>  - review comments from @dholmes-ora and @jdksjolen
>  - Merge branch 'master' into 8358799-refactor-jvm-path
>  - 8358799: Refactor os::jvm_path()

I'd still like some input from AIX folk on whether we can do better here, but in lieu of that this seems good enough to me.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25675#pullrequestreview-2913479876

From pchilanomate at openjdk.org  Tue Jun 10 15:35:32 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 10 Jun 2025 15:35:32 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
Message-ID: <MGVqcM5-RAWEcxTPT3A7V4adgGm3GzMESGiArClNjbI=.1f5c6cc6-b46c-4ab2-971d-69a808681073@github.com>

On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
>> 
>> Tested in tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8265754: Addressed reviewers comments.

Looks good to me, thanks!

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2914125850

From sviswanathan at openjdk.org  Tue Jun 10 15:49:30 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 10 Jun 2025 15:49:30 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6]
In-Reply-To: <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
Message-ID: <5nYyGDNyp9M_8i6SrURSf4kfyrxQLu6Ct6Av7RgAKqA=.a8df5cd6-ad3c-4045-ab7b-9839be52c670@github.com>

On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail

Changes look good.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25680#pullrequestreview-2914172623

From jsjolen at openjdk.org  Tue Jun 10 16:06:30 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 16:06:30 GMT
Subject: RFR: 8358799: Refactor os::jvm_path() [v2]
In-Reply-To: <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
Message-ID: <-USP59DTPiIjC9kWa0lNg2tiS7oFP6omWyC4u9y_nS0=.ceabe825-5d31-4714-8d2b-814a9efbd14f@github.com>

On Mon, 9 Jun 2025 19:01:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
>> 
>> Passed tiers 1 - 3 tests.
>> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.
>
> Calvin Cheung 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:
> 
>  - review comments from @dholmes-ora and @jdksjolen
>  - Merge branch 'master' into 8358799-refactor-jvm-path
>  - 8358799: Refactor os::jvm_path()

I'm also OK with this.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25675#pullrequestreview-2914232919

From ccheung at openjdk.org  Tue Jun 10 16:23:37 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 10 Jun 2025 16:23:37 GMT
Subject: RFR: 8358799: Refactor os::jvm_path() [v2]
In-Reply-To: <ujQTADYmL4khjnm3vSsM_KQHyFMnoQfKnvsGhE-oSUk=.73380b1c-8515-44f0-a95c-718a674db5a0@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
 <ddJJ8TFL2RB-QEEXYiPLqfnFYoe5lyMS5Z8XrZ5liRc=.56e7004f-a2ac-41dd-9416-98adadffa800@github.com>
 <ujQTADYmL4khjnm3vSsM_KQHyFMnoQfKnvsGhE-oSUk=.73380b1c-8515-44f0-a95c-718a674db5a0@github.com>
Message-ID: <warbwa8Qwet-ZmL1IOAC5-7pijGKvWDUIJ4XwtU402U=.fa231e6a-81f7-43ba-99d4-ac17cee6dc70@github.com>

On Tue, 10 Jun 2025 13:01:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Calvin Cheung 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:
>> 
>>  - review comments from @dholmes-ora and @jdksjolen
>>  - Merge branch 'master' into 8358799-refactor-jvm-path
>>  - 8358799: Refactor os::jvm_path()
>
> I'd still like some input from AIX folk on whether we can do better here, but in lieu of that this seems good enough to me.
> 
> Thanks

Thanks @dholmes-ora @jdksjolen for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25675#issuecomment-2959903451

From ccheung at openjdk.org  Tue Jun 10 16:23:38 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 10 Jun 2025 16:23:38 GMT
Subject: Integrated: 8358799: Refactor os::jvm_path()
In-Reply-To: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
References: <5V8S8Phzg3pWOlcnNP4o1jWnfC7xE5cYs2oyejSxF0c=.cb358c1b-6f13-4b82-9f11-ee6013f7b954@github.com>
Message-ID: <3nE5B4ckBR8GX_pj1TrWnWTVz_R6Oa_2J-wuUmimUwo=.47ed92c3-ddda-4fe6-a0a5-840d4c341170@github.com>

On Fri, 6 Jun 2025 16:35:15 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> The linux, bsd, and aix versions of os::jvm_path() are very similar and can be combined into one in os_posix.cpp.
> 
> Passed tiers 1 - 3 tests.
> However, tests were not run on the aix platform since it is not one of the Oracle supported platforms.

This pull request has now been integrated.

Changeset: 500a3a2d
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/500a3a2d0af0a3f7cf58b909bbbc2aa25926d8b4
Stats:     300 lines in 4 files changed: 89 ins; 211 del; 0 mod

8358799: Refactor os::jvm_path()

Reviewed-by: dholmes, jsjolen

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

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

From kvn at openjdk.org  Tue Jun 10 16:36:30 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 10 Jun 2025 16:36:30 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6]
In-Reply-To: <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
Message-ID: <ZjJLlzBcxVUWFbhKRQzqTXdyWOIXdKfb1VEJzYJep2M=.ad57fc87-8fff-4a38-baac-7ddfa1110de0@github.com>

On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail

Please, do not push until we review and test it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2959932766

From sviswanathan at openjdk.org  Tue Jun 10 16:36:30 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 10 Jun 2025 16:36:30 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6]
In-Reply-To: <ZjJLlzBcxVUWFbhKRQzqTXdyWOIXdKfb1VEJzYJep2M=.ad57fc87-8fff-4a38-baac-7ddfa1110de0@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
 <ZjJLlzBcxVUWFbhKRQzqTXdyWOIXdKfb1VEJzYJep2M=.ad57fc87-8fff-4a38-baac-7ddfa1110de0@github.com>
Message-ID: <JUOCHoOIsR6SVmhfE1Bl9dU132H4_hO82Ed78J4jE1U=.e077f941-137c-4afc-a105-e782917925f5@github.com>

On Tue, 10 Jun 2025 16:31:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail
>
> Please, do not push until we review and test it.

Thanks @vnkozlov, we will look forward to your testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2959937875

From kvn at openjdk.org  Tue Jun 10 17:01:31 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 10 Jun 2025 17:01:31 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6]
In-Reply-To: <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
Message-ID: <jyDTnxwwzUyDy-pL2TB-NJG2IQSrClhbYOlgVsWO-J4=.75400b6c-56b0-4f22-a802-db2f4c73de6b@github.com>

On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail

I submitted testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25680#issuecomment-2960000360

From mdoerr at openjdk.org  Tue Jun 10 18:57:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 10 Jun 2025 18:57:02 GMT
Subject: RFR: 8359165: AIX build broken after 8358799
Message-ID: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>

This fixes the build.

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

Commit messages:
 - 8359165: AIX build broken after 8358799

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

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

From mdoerr at openjdk.org  Tue Jun 10 18:57:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 10 Jun 2025 18:57:02 GMT
Subject: RFR: 8359165: AIX build broken after 8358799
In-Reply-To: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
Message-ID: <h-35pX7fRxKYkmXNsy1wq_77g9-9r8Oq3RGbin8mVtg=.4fb46572-3cbd-4070-a8c0-58fc68e1639b@github.com>

On Tue, 10 Jun 2025 18:52:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fixes the build.

@JoKern65: Please check if the code is still correct after https://github.com/openjdk/jdk/commit/500a3a2d0af0a3f7cf58b909bbbc2aa25926d8b4.

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

PR Comment: https://git.openjdk.org/jdk/pull/25734#issuecomment-2960290542

From gziemski at openjdk.org  Tue Jun 10 19:05:39 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Jun 2025 19:05:39 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v35]
In-Reply-To: <I0GU9F9F_3XCwI7b2zla278aey6VgPZYZXO6dv33aWQ=.d29e6f07-cfac-40b1-9e0e-02328e3de0b8@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <I0GU9F9F_3XCwI7b2zla278aey6VgPZYZXO6dv33aWQ=.d29e6f07-cfac-40b1-9e0e-02328e3de0b8@github.com>
Message-ID: <l8sDO6QpizhAXXDT41LrGS9KBnKRly1YWpUPdxmMs3M=.b33ed0af-9e60-4b83-b23f-c2e2f9c7ae65@github.com>

On Tue, 3 Jun 2025 10:18:47 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   invalid -> release.

LGTM, thanks for your patience and all the work!

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2914760453

From mdoerr at openjdk.org  Tue Jun 10 19:23:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 10 Jun 2025 19:23:30 GMT
Subject: RFR: 8359165: AIX build broken after 8358799
In-Reply-To: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
Message-ID: <juQnKDJfqCFW59kuRvZTS5yuzoYkky_-_BJz2G7xBNQ=.19115382-7265-4dc2-aa18-93da09b47623@github.com>

On Tue, 10 Jun 2025 18:52:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fixes the build.

@varada1110: You may as well want to take a look if the refactored code is still correct. (This PR is a P1 build fix.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25734#issuecomment-2960352222

From mdoerr at openjdk.org  Tue Jun 10 19:46:10 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 10 Jun 2025 19:46:10 GMT
Subject: RFR: 8359165: AIX build broken after 8358799 [v2]
In-Reply-To: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
Message-ID: <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>

> This fixes the build.

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

  Improve constness.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25734/files
  - new: https://git.openjdk.org/jdk/pull/25734/files/3bcb5277..667d307a

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

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

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

From gziemski at openjdk.org  Tue Jun 10 19:52:27 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 10 Jun 2025 19:52:27 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
Message-ID: <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com>

On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The problem here stems from the following facts:
> 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. 
> 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.
> 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above.
> 
> So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue).
> 
> Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings.
> 
> Tests:
> linux-x64: runtime/NMT jtreg tests passed
> linux-aarch64: tier1 to tier3 passed

src/hotspot/share/cds/archiveBuilder.cpp line 346:

> 344:   // During an aligned reserve, some extra sub-regions of the memory region may be released due to alignment requirements.
> 345:   // NMT will ignore releasing sub-regions (i.e., contained in other regions) that have mtClassShared tags.
> 346:   MemTracker::record_virtual_memory_tag(rs, mtClassShared);

Is it possible to capture this logic in a test, so we can always check for this behavior?

Where in the code do we release and check for the special case of `mtClassShared`?

I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2138658913

From ccheung at openjdk.org  Tue Jun 10 22:33:38 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 10 Jun 2025 22:33:38 GMT
Subject: RFR: 8357382:
 runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp
 and C1
Message-ID: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>

One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`.

Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description.

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

Commit messages:
 - 8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1

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

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

From kbarrett at openjdk.org  Wed Jun 11 01:14:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Jun 2025 01:14:39 GMT
Subject: RFR: 8359165: AIX build broken after 8358799 [v2]
In-Reply-To: <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
 <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>
Message-ID: <jeE8c3uaQCCLCKTvG9HqdRkSpHw1BqgD0-nrTEBmit0=.995d6639-d685-43d6-8bb0-ba77b3df0e28@github.com>

On Tue, 10 Jun 2025 19:46:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fixes the build.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve constness.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25734#pullrequestreview-2915369045

From duke at openjdk.org  Wed Jun 11 07:29:31 2025
From: duke at openjdk.org (duke)
Date: Wed, 11 Jun 2025 07:29:31 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
Message-ID: <8tVGOT8BT3v9vEil8CNXdwWKrdPv8xVbHUABinhgTqc=.0a06daca-0a34-4a55-a557-82548fd3a88a@github.com>

On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
>> 
>> Tested in tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8265754: Addressed reviewers comments.

@toxaart 
Your change (at version 1d34f5ad466f07c2c7ec5a4c00ba93a3b5eb66be) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2961542506

From jkern at openjdk.org  Wed Jun 11 07:58:29 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 11 Jun 2025 07:58:29 GMT
Subject: RFR: 8359165: AIX build broken after 8358799 [v2]
In-Reply-To: <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
 <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>
Message-ID: <aZEGaXsoaWWa4bz5hqhsOfmu3HP-7WESpWlIJr5EubA=.338ad06a-c987-4f0b-ae0e-1e8ac5c6c62f@github.com>

On Tue, 10 Jun 2025 19:46:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fixes the build.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve constness.

Yes, your fix should repair the regression after 500a3a2. That was the only thing I found in this commit. With your fix it should work again for AIX.

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25734#pullrequestreview-2916054731

From cstein at openjdk.org  Wed Jun 11 08:30:18 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Jun 2025 08:30:18 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

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

  Extract shared function to compute current token

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25589/files
  - new: https://git.openjdk.org/jdk/pull/25589/files/21afeb37..bea8cc79

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

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

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

From mdoerr at openjdk.org  Wed Jun 11 08:31:42 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 08:31:42 GMT
Subject: RFR: 8359165: AIX build broken after 8358799 [v2]
In-Reply-To: <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
 <sqZ2KFI4jHM4WQIHc2EaBrsjnjg_2YtN_-Yfi_DRbfA=.8c77ece0-24dd-44a3-94f4-b2249304776b@github.com>
Message-ID: <mxD5wV8xELhi8nkrWbAr-Eqxl0Ca11p8gnEK_fcC-tI=.cc7c2f25-6b9e-4add-aef5-3ee9ab6662da@github.com>

On Tue, 10 Jun 2025 19:46:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This fixes the build.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve constness.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25734#issuecomment-2961706305

From mdoerr at openjdk.org  Wed Jun 11 08:31:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 08:31:43 GMT
Subject: Integrated: 8359165: AIX build broken after 8358799
In-Reply-To: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
References: <k26j40u8rehkFix8O_o_IYlsltsUKUavCoNdWXKZI_g=.61c3a87e-1ef6-40b3-a142-83557d6a2cab@github.com>
Message-ID: <rocPpgJ-q8QpCbMU6HvpEWkE5K9y91WASC3nf22M18U=.828e088f-6e87-4bfe-ae39-e9e7ca3647aa@github.com>

On Tue, 10 Jun 2025 18:52:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This fixes the build.

This pull request has now been integrated.

Changeset: 56ce70c5
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56ce70c5dfe1ecaf371d462d4198765d4a86db3c
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8359165: AIX build broken after 8358799

Reviewed-by: kbarrett, jkern

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

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

From cstein at openjdk.org  Wed Jun 11 08:35:29 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Jun 2025 08:35:29 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <IqvVkOj7xntKKswD9SJsGwSyI7gDgHYHWfCrkgh1zjY=.0dbce17a-81e5-41e5-8bfd-a95d01230b3e@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <tO_z8q0cawzrkDP_z__sUZbM2sWejgIHdwksIbFboUI=.1b657729-6541-4310-9117-d4f7f0d75a7a@github.com>
 <4Xzu7FifgELCGKkOTBMCpcgYwwKuqymJBpMSQHVFbcA=.95d8329e-453e-439f-a628-149ce8c22a51@github.com>
 <1aNuDmukQdUIs83wrKGgzmEHIOgMMUtTtePU9dHsUyE=.6b73641a-ab98-4b37-af3d-08b06d73533b@github.com>
 <IqvVkOj7xntKKswD9SJsGwSyI7gDgHYHWfCrkgh1zjY=.0dbce17a-81e5-41e5-8bfd-a95d01230b3e@github.com>
Message-ID: <7Es28Ts_GeDSE5WMTb6XPEy7OnT71Wouv07AGrlMSwA=.734b2270-d85d-4b26-ac3f-a6bdcb1a2d17@github.com>

On Tue, 10 Jun 2025 08:15:58 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Or the handling of `#` can be merged with the previous case ... somehow.
>
> Extracting a method wouldn't really simplify the code, as many local variables are in play.
> 
> Merging the cases also ends up in more if-else constructs in the case block that counter-act readability.
> 
> So, perhaps, the duplication is goog-enough here?

Created an internal shared function in https://github.com/openjdk/jdk/pull/25589/commits/bea8cc7905541e339ed30d0618e70ab6db7b6da6

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139538469

From stefank at openjdk.org  Wed Jun 11 08:58:31 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Jun 2025 08:58:31 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
Message-ID: <NSQwR1aBe6TLcTJKGgt2KL6RqFut8wYpnGwc0TH80ho=.7ff5e756-58e5-40de-a709-a9b41b36c4a8@github.com>

On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.

The special-case handling of CDS in NMT breaks abstractions and has caused a number of bugs. I'm worried that trying to workaround this special-case code makes the code even more susceptible for future bugs. So, therefore I'm interested to here about the planes you have to replace the NMT implementation with a tree. Isn't that going to remove the CDS special-case code and maybe be even solve this issue without the need for this fix? If not, feel free to ignore my comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/25719#issuecomment-2961794111

From stefank at openjdk.org  Wed Jun 11 09:11:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Jun 2025 09:11:30 GMT
Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed
 to uncommit metaspace'
In-Reply-To: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
References: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
Message-ID: <uR5bxz2rVWrgGY41Obf0A4mMT534QJGO6drXGTwsY7A=.c8e3520a-976d-405a-bf59-2dda728ad6cb@github.com>

On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make the fatal error a log warning and return. The metaspace commit accounting is done after this return.  Tested with this always returning here, and it seems okay.  Tested with this change tier 1-4 and 8.

I'm not sure this is safe.

Could you explain how you come to the conclusion that failing to uncommit shouldn't be considered fatal? If the failure mode really is that we failed to split the memory mapping then I don't think we can be sure that the OS left the memory reservation the way the JVM has book keeped it. In other situations like this we have found that this could lead to other threads allocating into memory that another sub-system thinks that it has reserved (and owns), which can lead to various memory corruption issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2961842406

From azafari at openjdk.org  Wed Jun 11 11:09:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 11 Jun 2025 11:09:35 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
 <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com>
Message-ID: <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com>

On Tue, 10 Jun 2025 19:49:57 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Is it possible to capture this logic in a test, so we can always check for this behavior?

Work on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2139856485

From azafari at openjdk.org  Wed Jun 11 11:12:30 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 11 Jun 2025 11:12:30 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
 <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com>
 <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com>
Message-ID: <vppCQsV4_oadwwU6kYggQfpVfrmTkmfMJ-ffc7SX-ww=.497cc8c3-0e9d-433f-aa1a-ecaa7f008090@github.com>

On Wed, 11 Jun 2025 11:06:55 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveBuilder.cpp line 346:
>> 
>>> 344:   // During an aligned reserve, some extra sub-regions of the memory region may be released due to alignment requirements.
>>> 345:   // NMT will ignore releasing sub-regions (i.e., contained in other regions) that have mtClassShared tags.
>>> 346:   MemTracker::record_virtual_memory_tag(rs, mtClassShared);
>> 
>> Is it possible to capture this logic in a test, so we can always check for this behavior?
>> 
>> Where in the code do we release and check for the special case of `mtClassShared`?
>> 
>> I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start?
>
>> Is it possible to capture this logic in a test, so we can always check for this behavior?
> 
> Work on it.

> Where in the code do we release and check for the special case of `mtClassShared`?

In `virtualMemoryTracker.cpp, remove_released_region(adddress, size)` in an `if` block as this:

if (reserved_rgn->mem_tag() == mtClassShared) {
    if (reserved_rgn->contain_region(addr, size)) {
      // This is an unmapped CDS region, which is part of the reserved shared
      // memory region.
      // See special handling in VirtualMemoryTracker::add_reserved_region also.
      return true;
    }

    if (size > reserved_rgn->size()) {
      // This is from release the whole region spanning from archive space to class space,
      // so we release them altogether.
      ReservedMemoryRegion class_rgn(addr + reserved_rgn->size(),
                                     (size - reserved_rgn->size()));
      ReservedMemoryRegion* cls_rgn = _reserved_regions->find(class_rgn);
      assert(cls_rgn != nullptr, "Class space region  not recorded?");
      assert(cls_rgn->mem_tag() == mtClass, "Must be class mem tag");
      remove_released_region(reserved_rgn);
      remove_released_region(cls_rgn);
      return true;
    }
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2139864313

From coleenp at openjdk.org  Wed Jun 11 11:29:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Jun 2025 11:29:29 GMT
Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed
 to uncommit metaspace'
In-Reply-To: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
References: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
Message-ID: <YlGaThzPoxr9_PnXaFJHkQ9DVigk1H4rBJANKv1oxoo=.79d79500-8699-4ec8-a2d4-d9438121d48d@github.com>

On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make the fatal error a log warning and return. The metaspace commit accounting is done after this return.  Tested with this always returning here, and it seems okay.  Tested with this change tier 1-4 and 8.

If pd_uncommit_memory fails, it returns a boolean. If this is unsafe, shouldn't pd_uncommit_memory have a fatal error?

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

PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2962314988

From azafari at openjdk.org  Wed Jun 11 11:41:29 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 11 Jun 2025 11:41:29 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <vppCQsV4_oadwwU6kYggQfpVfrmTkmfMJ-ffc7SX-ww=.497cc8c3-0e9d-433f-aa1a-ecaa7f008090@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
 <5iK4kLVAXBQwAk5CIanwth29A526ixl_2HZ9Rd2F6fU=.021491ae-c2fa-4ece-af3a-ea94a78da6f5@github.com>
 <7NlUTEfQMHShVK2BRfHMPOV0dfgmSiU6dVhuvfI4rpY=.d1495e5f-13b2-48ad-b28a-ea71891b3151@github.com>
 <vppCQsV4_oadwwU6kYggQfpVfrmTkmfMJ-ffc7SX-ww=.497cc8c3-0e9d-433f-aa1a-ecaa7f008090@github.com>
Message-ID: <evkGCkAODj6wgcYbsCCopG19vo61xjK47gVxaxkt0bo=.cc676aa0-0aee-4139-9e85-dfcc80823418@github.com>

On Wed, 11 Jun 2025 11:10:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>>> Is it possible to capture this logic in a test, so we can always check for this behavior?
>> 
>> Work on it.
>
>> Where in the code do we release and check for the special case of `mtClassShared`?
> 
> In `virtualMemoryTracker.cpp, remove_released_region(adddress, size)` in an `if` block as this:
> 
> if (reserved_rgn->mem_tag() == mtClassShared) {
>     if (reserved_rgn->contain_region(addr, size)) {
>       // This is an unmapped CDS region, which is part of the reserved shared
>       // memory region.
>       // See special handling in VirtualMemoryTracker::add_reserved_region also.
>       return true;
>     }
> 
>     if (size > reserved_rgn->size()) {
>       // This is from release the whole region spanning from archive space to class space,
>       // so we release them altogether.
>       ReservedMemoryRegion class_rgn(addr + reserved_rgn->size(),
>                                      (size - reserved_rgn->size()));
>       ReservedMemoryRegion* cls_rgn = _reserved_regions->find(class_rgn);
>       assert(cls_rgn != nullptr, "Class space region  not recorded?");
>       assert(cls_rgn->mem_tag() == mtClass, "Must be class mem tag");
>       remove_released_region(reserved_rgn);
>       remove_released_region(cls_rgn);
>       return true;
>     }
>   }

> I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start?

The sequence is as follows:
_All the reserve/release operations here are from `os::` namespace and therefore will call NMT tracking API_
1- CDS requests for reserving `S` bytes at address `Base` with alignment `A` and memTag `M`.
2- Due to OS alignment limitations regarding `A`, new base `XBase` to be used with new size `XS`. Read X as extra here.
3- Do instead, reserve `XS` bytes at `XBase`.
4- If succeeds, memory would be like `<--s1---><----S----><----s2--->`, where `XS = s1 + S + s2` and `XBase + s1 == Base`  
5- Release extra parts `s1` and `s2`.
6- request at step 1 above is fulfilled now.

If at step 1, the memTag `M` is `mtClassShared` , the releases at step 5 will be ignored by NMT. Which means that there are regions in NMT lists that are actually released (at os level) but NMT takes them still as reserved. Therefore, further reservations by os at those regions (e.g., for stack) will intersect with existing NMT regions and the NMT assertions fail. So the memTag is to be `mtNone` to bypass/avoid the NMT ignore branch.

If we want to track the new memory region as belongs to CDS, we need to set the memTag of the region to `mtClassShared` with the corresponding `MemTracker` API.(as is done here in this PR)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2139917194

From duke at openjdk.org  Wed Jun 11 11:44:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 11 Jun 2025 11:44:29 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
Message-ID: <nLfsz3_WW_ULOEnLGN8xI8T_DkaqQmhReBEUh4f9whM=.6e91eba1-5ef6-4670-852d-0c00eff40ac7@github.com>

On Wed, 11 Jun 2025 08:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
>> 
>> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
>> 
>> Use the number sign `#` in the argument file to identify comments.
>> All characters following the `#` are ignored until the end of line.
>> 
>> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract shared function to compute current token

test/jdk/tools/launcher/ArgFileSyntax.java line 177:

> 175:         },
> 176:         { // multiple args in one line and comments without preceding whitespace
> 177:             { "-Xmx32m -XshowSettings#COMMENT 1",

First case feels like a duplicate of the test at line 73. What's different?
Maybe this case should just live next to that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139921427

From cstein at openjdk.org  Wed Jun 11 12:04:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Jun 2025 12:04:33 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <nLfsz3_WW_ULOEnLGN8xI8T_DkaqQmhReBEUh4f9whM=.6e91eba1-5ef6-4670-852d-0c00eff40ac7@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
 <nLfsz3_WW_ULOEnLGN8xI8T_DkaqQmhReBEUh4f9whM=.6e91eba1-5ef6-4670-852d-0c00eff40ac7@github.com>
Message-ID: <AsMhBQ_8RMzAI0me2ZF-rWM8WGtzfIfArvIW4I8EHs0=.1844621f-36c4-4ca9-9ec0-c6215c0855ba@github.com>

On Wed, 11 Jun 2025 11:41:41 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extract shared function to compute current token
>
> test/jdk/tools/launcher/ArgFileSyntax.java line 177:
> 
>> 175:         },
>> 176:         { // multiple args in one line and comments without preceding whitespace
>> 177:             { "-Xmx32m -XshowSettings#COMMENT 1",
> 
> First case feels like a duplicate of the test at line 73. What's different?
> Maybe this case should just live next to that?

It only _feels_ so. Mind the gap(s) before the `#` number signs in the test at line 73: they were and are still supported. This fix and test now ensures that comments without gaps (read: whitespace) are supported.

> Maybe this case should just live next to that?

The location of the new test data is next to another "whitespace-related" use-case. So, it's also related.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25589#discussion_r2139957273

From duke at openjdk.org  Wed Jun 11 12:45:54 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 11 Jun 2025 12:45:54 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v12]
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <05reBLJRa6h9U7KCNqZtao-6oCB689hF-DjsMyTgOKo=.40105ae6-073a-44b4-b20e-8be084f455ef@github.com>

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

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

  8265754: Fixed date in copyright comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25407/files
  - new: https://git.openjdk.org/jdk/pull/25407/files/1d34f5ad..00a9faaa

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

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

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

From coleenp at openjdk.org  Wed Jun 11 12:45:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Jun 2025 12:45:54 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v12]
In-Reply-To: <05reBLJRa6h9U7KCNqZtao-6oCB689hF-DjsMyTgOKo=.40105ae6-073a-44b4-b20e-8be084f455ef@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <05reBLJRa6h9U7KCNqZtao-6oCB689hF-DjsMyTgOKo=.40105ae6-073a-44b4-b20e-8be084f455ef@github.com>
Message-ID: <Q1zlkAxU6oycwFDHz9AVY4VoBPqkHqBCNRIB_MozNTY=.464535cd-0c74-4ed8-832a-1c239ce15f91@github.com>

On Wed, 11 Jun 2025 12:43:15 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
>> 
>> Tested in tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8265754: Fixed date in copyright comment.

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2916974124

From coleenp at openjdk.org  Wed Jun 11 12:45:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Jun 2025 12:45:54 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
Message-ID: <FRZJBVlDUO_a2MvyE0KdeCSdHNP2Xnx1NoDkOnkDkjY=.cc048e1e-e7f5-4a54-a92a-b0cda64e6be4@github.com>

On Tue, 10 Jun 2025 08:40:53 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi,
>> 
>> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
>> 
>> Tested in tiers 1-4.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8265754: Addressed reviewers comments.

Just needs a copyright fix.

src/hotspot/share/runtime/suspendResumeManager.cpp line 2:

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

Suggestion:

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

src/hotspot/share/runtime/suspendResumeManager.hpp line 2:

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

Suggestion:

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

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2916964481
PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140025045
PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140024252

From duke at openjdk.org  Wed Jun 11 12:45:54 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 11 Jun 2025 12:45:54 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <FRZJBVlDUO_a2MvyE0KdeCSdHNP2Xnx1NoDkOnkDkjY=.cc048e1e-e7f5-4a54-a92a-b0cda64e6be4@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
 <FRZJBVlDUO_a2MvyE0KdeCSdHNP2Xnx1NoDkOnkDkjY=.cc048e1e-e7f5-4a54-a92a-b0cda64e6be4@github.com>
Message-ID: <B5fS6RBGssVzKRIJXwFzlTAyvBpKROisdSHRw6L1PG4=.4af308b8-12fc-443e-b9b8-5a86b7053d5e@github.com>

On Wed, 11 Jun 2025 12:38:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8265754: Addressed reviewers comments.
>
> src/hotspot/share/runtime/suspendResumeManager.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Addressed in the latest commit.

> src/hotspot/share/runtime/suspendResumeManager.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140030245
PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2140030001

From duke at openjdk.org  Wed Jun 11 12:45:56 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 11 Jun 2025 12:45:56 GMT
Subject: Integrated: 8265754: Move suspend/resume API from HandshakeState
In-Reply-To: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
Message-ID: <M_XFj16EOruepgYJcFOBVoMzA0Y2s6YGbQ1A8nXJRkQ=.eab12942-4563-4997-aca8-3757666a5426@github.com>

On Fri, 23 May 2025 08:24:34 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi,
> 
> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class SuspendResumeManager. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. 
> 
> Tested in tiers 1-4.

This pull request has now been integrated.

Changeset: 42ab8fcf
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42ab8fcfb98eacb2d93f59c012360a99a16e5450
Stats:     393 lines in 6 files changed: 234 ins; 152 del; 7 mod

8265754: Move suspend/resume API from HandshakeState

Reviewed-by: coleenp, dholmes, pchilanomate

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

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

From mdoerr at openjdk.org  Wed Jun 11 12:56:27 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Jun 2025 12:56:27 GMT
Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too
 low values
In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
Message-ID: <3GIKiPAcY6CABfp1c2husazPDd_dFAtAC4EnpYkC2ao=.bafe633b-3dde-4578-accf-7a63eec3d9a9@github.com>

On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently os::Bsd::available_memory() returns on macOS
> `vmstat.free_count * os::vm_page_size();`
> But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories 
> There is a bit of additional information here https://developer.apple.com/forums/thread/118867
> that confirms that free memory / free_count is only a fraction of what is available.
> 
> There is also some info here
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB
> containing this relevant info :
> "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them."
> 
> and also about purgeable memory at
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1

LGTM. But I'm not a memory management expert.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25657#pullrequestreview-2917025968

From lucy at openjdk.org  Wed Jun 11 13:25:31 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 11 Jun 2025 13:25:31 GMT
Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too
 low values
In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
Message-ID: <nl3v2TXL9hUUn-SzFf8FuReet8CbiDKFkZ6ITj9JlYo=.afbb297b-3b7e-4b86-9686-bb306c99dc27@github.com>

On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently os::Bsd::available_memory() returns on macOS
> `vmstat.free_count * os::vm_page_size();`
> But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories 
> There is a bit of additional information here https://developer.apple.com/forums/thread/118867
> that confirms that free memory / free_count is only a fraction of what is available.
> 
> There is also some info here
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB
> containing this relevant info :
> "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them."
> 
> and also about purgeable memory at
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1

LGTM.
The cited documentation suggests the fix is ok.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25657#pullrequestreview-2917141081

From mbaesken at openjdk.org  Wed Jun 11 13:35:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Jun 2025 13:35:40 GMT
Subject: RFR: 8357570: [macOS] os::Bsd::available_memory() might return too
 low values
In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
Message-ID: <S1BgjegmPE80SOE0KzdNTULd6haf6uVTRvHnVCm1jpI=.c786be01-7d48-48fe-9601-60b6b5409098@github.com>

On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently os::Bsd::available_memory() returns on macOS
> `vmstat.free_count * os::vm_page_size();`
> But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories 
> There is a bit of additional information here https://developer.apple.com/forums/thread/118867
> that confirms that free memory / free_count is only a fraction of what is available.
> 
> There is also some info here
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB
> containing this relevant info :
> "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them."
> 
> and also about purgeable memory at
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/25657#issuecomment-2962728277

From mbaesken at openjdk.org  Wed Jun 11 13:35:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Jun 2025 13:35:41 GMT
Subject: Integrated: 8357570: [macOS] os::Bsd::available_memory() might return
 too low values
In-Reply-To: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
References: <5_OBJDFHZlZkhWyqcyD8ssvE2j3pvQa-6baoD5UAPPY=.a1f51b80-61ba-4e50-af9f-975166f8fdc8@github.com>
Message-ID: <srkQJ-1vRlfw2UJEmuuXPwjGiqa9mTt4V4S5QDnCuwg=.1192f802-aced-47b4-96b9-72c11c604977@github.com>

On Thu, 5 Jun 2025 07:53:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently os::Bsd::available_memory() returns on macOS
> `vmstat.free_count * os::vm_page_size();`
> But just using free_count is rather conservative because there are other memory categories on macOS that can be made available too. Unfortunately the different memory categories 
> There is a bit of additional information here https://developer.apple.com/forums/thread/118867
> that confirms that free memory / free_count is only a fraction of what is available.
> 
> There is also some info here
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB
> containing this relevant info :
> "The inactive list contains pages that are currently resident in physical memory but have not been accessed recently. These pages contain valid data but may be removed from memory at any time. The free list contains pages of physical memory that are not associated with any address space of VM object. These pages are available for immediate use by any process that needs them."
> 
> and also about purgeable memory at
> https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/CachingandPurgeableMemory.html#//apple_ref/doc/uid/TP40013104-SW1

This pull request has now been integrated.

Changeset: 7d7fc693
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d7fc69355e6f5421cf09f93290270bb16d13182
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8357570: [macOS] os::Bsd::available_memory() might return too low values

Reviewed-by: clanger, mdoerr, lucy

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

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

From stefank at openjdk.org  Wed Jun 11 16:55:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Jun 2025 16:55:30 GMT
Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed
 to uncommit metaspace'
In-Reply-To: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
References: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
Message-ID: <AuHDJQJV8L0uwCtAnjtbfWzL1mpTsMTPm_rsbDld3QE=.2351840a-6dac-4eb7-b14e-928aa409798e@github.com>

On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make the fatal error a log warning and return. The metaspace commit accounting is done after this return.  Tested with this always returning here, and it seems okay.  Tested with this change tier 1-4 and 8.

I think we should have a fatal error. I argue for that here:
https://github.com/openjdk/jdk/pull/24084#issuecomment-2755656985

(You will likely have to read surrounding comments to get the context of that discussion)

There was an action item in there to create a bug report for this. I'm fine to be proven wrong w.r.t. this but I think there needs to be some very convincing argument to prove that the OS leaves the JVM in a safe state when we hit the various error parts in the kernel that returns ENOMEM.

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

PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2963531582

From vromero at openjdk.org  Wed Jun 11 17:02:28 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Jun 2025 17:02:28 GMT
Subject: RFR: 8357862: Java argument file is parsed unexpectedly with
 trailing comment [v2]
In-Reply-To: <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
 <WDT4hGnZmonDpTycLenA9jd_OCqJ2jrmgLAXfd6TxtA=.925df0d9-12d2-403d-92c6-26f927585f1b@github.com>
Message-ID: <eFpBQC2CKyUxLn-mDn6geKi4wVMxIss3xpoEpCwaKF0=.689397c3-bbf3-4496-93d2-8901225df113@github.com>

On Wed, 11 Jun 2025 08:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
>> 
>> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
>> 
>> Use the number sign `#` in the argument file to identify comments.
>> All characters following the `#` are ignored until the end of line.
>> 
>> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract shared function to compute current token

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25589#pullrequestreview-2918023875

From iklam at openjdk.org  Wed Jun 11 17:12:30 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Jun 2025 17:12:30 GMT
Subject: RFR: 8357382:
 runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp
 and C1
In-Reply-To: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
References: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
Message-ID: <djw1GJntxQ2B89jST7N9Gko-BkOXaEPeTe7pS9a3_e8=.e65b8342-c104-427e-8ec2-4a7d9c7fb66f@github.com>

On Tue, 10 Jun 2025 22:28:41 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`.
> 
> Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25737#pullrequestreview-2918061492

From kvn at openjdk.org  Wed Jun 11 17:23:30 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 11 Jun 2025 17:23:30 GMT
Subject: RFR: 8358556: Assert when running with -XX:-UseLibmIntrinsic [v6]
In-Reply-To: <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
 <jZUrjyxX5OmXQ3iO8VLovIZyIq0wqSs-mP1hibRLe1o=.b36ccc45-3f84-4090-954f-3abc39b003a1@github.com>
Message-ID: <7zH3dpVRh0CApiUlhYRpHOe1EBMTixBKuNcxv_icngI=.406cf55f-287a-4b58-a8ca-dc9e680a98cf@github.com>

On Tue, 10 Jun 2025 00:53:23 GMT, Mohamed Issa <duke at openjdk.org> wrote:

>> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.
>
> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add guard preprocessors to ensure HotSpot Zero JVM builds don't fail

My testing passed

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25680#pullrequestreview-2918098117

From kvn at openjdk.org  Wed Jun 11 17:28:27 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 11 Jun 2025 17:28:27 GMT
Subject: RFR: 8357382:
 runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp
 and C1
In-Reply-To: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
References: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
Message-ID: <MTRn-oafa27JYLfrXvxuC6tXuE-Nb4RstYlngR89PCE=.9ed515de-1994-4254-8d32-b6565de0bed0@github.com>

On Tue, 10 Jun 2025 22:28:41 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`.
> 
> Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25737#pullrequestreview-2918111133

From duke at openjdk.org  Wed Jun 11 17:49:33 2025
From: duke at openjdk.org (Mohamed Issa)
Date: Wed, 11 Jun 2025 17:49:33 GMT
Subject: Integrated: 8358556: Assert when running with -XX:-UseLibmIntrinsic
In-Reply-To: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
References: <5I__-Q1nU1f370O41lwrUa7frkOzOG81ROhH8H73jGM=.defaed01-68cf-447d-870e-121edd60b80b@github.com>
Message-ID: <IpHwsXzjYqWC_kQ_vskcnSlKyZzHFy1KvahfogMZ2TU=.40c1a09c-4811-4fdd-a61d-db8567aa93e4@github.com>

On Fri, 6 Jun 2025 20:40:49 GMT, Mohamed Issa <duke at openjdk.org> wrote:

> This change fixes unwanted calls to the cbrt and tanh intrinsics on x86 when they are explicitly disabled by flags such as _-XX:-UseLibmIntrinsic_ or _-XX:-InlineIntrinsics_.

This pull request has now been integrated.

Changeset: ef4cbec6
Author:    Mohamed Issa <mohamed.issa at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef4cbec6fba77fd84b328d333f8592c6eedf1a2d
Stats:     19 lines in 2 files changed: 13 ins; 2 del; 4 mod

8358556: Assert when running with -XX:-UseLibmIntrinsic

Reviewed-by: sviswanathan, kvn

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

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

From ccheung at openjdk.org  Wed Jun 11 18:13:32 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 11 Jun 2025 18:13:32 GMT
Subject: RFR: 8357382:
 runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp
 and C1
In-Reply-To: <djw1GJntxQ2B89jST7N9Gko-BkOXaEPeTe7pS9a3_e8=.e65b8342-c104-427e-8ec2-4a7d9c7fb66f@github.com>
References: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
 <djw1GJntxQ2B89jST7N9Gko-BkOXaEPeTe7pS9a3_e8=.e65b8342-c104-427e-8ec2-4a7d9c7fb66f@github.com>
Message-ID: <Odd8IjDfyM76Xhsx5FPXkyHyi49cr8UUspjq1hn4-wM=.c77939c0-4292-4b78-8193-2e7677441def@github.com>

On Wed, 11 Jun 2025 17:10:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`.
>> 
>> Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description.
>
> LGTM

@iklam @vnkozlov Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25737#issuecomment-2963735644

From ccheung at openjdk.org  Wed Jun 11 18:13:33 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 11 Jun 2025 18:13:33 GMT
Subject: Integrated: 8357382:
 runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp
 and C1
In-Reply-To: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
References: <ZMU4PSbPhTMxHPYrWNatulz6YzucQrrqV1sSDb3Mj4M=.c6367b23-6f01-4fde-8090-fedd6f792ab4@github.com>
Message-ID: <5r5chuNab6LeYavdukooa2uGK3XW9ipc8Jg4vdoa1xQ=.f7e5a01d-8b77-41da-a4ca-e1faae8163e6@github.com>

On Tue, 10 Jun 2025 22:28:41 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> One possible cause of the failure is that one of the `SimpleCusty` test classes was garbaged collected. To make the test run more reliably, the fix is to store the class loaders in a static `ArrayList`.
> 
> Testing: ran the test 20 times on Oracle supported platforms with the VM options listed in the bug report description.

This pull request has now been integrated.

Changeset: 42915821
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/429158218b52964ad1e79ba9d2fa5618d6b3398e
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8357382: runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java#aot fails with Xcomp and C1

Reviewed-by: iklam, kvn

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

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

From gziemski at openjdk.org  Wed Jun 11 19:12:28 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 11 Jun 2025 19:12:28 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v2]
In-Reply-To: <WewOYkcVm6DQNiZD1z33icG0nt2AZEIIbR6pA_qPTLQ=.81cf1a3e-e1c4-42be-ab25-7b53cd52bfb2@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <WewOYkcVm6DQNiZD1z33icG0nt2AZEIIbR6pA_qPTLQ=.81cf1a3e-e1c4-42be-ab25-7b53cd52bfb2@github.com>
Message-ID: <JJTJ_r_c2XFyNOocT9okT1ucDpKy3LtJD-R5C8DtzdI=.1ae6a392-e92b-4b1d-a1b1-d81360735102@github.com>

On Mon, 2 Jun 2025 08:27:36 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   user-facing terms remained as 'category'

Need to fix the test `runtime/NMT/MallocLimitTest.java#compiler-limit-oom`

Just in case, can you run MACH5 tier1-3 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2963885339

From syan at openjdk.org  Thu Jun 12 02:10:33 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 12 Jun 2025 02:10:33 GMT
Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128
 is not accepted as unlimited
In-Reply-To: <rh21qpq9dQeP3vq0QGFZEJJ6cKi3YMtnFYNMGpuhFBo=.e60b8ed5-ed91-4d5c-99dd-64f64bdf5530@github.com>
References: <rh21qpq9dQeP3vq0QGFZEJJ6cKi3YMtnFYNMGpuhFBo=.e60b8ed5-ed91-4d5c-99dd-64f64bdf5530@github.com>
Message-ID: <K7aT-OIzgt1YC58duAU1855-xGK0-vqKa_BjC8KPEnk=.fb89c545-3957-4379-9b58-8b23d74a90ca@github.com>

On Tue, 6 May 2025 14:06:54 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM.
> 
> 
> test/hotspot/jtreg/containers/docker/TestPids.java
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128
> 
> 
> DefaultTasksMax=28776 for RAM 24576MB
> DefaultTasksMax=19128 for RAM 16384MB
> DefaultTasksMax=1088 for RAM 1024MB
> 
> The testcase expects DefaultTasksMax>=20000.

test/hotspot/jtreg/containers/docker/TestPids.java line 103:

> 101: 
> 102:     private static String runSystemctlShow() throws IOException {
> 103:         ProcessBuilder pb = new ProcessBuilder("systemctl", "show", "--property=DefaultTasksMax");

On windows-cygwin, there is no `systemctl` command.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25067#discussion_r2141412173

From iklam at openjdk.org  Thu Jun 12 02:53:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 12 Jun 2025 02:53:15 GMT
Subject: RFR: 8355556: JVM crash because archived method handle intrinsics are
 not restored
Message-ID: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>

`AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from `<clinit>`). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used.

In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline.

However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`.

Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25).

Thanks to @iwanowww for providing the fix!

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

Commit messages:
 - 8355556: JVM crash because archived method handle intrinsics are not restored

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

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

From syan at openjdk.org  Thu Jun 12 09:00:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 12 Jun 2025 09:00:38 GMT
Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test
In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com>
Message-ID: <va7nqTgHRC0HzTfrFTlDGDwrZy18lx4Lyzyi4_QvkDw=.e72982d2-0be5-4aa0-864f-f364b3243766@github.com>

On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797
> that causes test failure.
> 
> The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. 
> I am removing it just to avoid spending time for anyone who can run test and observe this failure.

LGTM

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25316#pullrequestreview-2920150175

From azafari at openjdk.org  Thu Jun 12 09:23:24 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Jun 2025 09:23:24 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v3]
In-Reply-To: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
Message-ID: <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>

> Renamed usage of 'category' for 'MemTag' cases.

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

 - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
 - fixed a missed test.
 - user-facing terms remained as 'category'
 - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25226/files
  - new: https://git.openjdk.org/jdk/pull/25226/files/05ca64d3..85cfb2b4

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

  Stats: 154841 lines in 2417 files changed: 93346 ins; 43674 del; 17821 mod
  Patch: https://git.openjdk.org/jdk/pull/25226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25226/head:pull/25226

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

From adinn at openjdk.org  Thu Jun 12 09:28:31 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 12 Jun 2025 09:28:31 GMT
Subject: RFR: 8355556: JVM crash because archived method handle intrinsics
 are not restored
In-Reply-To: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
References: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
Message-ID: <oQSFOwqUIoi-jIQuLPzx5Md-l6iYWJRpxkQnLBx4gMU=.20b073af-05fb-429b-a996-19ed2d8c27d0@github.com>

On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from `<clinit>`). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used.
> 
> In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline.
> 
> However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`.
> 
> Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25).
> 
> Thanks to @iwanowww for providing the fix!

Looks good.

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25766#pullrequestreview-2920252641

From duke at openjdk.org  Thu Jun 12 09:44:38 2025
From: duke at openjdk.org (duke)
Date: Thu, 12 Jun 2025 09:44:38 GMT
Subject: Withdrawn: 8349944: [JMH] sun.misc.UnsafeOps cannot access class
 jdk.internal.misc.Unsafe
In-Reply-To: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
References: <gqI8FO7CjXn1YZv-QNUq1gSaZ5GYGFDJrEzStF8wvTg=.3549d7c1-7f42-427a-abfd-d516a330929d@github.com>
Message-ID: <BCBZuN-yf7YnTv8196UNLJZj1J9t7eYwkms26iKcU3A=.e51db459-5611-40fc-bd81-18126940843b@github.com>

On Wed, 19 Feb 2025 07:53:15 GMT, Nicole Xu <duke at openjdk.org> wrote:

> The UnsafeOps JMH benchmark fails with the following error:
> 
>       ```
>       java.lang.IllegalAccessError: class org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot access class jdk.internal.misc.Unsafe (in module java.base) because module java.base does not export jdk.internal.misc to unnamed module @0x520a3426
>       ```
> 
> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than
> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744.
> 
> Note that even it will raise "proprietary API" warnings after this
> patch, it is acceptable because the relevant APIs are bound for removal
> for the integrity of the platform.

This pull request has been closed without being integrated.

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

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

From azafari at openjdk.org  Thu Jun 12 09:51:13 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Jun 2025 09:51:13 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v36]
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <EQUB5FBznpQ0S0gEt4CAtn93fYlE1hyAsjZQ85Dcnns=.60612d38-8939-4c10-99d0-64348b287fa1@github.com>

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit
 - invalid -> release.
 - old format comments are removed. Redundant tests are removed.
 - visualizations added. 1st try.
 - 'rd*' ->'rd_<Tag>_cs<n>'
 - Johan's comments.
 - some comments changed
 - fixed a missed change in test.
 - impl of new visualization in one test case, for getting feedback.
 - a merge glitch
 - ... and 29 more: https://git.openjdk.org/jdk/compare/3f0fef2c...cff9eeb4

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

Changes: https://git.openjdk.org/jdk/pull/24028/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=35
  Stats: 2113 lines in 6 files changed: 1845 ins; 81 del; 187 mod
  Patch: https://git.openjdk.org/jdk/pull/24028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028

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

From azafari at openjdk.org  Thu Jun 12 10:12:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Jun 2025 10:12:28 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <NSQwR1aBe6TLcTJKGgt2KL6RqFut8wYpnGwc0TH80ho=.7ff5e756-58e5-40de-a709-a9b41b36c4a8@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
 <NSQwR1aBe6TLcTJKGgt2KL6RqFut8wYpnGwc0TH80ho=.7ff5e756-58e5-40de-a709-a9b41b36c4a8@github.com>
Message-ID: <S-vx1sRZ7aOy8pHBqvzwcGjIk93nBooLtH_ToIoxJv8=.852077b6-80c0-4ac9-8a5f-9b586403f73b@github.com>

On Wed, 11 Jun 2025 08:55:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.
> 
> The special-case handling of CDS in NMT breaks abstractions and has caused a number of bugs. I'm worried that trying to workaround this special-case code makes the code even more susceptible for future bugs. So, therefore I'm interested to here about the planes you have to replace the NMT implementation with a tree. Isn't that going to remove the CDS special-case code and maybe be even solve this issue without the need for this fix? If not, feel free to ignore my comment.

In the new implementation of NMT with tree, there will be no special-case handling neither for CDS nor for any other memory types. Thanks for bringing this up.

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

PR Comment: https://git.openjdk.org/jdk/pull/25719#issuecomment-2965999494

From duke at openjdk.org  Thu Jun 12 11:28:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 11:28:35 GMT
Subject: Withdrawn: 8359110: Log accumulated GC and process CPU time upon VM
 exit
In-Reply-To: <dJ1wtrK-AzIRBUUEKh44iP4UsWuR8a2x0fRiPlVXr30=.6cbaa927-879e-4e0e-8bd8-ac5eed26ed52@github.com>
References: <dJ1wtrK-AzIRBUUEKh44iP4UsWuR8a2x0fRiPlVXr30=.6cbaa927-879e-4e0e-8bd8-ac5eed26ed52@github.com>
Message-ID: <24ib50kFQIUcwJ1BlMmQPdDDZI2wDSV0aHdR1_ratQE=.7c283605-89a7-491b-802b-86958b78e801@github.com>

On Tue, 10 Jun 2025 13:24:37 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Jun 12 12:32:46 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 12:32:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
Message-ID: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>

Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.


[1.500s][info ][gc] GC CPU cost: 1.75%


Additionally, detailed information may be retrieved with `-Xlog:gc=trace`


[1.500s][trace][gc] Process CPU time: 4.945370s
[1.500s][trace][gc] GC CPU time: 0.086382s
[1.500s][info ][gc] GC CPU cost: 1.75%

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

Commit messages:
 - Add elapsed_process_vtime
 - Log GC vtime on VM exit

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

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

From duke at openjdk.org  Thu Jun 12 12:32:46 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 12:32:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <Ue8SSC2EoS4-lc-PZsHEiMelSH2OjuYNcElXEvxuCzc=.3abc83a3-4706-4daf-9f93-7dd8b58d65fb@github.com>

On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

This PR is ready for review

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966510906

From mdoerr at openjdk.org  Thu Jun 12 12:53:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 12 Jun 2025 12:53:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v2]
In-Reply-To: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
Message-ID: <RxFOQmRFDnrOUb9TbplJl1e_EjK4cLwb-YDTJbywGVA=.be50fd6c-66f3-4874-90e5-5f3e56f5e851@github.com>

On Thu, 12 Jun 2025 02:01:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ... and stale code
>  - removed stale comment

I appreciate this PR. I like using the nmethod entry barrier and getting rid of not-entrant patching.
I have some change requests. In addition, we can get rid of much more code. I've put my proposal in a Commit: https://github.com/TheRealMDoerr/jdk/commit/4aed569dc353c254a2f4de2d387208a0a1323990
Please take a look!

src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 246:

> 244:   ConditionalMutexLocker ml(NMethodEntryBarrier_lock, !NMethodEntryBarrier_lock->owned_by_self(), Mutex::_no_safepoint_check_flag);
> 245:   int value = guard_value(nm) | not_entrant;
> 246:   set_guard_value(nm, value);

Same here.

src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 153:

> 151:         // Code cache unloading needs to know about on-stack nmethods. Arm the nmethods to get
> 152:         // mark_as_maybe_on_stack() callbacks when they are used again.
> 153:         _bs->arm(nm);

This breaks the Shenandoah build. `arm` is private.

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 116:

> 114:     value |= not_entrant;
> 115:   }
> 116:   set_guard_value(nm, value);

We can avoid redundant patching since we have the lock: Only update if the value is not already there. This happens quite often.

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

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2920990811
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142655962
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142641974
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142654627

From jsjolen at openjdk.org  Thu Jun 12 12:59:42 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 12 Jun 2025 12:59:42 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v36]
In-Reply-To: <EQUB5FBznpQ0S0gEt4CAtn93fYlE1hyAsjZQ85Dcnns=.60612d38-8939-4c10-99d0-64348b287fa1@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <EQUB5FBznpQ0S0gEt4CAtn93fYlE1hyAsjZQ85Dcnns=.60612d38-8939-4c10-99d0-64348b287fa1@github.com>
Message-ID: <oRp-YLTOUjUn4G88lh-YCUPP4yZH_WMTq2XS3qsSAv0=.c2e6c2de-d43a-432b-9dc9-38544f6bb431@github.com>

On Thu, 12 Jun 2025 09:51:13 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
>> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit
>  - invalid -> release.
>  - old format comments are removed. Redundant tests are removed.
>  - visualizations added. 1st try.
>  - 'rd*' ->'rd_<Tag>_cs<n>'
>  - Johan's comments.
>  - some comments changed
>  - fixed a missed change in test.
>  - impl of new visualization in one test case, for getting feedback.
>  - a merge glitch
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/3f0fef2c...cff9eeb4

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2921035723

From duke at openjdk.org  Thu Jun 12 13:35:51 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 13:35:51 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused bool
 - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/4eaa6e1f..dbf314c7

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

  Stats: 125 lines in 5 files changed: 101 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From duke at openjdk.org  Thu Jun 12 13:35:52 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 13:35:52 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <W1lPRJzuwttSAcdvB8sNM2G9o21W6hylXbx8TCxVxQk=.350f9e13-d53d-45cf-ae43-85f3b7b94473@github.com>

On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Refactored code per @kstefanj suggestions

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966727348

From tschatzl at openjdk.org  Thu Jun 12 13:42:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 13:42:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
Message-ID: <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>

On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused bool
>  - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966768048

From tschatzl at openjdk.org  Thu Jun 12 13:53:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 13:53:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
Message-ID: <Lr7C5g7ICViqGcC76awvF81P8Mm6nfQgN39LJxWesCk=.ad5369c4-a0c2-41fc-a8b7-735287440d4b@github.com>

On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused bool
>  - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1498:

> 1496:   _cr->threads_do(&cl);
> 1497:   _cm->threads_do(&cl);
> 1498:   _workers->threads_do(&cl);

There is `CollectedHeap::gc_threads_do()` (in general, for all collectors) to iterate over GC threads. Please use that. It may allow putting all that code into `CollectedHeap` used by all collectors too.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2921251009
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2142799289

From tschatzl at openjdk.org  Thu Jun 12 13:56:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 13:56:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
 <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>
Message-ID: <Nha1mhv7H0CgBo5AV7DWmFuPyfmkuapnhI-LThs4XPI=.af8c4bd2-fad0-4bdc-b0c2-593cb0553b56@github.com>

On Thu, 12 Jun 2025 13:39:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message.

Also reduces the amount of parsing needed in scripts etc. (I.e. three regexps vs. one). These three values are not really too much to digest for human readers.

Another problem seems to be the large amount of digits after the comma for the times; maybe use a different time scale (ms/us).

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966846342

From azafari at openjdk.org  Thu Jun 12 14:11:40 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Jun 2025 14:11:40 GMT
Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for
 reserve and commit operations [v29]
In-Reply-To: <J188imCQjQx2kRegwWq8ad82g8Zx5hnvY_tlaaG17ig=.8efa0640-a840-41c5-acee-3fd4d7bae69c@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
 <JNLjfTGhYLLTVFi_R7-8jFj1ZmycsfAv8S7OTzKNb3Y=.825a0441-f01a-446d-9cf5-88276b91030c@github.com>
 <J188imCQjQx2kRegwWq8ad82g8Zx5hnvY_tlaaG17ig=.8efa0640-a840-41c5-acee-3fd4d7bae69c@github.com>
Message-ID: <KEc9Yodirpl1NkeXr8uJOsFcQ1fffNesTHHb3axL2ak=.d451efda-9b3d-4764-a462-438fb165670d@github.com>

On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed a missed change in test.
>
> For this case:
> 
> 
>   {// Check committing into a reserved region inherits the call stacks
>     VMATree::RegionData call_stack_test(si_1, mtTest);
>     VMATree::RegionData call_stack_none(si_2, mtNone);
>     VMATree::RegionData call_stack_nmt(si_2, mtNMT);
>     Tree tree;
>     tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree
>     tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region
>     tree.print_timeline_on();
>   }
> 
> 
> I know that we are passing `true` for `use_tag_inplace` here,  but it just does not feel right to get this:
> 
>  ```
>            1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC....................
> Legend:
> A - Test (reserved)
> b - Test (committed)
> C - Test (reserved)
> . - None (free/released)
> 
> 
> I was expecting this:
> 
>  ```
>            1         2         3         4         5         6
> 0123456789012345678901234567890123456789012345678901234567890123456789
> AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC....................
> Legend:
> A - Test (reserved)
> b - Native Memory Tracking (committed)
> C - Test (reserved)
> . - None (free/released)
> 
> 
> I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter?

Thank you @gerard-ziemski and @jdksjolen for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2966962304

From kvn at openjdk.org  Thu Jun 12 14:29:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Jun 2025 14:29:40 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be used
 with graal jit
Message-ID: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>

We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.

Record used compiler type in archive and check it when using archive.

Tested with tiers which use Graal.

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

Commit messages:
 - 8358738: AOT cache created without graal jit should not be used with graal jit

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

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

From tschatzl at openjdk.org  Thu Jun 12 14:33:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 14:33:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
Message-ID: <Bb8ks2_3B7h_4zra7NehB-7Hv3bf_LyfWfXEiwu2MdY=.19ca851d-8520-4a12-8bbd-cefee760f8c7@github.com>

On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused bool
>  - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

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

> 232:       cost = 100 * gc_vtime / process_vtime;
> 233:     }
> 234:     log_info(gc)("GC CPU cost: %2.2f%%", cost);

I would prefer "usage" instead of "cost". The former seems to be more neutral.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2142928706

From duke at openjdk.org  Thu Jun 12 14:40:27 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 14:40:27 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <Nha1mhv7H0CgBo5AV7DWmFuPyfmkuapnhI-LThs4XPI=.af8c4bd2-fad0-4bdc-b0c2-593cb0553b56@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
 <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>
 <Nha1mhv7H0CgBo5AV7DWmFuPyfmkuapnhI-LThs4XPI=.af8c4bd2-fad0-4bdc-b0c2-593cb0553b56@github.com>
Message-ID: <H_hXvJ5PaF7KWK36HtkHDZ_4He65ahwp7l5Fl6GcC64=.ff46150e-31ac-4c8a-9ac5-2ea5883e68e9@github.com>

On Thu, 12 Jun 2025 13:53:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message.

Thank you for sharing your concern. I'm OK with putting the CPU times currently in trace into the `exit` tag but I strongly believe we should keep the 
`[1.500s][info ][gc] GC CPU cost: 1.75%` as is. I discussed the `exit` tag option with @kstefanj but I thought that hiding the nominal values in the trace level would suffice, but can change that if we think that is preferable. I think that exposing this number at `-Xlog:gc`-level may be an important tool for users to understand that they may running with too small heap. We expose a lot of way for users to understand the memory footprint, but not too much about the CPU footprint. Putting this number behind `exit` may increase the risk that the typical user will not discover it. Adding one line at the end while at the same time logging information about each GC cycle does not clutter the message log IMO.

Another option could be to not log the nominal values at all. If one have the percentage and measure process CPU time with e.g. perf one could calculate it yourself anyways. What do you think about that?

> 
> Another problem seems to be the large amount of digits after the comma for the times; maybe use a different time scale (ms/us).

Thanks for pointing that out, I will fix that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2967112195

From azafari at openjdk.org  Thu Jun 12 14:49:43 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 12 Jun 2025 14:49:43 GMT
Subject: Integrated: 8351661: NMT: VMATree should support separate call-stacks
 for reserve and commit operations
In-Reply-To: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
References: <s3J3Ag7U19FfJRhnjdqthKc5VTXFNFdiOUPsnQ9r_aI=.050efebc-674b-4cf2-99a5-9b277fabde79@github.com>
Message-ID: <CL7t1tbTedJ3kX__YhuIfmVFYHdP1gJo2igWhWvdky4=.32fe4cf9-dd1a-46c0-86c3-b28755950235@github.com>

On Thu, 13 Mar 2025 10:20:49 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations.
> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region.

This pull request has now been integrated.

Changeset: fae9c7a3
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fae9c7a3f04f85aeb9e03c5c9c15fda6405ee989
Stats:     2113 lines in 6 files changed: 1845 ins; 81 del; 187 mod

8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations

Reviewed-by: gziemski, jsjolen

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

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

From duke at openjdk.org  Thu Jun 12 15:25:08 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 15:25:08 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
 - Remove unnecessary assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/dbf314c7..aeb4ad04

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

  Stats: 84 lines in 9 files changed: 17 ins; 62 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From duke at openjdk.org  Thu Jun 12 15:31:31 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 15:31:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
Message-ID: <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>

On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>  - Remove unnecessary assert

FYI; I removed nominal logging

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2967302296

From gziemski at openjdk.org  Thu Jun 12 15:41:39 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Jun 2025 15:41:39 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v3]
In-Reply-To: <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
Message-ID: <WGhnySZn42u6A7xJZe5ptuCrNPLs-KiwJB21FwRuQj8=.f2b830c1-5b4c-4e2c-8cd3-2a47dd4cb4be@github.com>

On Thu, 12 Jun 2025 09:23:24 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
>  - fixed a missed test.
>  - user-facing terms remained as 'category'
>  - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

There is still a problem with GHA test, but I think this is MACH5, so when that passes and maybe MACH tier1-3, we're good.

Thanks!

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25226#pullrequestreview-2921731560

From gziemski at openjdk.org  Thu Jun 12 15:42:34 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 12 Jun 2025 15:42:34 GMT
Subject: RFR: 8356228: NMT does not record reserved memory base address
 correctly
In-Reply-To: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
References: <9cxOcodCQ6C9C3aco0ciPnjWrArvGpk-RlKkcTOD33o=.7f81a4e5-a7ef-48f7-bb50-7553a6e8b8c7@github.com>
Message-ID: <cJFuuV6dLrW1adaLfz-QysEjKw8XrPCTD_JWYchuKDQ=.1b9faa8c-e0f1-4901-afa7-e0d660f1b4fc@github.com>

On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The problem here stems from the following facts:
> 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. 
> 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.
> 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above.
> 
> So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue).
> 
> Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings.
> 
> Tests:
> linux-x64: runtime/NMT jtreg tests passed
> linux-aarch64: tier1 to tier3 passed

Do we need to bother with this fix then? Should we wait for the VMATree and just verify?

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

PR Comment: https://git.openjdk.org/jdk/pull/25719#issuecomment-2967341763

From dlong at openjdk.org  Thu Jun 12 19:54:45 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 12 Jun 2025 19:54:45 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v3]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <cXYQYfOLGgpJUJXn_mfH0sFsyhUHzUlOa7kCZD5sA4A=.537b7c84-4fb4-4c59-b125-d876a50449cf@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with six additional commits since the last revision:

 - more cleanup
 - more TheRealMDoerr suggestions
 - TheRealMDoerr suggestions
 - remove trailing space
 - Fix Shenandoah build
 - more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/0780d156..0950fc5e

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

  Stats: 330 lines in 25 files changed: 10 ins; 304 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764

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

From dlong at openjdk.org  Thu Jun 12 19:57:28 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 12 Jun 2025 19:57:28 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v2]
In-Reply-To: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
Message-ID: <QmK2HAht4vFeChrAEcBdGS0s3eZFRS2VUPs34gcNO10=.f6aa2937-81e6-482c-9ef2-d83859fe2e39@github.com>

On Thu, 12 Jun 2025 02:01:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ... and stale code
>  - removed stale comment

Thanks @TheRealMDoer for the suggestions, I incorporated all of them, however for shenandoahCodeRoots.cpp I decided to make arm() public, so the caller code doesn't need to know about the magic value 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2967999465

From mdoerr at openjdk.org  Thu Jun 12 20:08:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 12 Jun 2025 20:08:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v2]
In-Reply-To: <QmK2HAht4vFeChrAEcBdGS0s3eZFRS2VUPs34gcNO10=.f6aa2937-81e6-482c-9ef2-d83859fe2e39@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
 <QmK2HAht4vFeChrAEcBdGS0s3eZFRS2VUPs34gcNO10=.f6aa2937-81e6-482c-9ef2-d83859fe2e39@github.com>
Message-ID: <15r53QUpAANeu3oucJCrmg3BOqTksEQK24cppfHjQow=.b5848d6f-0bfe-43ce-a4d8-29d57d91e873@github.com>

On Thu, 12 Jun 2025 19:54:28 GMT, Dean Long <dlong at openjdk.org> wrote:

> Thanks @TheRealMDoer for the suggestions, I incorporated all of them, however for shenandoahCodeRoots.cpp I decided to make arm() public, so the caller code doesn't need to know about the magic value 0.

Excellent! Thank you! I'll take another look over it and run tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2968024418

From iklam at openjdk.org  Thu Jun 12 21:17:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 12 Jun 2025 21:17:28 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit
In-Reply-To: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
Message-ID: <jf6Zi5-QzZkj7LvKRj3JO65Mrldp2yi5_N0GiP6Gd_0=.f2b53acc-eb9d-4302-93de-4f41a65eceb7@github.com>

On Thu, 12 Jun 2025 14:24:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.
> 
> Record used compiler type in archive and check it when using archive.
> 
> Tested with tiers which use Graal.

Looks good. Suggestions for code clean up and inline comments.

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

> 1954:   } else if (CompilerConfig::is_c1_enabled()) {
> 1955:     compiler_type = CompilerType::compiler_c1;
> 1956:   }

This block of code should be put in a method in CompilerConfig to avoid duplication.

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

> 1956:   }
> 1957:   CompilerType archive_compiler_type = CompilerType(_compiler_type);
> 1958:   // JVMCI compiler loads additional jdk.internal.vm.ci module,

Since [JDK-8345826](https://github.com/openjdk/jdk/commit/81536830ed096005c4f09ab446238ce50989cea9), the jdk.internal.vm.ci module is no longer added when libgraal is used. I think you can remove this line from the comments. Incompatible module options are checked elsewhere in modules.cpp.

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2922663464
PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2143663959
PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2143668954

From kvn at openjdk.org  Thu Jun 12 22:02:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Jun 2025 22:02:43 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
Message-ID: <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>

> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.
> 
> Record used compiler type in archive and check it when using archive.
> 
> Tested with tiers which use Graal.

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

  Address comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25782/files
  - new: https://git.openjdk.org/jdk/pull/25782/files/3a8c8e5b..20c80da8

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

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

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

From kvn at openjdk.org  Thu Jun 12 22:02:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 12 Jun 2025 22:02:46 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <jf6Zi5-QzZkj7LvKRj3JO65Mrldp2yi5_N0GiP6Gd_0=.f2b53acc-eb9d-4302-93de-4f41a65eceb7@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
 <jf6Zi5-QzZkj7LvKRj3JO65Mrldp2yi5_N0GiP6Gd_0=.f2b53acc-eb9d-4302-93de-4f41a65eceb7@github.com>
Message-ID: <0GS7REZue3eNAQ7om2zJowRf1aH9gPgPAAGJ3V-4kg4=.08e18105-edb6-4465-98a2-d8422b99174e@github.com>

On Thu, 12 Jun 2025 21:14:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> Looks good. Suggestions for code clean up and inline comments.

Thank you, @iklam, for review. I addressed your comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/25782#issuecomment-2968275950

From iklam at openjdk.org  Thu Jun 12 22:23:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 12 Jun 2025 22:23:27 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
 <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
Message-ID: <MFm-UA75mwkH_yNpiiJ8L2LMN0ENsBDe7NARMzoGSfQ=.43bce548-3154-4bab-be93-509428b7d99a@github.com>

On Thu, 12 Jun 2025 22:02:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.
>> 
>> Record used compiler type in archive and check it when using archive.
>> 
>> Tested with tiers which use Graal.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2922796507

From vlivanov at openjdk.org  Fri Jun 13 04:48:28 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 13 Jun 2025 04:48:28 GMT
Subject: RFR: 8355556: JVM crash because archived method handle intrinsics
 are not restored
In-Reply-To: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
References: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
Message-ID: <HV4PUJnvXTMvnFABO5LQogK1qN3EWD-gWNO0_n5a-dw=.c4ba77a1-1289-4db0-ac83-0fc929ccc91d@github.com>

On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from `<clinit>`). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used.
> 
> In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline.
> 
> However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`.
> 
> Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25).
> 
> Thanks to @iwanowww for providing the fix!

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25766#pullrequestreview-2923402355

From shade at openjdk.org  Fri Jun 13 09:27:27 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 09:27:27 GMT
Subject: RFR: 8355556: JVM crash because archived method handle intrinsics
 are not restored
In-Reply-To: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
References: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
Message-ID: <fWisHp-q9Oo418aN9DlcJVxTtxKgQdM-SAUWpZyb4Jk=.6e9097c1-5d84-4912-8de6-2e8a569d2f1e@github.com>

On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from `<clinit>`). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used.
> 
> In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline.
> 
> However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`.
> 
> Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25).
> 
> Thanks to @iwanowww for providing the fix!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25766#pullrequestreview-2924017465

From shade at openjdk.org  Fri Jun 13 09:50:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 09:50:28 GMT
Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code
In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
Message-ID: <SCpGf_BHThMgs3cLpagurgXsdb51qqjxDQmx0ROQDME=.8a4de650-1f91-4222-badb-e9201d133ba6@github.com>

On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function.

Looks fine to me, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25722#pullrequestreview-2924115292

From azafari at openjdk.org  Fri Jun 13 10:09:34 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 13 Jun 2025 10:09:34 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v3]
In-Reply-To: <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
Message-ID: <4oPITwdrPA1B0KKbkl6MSuyo-yjgje5yK3lQc40tEJ0=.9567be7c-2a8e-41ee-93b9-557a7cdbe750@github.com>

On Thu, 12 Jun 2025 09:23:24 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
>  - fixed a missed test.
>  - user-facing terms remained as 'category'
>  - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

GHA test failure is due to disable to load/build JTREG. not related to this change.
Mach5 tiers 1-3 passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2969829446

From tschatzl at openjdk.org  Fri Jun 13 10:21:22 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Jun 2025 10:21:22 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
Message-ID: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>

On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>  - Remove unnecessary assert

The string deduplication thread, which is to some degree also a GC helper thread, is not considered here. Not sure if it should, slightly tending to add it.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 164:

> 162: 
> 163: void ParallelScavengeHeap::stop() {
> 164:   log_gc_vtime();

I think in OO-fashion, instead of adding the `log_gc_vtime()` call everywhere, it should be called in the super-class method and the others defer to it.

src/hotspot/share/gc/serial/serialHeap.cpp line 153:

> 151: 
> 152: double SerialHeap::elapsed_gc_vtime() {
> 153:   return (double) Universe::heap()->vm_vtime() / NANOSECS_PER_SEC;

This specialization does not seem necessary. Serial GC also has `gc_threads_do()`, which does nothing, as expected.

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

> 237:     double gc_vtime = elapsed_gc_vtime();
> 238: 
> 239:     if (process_vtime == -1 || gc_vtime == -1) return;

I would prefer to add braces to avoid overlooking this return statement in this context.

src/hotspot/share/gc/z/zCollectedHeap.cpp line 123:

> 121:       Atomic::add(&_vtime, os::thread_cpu_time(thread));
> 122:     }
> 123:   }

Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete.
The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result.

src/hotspot/share/gc/z/zCollectedHeap.cpp line 130:

> 128:   ZVCPUThreadClosure cl;
> 129:   gc_threads_do(&cl);
> 130:   return (double)(cl.vtime() + Universe::heap()->vm_vtime()) / NANOSECS_PER_SEC;

Taking the comment about missing ZGC threads into account, it seems `elapsed_gc_vtime()` can be implemented without any need of overrides in `CollectedHeap`.

src/hotspot/share/runtime/vmOperation.hpp line 171:

> 169:   virtual bool evaluate_at_safepoint() const { return true; }
> 170: 
> 171:   virtual bool operation_is_gc() const { return false; }

This method seems to be never read anywhere. Is this correct?

src/hotspot/share/runtime/vmThread.cpp line 282:

> 280: 
> 281:     EventExecuteVMOperation event;
> 282:     VTimeScope vTimeScope(this);

Not sure if it is the intent of this change to put all VM operations into the "GC" bucket, particularly because of the log message indicating so. I would prefer if really only GC operations would be counted here; `VTimeScope` does not use `operation_is_gc()` either, so I am not sure about the intention here.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2921860873
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144665083
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144669651
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2143164063
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144687225
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144693093
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144695741
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2143169291

From tschatzl at openjdk.org  Fri Jun 13 10:28:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Jun 2025 10:28:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
Message-ID: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>

On Thu, 12 Jun 2025 15:28:25 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> FYI; I removed nominal logging

Okay, these can be re-added if needed. I also see your point about that this is just one message at VM exit, so we do not need the "exit" label. I would prefer if it had, so I won't insist on it given that others do not mind either. It would fit the purpose of the `exit` label perfectly though.

The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time.

I.e. if there is need to monitor it, only printing it at the end seems insufficient, as that kind of monitoring is continuous. It helps benchmarking though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969876711

From duke at openjdk.org  Fri Jun 13 10:50:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 10:50:38 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
 <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>
Message-ID: <UmjavZ2LxSQe-jy2OqaVOD5N_TT_tuZsWDb33Z00EJM=.9d37a8cd-d41e-4769-8f11-f372fcb71eeb@github.com>

On Fri, 13 Jun 2025 10:25:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time.

I disagree, it is equally important as reporting pre and post compaction heap usage like we do now with -Xlog:gc. Users who are not experts in GC may underestimate the CPU cost of GC at a given heap max. Even experts in academia tend to run with too small heap. I maintain my position that adding it at the end is crucial.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969922344

From duke at openjdk.org  Fri Jun 13 10:50:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 10:50:39 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
Message-ID: <1rWshKBN5OE7MVryOUpeH2aOo4cbVLaZpbj7H8WCr9Q=.201e4fb8-50b6-466c-b863-1081bf034e9e@github.com>

On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>  - Remove unnecessary assert

Additionally, if we want to we can also add capabilities to track it continuously with JFR and/or MXBeans. But that may introduce a performance penalty as sampling may not be free so I want to still keep logging it at the end as a base case.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969931470

From tschatzl at openjdk.org  Fri Jun 13 11:21:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Jun 2025 11:21:30 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <UmjavZ2LxSQe-jy2OqaVOD5N_TT_tuZsWDb33Z00EJM=.9d37a8cd-d41e-4769-8f11-f372fcb71eeb@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
 <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>
 <UmjavZ2LxSQe-jy2OqaVOD5N_TT_tuZsWDb33Z00EJM=.9d37a8cd-d41e-4769-8f11-f372fcb71eeb@github.com>
Message-ID: <_rAjyUhvY8figCunG0eUdqNQyZoRTnJz-RUTkv8KJR0=.32329766-3198-4b9f-8399-34ffd90a9dce@github.com>

On Fri, 13 Jun 2025 10:45:15 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> > The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time.
> 
> I disagree, it is equally important as reporting pre and post compaction heap usage like we do now with -Xlog:gc. Users who are not experts in GC may underestimate the CPU cost of GC at a given heap max. Even experts in academia tend to run with too small heap. I maintain my position that adding it at the end is crucial.

I do not disagree about the usefulness of the message (it is - I even liked the nominal output), I only somewhat disagree about making a message purposefully printed at VM exit, to state the cpu usage at exit, not having the "exit" label.
(Regarding the nominal logging: my points were that I thought it was a waste to use three messages, and the presentation format)

We do not need to agree on everything 100%.

> Additionally, if we want to we can also add capabilities to track it continuously with JFR and/or MXBeans. But that may introduce a performance penalty as sampling may not be free so I want to still keep logging it at the end as a base case.

That's fine.

Fwiw, there has even been interest from me (https://bugs.openjdk.org/browse/JDK-8349476) about regularly printing these statistics at even higher detail.

However as far as I understand, there are jstat/perf counters already for that, and they are in use (in industry). There is the jcmd command (even before that) that prints per-thread cpu usage for some time now - one could filter out the interesting threads manually...

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2970035555

From shade at openjdk.org  Fri Jun 13 11:37:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 11:37:43 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
Message-ID: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>

A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".

I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `runtime/cds`

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

Commit messages:
 - Fix

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

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

From mdoerr at openjdk.org  Fri Jun 13 11:57:35 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Jun 2025 11:57:35 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v3]
In-Reply-To: <cXYQYfOLGgpJUJXn_mfH0sFsyhUHzUlOa7kCZD5sA4A=.537b7c84-4fb4-4c59-b125-d876a50449cf@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <cXYQYfOLGgpJUJXn_mfH0sFsyhUHzUlOa7kCZD5sA4A=.537b7c84-4fb4-4c59-b125-d876a50449cf@github.com>
Message-ID: <0jwlIB4VebRh3dORUSPdbmmE4YWS1Z6t_Ax8ni0_tpg=.f9dd6d19-1c97-43d7-acb2-ad575b61d433@github.com>

On Thu, 12 Jun 2025 19:54:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - Fix Shenandoah build
>  - more cleanup

LGTM, now. I think `is_sigill_not_entrant` should also be removed completely: https://github.com/TheRealMDoerr/jdk/commit/f61f54a40ad0b952ba8c0a668675b3f315f83a95
I've run tests on some platforms, but will run on more.
@offamitkumar, @RealFYang, @bulasevich: You may also want to check your platforms.
@fisk: You may want to take a look at the nmethod entry barrier changes.

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

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2924552667

From duke at openjdk.org  Fri Jun 13 12:02:40 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 12:02:40 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <Nu5fmsTJbdSRmLg6Scl9kwD8UNAlskBXA02YRSCo06U=.ae87dac8-0969-41a2-bf30-a9b1027325cc@github.com>

On Thu, 12 Jun 2025 16:21:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>>  - Remove unnecessary assert
>
> src/hotspot/share/runtime/vmThread.cpp line 282:
> 
>> 280: 
>> 281:     EventExecuteVMOperation event;
>> 282:     VTimeScope vTimeScope(this);
> 
> Not sure if it is the intent of this change to put all VM operations into the "GC" bucket, particularly because of the log message indicating so. I would prefer if really only GC operations would be counted here; `VTimeScope` does not use `operation_is_gc()` either, so I am not sure about the intention here.

Ouch, thanks for catching this! My intention to use `operation_is_gc()` got lost during code refactoring. `VTimeScope` are supposed to call `os::thread_cpu_time` minimum amount of times needed and update VM cpu time tracking used by hsperf counters and the CPU time tracking this patch adds for GC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144945218

From duke at openjdk.org  Fri Jun 13 12:54:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 12:54:34 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>

On Fri, 13 Jun 2025 10:04:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>>  - Remove unnecessary assert
>
> src/hotspot/share/gc/z/zCollectedHeap.cpp line 123:
> 
>> 121:       Atomic::add(&_vtime, os::thread_cpu_time(thread));
>> 122:     }
>> 123:   }
> 
> Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete.
> The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result.

I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in:


ZDirector
ZDriverMajor
ZDriverMinor
ZStat
ZUncommitter#0
ZWorkerYoung#0
ZWorkerYoung#1
ZWorkerYoung#2
ZWorkerYoung#3
ZWorkerOld#0
ZWorkerOld#1
ZWorkerOld#2
ZWorkerOld#3


This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145029576

From ayang at openjdk.org  Fri Jun 13 13:07:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 13 Jun 2025 13:07:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
 <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
Message-ID: <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>

On Fri, 13 Jun 2025 12:51:40 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/z/zCollectedHeap.cpp line 123:
>> 
>>> 121:       Atomic::add(&_vtime, os::thread_cpu_time(thread));
>>> 122:     }
>>> 123:   }
>> 
>> Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete.
>> The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result.
>
> I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in:
> 
> 
> ZDirector
> ZDriverMajor
> ZDriverMinor
> ZStat
> ZUncommitter#0
> ZWorkerYoung#0
> ZWorkerYoung#1
> ZWorkerYoung#2
> ZWorkerYoung#3
> ZWorkerOld#0
> ZWorkerOld#1
> ZWorkerOld#2
> ZWorkerOld#3
> 
> 
> This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work.

Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145051424

From kvn at openjdk.org  Fri Jun 13 13:30:33 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 13:30:33 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <O3uN954QqE3DsWqwWqr9rnEtMcEGD3aayquY9LPylwc=.cc1dd87c-301d-4698-87c9-58e5ddabf73f@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.

Why do you need to change it then?

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970396352

From duke at openjdk.org  Fri Jun 13 14:40:30 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 14:40:30 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <TBuVnwupYtMrRKHMazEXgmCK-9Bwr2qKUSJpHSX1l8U=.4071ab22-4b05-4cb0-9267-6a743898e7d6@github.com>

On Fri, 13 Jun 2025 09:55:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>>  - Remove unnecessary assert
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 164:
> 
>> 162: 
>> 163: void ParallelScavengeHeap::stop() {
>> 164:   log_gc_vtime();
> 
> I think in OO-fashion, instead of adding the `log_gc_vtime()` call everywhere, it should be called in the super-class method and the others defer to it.

Just wanna double-check that I understood your suggestion. Are you suggesting that we should rather add calls to `CollectedHeap::stop()` at the beginning of the specialization?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145239880

From ccheung at openjdk.org  Fri Jun 13 15:18:43 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 13 Jun 2025 15:18:43 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
 <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
Message-ID: <GXfo6bTwUK_X-Qms-CANssBwx7edNOHxNW-0mtpKlEE=.9a4394d8-8a82-48ee-bd01-d7e7d754398c@github.com>

On Thu, 12 Jun 2025 22:02:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.
>> 
>> Record used compiler type in archive and check it when using archive.
>> 
>> Tested with tiers which use Graal.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Looks good. I have one question.

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

> 1950:                             (compiler_type == CompilerType::compiler_none);
> 1951:   if (!intepreter_is_used &&
> 1952:       jvmci_compiler_is_enabled != (archive_compiler_type == CompilerType::compiler_jvmci)) {

Does it mean we allow different compiler type during assembly phase and production phase? e.g. assembly phase using c1, production phase using c2?

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

PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2925191023
PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2145312369

From shade at openjdk.org  Fri Jun 13 15:52:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 15:52:35 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <O3uN954QqE3DsWqwWqr9rnEtMcEGD3aayquY9LPylwc=.cc1dd87c-301d-4698-87c9-58e5ddabf73f@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <O3uN954QqE3DsWqwWqr9rnEtMcEGD3aayquY9LPylwc=.cc1dd87c-301d-4698-87c9-58e5ddabf73f@github.com>
Message-ID: <sLmz6nUr1znth3V7pf_tF4FCac4CSfhGPOdo3gbqukY=.08090885-4811-42d8-99fb-889e54cc154c@github.com>

On Fri, 13 Jun 2025 13:27:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Why do you need to change it then?

Because in JDK 25, I can see people experimenting with this option, or even turning it on. It is inconvenient to turn on diagnostic option for production use.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970804695

From kvn at openjdk.org  Fri Jun 13 15:53:31 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 15:53:31 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <GXfo6bTwUK_X-Qms-CANssBwx7edNOHxNW-0mtpKlEE=.9a4394d8-8a82-48ee-bd01-d7e7d754398c@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
 <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
 <GXfo6bTwUK_X-Qms-CANssBwx7edNOHxNW-0mtpKlEE=.9a4394d8-8a82-48ee-bd01-d7e7d754398c@github.com>
Message-ID: <gRko9KzfXMDxhKyx1jjFxTCyWS8D2Uo3F44RVgiq2Fw=.380c83bf-cd44-4272-9887-1b766bcdd333@github.com>

On Fri, 13 Jun 2025 15:15:26 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comments
>
> Looks good. I have one question.

Thank you @calvinccheung for review.

> src/hotspot/share/cds/filemap.cpp line 1952:
> 
>> 1950:                             (compiler_type == CompilerType::compiler_none);
>> 1951:   if (!intepreter_is_used &&
>> 1952:       jvmci_compiler_is_enabled != (archive_compiler_type == CompilerType::compiler_jvmci)) {
> 
> Does it mean we allow different compiler type during assembly phase and production phase? e.g. assembly phase using c1, production phase using c2?

Yes. By default we have both with TieredCompilation. But we can switch it off (C2 only) or use TieredStopAtLevel=1 (C1 only). When they are mixed (one phase use only C1 and an other C2) we simple will not load AOT nmethods because corresponding compiler's runtime stubs will not be created so we can't use AOT nmethods referencing these stubs. But nothing in code generation or methods profiling prevents us from mixing them.

On other hand Graal creates different profiling data and additional nmethod's metadata. So we can't use such data with other JIT compilers.

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

PR Comment: https://git.openjdk.org/jdk/pull/25782#issuecomment-2970809429
PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2145398615

From kvn at openjdk.org  Fri Jun 13 16:00:29 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 16:00:29 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <Z0zYFP_-ZyUeKBTYodMVbipuneMLQszo9qOntED_CbM=.c52ed628-f4e2-4326-a053-71bcdb115aab@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

When AOT code caching is integrated do you plan to move it back to diagnostic? As you said - it does not make sense to touch it.

But then people will be confused if in JDK 25 and 26 they are different.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970826963

From duke at openjdk.org  Fri Jun 13 16:01:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 16:01:35 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
 <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
 <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>
Message-ID: <vLqfVwJ1I5pqpacCN6hRdNUmmz8tyoRXhE62ToVZ83g=.9b8731a4-1410-4103-b466-56f98dff62b7@github.com>

On Fri, 13 Jun 2025 13:04:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in:
>> 
>> 
>> ZDirector
>> ZDriverMajor
>> ZDriverMinor
>> ZStat
>> ZUncommitter#0
>> ZWorkerYoung#0
>> ZWorkerYoung#1
>> ZWorkerYoung#2
>> ZWorkerYoung#3
>> ZWorkerOld#0
>> ZWorkerOld#1
>> ZWorkerOld#2
>> ZWorkerOld#3
>> 
>> 
>> This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work.
>
> Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi.

FWIW; I confirmed with @stefank that `_runtime_workers` shoud not be accounted for GC CPU time for ZGC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145419752

From iklam at openjdk.org  Fri Jun 13 16:15:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 13 Jun 2025 16:15:00 GMT
Subject: RFR: 8355556: JVM crash because archived method handle intrinsics
 are not restored
In-Reply-To: <oQSFOwqUIoi-jIQuLPzx5Md-l6iYWJRpxkQnLBx4gMU=.20b073af-05fb-429b-a996-19ed2d8c27d0@github.com>
References: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
 <oQSFOwqUIoi-jIQuLPzx5Md-l6iYWJRpxkQnLBx4gMU=.20b073af-05fb-429b-a996-19ed2d8c27d0@github.com>
Message-ID: <pkD9Vaq1fa8EAr773nHYIYwcj2jBoHwsVzwbWPzSfOk=.290d4286-3019-4017-ad74-67fdd5d47f08@github.com>

On Thu, 12 Jun 2025 09:25:50 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from `<clinit>`). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used.
>> 
>> In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline.
>> 
>> However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`.
>> 
>> Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25).
>> 
>> Thanks to @iwanowww for providing the fix!
>
> Looks good.

Thanks @adinn @iwanowww @shipilev for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25766#issuecomment-2970861716

From iklam at openjdk.org  Fri Jun 13 16:15:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 13 Jun 2025 16:15:00 GMT
Subject: Integrated: 8355556: JVM crash because archived method handle
 intrinsics are not restored
In-Reply-To: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
References: <AJfRNDcw-pXOvHhD62oNao_Q1QijRHtD3w_eJRRVUrI=.8be6348a-3198-4a74-810e-83a3cdd74ecb@github.com>
Message-ID: <hv-ATfU87ayvnVQz3QIFwkDzJptMtMQ1OAHot8MJkiE=.e2f447e9-3559-4420-be0c-1629116c31a1@github.com>

On Thu, 12 Jun 2025 02:48:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()` can execute Java bytecodes (from `<clinit>`). If one of these bytecodes is an AOT-resolved `invokedynamic`, it may be dispatched using an archived method handle intrinsic. Therefore, we should call `SystemDictionary::restore_archived_method_handle_intrinsics()` first to make sure that the method handle intrinsics are ready to be used.
> 
> In the JDK mainline, we only execute a very limited set of Java methods which happens to not include any `invokedynamic` bytecodes. That's why this bug has not been found in the mainline.
> 
> However, in the Leyden repo, we have other optimizations, such as archived ProtectionDomains, which will cause `invokedynamic` bytecodes to be executed inside `AOTLinkedClassBulkLoader::finish_loading_javabase_classes()`.
> 
> Since this is a potential issue even for the JDK mainline, we should fix it (and also backport to JDK 25).
> 
> Thanks to @iwanowww for providing the fix!

This pull request has now been integrated.

Changeset: 366650a4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8355556: JVM crash because archived method handle intrinsics are not restored

Reviewed-by: adinn, vlivanov, shade

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

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

From ccheung at openjdk.org  Fri Jun 13 16:16:34 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 13 Jun 2025 16:16:34 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
 <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
Message-ID: <MagZQRlir20e3_1Vsvrtu-aiAW9YN0D6n_ALb6DBI_4=.beb34566-fe96-4696-99d1-12fa6790a033@github.com>

On Thu, 12 Jun 2025 22:02:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.
>> 
>> Record used compiler type in archive and check it when using archive.
>> 
>> Tested with tiers which use Graal.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments

Marked as reviewed by ccheung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25782#pullrequestreview-2925397901

From ccheung at openjdk.org  Fri Jun 13 16:16:35 2025
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 13 Jun 2025 16:16:35 GMT
Subject: RFR: 8358738: AOT cache created without graal jit should not be
 used with graal jit [v2]
In-Reply-To: <gRko9KzfXMDxhKyx1jjFxTCyWS8D2Uo3F44RVgiq2Fw=.380c83bf-cd44-4272-9887-1b766bcdd333@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
 <n9f_lXg8AWndAnYMsUz29PF913EOX0wH5JKALOT4CUw=.804a819d-a103-48b4-a168-e6762cd6148b@github.com>
 <GXfo6bTwUK_X-Qms-CANssBwx7edNOHxNW-0mtpKlEE=.9a4394d8-8a82-48ee-bd01-d7e7d754398c@github.com>
 <gRko9KzfXMDxhKyx1jjFxTCyWS8D2Uo3F44RVgiq2Fw=.380c83bf-cd44-4272-9887-1b766bcdd333@github.com>
Message-ID: <Dwb8Qo4AcNelHcybpzXacSnEFotO3Z5Gjsq01JrSVIs=.8c788981-2661-4a64-a739-fd0b3dfcd419@github.com>

On Fri, 13 Jun 2025 15:50:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/cds/filemap.cpp line 1952:
>> 
>>> 1950:                             (compiler_type == CompilerType::compiler_none);
>>> 1951:   if (!intepreter_is_used &&
>>> 1952:       jvmci_compiler_is_enabled != (archive_compiler_type == CompilerType::compiler_jvmci)) {
>> 
>> Does it mean we allow different compiler type during assembly phase and production phase? e.g. assembly phase using c1, production phase using c2?
>
> Yes. By default we have both with TieredCompilation. But we can switch it off (C2 only) or use TieredStopAtLevel=1 (C1 only). When they are mixed (one phase use only C1 and an other C2) we simple will not load AOT nmethods because corresponding compiler's runtime stubs will not be created so we can't use AOT nmethods referencing these stubs. But nothing in code generation or methods profiling prevents us from mixing them.
> 
> On other hand Graal creates different profiling data and additional nmethod's metadata. So we can't use such data with other JIT compilers.

Thanks for the explanations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25782#discussion_r2145446449

From kvn at openjdk.org  Fri Jun 13 16:22:43 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 16:22:43 GMT
Subject: Integrated: 8358738: AOT cache created without graal jit should not be
 used with graal jit
In-Reply-To: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
References: <MaC5e4iCgkAhP0UaF26ongb_hpo9yfKcnvBwmRZFdxc=.f7f59c46-8f8a-45bd-9362-95297fb27ca0@github.com>
Message-ID: <qbrIPWMyJqhfSfrqdrUocpkJ2XfHkXv8BF4M1dUa2To=.3388fee7-86ee-488d-8f74-7b9c4fac9e76@github.com>

On Thu, 12 Jun 2025 14:24:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> We can't mix generation and usage of AOT cache when different JIT compilers are used (C2 vs Graal). Graal does different profiling settings and generate different code. We can only allow mix with Interpreter.
> 
> Record used compiler type in archive and check it when using archive.
> 
> Tested with tiers which use Graal.

This pull request has now been integrated.

Changeset: 12a0dd03
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12a0dd03b89cc3bf7f9d32b17eb41ff2bf687536
Stats:     36 lines in 4 files changed: 36 ins; 0 del; 0 mod

8358738: AOT cache created without graal jit should not be used with graal jit

Reviewed-by: iklam, ccheung

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

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

From shade at openjdk.org  Fri Jun 13 17:07:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 17:07:39 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <Z0zYFP_-ZyUeKBTYodMVbipuneMLQszo9qOntED_CbM=.c52ed628-f4e2-4326-a053-71bcdb115aab@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <Z0zYFP_-ZyUeKBTYodMVbipuneMLQszo9qOntED_CbM=.c52ed628-f4e2-4326-a053-71bcdb115aab@github.com>
Message-ID: <qQ5xd5jmy-9TYEIOzXkWRlVNKhY32LwdBwHDJTWa3t4=.34be931f-28d1-492e-8108-bcf692d0de5f@github.com>

On Fri, 13 Jun 2025 15:57:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> When AOT code caching is integrated do you plan to move it back to diagnostic? As you said - it does not make sense to touch it.

Right. I think we would need to move it back to diagnostic once AOT code compilation would land. It would also reflect the status of the feature: in JDK 25, it is sensible to flip it back and forth as experimental performance flag; past that, the only sensible behavior is "on", and you only turn it off to diagnose bugs.

What I am trying to achieve with this PR: users in JDK 25 should not be unlocking diagnostic flags for their performance needs. At most, they need to unlock experimental ones.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2970984311

From duke at openjdk.org  Fri Jun 13 17:08:00 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 17:08:00 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v4]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <k5hvg8PoaIH_cuL2JAGKgn0Ffi3XGRe6bpAE3KIDWQE=.bec462cc-6fb3-47dd-8cea-fcba22808587@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Replace calls to log_gc_vtime with super-class method calls
 - Add bug fix after refactor and fixes for review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/aeb4ad04..dec5b8ba

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

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

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

From duke at openjdk.org  Fri Jun 13 17:14:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 17:14:35 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <OKHlSSVavKR-Xn-qZKlJUfazQdwCuyOS4NeuRLOSfRo=.c69354e7-152f-45fd-9941-592065933681@github.com>

On Fri, 13 Jun 2025 10:17:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The string deduplication thread, which is to some degree also a GC helper thread, is not considered here. Not sure if it should, slightly tending to add it.

I can see arguments for both ways, but do not have a strong opinion. Unless someone object I will add it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2970995550

From shade at openjdk.org  Fri Jun 13 17:17:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 17:17:29 GMT
Subject: RFR: 8355298: Increase timeout for StressAsyncUL
In-Reply-To: <HNNV413pNib7S4m5hfHqaGDQXnlts6jbFvgkYonRZbs=.be82315d-65cc-4c2a-a128-7a54d5fb1c37@github.com>
References: <HNNV413pNib7S4m5hfHqaGDQXnlts6jbFvgkYonRZbs=.be82315d-65cc-4c2a-a128-7a54d5fb1c37@github.com>
Message-ID: <GN3R4MW8Cz0LSdNdTRPxM78KoeqZ6N6Ni-Jq-9ilI0E=.761c1773-58f2-467e-ad81-502f62f36aef@github.com>

On Mon, 9 Jun 2025 14:01:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> Running async UL with stalling mode enabled is very slow if your buffer is very small. This turns out to become an issue on slow machines, where we run the risk of the test timing out.
> 
> The ticket's suggestion (and title) is to increase the timeout. I think that it'd be fine to reduce the logging level to 'debug' instead, thus reducing the time required to run the test.
> 
> Obviously, if we go with this solution then the ticket name and description must be adjusted.

I think it is fine to switch to `debug`, if that indeed produces much fewer messages, while still testing the stalling mode.

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

PR Review: https://git.openjdk.org/jdk/pull/25695#pullrequestreview-2925570815

From kvn at openjdk.org  Fri Jun 13 17:18:30 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 17:18:30 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <QH_0gIRmb91xtji7BDoe3KvCrKW8fdIIeuOBMca_CBI=.c9007f4c-1b8d-4ab2-969d-c412aafca6a3@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

Okay. Then why not do this change in JDK 25 branch only and don't touch JDK 26?
You would need approval for JDK 25: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2971001482

From shade at openjdk.org  Fri Jun 13 17:18:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 17:18:31 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <QH_0gIRmb91xtji7BDoe3KvCrKW8fdIIeuOBMca_CBI=.c9007f4c-1b8d-4ab2-969d-c412aafca6a3@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <QH_0gIRmb91xtji7BDoe3KvCrKW8fdIIeuOBMca_CBI=.c9007f4c-1b8d-4ab2-969d-c412aafca6a3@github.com>
Message-ID: <-V-JrwlZRvHgbO2-fFwiVt2yavoeOi00LHYQ24P-bEs=.041c81b2-c00e-4555-9ea1-95b2c421d021@github.com>

On Fri, 13 Jun 2025 17:13:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Okay. Then why not do this change in JDK 25 branch only and don't touch JDK 26?

Are we 100% sure AOT code cache would land in JDK 26? I don't think we can make that bet yet :) This is why it is for both mainline and JDK 25.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2971005378

From kvn at openjdk.org  Fri Jun 13 17:31:37 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 17:31:37 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <IRrk002265m2dB6uq9OKZBYWqWD9X3ZYwBgXf90zJVI=.425baa4d-df70-4205-afb9-bcc6ae2ce733@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

Okay, let's go with this. Don't forget to request approval for JDK 25.

Trivial.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2925631848

From kvn at openjdk.org  Fri Jun 13 17:31:38 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 13 Jun 2025 17:31:38 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <-V-JrwlZRvHgbO2-fFwiVt2yavoeOi00LHYQ24P-bEs=.041c81b2-c00e-4555-9ea1-95b2c421d021@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <QH_0gIRmb91xtji7BDoe3KvCrKW8fdIIeuOBMca_CBI=.c9007f4c-1b8d-4ab2-969d-c412aafca6a3@github.com>
 <-V-JrwlZRvHgbO2-fFwiVt2yavoeOi00LHYQ24P-bEs=.041c81b2-c00e-4555-9ea1-95b2c421d021@github.com>
Message-ID: <CVvRhXDV2aGrd8RPUB3qSAeuMwbo0P9n183byigV3n4=.d0974359-b402-4e3b-ace6-05d04d7eb361@github.com>

On Fri, 13 Jun 2025 17:15:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Okay. Then why not do this change in JDK 25 branch only and don't touch JDK 26?
> 
> Are we 100% sure AOT code cache would land in JDK 26? I don't think we can make that bet yet :) This is why it is for both mainline and JDK 25.

That is the plan but we can't promise officially. "When it is ready".

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2971046938

From dlong at openjdk.org  Fri Jun 13 19:18:19 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 13 Jun 2025 19:18:19 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

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

  remove is_sigill_not_entrant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/0950fc5e..c1ebde09

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

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

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

From duke at openjdk.org  Fri Jun 13 20:11:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 20:11:04 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

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

  Add CPU time tracking for string deduplication to log_gc_vtime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/dec5b8ba..895f3747

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

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

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

From syan at openjdk.org  Sat Jun 14 01:01:43 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 14 Jun 2025 01:01:43 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <zEsttPaMQlEd-hG-CS0J5QDiEWu6WybY4qscgdikMCA=.61929cfc-b47c-4492-b81b-67c17a23d102@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2926932034

From mdoerr at openjdk.org  Sat Jun 14 11:10:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 14 Jun 2025 11:10:38 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2928005394

From eosterlund at openjdk.org  Mon Jun 16 00:59:31 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 16 Jun 2025 00:59:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Thanks for doing this! I have been wanting something like this for a while too and it looks great. I have some comments though...

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 109:

> 107: }
> 108: 
> 109: void ZBarrierSetNMethod::arm_with(nmethod* nm, int value) {

I don't usually comment on names, but could we call this guard_with instead? We tried to stop saying "arm" about things used also for disarming and we have (hopefully) been consistent about calling that "guard" instead.

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114:

> 112:   // Preserve the sticky bit
> 113:   if (is_not_entrant(nm)) {
> 114:     value |= not_entrant;

Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant?

If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier.

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

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2930412450
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2148888954
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2148891702

From iklam at openjdk.org  Mon Jun 16 02:04:27 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 16 Jun 2025 02:04:27 GMT
Subject: [jdk25] RFR: 8355556: JVM crash because archived method handle
 intrinsics are not restored
Message-ID: <L4L_CcMiwni_zfR32kpArfseR6rCTDmdVssyFmsUPC8=.b5815c0f-0c81-4cad-b17e-575316437dbb@github.com>

Hi all,

This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev.

Thanks!

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

Commit messages:
 - Backport 366650a438d046f3da5b490c42e37faaf3a9abc5

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

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

From dholmes at openjdk.org  Mon Jun 16 04:36:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Jun 2025 04:36:42 GMT
Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v11]
In-Reply-To: <B5fS6RBGssVzKRIJXwFzlTAyvBpKROisdSHRw6L1PG4=.4af308b8-12fc-443e-b9b8-5a86b7053d5e@github.com>
References: <a0o8map8m_YGijcArSUAbhB6pYp1JupJzg_jM-U0EcY=.b7bde17a-6d66-41c2-b919-46c60a53adf1@github.com>
 <-iuKFZl5TFXoUq09XFZ_uhqPD8p-kTIdi6oC56kcQ88=.aaa561a0-e339-44df-a2bc-1bdc741eddd2@github.com>
 <FRZJBVlDUO_a2MvyE0KdeCSdHNP2Xnx1NoDkOnkDkjY=.cc048e1e-e7f5-4a54-a92a-b0cda64e6be4@github.com>
 <B5fS6RBGssVzKRIJXwFzlTAyvBpKROisdSHRw6L1PG4=.4af308b8-12fc-443e-b9b8-5a86b7053d5e@github.com>
Message-ID: <eUFFogdNQknGfjz0eCqhzGhCufI5e9adOSWLjLctw2A=.c309e53d-fa93-4286-ab72-8cbdc7d8e547@github.com>

On Wed, 11 Jun 2025 12:40:40 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/suspendResumeManager.cpp line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2017, 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> Suggestion:
>> 
>>  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
>
> Addressed in the latest commit.

We have had this raised a number of times recently. When you refactor code into a new file the copyright years for the new file are taken from the oldest dates in the original files. It is an approximation as you don't know exactly when the refactored code was first added, but you don't just give it the current year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25407#discussion_r2149025086

From dholmes at openjdk.org  Mon Jun 16 07:43:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Jun 2025 07:43:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
Message-ID: <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>

On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CPU time tracking for string deduplication to log_gc_vtime

This seems reasonable though I'm unclear on some details.  Could you give a high-level description of what times we capture for what threads and when, and the calculations involved. Thanks.

Some minor style nits.

src/hotspot/share/gc/shared/vtimeScope.hpp line 38:

> 36: 
> 37: public:
> 38:   VTimeScope(VMThread *thread, bool operation_is_gc);

Suggestion:

  VTimeScope(VMThread* thread, bool operation_is_gc);

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 32:

> 30: #include "runtime/os.hpp"
> 31: 
> 32: inline VTimeScope::VTimeScope(VMThread *thread, bool operation_is_gc)

Suggestion:

inline VTimeScope::VTimeScope(VMThread* thread, bool operation_is_gc)

This style nit needs fixing in a few places.

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 35:

> 33:     : _start(0), _enabled(os::is_thread_cpu_time_supported()),
> 34:       _gcLogging(operation_is_gc && (log_is_enabled(Info, gc) || log_is_enabled(Info, gc, cpu))),
> 35:       _thread((Thread*)thread) {

Cast should not be necessary

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2930801029
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153155
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153527
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153897

From amitkumar at openjdk.org  Mon Jun 16 08:29:34 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 16 Jun 2025 08:29:34 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Just FYI, s390 build is broken with this change: 


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
#  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
#
# JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
# Problematic frame:
# V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
#
# Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#


stack trace: 

Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
....

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2975564797

From tschatzl at openjdk.org  Mon Jun 16 08:34:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 16 Jun 2025 08:34:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
Message-ID: <8JpTGtXweaka2sBESSAKeOHqdsd-DrnLj7oF0XiZ0GI=.c8212dfd-a4ee-41a4-bf83-848c87bbd7ba@github.com>

On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CPU time tracking for string deduplication to log_gc_vtime

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 166:

> 164:   CollectedHeap::stop();
> 165: }
> 166: 

There is no need to override this method if the only thing it does is calling the super class method.

src/hotspot/share/gc/serial/serialHeap.cpp line 151:

> 149:   CollectedHeap::stop();
> 150: }
> 151: 

There is no need to override this method if the only thing it does is calling the super class method.

src/hotspot/share/gc/shared/collectedHeap.hpp line 245:

> 243: 
> 244:   // Stop any onging concurrent work and prepare for exit.
> 245:   virtual void stop() { log_gc_vtime(); }

Please move this implementation into the `.cpp` file to avoid making the `.hpp` file more complicated than needed. It's not performance sensitive at all (or if you really think this is required, into the `.inline.hpp` file).

src/hotspot/share/gc/shared/collectedHeap.hpp line 258:

> 256:     _vm_vtime += time;
> 257:   }
> 258: 

Probably better to move into `.inline.hpp` file too.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2930986521
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149271551
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149272195
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149350924
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149352267

From tschatzl at openjdk.org  Mon Jun 16 08:34:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 16 Jun 2025 08:34:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <vLqfVwJ1I5pqpacCN6hRdNUmmz8tyoRXhE62ToVZ83g=.9b8731a4-1410-4103-b466-56f98dff62b7@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
 <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
 <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>
 <vLqfVwJ1I5pqpacCN6hRdNUmmz8tyoRXhE62ToVZ83g=.9b8731a4-1410-4103-b466-56f98dff62b7@github.com>
Message-ID: <ybJ_XoFTxPFpOxcux5e4ofseTtOZskiXBsk353QOPxA=.a8eeac02-4fb4-434f-a793-98b28add5648@github.com>

On Fri, 13 Jun 2025 15:59:05 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi.
>
> FWIW; I confirmed with @stefank that `_runtime_workers` shoud not be accounted for GC CPU time for ZGC.

But then runtime tasks performed by the GC worker threads when using them for runtime work is differently counted towards those GCs that do this sharing/shadowing.

I looked a bit what they are doing, after JDK-8329488 they are only used by heap inspection and heap dumping. Which seems to be solely GC related task, so I kind of think they should be counted against GC.
At least make the accounting uniform across collectors.

So one option is duplicating these workers in G1/Parallel too, and fix https://bugs.openjdk.org/browse/JDK-8277394. Since we can't share GC workers and these "runtime workers" any more due to this change, the safepoint workers management should probably be moved to `CollectedHeap`, and they shouldn't be advertised as general purpose workers everyone can hook into.

Or just let ZGC's `_runtime_threads` also count towards GC time. After all both of these VM operations are `VM_GC_Operations`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149337356

From duke at openjdk.org  Mon Jun 16 09:03:32 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 09:03:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
Message-ID: <k_YqSpi_9RH66Yjcm71vsJU5PSE0QL63yqKnFvX1Uz0=.2e2248c0-35ac-467b-b1bf-c78a1525ce5d@github.com>

On Mon, 16 Jun 2025 06:37:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add CPU time tracking for string deduplication to log_gc_vtime
>
> src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 35:
> 
>> 33:     : _start(0), _enabled(os::is_thread_cpu_time_supported()),
>> 34:       _gcLogging(operation_is_gc && (log_is_enabled(Info, gc) || log_is_enabled(Info, gc, cpu))),
>> 35:       _thread((Thread*)thread) {
> 
> Cast should not be necessary

Not casting requires adding `#include "runtime/vmThread.hpp"`. Will add that since that seems to be preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149417216

From duke at openjdk.org  Mon Jun 16 09:19:32 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 09:19:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
Message-ID: <djVKbomyI9yqnNVulCU26eHLGhU1M6oPIPd_nc2s8sY=.66ab1eeb-0073-4f32-8335-145a40374fcf@github.com>

On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CPU time tracking for string deduplication to log_gc_vtime

src/hotspot/share/runtime/vmThread.cpp line 278:

> 276:     PerfTraceTime vm_op_timer(perf_accumulated_vm_operation_time());
> 277:     HOTSPOT_VMOPS_BEGIN(
> 278:                      (char *) op->name(), strlen(op->name()),

@dholmes-ora given that I'm editing `VMThread::evaluate_operation` and your comments about code style - do you want me to also change this type cast to `(char*)` to align with the preferred style?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149450013

From shade at openjdk.org  Mon Jun 16 09:22:33 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 16 Jun 2025 09:22:33 GMT
Subject: [jdk25] RFR: 8355556: JVM crash because archived method handle
 intrinsics are not restored
In-Reply-To: <L4L_CcMiwni_zfR32kpArfseR6rCTDmdVssyFmsUPC8=.b5815c0f-0c81-4cad-b17e-575316437dbb@github.com>
References: <L4L_CcMiwni_zfR32kpArfseR6rCTDmdVssyFmsUPC8=.b5815c0f-0c81-4cad-b17e-575316437dbb@github.com>
Message-ID: <VvMpLoInxPAcGCjVGtMUnOxMNvQK5aGb3iCjznXeYm8=.e37bd024-7bea-44fe-b817-86b45b0be829@github.com>

On Mon, 16 Jun 2025 01:59:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25815#pullrequestreview-2931282671

From schernyshev at openjdk.org  Mon Jun 16 09:50:48 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 16 Jun 2025 09:50:48 GMT
Subject: RFR: 8319589: Attach from root to a user java process not supported in
 Mac
Message-ID: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>

Hi all,

I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs.

This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.

Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.

Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.

The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().

The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.

Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.

The patch is tested against the range of macOS versions, the earliest version tested is 10.13 High Sierra (as 11u backport), the latest version tested is 15.5 Sequoia.

Testing:

- jtreg hotspot/jdk tier1 passed
- jtreg tier2, tier3 no regresstions
- gtest:all passed


[1] https://github.com/apple-oss-distributions/Libc/blob/Libc-997.90.3/darwin/_dirhelper.c#L210

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

Commit messages:
 - 8319589: Attach from root to a user java process not supported in Mac

Changes: https://git.openjdk.org/jdk/pull/25824/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25824&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319589
  Stats: 255 lines in 8 files changed: 241 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

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

From syan at openjdk.org  Mon Jun 16 10:02:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 16 Jun 2025 10:02:15 GMT
Subject: RFR: 8359207: Remove redundant runtime/signal/TestSigusr2.java
Message-ID: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>

Hi all,

The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux and macos. Thus this test will is always skipped indeed. So I want to removed this test. Test-fix only, no rsik.

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

Commit messages:
 - 8359207: Remove redundant runtime/signal/TestSigusr2.java

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

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

From duke at openjdk.org  Mon Jun 16 11:25:16 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 11:25:16 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v6]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <hYV-Wcy1Z3qgRT0MQHpkZ-4ouZD8Tg6LwkYv14RNH6s=.4c6ca02b-d2da-4933-9104-beb67280f313@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

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

  Remove explicit super call and minor fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/895f3747..effaeede

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

  Stats: 41 lines in 10 files changed: 14 ins; 17 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From duke at openjdk.org  Mon Jun 16 11:31:51 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 11:31:51 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v7]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <8LJedORsD5AZ49XAf3_JjzbYhOa_HVvB0PMUWyI7m5s=.3cf83050-ed44-4516-96e1-ea87a97ae9fa@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

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

  Only sample if needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/effaeede..2ac00321

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

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

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

From duke at openjdk.org  Mon Jun 16 11:52:28 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 11:52:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
Message-ID: <jbnYC9JF8tUEu88HJ0DBOVQK59pc_qo722YmKZX7De0=.58085ec8-6f1d-4b55-a8b3-af7d2e7b9810@github.com>

On Mon, 16 Jun 2025 07:40:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems reasonable though I'm unclear on some details. Could you give a
> high-level description of what times we capture for what threads and when, and
> the calculations involved. Thanks.

What threads:

* All GC threads e.g. director thread, sample threads, worker threads, driver
  threads (except for ZGC where I currently exclude the "runtime" threads which
  we may decide to change, see @tschatzl comments above)

* The VM thread, but only include VM operations related to GC

* The string deduplication thread

What times:

* CPU time for all the threads above

* CPU time for the entire process


When:

* VM thread:

  - If VM operation is GC and `-Xlog:gc` or more is enabled, sample `start`, and `end` CPU time
    for the GC operation. Add `end - start` to `gc_vm_vtime`.

* GC threads:

  - If `-Xlog:gc` or more is enabled, sample all GC threads and store the CPU
    time sum to `gc_threads_vtime` during VM exit.

* String deduplication thread:

  - If string deduplication is enabled and if `-Xlog:gc` or more is enabled
    sample CPU time during VM exit for that thread and store to `string_deduplication_vtime`

* Process:

  - If  `-Xlog:gc` or more is enabled, sample the CPU time for the entire process

Log accumulated CPU time `gc_threads_vtime + gc_vm_vtime + string_deduplication_vtime`
as a percentage of the total process CPU time. We sample the total process CPU 
time with the new method `os::elapsed_process_vtime`.

It should be noted from the above that calling elapsed_gc_vtime assumes that
-Xlog:gc or more is enabled. If one breaks this assumption the GC CPU time will
not include VM thread and may be horribly wrong (e.g. if one runs Serial).

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2976252452

From azafari at openjdk.org  Mon Jun 16 12:06:31 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 16 Jun 2025 12:06:31 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v40]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <gpSw1V4nKvHhN1ccsYp1MAPt0OO33kwzVHE0Jd0tSaM=.a6d06193-46e0-4b32-810d-d04d995f704c@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits:

 - changes after merge
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - fixes after merge with master.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - more reviews.
 - review comments applied
 - test cases for doing reserve or commit the same region twice.
 - style, some cleanup, VMT and regionsTree circular dep resolved
 - removed UseFlagInPlace test.
 - ... and 76 more: https://git.openjdk.org/jdk/compare/3a188726...e303ee7c

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

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=39
  Stats: 1426 lines in 26 files changed: 555 ins; 557 del; 314 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

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

From duke at openjdk.org  Mon Jun 16 12:50:17 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 12:50:17 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v8]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

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

  operation_is_gc -> is_gc_operation per @stefank suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/2ac00321..b20c9740

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

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

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

From mdoerr at openjdk.org  Mon Jun 16 13:59:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Jun 2025 13:59:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
Message-ID: <eKflnYAqlB11rSLWSuw6ZAeIzNQjESuZ_TBG1Le2dS4=.78600187-5347-45b7-855c-03ac92941117@github.com>

On Mon, 16 Jun 2025 08:26:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> Just FYI, s390 build is broken with this change: 
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
> #
> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
> # Problematic frame:
> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> 
> stack trace: 
> 
> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
> ....

@offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183)
Should be 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2976308103

From mdoerr at openjdk.org  Mon Jun 16 13:59:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Jun 2025 13:59:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Seems like arm32 has the same issue: https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
The init value shouldn't have the sticky bit set.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2976766766

From amitkumar at openjdk.org  Mon Jun 16 15:07:29 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 16 Jun 2025 15:07:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
Message-ID: <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>

On Mon, 16 Jun 2025 08:26:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> Just FYI, s390 build is broken with this change: 
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
> #
> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
> # Problematic frame:
> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> 
> stack trace: 
> 
> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
> ....

> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0.

Thank you Martin for the suggestion. 

@dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; 


diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
index e78906708af..2d663061aec 100644
--- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
@@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) {
     __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes
 
     // Compare to current patched value:
-    __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val)
+    __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val)
 
     // Conditional Jump
     __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes
diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
index d3f6540a3ea..bb1d9ce6037 100644
--- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
+++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
@@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator {
 
     // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr)
     __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier));
-    __ z_ltr(Z_R0_scratch, Z_RET);
+    __ z_ltr(Z_RET, Z_RET);
 
     // VM-Call Epilogue
     __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false);

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2977015369

From coleenp at openjdk.org  Mon Jun 16 18:02:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Jun 2025 18:02:29 GMT
Subject: RFR: 8357662: applications/runthese/RunThese8H.java Crash: 'Failed
 to uncommit metaspace'
In-Reply-To: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
References: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
Message-ID: <jTgpgxoTmX6_UeIcGQmgyHaWB9zyHiszpz_hGxS_u54=.3eb61a70-849c-4997-b67d-ffe1360de7d6@github.com>

On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make the fatal error a log warning and return. The metaspace commit accounting is done after this return.  Tested with this always returning here, and it seems okay.  Tested with this change tier 1-4 and 8.

I don't see any evidence of a bug filed to examine whether uncommit failures should always/never/sometimes be a fatal error.  As the code is now, it's up to the caller, which is a situation that could go badly wrong if the caller guesses wrong.  I'd rather it always be a fatal error inside our os code that does uncommit in the cases that would corrupt memory.  If that's the case.
This metaspace uncommit is a case that seems like it could fail and the memory simply isn't returned as we'd wished.  Who knows whether memory is corrupted here or not.  I'd like the OS layer of code to tell me that.

Not really sure what to do about this other than close it as WNF.

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

PR Comment: https://git.openjdk.org/jdk/pull/25720#issuecomment-2977532489

From duke at openjdk.org  Mon Jun 16 21:15:29 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 21:15:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v8]
In-Reply-To: <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
Message-ID: <I1w52ppE-DOj6l4srchOPKVMIJ9lZt6DF093icbXDzo=.c6496623-d7d2-4fcb-b305-c03d8af80508@github.com>

On Mon, 16 Jun 2025 12:50:17 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   operation_is_gc -> is_gc_operation per @stefank suggestion

> After all both of these VM operations are VM_GC_Operations.

@tschatzl Thanks for pointing that out, that's an excellent point!

Your comment caused me to reflect over that I have currently defined all operations as GC operations if they inherit from `VM_GC_Sync_Operation`. However the following should probably not be strictly counted as a GC activity: `VM_GC_HeapInspection`, `VM_PopulateDynamicDumpSharedSpace`, `VM_Verify`, `VM_PopulateDumpSharedSpace`. I will update the PR.

> So one option is duplicating these workers in G1/Parallel too, and fix https://bugs.openjdk.org/browse/JDK-8277394. 

Thanks for the suggestion, I agree that we should do that to fix the root issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2978167405

From dcubed at openjdk.org  Mon Jun 16 21:38:27 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 16 Jun 2025 21:38:27 GMT
Subject: RFR: 8359207: Remove redundant runtime/signal/TestSigusr2.java
In-Reply-To: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
References: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
Message-ID: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>

On Mon, 16 Jun 2025 09:56:47 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik.

Thumbs up on the code changes.

"redundant" implies that the functionality is tested elsewhere. I have changed the bug's synopsis from:

    Remove redundant runtime/signal/TestSigusr2.java

to:

    Remove runtime/signal/TestSigusr2.java since it is always skipped

which I think is more accurate.

I wonder if `SIGUSR2` was only useful on Solaris.

Please use "/issue JDK-8359207" as the easiest way to sync the PR title with the synopsis.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25825#pullrequestreview-2933584282
PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2978224302
PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2978226019

From dlong at openjdk.org  Mon Jun 16 23:34:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:34:43 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v5]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <ZN6kFFf-mJIH6ATSurRl3RmKBp7MUytFmJJRMvdEag4=.92f1c003-6de3-47cb-9d97-cb75f5d9b348@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

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

  s390 fix courtesy of Amit Kumar

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/c1ebde09..a7d784b2

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

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

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

From dlong at openjdk.org  Mon Jun 16 23:34:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:34:43 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
 <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
Message-ID: <Bluq4RaeKqEQJqYp4iVrX3AjaUQ9T1yQqmQx7iYw9A8=.596712ac-1525-4428-b80c-bb10098e26dd@github.com>

On Mon, 16 Jun 2025 15:04:23 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Just FYI, s390 build is broken with this change: 
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
>> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
>> #
>> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
>> # Problematic frame:
>> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> 
>> stack trace: 
>> 
>> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
>> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
>> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
>> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
>> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
>> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
>> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
>> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
>> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
>> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
>> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
>> ....
>
>> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0.
> 
> Thank you Martin for the suggestion. 
> 
> @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; 
> 
> 
> diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> index e78906708af..2d663061aec 100644
> --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) {
>      __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes
>  
>      // Compare to current patched value:
> -    __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val)
> +    __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val)
>  
>      // Conditional Jump
>      __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes
> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> index d3f6540a3ea..bb1d9ce6037 100644
> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator {
>  
>      // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr)
>      __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier));
> -    __ z_ltr(Z_R0_scratch, Z_RET);
> +    __ z_ltr(Z_RET, Z_RET);
>  
>      // VM-Call Epilogue
>      __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false);

Thanks @offamitkumar.  Could you explain the `__ z_ltr(Z_R0_scratch, Z_RET);` change, for my curiosity?  Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978470825

From dlong at openjdk.org  Mon Jun 16 23:39:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:39:08 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v6]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <T_ifzZkpru-qrX0_TKGUplo2NhJP_gK_WeZu5rHtFdg=.4a2f286e-c25e-48e6-84f7-a0225177af68@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

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

  arm32 fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/a7d784b2..c98f3864

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

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

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

From dlong at openjdk.org  Mon Jun 16 23:39:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:39:08 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
Message-ID: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>

On Mon, 16 Jun 2025 13:56:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Seems like arm32 has the same issue:
> 
> https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
> 
> The init value shouldn't have the sticky bit set.

Thanks, I pushed a potential fix for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978476161

From dlong at openjdk.org  Mon Jun 16 23:45:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:45:57 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v7]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <k0ooW4tQFu9rv5NHyktrIii96Uv8r-Frics2nUnxnSg=.8db6f73e-60da-4374-864e-14a691156f58@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

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

  rename arm_with to guard_with

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/c98f3864..3ac6dec0

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

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

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

From dlong at openjdk.org  Mon Jun 16 23:45:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:45:57 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
Message-ID: <Rs8iKPDKHrHqN4ULCnUCcdmwuIWxalw8lXn-YhWHW9c=.bafc9947-1c19-4688-8478-44ffe831e2af@github.com>

On Mon, 16 Jun 2025 00:48:40 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 109:
> 
>> 107: }
>> 108: 
>> 109: void ZBarrierSetNMethod::arm_with(nmethod* nm, int value) {
> 
> I don't usually comment on names, but could we call this guard_with instead? We tried to stop saying "arm" about things used also for disarming and we have (hopefully) been consistent about calling that "guard" instead.

Good suggestion.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2151070290

From dlong at openjdk.org  Tue Jun 17 00:05:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 00:05:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
Message-ID: <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>

On Mon, 16 Jun 2025 00:54:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114:
> 
>> 112:   // Preserve the sticky bit
>> 113:   if (is_not_entrant(nm)) {
>> 114:     value |= not_entrant;
> 
> Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant?
> 
> If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier.

If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2151084557

From dlong at openjdk.org  Tue Jun 17 00:13:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 00:13:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com>
Message-ID: <UoVXZCNouvAqNqc77bktWvKke8XV6HXXgWt4NmoFbHg=.d74782fc-763f-45a3-a1bc-57d73e419ebb@github.com>

On Sat, 14 Jun 2025 09:23:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.

For ZGC I am using a per-nmethod lock:
  ZLocker<ZReentrantLock> locker(ZNMethod::lock_for_nmethod(nm));

I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this.

One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978525224

From david.holmes at oracle.com  Tue Jun 17 02:36:45 2025
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jun 2025 12:36:45 +1000
Subject: AbstractInterpreter::is_not_reached wrongfully assumes
 reachability for invokedynamic
In-Reply-To: <955a583d795914024aaa0d78ef35e274@xdark.dev>
References: <955a583d795914024aaa0d78ef35e274@xdark.dev>
Message-ID: <11f148b6-c514-4147-afbb-df1a5b8eada0@oracle.com>

FYI: https://bugs.openjdk.org/browse/JDK-8359057

David

On 9/06/2025 4:29 am, me at xdark.dev wrote:
>
> Greetings,
> Since JDK-8301995 <https://bugs.openjdk.org/browse/JDK-8301995>, the 
> code to in AbstractInterpreter::is_not_reached(...) for invokedynamic 
> looks like this:
> ```
> ? ? ? case Bytecodes::_invokedynamic: {
> ? ? ? ? assert(invoke_bc.has_index_u4(code), "sanity");
> ? ? ? ? int method_index = invoke_bc.get_index_u4(code);
> ? ? ? ? return cpool->resolved_indy_entry_at(method_index)->is_resolved();
> ? ? ? }
> ```
> Is this a bug? Before the change, the code looked like this:
> ```
> ? ? ? case Bytecodes::_invokedynamic: {
> ? ? ? ? assert(invoke_bc.has_index_u4(code), "sanity");
> ? ? ? ? int method_index = invoke_bc.get_index_u4(code);
> ? ? ? ? return 
> cpool->invokedynamic_cp_cache_entry_at(method_index)->is_f1_null();
> ? ? ? }
> ```
> The comment for this method says:
> ```
> // Return true if the interpreter can prove that the given bytecode has
> // not yet been executed (in Java semantics, not in actual operation).
> ```
> Shouldn't the is_resolved check be negated? The code is two years old 
> since this change, and it seems like a regression. I'm unable to 
> submit a patch if that is the case, so, if this is a bug, It would be 
> great if someone would fix this.
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250617/4372daeb/attachment.htm>

From syan at openjdk.org  Tue Jun 17 02:46:28 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 02:46:28 GMT
Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is
 always skipped
In-Reply-To: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>
References: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
 <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>
Message-ID: <9YWxsDF37yy-L-ZuDgMq0-9qahrgtXBfu5M_aWtoqK0=.fe58d62b-640c-4754-9e41-19f7f3ec9892@github.com>

On Mon, 16 Jun 2025 21:34:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Hi all,
>> 
>> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik.
>
> Please use "/issue JDK-8359207" as the easiest way to sync the PR title with the synopsis.

Thanks for the correction and review @dcubed-ojdk

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

PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2978745676

From amitkumar at openjdk.org  Tue Jun 17 03:46:33 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 17 Jun 2025 03:46:33 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
 <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
Message-ID: <-0Y5IM8MHOmPZpTHRGKK5hnBLA5TyRV871YLJ1XnSAI=.027d1976-faf5-40f7-a7d0-fa05d6b986b4@github.com>

On Mon, 16 Jun 2025 15:04:23 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Just FYI, s390 build is broken with this change: 
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
>> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
>> #
>> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
>> # Problematic frame:
>> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> 
>> stack trace: 
>> 
>> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
>> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
>> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
>> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
>> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
>> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
>> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
>> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
>> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
>> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
>> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
>> ....
>
>> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0.
> 
> Thank you Martin for the suggestion. 
> 
> @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; 
> 
> 
> diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> index e78906708af..2d663061aec 100644
> --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) {
>      __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes
>  
>      // Compare to current patched value:
> -    __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val)
> +    __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val)
>  
>      // Conditional Jump
>      __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes
> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> index d3f6540a3ea..bb1d9ce6037 100644
> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator {
>  
>      // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr)
>      __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier));
> -    __ z_ltr(Z_R0_scratch, Z_RET);
> +    __ z_ltr(Z_RET, Z_RET);
>  
>      // VM-Call Epilogue
>      __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false);

> Thanks @offamitkumar. Could you explain the `__ z_ltr(Z_R0_scratch, Z_RET);` change, for my curiosity? Thanks.

`ltr` instruction stands for "load and test" (32 bit). Initially we were loading the value from `Z_RET` to `Z_R0_scratch` and then it will be compared against 0. But in this case there is no requirement of loading the value in Z_R0, as it's not being used further. So we can load the value again in `Z_RET` and the compare it against 0. There is nothing wrong in previous solution, it's just killing Z_R0 for nothing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978824615

From iklam at openjdk.org  Tue Jun 17 04:39:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Jun 2025 04:39:33 GMT
Subject: [jdk25] RFR: 8355556: JVM crash because archived method handle
 intrinsics are not restored
In-Reply-To: <VvMpLoInxPAcGCjVGtMUnOxMNvQK5aGb3iCjznXeYm8=.e37bd024-7bea-44fe-b817-86b45b0be829@github.com>
References: <L4L_CcMiwni_zfR32kpArfseR6rCTDmdVssyFmsUPC8=.b5815c0f-0c81-4cad-b17e-575316437dbb@github.com>
 <VvMpLoInxPAcGCjVGtMUnOxMNvQK5aGb3iCjznXeYm8=.e37bd024-7bea-44fe-b817-86b45b0be829@github.com>
Message-ID: <uPYYShrfQleTSXVxvzx58CRiF-TmjJK-99pGb2_dMl8=.2e399fe3-fe9e-4f30-a4d2-7247382634b9@github.com>

On Mon, 16 Jun 2025 09:19:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev.
>> 
>> Thanks!
>
> Marked as reviewed by shade (Reviewer).

Thanks @shipilev for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/25815#issuecomment-2978906549

From iklam at openjdk.org  Tue Jun 17 04:39:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 17 Jun 2025 04:39:33 GMT
Subject: [jdk25] Integrated: 8355556: JVM crash because archived method handle
 intrinsics are not restored
In-Reply-To: <L4L_CcMiwni_zfR32kpArfseR6rCTDmdVssyFmsUPC8=.b5815c0f-0c81-4cad-b17e-575316437dbb@github.com>
References: <L4L_CcMiwni_zfR32kpArfseR6rCTDmdVssyFmsUPC8=.b5815c0f-0c81-4cad-b17e-575316437dbb@github.com>
Message-ID: <a6wU-BNi4Vdnf3Q7FXXA_ElpzaqImkY3bHSsZnB4O7k=.2491ef4e-ab1c-43b4-9bbd-74576c0fdcaf@github.com>

On Mon, 16 Jun 2025 01:59:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [366650a4](https://github.com/openjdk/jdk/commit/366650a438d046f3da5b490c42e37faaf3a9abc5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Ioi Lam on 13 Jun 2025 and was reviewed by Andrew Dinn, Vladimir Ivanov and Aleksey Shipilev.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 75370018
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/753700182dfd0d0f4c22067f4e9aa77c138540a7
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8355556: JVM crash because archived method handle intrinsics are not restored

Reviewed-by: shade
Backport-of: 366650a438d046f3da5b490c42e37faaf3a9abc5

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

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

From dholmes at openjdk.org  Tue Jun 17 04:54:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 04:54:32 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>

On Mon, 16 Jun 2025 09:46:11 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

src/hotspot/os/posix/perfMemory_posix.cpp line 133:

> 131: //
> 132: 
> 133: #ifdef __APPLE__

This is a bit too much non-posix code in the posix file IMO. I'd rather see a `MACOS_ONLY` call later on to something defined in `os_bsd.cpp` for macOS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2151315769

From dholmes at openjdk.org  Tue Jun 17 05:49:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 05:49:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <djVKbomyI9yqnNVulCU26eHLGhU1M6oPIPd_nc2s8sY=.66ab1eeb-0073-4f32-8335-145a40374fcf@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <djVKbomyI9yqnNVulCU26eHLGhU1M6oPIPd_nc2s8sY=.66ab1eeb-0073-4f32-8335-145a40374fcf@github.com>
Message-ID: <xpg-TJBJi4KGmq-Lwhh4ByocP12vI2wy8HW3bVKJPo0=.7ad745a6-0af2-436c-8494-2b33be715797@github.com>

On Mon, 16 Jun 2025 09:17:05 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add CPU time tracking for string deduplication to log_gc_vtime
>
> src/hotspot/share/runtime/vmThread.cpp line 278:
> 
>> 276:     PerfTraceTime vm_op_timer(perf_accumulated_vm_operation_time());
>> 277:     HOTSPOT_VMOPS_BEGIN(
>> 278:                      (char *) op->name(), strlen(op->name()),
> 
> @dholmes-ora given that I'm editing `VMThread::evaluate_operation` and your comments about code style - do you want me to also change this type cast to `(char*)` to align with the preferred style?

Please do. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2151372297

From dholmes at openjdk.org  Tue Jun 17 05:59:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 05:59:30 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <jbnYC9JF8tUEu88HJ0DBOVQK59pc_qo722YmKZX7De0=.58085ec8-6f1d-4b55-a8b3-af7d2e7b9810@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
 <jbnYC9JF8tUEu88HJ0DBOVQK59pc_qo722YmKZX7De0=.58085ec8-6f1d-4b55-a8b3-af7d2e7b9810@github.com>
Message-ID: <Vh5cR_pON98NQD3F3fFpBOxCsr8H67-AUSLoELxB6Sc=.6e37acc0-d81e-4973-b698-ae140500b9ca@github.com>

On Mon, 16 Jun 2025 11:49:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> What threads: ...

Thanks for that. Once the details have stabilized I suggest adding this summary of operation to the JBS issue as well. 

I will let GC folk do the formal reviews/approvals here, but this looks quite reasonable to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2979038213

From dholmes at openjdk.org  Tue Jun 17 05:59:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 05:59:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v8]
In-Reply-To: <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
Message-ID: <9L-KW83n2k0foCwz6l7a2p5mMqkhrY6eigZL9FyRscU=.b8528248-522f-421d-8eae-184261a387d7@github.com>

On Mon, 16 Jun 2025 12:50:17 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   operation_is_gc -> is_gc_operation per @stefank suggestion

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 29:

> 27: #include "logging/log.hpp"
> 28: #include "memory/universe.hpp"
> 29: #include "runtime/vmThread.hpp"

Nit: if you put this in the .hpp file you can do away with the forward decl for VMThread that is in there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2151383344

From dholmes at openjdk.org  Tue Jun 17 06:16:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 06:16:28 GMT
Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is
 always skipped
In-Reply-To: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
References: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
Message-ID: <RtZuXwM35gjL6YZ7R3pSsmHP31tSXelt1mwmxlp_azo=.1c9de4a3-964e-4215-8994-2a7c8191110a@github.com>

On Mon, 16 Jun 2025 09:56:47 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik.

LGTM2.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25825#pullrequestreview-2934260769

From dholmes at openjdk.org  Tue Jun 17 06:16:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 06:16:29 GMT
Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is
 always skipped
In-Reply-To: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>
References: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
 <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>
Message-ID: <9dqpkeFuR93-ZwLXC_ckQCsq0x6uSM0xHl4_Bp216Z8=.d0f9e5e4-b564-4b1e-b923-49207841b331@github.com>

On Mon, 16 Jun 2025 21:33:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> I wonder if `SIGUSR2` was only useful on Solaris.

IIRC only testable on Solaris because there we had a special dedicated signal for suspend/resume. On all the *X platforms SIGUSR2 is used as SR_signum, and so can't be tested by this test.

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

PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2979071810

From dholmes at openjdk.org  Tue Jun 17 06:22:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 06:22:28 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com>

On Fri, 13 Jun 2025 11:31:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

Are there no tests that enable this flag and so would need updating to unlock it correctly?

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2979086278

From ktakakuri at openjdk.org  Tue Jun 17 07:54:35 2025
From: ktakakuri at openjdk.org (Kazuhisa Takakuri)
Date: Tue, 17 Jun 2025 07:54:35 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
Message-ID: <hIuECle5gdWJxxZrRj3XsfIbfkknOfmtmCFfh_VA8o8=.bffc1a33-9a97-4515-9aa2-6e893ac1ca94@github.com>

On Fri, 6 Jun 2025 08:21:08 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

@AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it?

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

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2979316887

From mbaesken at openjdk.org  Tue Jun 17 08:21:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 17 Jun 2025 08:21:38 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive
Message-ID: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>

In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
we get this message/error :


Error occurred during initialization of VM
Unable to use shared archive.


The error message could be a little improved, e.g. telling what jsa file is not present .
For example


./images/jdk/bin/java -Xshare:on -version
[0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
Error occurred during initialization of VM
Unable to use shared archive (unrecoverable archive loading error).

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

Commit messages:
 - JDK-8359423

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

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

From shade at openjdk.org  Tue Jun 17 08:32:32 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 17 Jun 2025 08:32:32 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com>
Message-ID: <7M5JVZlsjRQF27BMbg9mLXdG2CkltFIWz8Oklyb0tBs=.5b10c3ac-89d8-4ba0-9bb3-1632d3f51563@github.com>

On Tue, 17 Jun 2025 06:19:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Are there no tests that enable this flag and so would need updating to unlock it correctly?

Yeah, there are no tests for this flag. The flag was a late Leyden addition, and it defaults to `true` in Leyden/premain, so we know it performs well enough. But for mainline, we should really have a sanity test, let me do it here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2979434585

From shade at openjdk.org  Tue Jun 17 08:53:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 17 Jun 2025 08:53:16 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic
In-Reply-To: <7M5JVZlsjRQF27BMbg9mLXdG2CkltFIWz8Oklyb0tBs=.5b10c3ac-89d8-4ba0-9bb3-1632d3f51563@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <0e2u6WDkfZI8GMyQgD7FZupcPwMZU1AXf_157lDb3Ds=.179b418f-605b-4dfa-a533-7473622d856e@github.com>
 <7M5JVZlsjRQF27BMbg9mLXdG2CkltFIWz8Oklyb0tBs=.5b10c3ac-89d8-4ba0-9bb3-1632d3f51563@github.com>
Message-ID: <aIw6KJyIQgPw_OxaHCpzLerZf_OKpbQqXaxEjonOo2o=.96784bba-9d0f-40f1-bed7-e2f9af57f4a5@github.com>

On Tue, 17 Jun 2025 08:29:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Yeah, there are no tests for this flag. The flag was a late Leyden addition, and it defaults to `true` in Leyden/premain, so we know it performs well enough. But for mainline, we should really have a sanity test, let me do it here.

Added a sanity test. Passes Linux x86_64 server fastdebug/release.

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

PR Comment: https://git.openjdk.org/jdk/pull/25799#issuecomment-2979494614

From shade at openjdk.org  Tue Jun 17 08:53:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 17 Jun 2025 08:53:16 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2]
In-Reply-To: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
Message-ID: <mYJYh8k6VKawvSBU6lU4vp06PjAJ5MAw5FTaYzgqetQ=.1b21b0d8-5efc-4b77-9b10-190fc3b9443c@github.com>

> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
> 
> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`

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

  Test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25799/files
  - new: https://git.openjdk.org/jdk/pull/25799/files/c00fef1b..c62f367f

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

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

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

From azafari at openjdk.org  Tue Jun 17 10:17:06 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 17 Jun 2025 10:17:06 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

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

  fixes to a few failures.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/e303ee7c..815092d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=39-40

  Stats: 49 lines in 6 files changed: 19 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

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

From aturbanov at openjdk.org  Tue Jun 17 10:22:27 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 17 Jun 2025 10:22:27 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <I2n1BHIyHWVvvFA4DlF-a9D0a36RhaSuNdDnyKPu9ks=.8d150a80-c26b-4470-b000-eec5ba6ff0ef@github.com>

On Mon, 16 Jun 2025 09:46:11 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java line 242:

> 240:                 for (String dir : platformSupport.getTemporaryDirectories(pid)) {
> 241:                     Path fullPath = Path.of(dir, HSPERFDATA_PREFIX + user, String.valueOf(pid));
> 242:                     if(Files.exists(fullPath)) {

Suggestion:

                    if (Files.exists(fullPath)) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2151898308

From mdoerr at openjdk.org  Tue Jun 17 12:52:34 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 17 Jun 2025 12:52:34 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
 <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>
Message-ID: <NXEl1i8ECESz1PQoLstGmaOkzffoX_17X6Bsjqz7WGA=.1f7458a4-43b1-40c8-bade-895ddd7ded1e@github.com>

On Mon, 16 Jun 2025 23:35:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> > Seems like arm32 has the same issue:
> > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
> > 
> > The init value shouldn't have the sticky bit set.
> 
> Thanks, I pushed a potential fix for that.

Unfortunately, 0xBEAFDEAD also has the MSB set. Shouldn't we better use 0 like on all other platforms?

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2980261201

From dholmes at openjdk.org  Tue Jun 17 13:01:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 13:01:28 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2]
In-Reply-To: <mYJYh8k6VKawvSBU6lU4vp06PjAJ5MAw5FTaYzgqetQ=.1b21b0d8-5efc-4b77-9b10-190fc3b9443c@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <mYJYh8k6VKawvSBU6lU4vp06PjAJ5MAw5FTaYzgqetQ=.1b21b0d8-5efc-4b77-9b10-190fc3b9443c@github.com>
Message-ID: <_Ce1MuI4HkjVyZQh8qxL154B-EwBd4BuioSFiYI4nIQ=.557e82a2-65d9-498f-a95e-fea92264194b@github.com>

On Tue, 17 Jun 2025 08:53:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
>> 
>> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test

Sanity test seems okay. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2935569664

From syan at openjdk.org  Tue Jun 17 13:52:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 13:52:36 GMT
Subject: Integrated: 8359207: Remove runtime/signal/TestSigusr2.java since it
 is always skipped
In-Reply-To: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
References: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
Message-ID: <VhVf3cxvwLJ4lTDoo5abJrA4nHjzkF13L20IigjAsOo=.d2bdb9c6-c4cf-4d17-b97a-35a7f4a22606@github.com>

On Mon, 16 Jun 2025 09:56:47 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik.

This pull request has now been integrated.

Changeset: 51877f56
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51877f568ba84a8ec7721656571c90c5eb952eb3
Stats:     43 lines in 2 files changed: 0 ins; 41 del; 2 mod

8359207: Remove runtime/signal/TestSigusr2.java since it is always skipped

Reviewed-by: dcubed, dholmes

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

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

From syan at openjdk.org  Tue Jun 17 13:52:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 13:52:35 GMT
Subject: RFR: 8359207: Remove runtime/signal/TestSigusr2.java since it is
 always skipped
In-Reply-To: <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>
References: <t83E9eGBu9p1jD77tVRLLQYaqG-xoU1o2-SntYzJRPA=.aef16231-e33a-41ce-b931-b60bc8ba9e9c@github.com>
 <5OS0UxCE1hyzyRuYjmBlHn244ZTbQKSzZLFlo_0ECec=.c8018b49-1f09-4b0e-a5cb-ab4b14419ca2@github.com>
Message-ID: <a-2ShatVxfbVtIfP6JtNxTw2JHSwT3spvoJ0mW-FaLU=.fa8cf2a4-3002-43c9-a823-bd6a1211ff34@github.com>

On Mon, 16 Jun 2025 21:34:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Hi all,
>> 
>> The test `runtime/signal/TestSigusr2.java` has jtreg tag `@requires os.family != "windows" & os.family != "aix"`, and this test will skip on linux or macos(https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/signal/SigTestDriver.java#L59). Thus this test is always skipped indeed. So I want to removed this test. Test-fix only, no rsik.
>
> Please use "/issue JDK-8359207" as the easiest way to sync the PR title with the synopsis.

Thanks @dcubed-ojdk @dholmes-ora for the correction and reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25825#issuecomment-2980463950

From cstein at openjdk.org  Tue Jun 17 14:03:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Jun 2025 14:03:38 GMT
Subject: Integrated: 8357862: Java argument file is parsed unexpectedly with
 trailing comment
In-Reply-To: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
References: <gey-57OoSqtxNyNhLb2VuynwWHZSFPFqVMkRnmUjLPU=.ac3008d2-265e-441d-8bfd-1441c450b491@github.com>
Message-ID: <zHDzgy9rsA833UGhZKfiqPN5xwzglh00W-ZABFXH1f8=.8b1855e5-f7dd-4741-9d0a-38d5edead887@github.com>

On Mon, 2 Jun 2025 13:46:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this fix to correctly parse tokens in an argument file that contains trailing comments without preceding whitespace characters before the '#' comment marker, the number sign.
> 
> The specifaction of the `java` Command has in section [java Command-Line Argument Files](https://docs.oracle.com/en/java/javase/12/docs/specs/man/java.html#java-command-line-argument-files):
> 
> Use the number sign `#` in the argument file to identify comments.
> All characters following the `#` are ignored until the end of line.
> 
> There is not requirement specified to prepend a comment in a line with at least one argument with one or more preceding whitespace characters.

This pull request has now been integrated.

Changeset: 21b72dea
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21b72dea7805357b3644161d1a158c52f49d0e6e
Stats:     40 lines in 2 files changed: 29 ins; 7 del; 4 mod

8357862: Java argument file is parsed unexpectedly with trailing comment

Co-authored-by: Stuart Marks <smarks at openjdk.org>
Reviewed-by: vromero

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

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

From jsjolen at openjdk.org  Tue Jun 17 14:04:48 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 17 Jun 2025 14:04:48 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41]
In-Reply-To: <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>
Message-ID: <xBHBonGEwXm5cGH2zgqjA231cbHYV2jWlVEpwgEbxSI=.c21dfa6a-970c-4544-8e41-c69ae9212587@github.com>

On Tue, 17 Jun 2025 10:17:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes to a few failures.

LGTM!

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2935814156

From kvn at openjdk.org  Tue Jun 17 14:59:31 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 17 Jun 2025 14:59:31 GMT
Subject: RFR: 8359436: AOTCompileEagerly should not be diagnostic [v2]
In-Reply-To: <mYJYh8k6VKawvSBU6lU4vp06PjAJ5MAw5FTaYzgqetQ=.1b21b0d8-5efc-4b77-9b10-190fc3b9443c@github.com>
References: <dZEQ6cAv4KJjRLjmBDzqX0KPMDjmcbb9e--zVFx6B2g=.bf626b98-f39a-4955-b8e7-8f6c5dc14d09@github.com>
 <mYJYh8k6VKawvSBU6lU4vp06PjAJ5MAw5FTaYzgqetQ=.1b21b0d8-5efc-4b77-9b10-190fc3b9443c@github.com>
Message-ID: <C-EuvxpmtzYmgfq6WoogmzQLruaBv0N58yaE4SxvexU=.ddace1a9-7973-4524-bd52-d4eb8b4c1e70@github.com>

On Tue, 17 Jun 2025 08:53:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A new AOTCompileEagerly flag introduced by [JDK-8355003](https://bugs.openjdk.org/browse/JDK-8355003) is marked as diagnostic. However, this flag guards the experimental feature, that is, whether the existence of AOT profiles should trigger immediate JIT compilation. Therefore, this flag should be at least be "experimental", rather than "diagnostic".
>> 
>> I don't think it makes sense to elevate this flag to full product flag, since once AOT code caching arrives, this flag would default to true, and would cause AOT loads instead of JIT compilations. Disabling the flag by user choice would be significantly counter-productive then.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test

May be modify `aotProfile/AOTProfileFlags.java` instead.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCompileEagerly.java line 1:

> 1: /*

There is `aotProfile` directory for training data testing.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCompileEagerly.java line 27:

> 25: 
> 26: /*
> 27:  * @test

Missing ` * @bug 8359436`

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

PR Review: https://git.openjdk.org/jdk/pull/25799#pullrequestreview-2936031765
PR Review Comment: https://git.openjdk.org/jdk/pull/25799#discussion_r2152492526
PR Review Comment: https://git.openjdk.org/jdk/pull/25799#discussion_r2152487114

From eastigeevich at openjdk.org  Tue Jun 17 15:49:28 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 17 Jun 2025 15:49:28 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <j2uZXq3KOQirsenyKBfUJJZrKIFbk2F50xTKUNMXITo=.2e4ceda4-ae30-4a78-b18c-2869ef26a553@github.com>

On Tue, 17 Jun 2025 08:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

src/hotspot/share/cds/metaspaceShared.cpp line 1388:

> 1386:   }
> 1387:   if (RequireSharedSpaces && has_failed) {
> 1388:       MetaspaceShared::unrecoverable_loading_error("Unable to map shared spaces, but they were required");

If you want the message to be more specific, you might need to add whether the failed loading was dynamic or static.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2152609002

From eastigeevich at openjdk.org  Tue Jun 17 16:08:27 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Tue, 17 Jun 2025 16:08:27 GMT
Subject: RFR: 8359423: Improve error message in case of missing jsa shared
 archive
In-Reply-To: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
References: <LhjB0rkam9i1mj-8tnIqR9Ldwe68b5CUPJZwrak0mVk=.05e3b934-3495-4b1f-9045-db5ec9647332@github.com>
Message-ID: <wvsxFPhtAfov_kmaX7vFbIv8y_5FS0G5rZXJzqlkGVE=.4ba09c65-4b5b-4706-80df-8595d409c345@github.com>

On Tue, 17 Jun 2025 08:17:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In case we use `-Xshare:on` with additional flags (regarding coh or coops) and we have the corresponding jsa archive not present,
> we get this message/error :
> 
> 
> Error occurred during initialization of VM
> Unable to use shared archive.
> 
> 
> The error message could be a little improved, e.g. telling what jsa file is not present .
> For example
> 
> 
> ./images/jdk/bin/java -Xshare:on -version
> [0.017s][error][aot] Opening of static archive /build_linux/images/jdk/lib/server/classes.jsa failed
> Error occurred during initialization of VM
> Unable to use shared archive (unrecoverable archive loading error).

src/hotspot/share/cds/metaspaceShared.cpp line 1274:

> 1272:     vm_exit_during_initialization("Unable to use AOT cache.", nullptr);
> 1273:   } else {
> 1274:     vm_exit_during_initialization("Unable to use shared archive (unrecoverable archive loading error).", nullptr);

Who not to use message here instead of 'unrecoverable archive loading error'? The default message is 'unrecoverable error'. The default message can be updated to 'unrecoverable archive loading error'.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25846#discussion_r2152647530

From gziemski at openjdk.org  Tue Jun 17 16:46:48 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 17 Jun 2025 16:46:48 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41]
In-Reply-To: <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>
Message-ID: <Qdb_SyHf7a_ZSLSMj5wFZSzSUOvrUIPAuozvOwZC5EA=.bfe6907b-bfae-4276-ada8-5542c9a9bfe1@github.com>

On Tue, 17 Jun 2025 10:17:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes to a few failures.

Small changes (copyright years) and one question, otherwise LGTM.

Nice!

Marked as reviewed by gziemski (Reviewer).

src/hotspot/share/nmt/regionsTree.cpp line 2:

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

Copyright year

src/hotspot/share/nmt/regionsTree.hpp line 2:

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

Copyright year

test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 259:

> 257:   static void test_add_committed_region_overlapping() {
> 258:     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
> 259:     rtree->tree().remove_all();

Why are we calling `remove_all()` right after we create the tree?

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

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2936231261
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2936387120
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2152711203
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2152711676
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2152621722

From coleenp at openjdk.org  Tue Jun 17 17:18:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 17:18:38 GMT
Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper
Message-ID: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>

I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
Tested with test.

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

Commit messages:
 - 8359707: Add classfile modification code to RedefineClassHelper

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

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

From mdonovan at openjdk.org  Tue Jun 17 17:36:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 17 Jun 2025 17:36:31 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
 <NBeas7VSHxEynwU9LXuGy-p9Lg9Tm5I9auSaHBExzRA=.effd0ad3-a5f2-4049-b4df-49030a0502ef@github.com>
 <v45mu9Zly3T9l94b-WP1p_4oB_Y2Pe0gdU6C3w_vRqM=.ebaa8261-3d70-43a1-82b2-bba9def061a2@github.com>
 <8pLm1mah1JKonu3z5tWwIpU_J5jEggSiBst-PNEdG4s=.931782e4-3e34-4535-bc71-622d76b871a7@github.com>
Message-ID: <I79KijRZOM7Stzc7Sax_hFgxyPD_sEV2xaHZVipl2y4=.6f2fbe79-555c-4d04-9c38-25cea18075c5@github.com>

On Tue, 10 Jun 2025 07:47:29 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself? Or are you envisaging enabling it at the test-level so the person running the tests doesn't have to do so? But then how does that affect the overall jtreg log content. ??
>
> To add on this, I should mention that I noticed a lot of tests are using OutputAnalyzer indirectly, returned as a result of a utility function, for example `ProcessTools.execute{Process,Command}`
> 
> 
> git grep -E "ProcessTools.execute((Process)|(Command))" | wc -l
>      351
> 
> 
> Instead of calling one of OutputAnalyzer's constructors (700 invocations, but many of them are with the Eager, string based and not process based, constructor, which we don't care about)
> 
> 
> I'm not sure adding additional parameters also to that code is an ideal solution, I'd much prefer adding the command line parameter to the docs of the OutputAnalyzer class, so that one knows to enable it when running the single test through jtreg
> 
> ---
> 
> That said, if there are multiple OutputAnalyzers going in a single test, then it makes perfect sense to have (or at least use) a constructor argument

> But isn't it the person running the tests that wants to set this, not an inherent property of a test itself?

I'm not sure if I completely understand your question. A lot of tests use the `test.debug` system property to enable more verbose test output. It's enabled when someone runs the test e.g., `jtreg -Dtest.debug=true ...`

As you pointed out, a lot of tests may not care if the subprocess's output is cached or not, but for those that do, having to specify a second property could be onerous and using the same `test.debug` property inside OutputBuffer could result in unexpected output. If the OutputAnalyzer ctor took a boolean , a test could enable (or not) with something like `new OutputAnalyzer(childProc, Boolean.getBoolean("test.debug"))`

> I'm not sure adding additional parameters also to that code is an ideal solution,

There are two constructors that take Process objects as arguments. I was thinking that you could overload them to take the extra argument. 


public OutputAnalyzer(Process process, Charset cs, boolean flushOutput)
public OutputAnalyzer(Process process, boolean flushOutput)


None of the existing tests would be affected and those tests that could benefit from inline output could specify it as needed. You're right that the use of OutputAnalyzer is usually indirect so that would cause some other code to be changed as well, but it only has to change when it becomes necessary to enable it. (And it can be updated in the same way i.e., overloading the methods to take an extra argument.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25587#discussion_r2152810288

From dlong at openjdk.org  Tue Jun 17 20:55:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 20:55:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <NXEl1i8ECESz1PQoLstGmaOkzffoX_17X6Bsjqz7WGA=.1f7458a4-43b1-40c8-bade-895ddd7ded1e@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
 <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>
 <NXEl1i8ECESz1PQoLstGmaOkzffoX_17X6Bsjqz7WGA=.1f7458a4-43b1-40c8-bade-895ddd7ded1e@github.com>
Message-ID: <87D1GHpnuO66YKnlxRh6JOlp7AZoZxhLBDbCpUG230A=.9119d110-62ba-4083-9a85-9bf78f5b462b@github.com>

On Tue, 17 Jun 2025 12:50:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > Seems like arm32 has the same issue:
> > > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
> > > 
> > > The init value shouldn't have the sticky bit set.
> > 
> > 
> > Thanks, I pushed a potential fix for that.
> 
> Unfortunately, 0xBEAFDEAD also has the MSB set. Shouldn't we better use 0 like on all other platforms?

Oops, I was tripped up trying to be clever.  Yes, I'm fine with using 0.  I'll fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2981800170

From dlong at openjdk.org  Tue Jun 17 20:59:46 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 20:59:46 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

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

  2nd try at arm fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/3ac6dec0..3e306dde

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

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

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

From sspitsyn at openjdk.org  Tue Jun 17 22:33:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 22:33:28 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper
In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
Message-ID: <je7381Rh9o9MqPD80nuDPm0SIDG4xQM8XtbbtMcClNo=.425818b1-cd31-479c-9e10-43c1c75e72d5@github.com>

On Tue, 17 Jun 2025 17:11:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
> Tested with test.

This looks reasonable. I've posted one nit suggestion.

test/lib/RedefineClassHelper.java line 104:

> 102:      */
> 103: 
> 104:     public static byte[] replaceAllStrings(ClassLoader loader, String oldString, String newString) throws Exception {

Nit: I'd suggest to rename parameters:
  `oldString`  => `oldClassName`
  `newString` => `newClassName`

Alternatively, it is possible to pass bytecodes buffer instead of class loader and keep `oldString` and `newString` as before.

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

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2937246161
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2153274007

From dholmes at openjdk.org  Wed Jun 18 04:43:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Jun 2025 04:43:29 GMT
Subject: RFR: 8356438: Update OutputAnalyzer to optionally print process
 output as it happens [v2]
In-Reply-To: <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
References: <cP-uMB2zwWrYPT2EOx-VpGAIaLjQY1YgkdQwehdjfo8=.d99ee1cf-5f91-40de-a5d1-fe6b762d1673@github.com>
 <J_G9wvyovxUuO0JdFMqnD7jvqUflEglF5L7qqvBc6-w=.e0def3d2-eb40-4167-b304-143f9d4c615d@github.com>
Message-ID: <_aliNvujYU-gs7CUS7oB8VPK595xV4OLnd82vJwYTIY=.6b041c7e-3907-4217-b8ef-a59404ac0a08@github.com>

On Thu, 5 Jun 2025 09:36:37 GMT, Alice Pellegrini <duke at openjdk.org> wrote:

>> The implemented solution modifies the `OutputBuffer` implementation instead of the `OutputAnalyzer` implementation.
>> This is because the **OutputBuffer implementation which handles processes** (LazyOutputBuffer) starts a thread in its constructor, so we would need to add a strange additional constructor parameter to the `OutputBuffer.of(Process, Charset)` static method, while the printing through to stdout (and stderr) only makes sense for LazyOutputBuffer.
>> 
>> I believe changing the config option from `outputanalyzer.verbose` to `output buffer.verbose` would make it cleaner, and avoid referencing the OutputAnalyzer in the OutputBuffer implementation.
>
> Alice Pellegrini has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8356438-outputanalyzer-optional-print
>  - Update test/lib/jdk/test/lib/process/OutputBuffer.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Initial working solution

> A lot of tests use the test.debug system property to enable more verbose test output. It's enabled when someone runs the test e.g., jtreg -Dtest.debug=true ...

I see a few tests that do that, nearly all of which are network tests. It is not something I was familiar with. But it doesn't seem right to me that a particular test would use that property to change the behaviour of `OutputAnalyzer`. I also don't think the test should have to opt-in to this kind of behaviour rather than it being directly controlled by the person running the tests. To that end I would see `OutputAnalyzer` examining a  specific property, e.g. `OutputAnalyzer.printToStdStreams` to control this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25587#issuecomment-2982650756

From mdoerr at openjdk.org  Wed Jun 18 08:33:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Jun 2025 08:33:37 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <sc4GKWY-5ptN8_s6UfuDx26vLOMpv23NNw-74eRGNNo=.13ccc52e-49e5-495f-9fe6-6dd922a8a2c2@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

Recent changes look good. Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2938255719

From yzheng at openjdk.org  Wed Jun 18 08:51:03 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 18 Jun 2025 08:51:03 GMT
Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even
 when logging is disabled
Message-ID: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>

When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message:

Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed.

This PR skips reporting loading error when CDS and AOT loggings are disabled.

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

Commit messages:
 - CDS and AOT can cause buffer truncation warning even when logging is disabled

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

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

From azafari at openjdk.org  Wed Jun 18 09:04:36 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 18 Jun 2025 09:04:36 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v42]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <mq9MEHXOVafjymOJGb0xyze9Kqr8EUm1xCtqA0aA2Xc=.7426736a-3bcb-44b5-8f04-a815eaa2f3af@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

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

  copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/815092d2..ac151586

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=40-41

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

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

From dnsimon at openjdk.org  Wed Jun 18 09:07:29 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 18 Jun 2025 09:07:29 GMT
Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even
 when logging is disabled
In-Reply-To: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
References: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
Message-ID: <p-wM8PUwwJCAyxbCfVLSz3b_DTlKoP3tqsoCRMcFL0Q=.9dc1c825-be07-453e-9e04-ff5baf9688ad@github.com>

On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message:
> 
> Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed.
> 
> This PR skips reporting loading error when CDS and AOT loggings are disabled.

LGTM

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25866#pullrequestreview-2938374154

From jsjolen at openjdk.org  Wed Jun 18 09:10:49 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 18 Jun 2025 09:10:49 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v42]
In-Reply-To: <mq9MEHXOVafjymOJGb0xyze9Kqr8EUm1xCtqA0aA2Xc=.7426736a-3bcb-44b5-8f04-a815eaa2f3af@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <mq9MEHXOVafjymOJGb0xyze9Kqr8EUm1xCtqA0aA2Xc=.7426736a-3bcb-44b5-8f04-a815eaa2f3af@github.com>
Message-ID: <TE5VW_A31IrqgYjgyiT-RpIsPvKS9DKhl6e_7ANnm6w=.3b8f56a2-4984-4300-ba6c-e7f2577d8979@github.com>

On Wed, 18 Jun 2025 09:04:36 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright years

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2938381625

From azafari at openjdk.org  Wed Jun 18 09:10:51 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 18 Jun 2025 09:10:51 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41]
In-Reply-To: <Qdb_SyHf7a_ZSLSMj5wFZSzSUOvrUIPAuozvOwZC5EA=.bfe6907b-bfae-4276-ada8-5542c9a9bfe1@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>
 <Qdb_SyHf7a_ZSLSMj5wFZSzSUOvrUIPAuozvOwZC5EA=.bfe6907b-bfae-4276-ada8-5542c9a9bfe1@github.com>
Message-ID: <00eARElwnxkitXuqWa5uDdul1WafVU6fUGcmnIOJIV4=.7d9fc71c-be40-468d-8f14-adb98f4e3eb6@github.com>

On Tue, 17 Jun 2025 16:37:22 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixes to a few failures.
>
> src/hotspot/share/nmt/regionsTree.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright year

Done.

> src/hotspot/share/nmt/regionsTree.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright year

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2154077488
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2154077012

From azafari at openjdk.org  Wed Jun 18 09:14:47 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 18 Jun 2025 09:14:47 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v41]
In-Reply-To: <Qdb_SyHf7a_ZSLSMj5wFZSzSUOvrUIPAuozvOwZC5EA=.bfe6907b-bfae-4276-ada8-5542c9a9bfe1@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <000AGCwbLZRbmxAGfatjpOnEFz_Ym2fMmDBaHgvV96w=.6b3c0c5c-0480-4036-8052-1b7ba8dabfd3@github.com>
 <Qdb_SyHf7a_ZSLSMj5wFZSzSUOvrUIPAuozvOwZC5EA=.bfe6907b-bfae-4276-ada8-5542c9a9bfe1@github.com>
Message-ID: <Rai3JV0_lDnHCt5ZaqasNwIY3HyEYIjjcGG5Tia-GDU=.39dac74e-a2a9-4b41-91af-05679c5d65d0@github.com>

On Tue, 17 Jun 2025 15:53:04 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixes to a few failures.
>
> test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp line 259:
> 
>> 257:   static void test_add_committed_region_overlapping() {
>> 258:     RegionsTree* rtree = VirtualMemoryTracker::Instance::tree();
>> 259:     rtree->tree().remove_all();
> 
> Why are we calling `remove_all()` right after we create the tree?

We are not creating the tree here. We just retrieve it from the Instance of VMT. Since the tree is also visible to other tests (it is static and not created per test), any changes in other tests will be visible here by this test. This is not as expected in the design of the tests (tests assume that tree is empty at the beginning of the test).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r2154087590

From azafari at openjdk.org  Wed Jun 18 09:20:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 18 Jun 2025 09:20:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v43]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <p3VR-CDGhhBuaPhf6Y1tm_g2jx0npLFA71QSEo2fQT0=.596b7f77-c86b-4895-bdb1-9f20e67bd1c7@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 89 commits:

 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - copyright years
 - fixes to a few failures.
 - changes after merge
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - fixes after merge with master.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - more reviews.
 - review comments applied
 - ... and 79 more: https://git.openjdk.org/jdk/compare/2b94b70e...66ddc675

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

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=42
  Stats: 1459 lines in 27 files changed: 571 ins; 567 del; 321 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

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

From eosterlund at openjdk.org  Wed Jun 18 11:36:30 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 18 Jun 2025 11:36:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
Message-ID: <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>

On Tue, 17 Jun 2025 00:02:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114:
>> 
>>> 112:   // Preserve the sticky bit
>>> 113:   if (is_not_entrant(nm)) {
>>> 114:     value |= not_entrant;
>> 
>> Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant?
>> 
>> If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier.
>
> If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
> And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.

My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
Does that make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2154370247

From azafari at openjdk.org  Wed Jun 18 11:40:54 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 18 Jun 2025 11:40:54 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v31]
In-Reply-To: <bkhUaGD4FoAP9TSk7uU3AuQEpmYsXr0dgxmZC3i0gpc=.87ccd0cb-1c4d-4a70-b023-90e179889d74@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <M5dtVpqx-_fZb4jN_tpNknGIQjctogvUWQiLwkuedYc=.22b1b1d6-39e5-4314-8660-269bcc2c57ca@github.com>
 <bkhUaGD4FoAP9TSk7uU3AuQEpmYsXr0dgxmZC3i0gpc=.87ccd0cb-1c4d-4a70-b023-90e179889d74@github.com>
Message-ID: <Jt6QRkE0OPZ7qCKDSbEthp0UbW1HTNu7lZnvf-qpqss=.dbcc44b2-2c46-4dea-96d2-60c2b3ca4557@github.com>

On Tue, 25 Feb 2025 15:40:54 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews applied.
>
> How would I go about verifying the performance gain? You mentioned previously that you wrote a microbenchmark for testing this?

Thanks for reviews @gerard-ziemski and @jdksjolen.

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

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2983833167

From azafari at openjdk.org  Wed Jun 18 11:40:56 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 18 Jun 2025 11:40:56 GMT
Subject: Integrated: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <BZRRNy6op3JUqVtrP3d3AGncclJbCfdOEDLs-efeze0=.3176411b-a32f-4039-bd39-a9e299d841a2@github.com>

On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167.

This pull request has now been integrated.

Changeset: 547ce030
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/547ce0301684fdebe95ce2e8e195a019bcefe493
Stats:     1459 lines in 27 files changed: 571 ins; 567 del; 321 mod

8337217: Port VirtualMemoryTracker to use VMATree

Reviewed-by: jsjolen, gziemski

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

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

From coleenp at openjdk.org  Wed Jun 18 11:52:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 11:52:17 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
Message-ID: <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>

> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
> Tested with test.

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

  Add a byte buffer version and rename parameters.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/3654034f..6bc1ca59

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

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

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

From coleenp at openjdk.org  Wed Jun 18 11:52:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 11:52:18 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <je7381Rh9o9MqPD80nuDPm0SIDG4xQM8XtbbtMcClNo=.425818b1-cd31-479c-9e10-43c1c75e72d5@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <je7381Rh9o9MqPD80nuDPm0SIDG4xQM8XtbbtMcClNo=.425818b1-cd31-479c-9e10-43c1c75e72d5@github.com>
Message-ID: <9JI9OF3xPXV3uMSXT4Upg7lQCPgfSy32jCd8T7Z62rU=.89eb5211-0b7e-4b80-98f0-aecea4e6365c@github.com>

On Tue, 17 Jun 2025 22:29:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a byte buffer version and rename parameters.
>
> test/lib/RedefineClassHelper.java line 104:
> 
>> 102:      */
>> 103: 
>> 104:     public static byte[] replaceAllStrings(ClassLoader loader, String oldString, String newString) throws Exception {
> 
> Nit: I'd suggest to rename parameters:
>   `oldString`  => `oldClassName`
>   `newString` => `newClassName`
> 
> Alternatively, it is possible to pass bytecodes buffer instead of class loader and keep `oldString` and `newString` as before.

I wanted this code to also read bytecodes off the disk and not the caller do that either.  The code for getBytecodes or very similar is duplicated all over the tests also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2154384879

From coleenp at openjdk.org  Wed Jun 18 11:52:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 11:52:18 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <9JI9OF3xPXV3uMSXT4Upg7lQCPgfSy32jCd8T7Z62rU=.89eb5211-0b7e-4b80-98f0-aecea4e6365c@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <je7381Rh9o9MqPD80nuDPm0SIDG4xQM8XtbbtMcClNo=.425818b1-cd31-479c-9e10-43c1c75e72d5@github.com>
 <9JI9OF3xPXV3uMSXT4Upg7lQCPgfSy32jCd8T7Z62rU=.89eb5211-0b7e-4b80-98f0-aecea4e6365c@github.com>
Message-ID: <RLiAbyGka3xCGPptiMH__VKkerGhw0zxk7LLRynYtds=.b1269eb5-c79a-49f9-a945-3f07ac4f65f1@github.com>

On Wed, 18 Jun 2025 11:41:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/lib/RedefineClassHelper.java line 104:
>> 
>>> 102:      */
>>> 103: 
>>> 104:     public static byte[] replaceAllStrings(ClassLoader loader, String oldString, String newString) throws Exception {
>> 
>> Nit: I'd suggest to rename parameters:
>>   `oldString`  => `oldClassName`
>>   `newString` => `newClassName`
>> 
>> Alternatively, it is possible to pass bytecodes buffer instead of class loader and keep `oldString` and `newString` as before.
>
> I wanted this code to also read bytecodes off the disk and not the caller do that either.  The code for getBytecodes or very similar is duplicated all over the tests also.

I can add a byte buffer version though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2154398739

From jsjolen at openjdk.org  Wed Jun 18 12:16:38 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 18 Jun 2025 12:16:38 GMT
Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker
 [v3]
In-Reply-To: <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
References: <mVv-IomtzU25S1Xv1kQAy0gkUYPmuOLFDc-bJskDTaY=.c434ab86-536f-4e22-9dfa-64a00274c06b@github.com>
 <XTCTiot9phOVQqQh70O-hDD1TDVhNY0AVqkApZ4Ne-o=.21b610a9-8c2f-4c64-94a1-df7c31752530@github.com>
Message-ID: <VyWYXgTSRRU837ZqpWAWiUbE033ZNugefwhgI2Zyq8c=.28575626-5fee-4618-87eb-075d3cca71b7@github.com>

On Thu, 12 Jun 2025 09:23:24 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Renamed usage of 'category' for 'MemTag' cases.
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into _8353444_mem_category_to_memtag
>  - fixed a missed test.
>  - user-facing terms remained as 'category'
>  - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker

Marked as reviewed by jsjolen (Reviewer).

test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java line 3:

> 1: /*
> 2:  * Copyright (c) 2022 SAP SE. All rights reserved.
> 3:  * Copyright (c) 2022, 2025, Oracle and/or its affiliates. All rights reserved.

Revert this copyright notice.

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

PR Review: https://git.openjdk.org/jdk/pull/25226#pullrequestreview-2938961864
PR Review Comment: https://git.openjdk.org/jdk/pull/25226#discussion_r2154444880

From jwilhelm at openjdk.org  Wed Jun 18 12:59:30 2025
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 18 Jun 2025 12:59:30 GMT
Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code
In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
Message-ID: <IbTrS-RVXQC_4CQVsr98e0L6H7lVi2khN85BMHpjj3o=.d182980e-3eff-413e-a8d0-1f09aeb13df6@github.com>

On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function.

Looks good to me.

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

Marked as reviewed by jwilhelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25722#pullrequestreview-2939108367

From cnorrbin at openjdk.org  Wed Jun 18 14:01:43 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 18 Jun 2025 14:01:43 GMT
Subject: RFR: 8358891: Remove the PerfDataSamplingIntervalFunc code
In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
Message-ID: <f6MtqcaTUieuKdMpmBfbiYFbZFGO9hOp-ixLiNJs184=.88053064-78cb-4e15-a1af-cdfa7314e78d@github.com>

On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25722#issuecomment-2984338348

From cnorrbin at openjdk.org  Wed Jun 18 14:01:43 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 18 Jun 2025 14:01:43 GMT
Subject: Integrated: 8358891: Remove the PerfDataSamplingIntervalFunc code
In-Reply-To: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
References: <1-LBtL3DEAvgqdCzGv8Ni6lm8n15zkcsx9-H6E8vdc0=.7f6a784e-7f14-4dab-b2da-a442d986afd4@github.com>
Message-ID: <-yjwc87ksQ3nPpufDK2uuKpRYtkHgsFDYB5hHs6h40I=.455c89e4-c5ef-45b9-aa9d-b6abdfddceb8@github.com>

On Tue, 10 Jun 2025 12:34:47 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> #24872 removed the statsampler and the associated flag `PerfDataSamplingInterval`. However, the constraint function for the flag got overlooked. This change removes that function.

This pull request has now been integrated.

Changeset: cf789258
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf78925859dd2640b3c2500fc6be8b5bb308d96e
Stats:     13 lines in 2 files changed: 0 ins; 13 del; 0 mod

8358891: Remove the PerfDataSamplingIntervalFunc code

Reviewed-by: shade, jwilhelm

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

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

From schernyshev at openjdk.org  Wed Jun 18 16:40:53 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 18 Jun 2025 16:40:53 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
Message-ID: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>

> Hi all,
> 
> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
> 
> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
> 
> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
> 
> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
> 
> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
> 
> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
> 
> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the JVM being attached to.
> 
> The pa...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25824/files
  - new: https://git.openjdk.org/jdk/pull/25824/files/9fd3781d..779a1b35

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

  Stats: 155 lines in 4 files changed: 79 ins; 74 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25824/head:pull/25824

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

From schernyshev at openjdk.org  Wed Jun 18 16:40:53 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 18 Jun 2025 16:40:53 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>
Message-ID: <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@github.com>

On Tue, 17 Jun 2025 04:51:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - addressed review comments
>
> src/hotspot/os/posix/perfMemory_posix.cpp line 133:
> 
>> 131: //
>> 132: 
>> 133: #ifdef __APPLE__
> 
> This is a bit too much non-posix code in the posix file IMO. I'd rather see a `MACOS_ONLY` call later on to something defined in `os_bsd.cpp` for macOS.

Thanks @dholmes-ora , I moved the function to `os_bsd.cpp`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25824#discussion_r2155061182

From dcubed at openjdk.org  Wed Jun 18 18:01:34 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 18 Jun 2025 18:01:34 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <8-K1wPHmyNI27RRTsvvuUdQJmt44m5QDr6cyt9hhLXQ=.ee86ccc9-839f-4af9-90eb-5d3a46b66ccf@github.com>
Message-ID: <nEqMh1GsNVg2KIXi4I-68dtgOilK87TmWK8R_AaNGMk=.b8b4b2b3-8842-46c0-88fa-c0d84f5b423f@github.com>

On Wed, 18 Jun 2025 16:40:53 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same approach on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to the ...
>
> Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments

For macOS questions, I usually ping Gerard (@gerard-ziemski).

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-2985227813

From mdoerr at openjdk.org  Wed Jun 18 19:59:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Jun 2025 19:59:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <7dqmRsrYN1O1zVQSYvFbVpmjSSABHnw7dL8QXSkrOtE=.eceed621-7482-436e-a999-73b6d2611616@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

Unfortunately, there's a merge conflict, now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2985526434

From mdoerr at openjdk.org  Wed Jun 18 19:59:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Jun 2025 19:59:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
Message-ID: <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>

On Wed, 18 Jun 2025 11:34:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
>> And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.
>
> My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
> Does that make sense?

Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155390909

From iklam at openjdk.org  Wed Jun 18 20:23:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 18 Jun 2025 20:23:29 GMT
Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even
 when logging is disabled
In-Reply-To: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
References: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
Message-ID: <PSEG1B3SvR1GhHUYymfEq7wAF167y5XosCu_RVQWumQ=.45442c70-6ceb-4f4f-b534-7e3acecb1240@github.com>

On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message:
> 
> Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed.
> 
> This PR skips reporting loading error when CDS and AOT loggings are disabled.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25866#pullrequestreview-2940556792

From eosterlund at openjdk.org  Wed Jun 18 20:28:29 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 18 Jun 2025 20:28:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
Message-ID: <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>

On Wed, 18 Jun 2025 19:56:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
>> Does that make sense?
>
> Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.

Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155434971

From dlong at openjdk.org  Thu Jun 19 00:22:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 19 Jun 2025 00:22:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
 <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
Message-ID: <NDd13XSxcbkLkY1hPDt7hlRUAo_3zlHikMaBpAHy8po=.c399c3e1-df5e-4ea8-a667-68d12bac991a@github.com>

On Wed, 18 Jun 2025 20:25:44 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.
>
> Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think?

I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand.  Arming the barrier is not guaranteed to be visible until there is a safepoint.  Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155757120

From azafari at openjdk.org  Thu Jun 19 09:19:30 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 19 Jun 2025 09:19:30 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test'
 missing from stdout/stderr
Message-ID: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>

The test expects that two disjunct regions are reserved but checked it incompletely.
It is fixed by reserving a region with triple required size and then released the middle part.

 Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers.

Tested local linux-x64-debug.

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

Commit messages:
 - 8359959: Test runtime/NMT/VirtualAllocTestType.java failed: '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for Test' missing from stdout/stderr

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

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

From dholmes at openjdk.org  Thu Jun 19 12:31:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 12:31:44 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr
In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
Message-ID: <scUJeD0WtYZiPmGnjQkFB4MXdhTReapZ-jmNH1E4GZ4=.c821df98-f359-47df-9fe8-b5d8adefa1f2@github.com>

On Thu, 19 Jun 2025 09:14:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The test expects that two disjunct regions are reserved but checked it incompletely.
> It is fixed by reserving a region with triple required size and then released the middle part.
> 
>  Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers.
> 
> Tested local linux-x64-debug.

test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 65:

> 63: 
> 64:       // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for
> 65:       // this test, we want to see two disjunct mappings.

The comment no longer seems quite accurate.

test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 66:

> 64:       // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for
> 65:       // this test, we want to see two disjunct mappings.
> 66:       if ((addr2 == addr1 + reserveSize) || (addr2 + reserveSize == addr1)) {

Suggestion:

      if ((addr2 == addr1 + reserveSize) || (addr2 == addr1 - reserveSize)) {

I find this formulation somewhat clearer in indicating `addr2` is adjacent after, or adjacent before `addr1`.

test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 72:

> 70: 
> 71:         wb.NMTReleaseMemory(addr1, reserveSize);
> 72:         wb.NMTReleaseMemory(addr2, reserveSize);

Just to be clear we are only releasing the original mappings to keep things consistent? And we could do this before reserving the new three region mapping - right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156896654
PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156894465
PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156901328

From azafari at openjdk.org  Thu Jun 19 12:50:20 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 19 Jun 2025 12:50:20 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr [v2]
In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
Message-ID: <MxyOfvCWha-qSzwzIKZdUjM1LeBOQLn7gyyw9jH6ItU=.dfd94eae-c82e-41c5-b5a6-fdb6d48cedc9@github.com>

> The test expects that two disjunct regions are reserved but checked it incompletely.
> It is fixed by reserving a region with triple required size and then released the middle part.
> 
>  Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers.
> 
> Tested local linux-x64-debug.

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

  another approach.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25894/files
  - new: https://git.openjdk.org/jdk/pull/25894/files/d24755a5..5c90d0a0

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

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

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

From azafari at openjdk.org  Thu Jun 19 12:55:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 19 Jun 2025 12:55:28 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr [v2]
In-Reply-To: <scUJeD0WtYZiPmGnjQkFB4MXdhTReapZ-jmNH1E4GZ4=.c821df98-f359-47df-9fe8-b5d8adefa1f2@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
 <scUJeD0WtYZiPmGnjQkFB4MXdhTReapZ-jmNH1E4GZ4=.c821df98-f359-47df-9fe8-b5d8adefa1f2@github.com>
Message-ID: <ivu2QKVL1mOVVDr-Xn9ks-xYkVr51p6GHIEj_hw4mEQ=.9e68479a-47a7-4c3e-aa79-ad75b8c9dcef@github.com>

On Thu, 19 Jun 2025 12:24:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   another approach.
>
> test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 66:
> 
>> 64:       // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for
>> 65:       // this test, we want to see two disjunct mappings.
>> 66:       if ((addr2 == addr1 + reserveSize) || (addr2 + reserveSize == addr1)) {
> 
> Suggestion:
> 
>       if ((addr2 == addr1 + reserveSize) || (addr2 == addr1 - reserveSize)) {
> 
> I find this formulation somewhat clearer in indicating `addr2` is adjacent after, or adjacent before `addr1`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156959698

From azafari at openjdk.org  Thu Jun 19 13:03:02 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 19 Jun 2025 13:03:02 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr [v3]
In-Reply-To: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
Message-ID: <NDsGug6xjxY1xzi_JZGQvMmvrVyd1WG-x0xuyKEdykM=.daeaedc1-bbd0-486e-af38-ce327139b802@github.com>

> The test expects that two disjunct regions are reserved but checked it incompletely.
> It is fixed by reserving a region with triple required size and then released the middle part.
> 
>  Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers.
> 
> Tested local linux-x64-debug.

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

  reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25894/files
  - new: https://git.openjdk.org/jdk/pull/25894/files/5c90d0a0..55795425

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

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

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

From azafari at openjdk.org  Thu Jun 19 13:03:02 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 19 Jun 2025 13:03:02 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr [v3]
In-Reply-To: <scUJeD0WtYZiPmGnjQkFB4MXdhTReapZ-jmNH1E4GZ4=.c821df98-f359-47df-9fe8-b5d8adefa1f2@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
 <scUJeD0WtYZiPmGnjQkFB4MXdhTReapZ-jmNH1E4GZ4=.c821df98-f359-47df-9fe8-b5d8adefa1f2@github.com>
Message-ID: <bii_NoNel4avjRrc7D5MX7TnihyvBFJ6zi9Z9nK5qEo=.2732a141-147a-41c1-b0ba-8c4a431cec67@github.com>

On Thu, 19 Jun 2025 12:25:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 65:
> 
>> 63: 
>> 64:       // If the second mapping happens to be adjacent to the first mapping, reserve another mapping and release the second mapping; for
>> 65:       // this test, we want to see two disjunct mappings.
> 
> The comment no longer seems quite accurate.

Updated.

> test/hotspot/jtreg/runtime/NMT/VirtualAllocTestType.java line 72:
> 
>> 70: 
>> 71:         wb.NMTReleaseMemory(addr1, reserveSize);
>> 72:         wb.NMTReleaseMemory(addr2, reserveSize);
> 
> Just to be clear we are only releasing the original mappings to keep things consistent? And we could do this before reserving the new three region mapping - right?

Not applicable in new approach. PR description is updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156967720
PR Review Comment: https://git.openjdk.org/jdk/pull/25894#discussion_r2156968098

From duke at openjdk.org  Thu Jun 19 13:18:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 19 Jun 2025 13:18:38 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation
Message-ID: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>

[JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.

Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.

Proposed changes in the shared class hierarchy:


//  VM_Operation
//    VM_Heap_Sync_Operation
//      VM_GC_Operation
//        VM_GC_Collect_Operation
//          VM_SerialGCCollect
//          VM_ParallelGCCollect
//          VM_CollectForAllocation
//            VM_SerialCollectForAllocation
//            VM_ParallelCollectForAllocation
//          VM_CollectForMetadataAllocation
//        VM_GC_Service_Operation
//          VM_GC_HeapInspection
//      VM_Verify
//      VM_PopulateDynamicDumpSharedSpace
//      VM_PopulateDumpSharedSpace


Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".

ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.

The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.

_Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot more overrides..._

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

Commit messages:
 - Add comment about is_gc_operation in base class
 - Align to ZGC styling
 - Reorganize GC VM operations and implement is_gc_operation

Changes: https://git.openjdk.org/jdk/pull/25896/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25896&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360024
  Stats: 80 lines in 12 files changed: 44 ins; 0 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/25896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25896/head:pull/25896

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

From yzheng at openjdk.org  Thu Jun 19 15:52:34 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 19 Jun 2025 15:52:34 GMT
Subject: RFR: 8358686: CDS and AOT can cause buffer truncation warning even
 when logging is disabled
In-Reply-To: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
References: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
Message-ID: <cawSd5rbO5_Ycbtnkl5Oz0slGesDC9jXozBV9MKzNNU=.a47ccfbe-c6a2-45e5-b74e-557a4b58e6da@github.com>

On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message:
> 
> Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed.
> 
> This PR skips reporting loading error when CDS and AOT loggings are disabled.

Thanks for the reviews! Passed tier1-3

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

PR Comment: https://git.openjdk.org/jdk/pull/25866#issuecomment-2987088457

From yzheng at openjdk.org  Thu Jun 19 15:52:34 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 19 Jun 2025 15:52:34 GMT
Subject: Integrated: 8358686: CDS and AOT can cause buffer truncation warning
 even when logging is disabled
In-Reply-To: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
References: <OY3H_l93etHDJ8sm-INWVxtoQWAsEJO-bKhsBbxGYBE=.dba4c8bd-4edb-4690-a053-5c4bd7585fda@github.com>
Message-ID: <zCqCdone-XGvr695qrOcxGad9lLjmVr0RGwuXPuTyJc=.5bf0deec-22e0-4109-9ca9-802bba516c78@github.com>

On Wed, 18 Jun 2025 08:46:04 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> When CDS and AOT loggings are disabled, HotSpot may still warn about `Mismatched values for property jdk.module.addexports:`. This warn message could be large and exceeds the current logging buffer length, and it leads to a non-informative message:
> 
> Java HotSpot(TM) 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 4276 bytes are needed.
> 
> This PR skips reporting loading error when CDS and AOT loggings are disabled.

This pull request has now been integrated.

Changeset: 2e3bdec9
Author:    Yudi Zheng <yzheng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e3bdec9857c64b307737ac7afed58170125cca9
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8358686: CDS and AOT can cause buffer truncation warning even when logging is disabled

Reviewed-by: dnsimon, iklam

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

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

From dholmes at openjdk.org  Thu Jun 19 23:08:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 23:08:28 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr [v3]
In-Reply-To: <NDsGug6xjxY1xzi_JZGQvMmvrVyd1WG-x0xuyKEdykM=.daeaedc1-bbd0-486e-af38-ce327139b802@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
 <NDsGug6xjxY1xzi_JZGQvMmvrVyd1WG-x0xuyKEdykM=.daeaedc1-bbd0-486e-af38-ce327139b802@github.com>
Message-ID: <4iDObr9QhghdmSQ9Vp-p1q8InjVsYRmTdWQe0tly388=.51b8b3a5-c0b0-4afa-8360-db594682bb68@github.com>

On Thu, 19 Jun 2025 13:03:02 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The test expects that two disjunct regions are reserved but checked it incompletely.
>> It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions.
>> In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid.
>>  
>>  Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers.
>> 
>> Tested local linux-x64-debug.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

Okay - I think I follow that.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25894#pullrequestreview-2944169350

From dholmes at openjdk.org  Fri Jun 20 04:43:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Jun 2025 04:43:27 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation
In-Reply-To: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
Message-ID: <ZQ2T-yHO_lX8l_gyZRNR0BCKkG4DXhXoAWX55SBaHt0=.85d92299-203d-4a2f-8d28-b70f23a7d92d@github.com>

On Thu, 19 Jun 2025 11:26:26 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
> 
> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
> 
> Proposed changes in the shared class hierarchy:
> 
> 
> //  VM_Operation
> //    VM_Heap_Sync_Operation
> //      VM_GC_Operation
> //        VM_GC_Collect_Operation
> //          VM_SerialGCCollect
> //          VM_ParallelGCCollect
> //          VM_CollectForAllocation
> //            VM_SerialCollectForAllocation
> //            VM_ParallelCollectForAllocation
> //          VM_CollectForMetadataAllocation
> //        VM_GC_Service_Operation
> //          VM_GC_HeapInspection
> //      VM_Verify
> //      VM_PopulateDynamicDumpSharedSpace
> //      VM_PopulateDumpSharedSpace
> 
> 
> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
> 
> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
> 
> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
> 
> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot...

This looks quite reasonable to me. Obviously GC folk get final approval.

One minor nit.

src/hotspot/share/gc/shared/gcVMOperations.hpp line 188:

> 186:                     GCCause::_heap_inspection /* GC Cause */,
> 187:                     0 /* total full collections, dummy, ignored */,
> 188:                     request_full_gc), _out(out), _full_gc(request_full_gc),

Please re-align the arguments.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2944528759
PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2158024854

From mdoerr at openjdk.org  Fri Jun 20 09:01:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Jun 2025 09:01:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <aqutosiSmqM1u3TePxEPFdPkM0Apd1XfjY7WXEssO-0=.83eb647e-114f-4b4f-b0f1-d2d89e16a426@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

> > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.
> 
> For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm));

Ah, right. So, ZGC should be fine.

> I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this.

I have tried some SPEC benchmarks with G1 on PPC64, but couldn't observe a regression. (If there is one, it was below noise.)
 
> One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.

I guess the most critical scenario is when many Java threads need to disarm a large number of nmethod entry barriers. That doesn't happen at a safepoint. Not sure if other scenarios are worth optimizing by this idea.

I guess this PR is ok as it is. Maybe other reviewers have more comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2990348628

From alanb at openjdk.org  Fri Jun 20 09:30:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jun 2025 09:30:30 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <hIuECle5gdWJxxZrRj3XsfIbfkknOfmtmCFfh_VA8o8=.bffc1a33-9a97-4515-9aa2-6e893ac1ca94@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
 <hIuECle5gdWJxxZrRj3XsfIbfkknOfmtmCFfh_VA8o8=.bffc1a33-9a97-4515-9aa2-6e893ac1ca94@github.com>
Message-ID: <AyBYtnOX-I19A-XzxvFSw3wp7mfQDpS3vx9-y2d4-Ik=.ec034a22-d6c1-47fb-9459-809076ab6e1a@github.com>

On Tue, 17 Jun 2025 07:52:20 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

> @AlanBateman This PR requires two approvals. I apologize for the long delay, but could you review it?

Sure, just have some drive by comments, switching to cp437 should be okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2990468037

From alanb at openjdk.org  Fri Jun 20 09:30:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Jun 2025 09:30:32 GMT
Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java
 fails on localized Windows platform [v8]
In-Reply-To: <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
References: <Ra31Q95DukIesp9Ivxsw4AYNOtqAm3JIeMSCtOHuTIM=.abd6dea4-4628-4983-9b38-642c21e792b5@github.com>
 <STlgNAPSBgWhFdC0FjPkBikj6BWGFIARLlYjgGJ5RBM=.90e1cf00-6440-4a22-b488-6ae3e5442c46@github.com>
Message-ID: <WnOz_iL4EFkoWTn-qCjg_VOe_g_bHdPMquYIwqg7Dnk=.1fe277b4-952c-4771-9ab7-998f371fa073@github.com>

On Fri, 6 Jun 2025 08:21:08 GMT, Kazuhisa Takakuri <ktakakuri at openjdk.org> wrote:

>> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms.
>> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail.
>> After this fix, I verified that the test passed.
>> 
>> https://github.com/openjdk/jdk/pull/22142
>> I refer to this fix.
>> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before.
>> 
>> Thanks.
>
> Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 75:

> 73:             throw new RuntimeException("SystemRoot or WINDIR environment variable is not set.");
> 74:         }
> 75:         String systemDirW = new File(systemRoot, "System32").getPath();

A drive-by comment is that you could remove the duplicate calls to getenv and just use a simple Path resolve. e.g.

        String systemRoot = System.getenv("SystemRoot");
        if (systemRoot == null) {
            systemRoot = System.getenv("WINDIR");
            if (systemRoot == null) {
                // throw
            }
        }
        String system32 = Path.of(systemRoot, "System32").toString();

test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 80:

> 78:         command.addAll(List.of("cmd.exe", "/c", "set", "PATH=%PATH%;" + systemDirW + ";" + systemDirW + "\\wbem", "&&"));
> 79:         command.addAll(List.of("chcp", "437", ">nul", "2>&1", "&&"));
> 80:         command.add(systeminfoPath);

I assume it would be more correct to say that it switches the active code page to cp437, the default code page for US english.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2158463587
PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2158469970

From mli at openjdk.org  Fri Jun 20 09:33:08 2025
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 20 Jun 2025 09:33:08 GMT
Subject: RFR: 8360090: [TEST] RISC-V: disable some cds tests on qemu
Message-ID: <sEU3dcbcF1dX7DVHE3Hu9Vcue6GUeUEAUZ7jY_uQQMI=.eaeeacb1-b9b5-42d7-ac9d-82078f6ac353@github.com>

Hi,
Can you help to review this patch?

CDS does not work well in cross compilation env, this is by desgin, please check `JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE` in make of jdk.

These tests depends on classes.jsa or classes_xxx.jsa which is not generated and will not be generated when build jdk in qemu environment for riscv, so we should disable them when qemu.

Thanks!

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

Commit messages:
 - initial commit

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

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

From duke at openjdk.org  Fri Jun 20 09:38:56 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 20 Jun 2025 09:38:56 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
Message-ID: <TgCAMNKAOcpp8YIa5cjtg_DeDyYSADp4_FBSQ3wwOLw=.73d7b7bc-b8ed-4016-87b9-65a3f7674f82@github.com>

> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
> 
> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
> 
> Proposed changes in the shared class hierarchy:
> 
> 
> //  VM_Operation
> //    VM_Heap_Sync_Operation
> //      VM_GC_Operation
> //        VM_GC_Collect_Operation
> //          VM_SerialGCCollect
> //          VM_ParallelGCCollect
> //          VM_CollectForAllocation
> //            VM_SerialCollectForAllocation
> //            VM_ParallelCollectForAllocation
> //          VM_CollectForMetadataAllocation
> //        VM_GC_Service_Operation
> //          VM_GC_HeapInspection
> //      VM_Verify
> //      VM_PopulateDynamicDumpSharedSpace
> //      VM_PopulateDumpSharedSpace
> 
> 
> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
> 
> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
> 
> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
> 
> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot...

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

  Re-align arguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25896/files
  - new: https://git.openjdk.org/jdk/pull/25896/files/7c8e6d81..7faaf506

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

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

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

From duke at openjdk.org  Fri Jun 20 09:38:56 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 20 Jun 2025 09:38:56 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <ZQ2T-yHO_lX8l_gyZRNR0BCKkG4DXhXoAWX55SBaHt0=.85d92299-203d-4a2f-8d28-b70f23a7d92d@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <ZQ2T-yHO_lX8l_gyZRNR0BCKkG4DXhXoAWX55SBaHt0=.85d92299-203d-4a2f-8d28-b70f23a7d92d@github.com>
Message-ID: <Dyr6AODa37szQwTZa5P7SaW9zc8eYssOTgxKWUs0C6o=.9c42c108-88fc-44d9-bb5f-5ff43f34a125@github.com>

On Fri, 20 Jun 2025 04:40:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-align arguments
>
> This looks quite reasonable to me. Obviously GC folk get final approval.
> 
> One minor nit.

Thanks for the review @dholmes-ora.

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

PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2990502655

From coleenp at openjdk.org  Fri Jun 20 11:55:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 11:55:09 GMT
Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace
Message-ID: <EYayEIkBDtbyUYUPVhMwF0sM536sbUYMmocXgbRqBp8=.bd481bf4-60b6-4e5a-9303-6d2984333f64@github.com>

This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like:

[490166] static void java.lang.String.<clinit>()
[490166]       13    18  putstatic 613 <java/lang/String.CASE_INSENSITIVE_ORDER:Ljava/util/Comparator;>
[490166]       14    21  return

[490166] static void java.lang.System.<clinit>()
[490166]       15     0  invokestatic 471 <java/lang/System.registerNatives()V>
[490166]       16     3  aconst_null
[490166]       17     4  putstatic 474 <java/lang/System.in:Ljava/io/InputStream;>

Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is.
Also ran tier1-4.

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

Commit messages:
 - 8295851: Do not use ttyLock in BytecodeTracer::trace

Changes: https://git.openjdk.org/jdk/pull/25915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295851
  Stats: 67 lines in 2 files changed: 36 ins; 13 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/25915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25915/head:pull/25915

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

From coleenp at openjdk.org  Fri Jun 20 12:52:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 12:52:09 GMT
Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v2]
In-Reply-To: <EYayEIkBDtbyUYUPVhMwF0sM536sbUYMmocXgbRqBp8=.bd481bf4-60b6-4e5a-9303-6d2984333f64@github.com>
References: <EYayEIkBDtbyUYUPVhMwF0sM536sbUYMmocXgbRqBp8=.bd481bf4-60b6-4e5a-9303-6d2984333f64@github.com>
Message-ID: <_i8ghcYb1qY-t2GkyUqA1391jLwmpiblGC9hvWlC9ZE=.680cc4c0-df2d-4c8d-a1ee-3857748b6f0a@github.com>

> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like:
> 
> [490166] static void java.lang.String.<clinit>()
> [490166]       13    18  putstatic 613 <java/lang/String.CASE_INSENSITIVE_ORDER:Ljava/util/Comparator;>
> [490166]       14    21  return
> 
> [490166] static void java.lang.System.<clinit>()
> [490166]       15     0  invokestatic 471 <java/lang/System.registerNatives()V>
> [490166]       16     3  aconst_null
> [490166]       17     4  putstatic 474 <java/lang/System.in:Ljava/io/InputStream;>
> 
> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is.
> Also ran tier1-4.

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

  Put back include osthread.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25915/files
  - new: https://git.openjdk.org/jdk/pull/25915/files/29b71ba5..0e4421be

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

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

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

From coleenp at openjdk.org  Fri Jun 20 13:22:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 13:22:35 GMT
Subject: Withdrawn: 8357662: applications/runthese/RunThese8H.java Crash:
 'Failed to uncommit metaspace'
In-Reply-To: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
References: <kpttSAqRr4f0MetYQCSiRixPIInOFqcXsCHLahBiv-g=.03588c4a-263c-43ce-94a8-a1a107de088a@github.com>
Message-ID: <UmD6TUisJDFSIKBDeu8JlRH1b_-qY1QcFdTtbVEiLLc=.295de680-41f7-4452-b678-bd199cf05d94@github.com>

On Tue, 10 Jun 2025 12:25:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make the fatal error a log warning and return. The metaspace commit accounting is done after this return.  Tested with this always returning here, and it seems okay.  Tested with this change tier 1-4 and 8.

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Fri Jun 20 13:29:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 13:29:42 GMT
Subject: RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3]
In-Reply-To: <EYayEIkBDtbyUYUPVhMwF0sM536sbUYMmocXgbRqBp8=.bd481bf4-60b6-4e5a-9303-6d2984333f64@github.com>
References: <EYayEIkBDtbyUYUPVhMwF0sM536sbUYMmocXgbRqBp8=.bd481bf4-60b6-4e5a-9303-6d2984333f64@github.com>
Message-ID: <xy-DqwdkkI0Sfx2WEua_0EGfGuorOEfPEJIOndp-WHw=.5df0dfb5-9405-4024-8c88-579475d76a46@github.com>

> This didn't need ttyLock for synchronization, the code only needs to see if the method changes so it can print the method name before the bytecodes, like:
> 
> [490166] static void java.lang.String.<clinit>()
> [490166]       13    18  putstatic 613 <java/lang/String.CASE_INSENSITIVE_ORDER:Ljava/util/Comparator;>
> [490166]       14    21  return
> 
> [490166] static void java.lang.System.<clinit>()
> [490166]       15     0  invokestatic 471 <java/lang/System.registerNatives()V>
> [490166]       16     3  aconst_null
> [490166]       17     4  putstatic 474 <java/lang/System.in:Ljava/io/InputStream;>
> 
> Verified manually and added some parallelism to the test, and fixed trace() to initialize is_linked(), which it always is.
> Also ran tier1-4.

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

  Put back include osthread.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25915/files
  - new: https://git.openjdk.org/jdk/pull/25915/files/0e4421be..5cdc5e11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25915&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25915/head:pull/25915

PR: https://git.openjdk.org/jdk/pull/25915

From gziemski at openjdk.org  Fri Jun 20 16:56:31 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 20 Jun 2025 16:56:31 GMT
Subject: RFR: 8356868: Not all cgroup parameters are made available [v2]
In-Reply-To: <HyFOvrbl6NwTMMODnCxZnQ_RgHy-sVZYcMgaI74pEEc=.d7b33069-3921-47a6-856a-bb2438c695be@github.com>
References: <l3Tgaauo359daJIgwYMA634iz-Ti6hIENuZzWrfe0qQ=.84235eac-ea06-4839-9941-93e804be507b@github.com>
 <HyFOvrbl6NwTMMODnCxZnQ_RgHy-sVZYcMgaI74pEEc=.d7b33069-3921-47a6-856a-bb2438c695be@github.com>
Message-ID: <Z77m3IvThaAiwFJe0cGX5oGcznSyA3_NfcvE78PERGI=.082af115-aaa3-43ce-b10a-4ca1abf7f13b@github.com>

On Wed, 4 Jun 2025 11:33:03 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data.
>> 
>> The new parameters are:
>> 
>> - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time.
>> 
>> - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed.
>> 
>> - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems.
>> 
>> Testing:
>> - All container tests under `/test/hotspot/jtreg/containers/`
>> - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update cpu usage to use >=
>   
>   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

LGTM, though I did have one feedback.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 431:

> 429:   return (jlong)cpu_usage / 1000;
> 430: }
> 431: 

Why don't we report the original value in nanos, if it is available?

This is new API, so no-one is using this yet, right?

-------------

Marked as reviewed by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25388#pullrequestreview-2946799576
PR Review Comment: https://git.openjdk.org/jdk/pull/25388#discussion_r2159367227

From dcubed at openjdk.org  Fri Jun 20 19:39:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 20 Jun 2025 19:39:37 GMT
Subject: RFR: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java
Message-ID: <z05vQXgkskeRfckgFK609iewLyM2AuSCwsbxa0_Klf8=.022c3a78-3091-47d8-81d2-b8c448d9a86a@github.com>

A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms.

Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely
integrate until next week and I want to reduce the noise for the weekend.

-------------

Commit messages:
 - 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java

Changes: https://git.openjdk.org/jdk/pull/25919/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25919&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360143
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25919.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25919/head:pull/25919

PR: https://git.openjdk.org/jdk/pull/25919

From rriggs at openjdk.org  Fri Jun 20 19:39:37 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Jun 2025 19:39:37 GMT
Subject: RFR: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java
In-Reply-To: <z05vQXgkskeRfckgFK609iewLyM2AuSCwsbxa0_Klf8=.022c3a78-3091-47d8-81d2-b8c448d9a86a@github.com>
References: <z05vQXgkskeRfckgFK609iewLyM2AuSCwsbxa0_Klf8=.022c3a78-3091-47d8-81d2-b8c448d9a86a@github.com>
Message-ID: <rq1iObqhq6-q4hZAOXx23rb8efQrXo6W4QXTsLrugfo=.ffe42a50-dad4-4e8f-985c-f001df348039@github.com>

On Fri, 20 Jun 2025 19:32:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms.
> 
> Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely
> integrate until next week and I want to reduce the noise for the weekend.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25919#pullrequestreview-2947125441

From dcubed at openjdk.org  Fri Jun 20 19:56:31 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 20 Jun 2025 19:56:31 GMT
Subject: RFR: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java
In-Reply-To: <rq1iObqhq6-q4hZAOXx23rb8efQrXo6W4QXTsLrugfo=.ffe42a50-dad4-4e8f-985c-f001df348039@github.com>
References: <z05vQXgkskeRfckgFK609iewLyM2AuSCwsbxa0_Klf8=.022c3a78-3091-47d8-81d2-b8c448d9a86a@github.com>
 <rq1iObqhq6-q4hZAOXx23rb8efQrXo6W4QXTsLrugfo=.ffe42a50-dad4-4e8f-985c-f001df348039@github.com>
Message-ID: <Rrhs6qsX2x0q3J_W5dMJ7DCzOPVwB7ypcKu8O8e6eA0=.ab205209-d49b-4fec-801c-4c738cf123cf@github.com>

On Fri, 20 Jun 2025 19:35:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms.
>> 
>> Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely
>> integrate until next week and I want to reduce the noise for the weekend.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the lightning fast review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25919#issuecomment-2992640662

From dcubed at openjdk.org  Fri Jun 20 19:56:31 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 20 Jun 2025 19:56:31 GMT
Subject: Integrated: 8360143: ProblemList runtime/NMT/VirtualAllocTestType.java
In-Reply-To: <z05vQXgkskeRfckgFK609iewLyM2AuSCwsbxa0_Klf8=.022c3a78-3091-47d8-81d2-b8c448d9a86a@github.com>
References: <z05vQXgkskeRfckgFK609iewLyM2AuSCwsbxa0_Klf8=.022c3a78-3091-47d8-81d2-b8c448d9a86a@github.com>
Message-ID: <QasxM3ck3-faPxToHJ5FJpWUkw4wUrBmNBUd5kn5ups=.83f80d23-1197-493e-86ea-a1870e0ab72b@github.com>

On Fri, 20 Jun 2025 19:32:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList runtime/NMT/VirtualAllocTestType.java on all platforms.
> 
> Yes, there is a fix for [JDK-8359959](https://bugs.openjdk.org/browse/JDK-8359959) out for review, but that fix won't likely
> integrate until next week and I want to reduce the noise for the weekend.

This pull request has now been integrated.

Changeset: d627282f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d627282f0c42c340db3b8b71121274b91638e09b
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8360143: ProblemList runtime/NMT/VirtualAllocTestType.java

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25919

From dcubed at openjdk.org  Fri Jun 20 19:58:29 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 20 Jun 2025 19:58:29 GMT
Subject: RFR: 8359959: Test runtime/NMT/VirtualAllocTestType.java failed:
 '\\[0x[0]*7f7dc4043000 - 0x[0]*7f7dc4083000\\] reserved 256KB for
 Test' missing from stdout/stderr [v3]
In-Reply-To: <NDsGug6xjxY1xzi_JZGQvMmvrVyd1WG-x0xuyKEdykM=.daeaedc1-bbd0-486e-af38-ce327139b802@github.com>
References: <2-l0JtW2VtfKO3NZ4TWgWaQCF-xOytE1k8U7OdBYEYI=.72004881-e43f-4b16-b99a-5bf1c93493d1@github.com>
 <NDsGug6xjxY1xzi_JZGQvMmvrVyd1WG-x0xuyKEdykM=.daeaedc1-bbd0-486e-af38-ce327139b802@github.com>
Message-ID: <sbsS6uldNhXdk6ROe3d320DS6gkNUTShqFZpRT-yKaE=.58dda415-f4d5-468d-b220-ed8c8599f422@github.com>

On Thu, 19 Jun 2025 13:03:02 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The test expects that two disjunct regions are reserved but checked it incompletely.
>> It is fixed by reserving a new (third) region with the required size and then released the middle region among these three regions.
>> In Windows, it is not possible/valid to release middle regions. Either a whole region or a region that has the same end-address with the whole region can be released. IOW, only 'release the whole' or 'release from address A up to the end' are valid.
>>  
>>  Since it (reserving two regions that become adjacent) is not happening always, the test failed occasionally at different tiers.
>> 
>> Tested local linux-x64-debug.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

@afshin-zafari  - I have ProblemListed this test on all platforms to reduce any noise
over the weekend. Please remember to resync your repo and remove the ProblemListing
as part of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25894#issuecomment-2992646103

From sspitsyn at openjdk.org  Fri Jun 20 20:52:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 20:52:29 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
Message-ID: <zNCBQ4PcPmoWQ0wU-gDC5GupgFfdTR37_HKZUS0zmNI=.7183720d-2d39-4a34-823c-f610ed7e479a@github.com>

On Wed, 18 Jun 2025 11:52:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a byte buffer version and rename parameters.

Thank you for the update! Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2947255421

From lmesnik at openjdk.org  Fri Jun 20 21:40:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 20 Jun 2025 21:40:28 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
Message-ID: <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>

On Wed, 18 Jun 2025 11:52:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I copied this code for another test in the Valhalla repo and thought it would be a good utility function.  It might be better written using the Classfile API.
>> Tested with test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a byte buffer version and rename parameters.

Changes requested by lmesnik (Reviewer).

test/lib/RedefineClassHelper.java line 68:

> 66: 
> 67:     private static byte[] getBytecodes(ClassLoader loader, String name) throws Exception {
> 68:         InputStream is = loader.getResourceAsStream(name + ".class");

I think this should be 
try(InputStream is = loader.getResourceAsStream(name + ".class");) {
...

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2947314649
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2159689305