From jbechberger at openjdk.org  Sun Jun  1 07:13:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:13:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <CRTBE7yyj-RP26N7o896T9PKWzzZPa-KOazE3ez74BQ=.69adda67-70d8-4877-a711-eec22ab8780b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <CRTBE7yyj-RP26N7o896T9PKWzzZPa-KOazE3ez74BQ=.69adda67-70d8-4877-a711-eec22ab8780b@github.com>
Message-ID: <2nYqo0wpUrLLJV9iDRLwj5xjV06waCzu8Ma8YSAToIY=.1059ee96-77f8-47e6-8797-3f2b47783311@github.com>

On Sat, 31 May 2025 10:37:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug printf
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 139:
> 
>> 137: 
>> 138:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
>> 139:   static void trigger_is_thread_in_native_stackwalking();
> 
> Is it sampling that is triggered? Sampling refers to the asynchronous signal received from the operating system (OS).
> 
> You are asking for the sampler thread to process already taken JFR Sample Requests in the queue, right?

Yes and I like your implied name better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2118819169

From jbechberger at openjdk.org  Sun Jun  1 07:17:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:17:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v25]
In-Reply-To: <wUE0E1SOPvEUeUT2TFEBU5MzoG9Al1WPRvxB4Nm9kvc=.b4595e9f-75b3-49b8-92a4-ebf938195bb0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <W934y28ILW3FN0zvo9ixbDwWIMrjPWpLTKUfyJOiOdc=.e013ee3a-9675-486d-a4e7-cf0f55552b0b@github.com>
 <wUE0E1SOPvEUeUT2TFEBU5MzoG9Al1WPRvxB4Nm9kvc=.b4595e9f-75b3-49b8-92a4-ebf938195bb0@github.com>
Message-ID: <V-gvB668d9MPgwPjeP-3P0XrPHxVjucgac6D4W-Rz0E=.669ebaad-4785-49b3-b0b2-aff587479747@github.com>

On Sat, 31 May 2025 10:09:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove debug printf
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 36:
> 
>> 34: #if defined(LINUX)
>> 35: 
>> 36: #include "memory/padded.hpp"
> 
> What is padded? If not, this should go.

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2118820425

From jbechberger at openjdk.org  Sun Jun  1 07:22:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:22:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
 <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>
 <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>
Message-ID: <dw0nEvtOhHk5pe5VLBy_RF29x_ACwQ_UTjAVZykGKmc=.41920e11-799a-40a2-a258-3e796c260196@github.com>

On Fri, 30 May 2025 09:19:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 975:
>> 
>>> 973:   </Event>
>>> 974: 
>>> 975:   <Event name="CPUTimeSampleLoss" category="Java Virtual Machine, Profiling" label="CPU Time Method Profiling Lost Samples" description="Records that the CPU time sampler lost samples"
>> 
>> I'm not a reviewer, but I just wanted to comment something I noticed.
>> The JEP document says CPUTimeSampleLos'**t**', but the implementation says CPUTimeSampleLos'**s**'. Which one is correct?
>> A sentence from the JEP document:
>> 
>> Another new event,?`jdk.CPUTimeSampleLost`, is emitted when samples are lost ...
>
> Thanks for catching this mistake. I'll fix it this afternoon.

I fixed it by changing the JEP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2118825477

From jbechberger at openjdk.org  Sun Jun  1 07:26:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 07:26:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Refactoring
 - Remove convoluted native trace logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/3a10d552..439763a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=24-25

  Stats: 56 lines in 5 files changed: 3 ins; 27 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From mgronlun at openjdk.org  Sun Jun  1 13:04:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:04:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <uywTbPrvFb9SBmQLpDMleEV0RC8q34PCf5UA-mtW58s=.0cd920f6-c263-46dc-a01f-3692354906d4@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 42:

> 40: #include "runtime/javaThread.hpp"
> 41: #include "runtime/osThread.hpp"
> 42: #include "runtime/safepointMechanism.hpp"

Not needed, since you have the .inline.hpp

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 102:

> 100: 
> 101: u4 JfrCPUTimeTraceQueue::size() const {
> 102:   return Atomic::load(&_head);

Is this read from multiple threads? In that case, load_acquire().

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:

> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
> 199: 
> 200:   // sample all threads that are in native state (and requested to be sampled)

We are not really "sampling", but processing their queues, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119128911
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119129239
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119129708

From mgronlun at openjdk.org  Sun Jun  1 13:08:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:08:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 367:

> 365:     JfrCPUTimeSampleRequest& request = queue.at(i);
> 366:     JfrStackTrace stacktrace;
> 367:     traceid tid = JfrThreadLocal::thread_id(thread);

Check the tid as a function of the JfrSampleRequest, like we do in JFR Cooperative Sampling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119130991

From mgronlun at openjdk.org  Sun Jun  1 13:12:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:12:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <S5eA8KfkIZtoUbXMgpvjF84gfCbUuvH9EvxhrieGc0I=.ec24e1d0-0084-41a0-aaff-ace3a2de96e7@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 413:

> 411:   }
> 412:   if (Atomic::load(&count) % 1000 == 0) {
> 413:     log_info(jfr)("CPU thread sampler sent %zu events, lost %d, biased %zu\n", Atomic::load(&count), Atomic::load(&_lost_samples_sum), Atomic::load(&biased_count));

put this logging under jfr+debug or log+trace please

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119137014

From mgronlun at openjdk.org  Sun Jun  1 13:23:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 13:23:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 557:

> 555:   if (!check_state(jt) ||
> 556:       jt->is_JfrRecorder_thread()) {
> 557:       queue.increment_lost_samples();

is_JfrRecorder_thread() will not appear here since it's excluded and would have returned nullptr from get_java_thread_if_valid().

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 558:

> 556:       jt->is_JfrRecorder_thread()) {
> 557:       queue.increment_lost_samples();
> 558:       tl->set_do_async_processing_of_cpu_time_jfr_requests(false);

Why is this restored here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119142346
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119142510

From jbechberger at openjdk.org  Sun Jun  1 13:43:58 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 13:43:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>
Message-ID: <DJve2ZIp1xOIaKtcTQXQM3sYintlrZJQWx1oRLTFIDY=.73ad47ec-2d86-4f18-8d9b-4cb1d398b2a8@github.com>

On Sun, 1 Jun 2025 13:19:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 558:
> 
>> 556:       jt->is_JfrRecorder_thread()) {
>> 557:       queue.increment_lost_samples();
>> 558:       tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 
> Why is this restored here?

Because I shouldn't sample if the thread isn't in native state anymore. The thread is probably sampled anyway on the outgoing safepoint.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119157906

From mgronlun at openjdk.org  Sun Jun  1 15:07:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:07:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <ZN_PiDKlmt3Y5b62nsc8F4LAvzx6-soxIS8q1I7oe5E=.49f21270-e9c2-45ae-a184-a28045de9ffb@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:

> 360:   drain_enqueued_requests(now, tl, jt, current);
> 361: #ifdef LINUX
> 362:   if (tl->has_cpu_time_jfr_requests()) {

You are having all threads traverse over this lock, even though the cpu time sampler is disabled by default. Can it be improved?

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 604:

> 602: 
> 603: bool JfrThreadLocal::has_cpu_time_jfr_requests() {
> 604:   return Atomic::load(&_has_cpu_time_jfr_requests);

Atomic::load_acquire()

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 620:

> 618: 
> 619: bool JfrThreadLocal::wants_async_processing_of_cpu_time_jfr_requests() {
> 620:   return Atomic::load(&_do_async_processing_of_cpu_time_jfr_requests);

Atomic::load_acquire()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119242319
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119243305
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119243393

From jbechberger at openjdk.org  Sun Jun  1 15:07:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 15:07:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <ZN_PiDKlmt3Y5b62nsc8F4LAvzx6-soxIS8q1I7oe5E=.49f21270-e9c2-45ae-a184-a28045de9ffb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <ZN_PiDKlmt3Y5b62nsc8F4LAvzx6-soxIS8q1I7oe5E=.49f21270-e9c2-45ae-a184-a28045de9ffb@github.com>
Message-ID: <62JxxY-xn3fwz0PnhcnIH6DOWBQUPIq_fhDD_7YrSmA=.bfbb317a-403e-4826-a3ed-c364882e821b@github.com>

On Sun, 1 Jun 2025 15:01:06 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:
> 
>> 360:   drain_enqueued_requests(now, tl, jt, current);
>> 361: #ifdef LINUX
>> 362:   if (tl->has_cpu_time_jfr_requests()) {
> 
> You are having all threads traverse over this lock, even though the cpu time sampler is disabled by default. Can it be improved?

Not without allocating in the signal handler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119243238

From mgronlun at openjdk.org  Sun Jun  1 15:27:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:27:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 332:

> 330:     JavaThread* jt = tlh.list()->thread_at(i);
> 331:     JfrThreadLocal* tl = jt->jfr_thread_local();
> 332:     if (tl != nullptr && tl->wants_async_processing_of_cpu_time_jfr_requests()) {

tl is never nullptr.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 344:

> 342: 
> 343: // equals operator for JfrSampleRequest
> 344: inline bool operator==(const JfrSampleRequest& lhs, const JfrSampleRequest& rhs) {

Can be removed.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 574:

> 572: 
> 573:   if (queue.enqueue(request)) {
> 574:     tl->set_has_cpu_time_jfr_requests(true);

This should only need to be set when enqueuing the first entry.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 581:

> 579: 
> 580:   if (jt->thread_state() == _thread_in_native &&
> 581:       queue.size() > queue.capacity() * 2 / 3) {

Is this logic still valid? You are only asking for a async processing depending on the load factor of the queue?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 586:

> 584:     JfrCPUTimeThreadSampling::trigger_async_processing_of_cpu_time_jfr_requests();
> 585:   } else {
> 586:     tl->set_do_async_processing_of_cpu_time_jfr_requests(false);

Was it true before and needed a reset?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119250661
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119250887
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119248176
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119248824
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119249381

From jbechberger at openjdk.org  Sun Jun  1 15:27:06 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 15:27:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
Message-ID: <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>

On Sun, 1 Jun 2025 15:18:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 574:
> 
>> 572: 
>> 573:   if (queue.enqueue(request)) {
>> 574:     tl->set_has_cpu_time_jfr_requests(true);
> 
> This should only need to be set when enqueuing the first entry.

You're right

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 581:
> 
>> 579: 
>> 580:   if (jt->thread_state() == _thread_in_native &&
>> 581:       queue.size() > queue.capacity() * 2 / 3) {
> 
> Is this logic still valid? You are only asking for a async processing depending on the load factor of the queue?

Yes, so I only start the thread walking if necessary

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119248709
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119250511

From mgronlun at openjdk.org  Sun Jun  1 15:35:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:35:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <GH6dTFPiJ18tIADVnfmghTTdyTpVngHjCeJ5-FZLBGc=.e10c9936-ae8f-4a1a-8a3e-e86828a8e926@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 536:

> 534: }
> 535: 
> 536: volatile size_t count__ = 0;

unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119258988

From jbechberger at openjdk.org  Sun Jun  1 15:39:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Sun, 1 Jun 2025 15:39:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <GH6dTFPiJ18tIADVnfmghTTdyTpVngHjCeJ5-FZLBGc=.e10c9936-ae8f-4a1a-8a3e-e86828a8e926@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <GH6dTFPiJ18tIADVnfmghTTdyTpVngHjCeJ5-FZLBGc=.e10c9936-ae8f-4a1a-8a3e-e86828a8e926@github.com>
Message-ID: <6Idy8j9wbNr9udYMhsW0BQmhb8dQvc_p20vCYtg5kZc=.6380eee6-bd1b-45d0-bca8-c8068e59bd36@github.com>

On Sun, 1 Jun 2025 15:32:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 536:
> 
>> 534: }
>> 535: 
>> 536: volatile size_t count__ = 0;
> 
> unused?

Yes.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 586:
> 
>> 584:     JfrCPUTimeThreadSampling::trigger_async_processing_of_cpu_time_jfr_requests();
>> 585:   } else {
>> 586:     tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 
> Was it true before and needed a reset?

I could check this before setting

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119260755
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119261558

From mgronlun at openjdk.org  Sun Jun  1 15:43:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 15:43:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <66tRvhjE2LrwccsAYmRycS6QLF2KdRg-XHfk-scr-wg=.c7f269f0-301a-4da3-ae54-7f6bc7a440b1@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 587:

> 585: }
> 586: 
> 587: bool JfrThreadLocal::acquire_cpu_time_jfr_native_lock() {

It appears that the lock state 'NATIVE' is redundant; an asynchronous request for queue drainage only requires the dequeue lock state. NATIVE can be removed to simplify the lock protocol.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119268003

From mgronlun at openjdk.org  Sun Jun  1 18:12:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:12:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
Message-ID: <PJG8IRqXcZw2wOgKlNq4-TnPH0eVgwnE-G9a4EXSD04=.4acea933-5451-43eb-86c5-502f5dcbf1ac@github.com>

On Sun, 1 Jun 2025 15:24:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 344:
> 
>> 342: 
>> 343: // equals operator for JfrSampleRequest
>> 344: inline bool operator==(const JfrSampleRequest& lhs, const JfrSampleRequest& rhs) {
> 
> Can be removed.

Unless you still want to try the ljf JfrSampleRequest optimization for the native ljf, which I kind of like now that I understand it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119386104

From mgronlun at openjdk.org  Sun Jun  1 18:13:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:13:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
Message-ID: <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>

On Sun, 1 Jun 2025 15:23:06 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 581:
>> 
>>> 579: 
>>> 580:   if (jt->thread_state() == _thread_in_native &&
>>> 581:       queue.size() > queue.capacity() * 2 / 3) {
>> 
>> Is this logic still valid? You are only asking for async processing assistance depending on the load factor of the queue?
>
> Yes, so I only start the thread walking if necessary

I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.

I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:
>> 
>>> 360:   drain_enqueued_requests(now, tl, jt, current);
>>> 361: #ifdef LINUX
>>> 362:   if (tl->has_cpu_time_jfr_requests()) {
>> 
>> You are having all threads traverse over this test, even though the cpu time sampler is disabled by default. Can it be improved?
>
> Not without allocating in the signal handler

How so?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119385303
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119389715

From mgronlun at openjdk.org  Sun Jun  1 18:25:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:25:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <GxaSY3WuT4Bz_JbcHS9H0b_CyJgBjWWtxrQDqcd80ec=.826e247c-1a11-45ef-967e-6fa617b3cee6@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:

> 248:     }
> 249: 
> 250:     biased = true;

Perhaps set on entry, and only keep the single biased = false below?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119396997

From mgronlun at openjdk.org  Sun Jun  1 18:31:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 18:31:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <GxaSY3WuT4Bz_JbcHS9H0b_CyJgBjWWtxrQDqcd80ec=.826e247c-1a11-45ef-967e-6fa617b3cee6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <GxaSY3WuT4Bz_JbcHS9H0b_CyJgBjWWtxrQDqcd80ec=.826e247c-1a11-45ef-967e-6fa617b3cee6@github.com>
Message-ID: <F-CBr0NN-RfUyFcEAFg5iXYy54V3PYkCITteBLT3ofU=.d67cfd9c-210e-4459-873b-6676b7d98dc5@github.com>

On Sun, 1 Jun 2025 18:22:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:
> 
>> 248:     }
>> 249: 
>> 250:     biased = true;
> 
> Perhaps set on entry, and only keep the single biased = false below?

Also, note you have a direct hit in line 221--222 above - it's biased = false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119404072

From dholmes at openjdk.org  Mon Jun  2 04:35:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:35:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
Message-ID: <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>

On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

Just some drive-by comments mainly on your acquire/release usage. I'm not at all clear what memory accesses you are trying to coordinate with those.

src/hotspot/share/jfr/jni/jfrJniMethod.cpp line 176:

> 174:   JfrEventSetting::set_enabled(JfrCPUTimeSampleEvent, rate > 0);
> 175:   JfrCPUTimeThreadSampling::set_rate(rate, autoadapt == JNI_TRUE);
> 176:   return JNI_TRUE;

What is the point of having a boolean return type if you always return true?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 59:

> 57:   Thread* raw_thread = Thread::current_or_null_safe();
> 58:   JavaThread* jt;
> 59:   if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parralelism

Suggestion:

  if (raw_thread == nullptr || !raw_thread->is_Java_thread()) { // this can happen due to the high level of parallelism

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 119:

> 117:   _data = new_data;
> 118:   _capacity = capacity;
> 119: }

I assume there is a lock protecting this so it happens atomically?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 122:

> 120: 
> 121: bool JfrCPUTimeTraceQueue::is_full() const {
> 122:   return Atomic::load_acquire(&_head) >= _capacity;

I don't see why acquire semantics would be needed here. Also how can it be > capacity?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 126:

> 124: 
> 125: bool JfrCPUTimeTraceQueue::is_empty() const {
> 126:   return Atomic::load_acquire(&_head) == 0;

Acquire semantics are definitely not needed here.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 130:

> 128: 
> 129: s4 JfrCPUTimeTraceQueue::lost_samples() const {
> 130:   return Atomic::load_acquire(&_lost_samples);

Again acquire semantics seem highly dubious here - what loads are you synchronizing with?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 139:

> 137: 
> 138: u4 JfrCPUTimeTraceQueue::get_and_reset_lost_samples() {
> 139:   s4 lost_samples = Atomic::load_acquire(&_lost_samples);

Again acquire semantics seem highly dubious here - what loads are you synchronizing with?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 151:

> 149:     set_capacity(capacity);
> 150:   }
> 151: }

Seems an odd definition - typically `ensure_capacity` will grow a data structure to ensure it has sufficient capacity, and if already larger than needed that is fine. Suggestion `change_capacity`, or more traditionally `resize`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 237:

> 235: 
> 236: void JfrCPUTimeThreadSampler::trigger_async_processing_of_cpu_time_jfr_requests() {
> 237:   Atomic::release_store(&_is_async_processing_of_cpu_time_jfr_requests_triggered, true);

What prior stores are you ensuring should be visible by using release semantics here?

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2886627655
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119983062
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119983911
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120016607
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120011705
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120012200
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120014449
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120014541
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120020174
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120021034

From dholmes at openjdk.org  Mon Jun  2 04:35:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 04:35:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v5]
In-Reply-To: <Czq2ZlXAaiBc6IFEwZ4HjHy5JiJ3cSrWdQ8OfDVwCf0=.82a7c7ad-44e0-498d-8a7a-7dd8c0e00a60@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <6hGNW2D3_VuD-2WN0eTLYdEJoNu_9rPLu-dH-InGSK4=.64de8bc8-a98f-400f-a5e3-885dbd84d901@github.com>
 <TEX3Z1hjpwJXlSDSGCz247MMUN5knTL6BpEJIVCMGvk=.9da268d5-3de5-41e0-8996-e00f68ce25bd@github.com>
 <yguC8lxZCJ1mYXeaC41Fyh4n23SE4oSMTNxxbZDa5hQ=.b5f7a3bb-a647-4158-83bb-ccdbfd376902@github.com>
 <Czq2ZlXAaiBc6IFEwZ4HjHy5JiJ3cSrWdQ8OfDVwCf0=.82a7c7ad-44e0-498d-8a7a-7dd8c0e00a60@github.com>
Message-ID: <7wOUvZZtjrX3TpgT9JQLm-8qTAax6PrXtfHwMJpNX4M=.13a7c6cc-e037-4108-b392-7ff30d279c05@github.com>

On Mon, 26 May 2025 06:29:03 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Also, is raw_thread == nullptr even possible? For the same reasons.
>
> `!raw_thread->is_Java_thread()` I found it during testing.

What thread was it, and how did it reach this code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119984783

From mbaesken at openjdk.org  Mon Jun  2 07:33:27 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Jun 2025 07:33:27 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is configured
Message-ID: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>

There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
Those fail when the address sanitizer is configured ( --enable-asan ).
The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
While at it, also same is also added for ubsan .

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

Commit messages:
 - remove zgc change
 - JDK-8357826

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

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

From mbaesken at openjdk.org  Mon Jun  2 07:33:27 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Jun 2025 07:33:27 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <Mg-f4jRoLJivH3ncEhspBpAoryWfk0PG-E5uG7N1qOM=.08129e83-cb21-4a24-8f34-751fd48a0928@github.com>

On Mon, 2 Jun 2025 07:25:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

The change to src/hotspot/cpu/x86/gc/z/zAddress_x86.cpp was added because of zgc issues with ASAN but we will address this in another change so I remove it from here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2929201143

From rvansa at openjdk.org  Mon Jun  2 07:36:51 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Jun 2025 07:36:51 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v16]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <VGGHZ6ois6Dlgbt8AGP9hVfqV2whRlnBzpjsOMuCt8A=.fb7809d8-bca3-4d6b-a48a-e27746c1ed80@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Add type cast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/70f62460..9cba2d4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=14-15

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

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

From mbaesken at openjdk.org  Mon Jun  2 08:07:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Jun 2025 08:07:38 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  TestBreakSignalThreadDump has issues with asan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/3ad0d93a..aa796c8a

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

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

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

From mbaesken at openjdk.org  Mon Jun  2 08:07:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 2 Jun 2025 08:07:38 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <4CZpPTh4S1qjEkxVcHZ-J8bxpkI4iTsOtX4iCG5M2Cw=.8c1f2e8e-02c1-4691-8d6f-aa362dd54932@github.com>

On Mon, 2 Jun 2025 07:25:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

TestBreakSignalThreadDump shows this, so it does not work well with asan too

 stdout: [];
 stderr: [==12484==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2929322761

From rvansa at openjdk.org  Mon Jun  2 08:14:48 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Jun 2025 08:14:48 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v17]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <qJNdGdWTx-zIRnVCEyXiH_551E73Kn8hFl31V11E3y0=.bb27cbc7-4a73-46ea-b707-3203c0353217@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Add type cast
 - Fix static_assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/9cba2d4a..c592ea59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=15-16

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

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

From jbechberger at openjdk.org  Mon Jun  2 08:44:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:44:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <uywTbPrvFb9SBmQLpDMleEV0RC8q34PCf5UA-mtW58s=.0cd920f6-c263-46dc-a01f-3692354906d4@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <uywTbPrvFb9SBmQLpDMleEV0RC8q34PCf5UA-mtW58s=.0cd920f6-c263-46dc-a01f-3692354906d4@github.com>
Message-ID: <yE-WI5e9DNtoD4z_3cQ3nwU-IjXjmN_Ea19CfTqUDRE=.cfa23e87-ce78-4dcb-9638-7f6ffac97c03@github.com>

On Sun, 1 Jun 2025 13:01:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:
> 
>> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
>> 199: 
>> 200:   // sample all threads that are in native state (and requested to be sampled)
> 
> We are not really "sampling", but processing their queues, no?

You're correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120450563

From jbechberger at openjdk.org  Mon Jun  2 08:47:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:47:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>
Message-ID: <3d549Fxkhzd6v0fAVFEBOcxZ7hBKI1ZAUafLClp7Npw=.70183618-7dbf-4e05-bcc8-fd1216741c66@github.com>

On Sun, 1 Jun 2025 13:05:44 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 367:
> 
>> 365:     JfrCPUTimeSampleRequest& request = queue.at(i);
>> 366:     JfrStackTrace stacktrace;
>> 367:     traceid tid = JfrThreadLocal::thread_id(thread);
> 
> Check the tid as a function of the JfrSampleRequest, like we do in JFR Cooperative Sampling.

You mean ` const traceid tid = in_continuation ? tl->vthread_id_with_epoch_update(jt) : JfrThreadLocal::jvm_thread_id(jt);`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120458307

From jbechberger at openjdk.org  Mon Jun  2 08:53:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:53:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <3d549Fxkhzd6v0fAVFEBOcxZ7hBKI1ZAUafLClp7Npw=.70183618-7dbf-4e05-bcc8-fd1216741c66@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <mtuh1chjiwzh1kWkGKorMecSUnPVoJqXhX_KlFPdeaE=.b20d3fb4-ba35-46cb-97ef-ea9a5be4dde0@github.com>
 <3d549Fxkhzd6v0fAVFEBOcxZ7hBKI1ZAUafLClp7Npw=.70183618-7dbf-4e05-bcc8-fd1216741c66@github.com>
Message-ID: <DWN-Va0XnzSIlWA4adYve6dRuQgW7QZcZnmlDUmW0ys=.b293bff9-7121-4a96-b5c6-ca9d980f948c@github.com>

On Mon, 2 Jun 2025 08:44:01 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 367:
>> 
>>> 365:     JfrCPUTimeSampleRequest& request = queue.at(i);
>>> 366:     JfrStackTrace stacktrace;
>>> 367:     traceid tid = JfrThreadLocal::thread_id(thread);
>> 
>> Check the tid as a function of the JfrSampleRequest, like we do in JFR Cooperative Sampling.
>
> You mean ` const traceid tid = in_continuation ? tl->vthread_id_with_epoch_update(jt) : JfrThreadLocal::jvm_thread_id(jt);`?

I implemented this in this function now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120473792

From jbechberger at openjdk.org  Mon Jun  2 08:57:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 08:57:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <DJve2ZIp1xOIaKtcTQXQM3sYintlrZJQWx1oRLTFIDY=.73ad47ec-2d86-4f18-8d9b-4cb1d398b2a8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <bE0PpCgKbqxuwmYZK0auYcjThaFb63jkqUnqVrFhTmA=.07ed573d-4805-465c-ab22-222ae8c21dd5@github.com>
 <DJve2ZIp1xOIaKtcTQXQM3sYintlrZJQWx1oRLTFIDY=.73ad47ec-2d86-4f18-8d9b-4cb1d398b2a8@github.com>
Message-ID: <rNihgxVesNTYLgvhEpoOHiDkGJYkyb0Fqw2O1JrcDFM=.7c641eca-9381-4286-b47c-d85d1814c7d3@github.com>

On Sun, 1 Jun 2025 13:41:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 558:
>> 
>>> 556:       jt->is_JfrRecorder_thread()) {
>>> 557:       queue.increment_lost_samples();
>>> 558:       tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
>> 
>> Why is this restored here?
>
> Because I shouldn't sample if the thread isn't in native state anymore. The thread is probably sampled anyway on the outgoing safepoint.

But you might be right, I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120481274

From jbechberger at openjdk.org  Mon Jun  2 09:01:05 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:01:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
Message-ID: <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>

On Sun, 1 Jun 2025 18:10:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Not without allocating in the signal handler
>
> How so?

Because we need to add the threads from the signal handler. So any kind of growing array or set would not work, especially if we want to remove the threads from within the signal handler again.

This is certainly an area of future optimization, albeit this doesn't seem to have any measurable performance impact in my renaissance benchmark runs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120492743

From jbechberger at openjdk.org  Mon Jun  2 09:05:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:05:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
Message-ID: <kjtklorYzkvVeGAK8ei4bmKWxHn-r66MkW06sLNLdKM=.dcd25136-5252-4389-b292-f9aa98f0350d@github.com>

On Sun, 1 Jun 2025 18:00:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Yes, so I only start the thread walking if necessary
>
> I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.
> 
> I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.

The problem is when in between queue processing a new JFR chunk is started. This caused problems before.

I would leave these kinds of optimizations for later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120501728

From jbechberger at openjdk.org  Mon Jun  2 09:09:04 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:09:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <PJG8IRqXcZw2wOgKlNq4-TnPH0eVgwnE-G9a4EXSD04=.4acea933-5451-43eb-86c5-502f5dcbf1ac@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <PJG8IRqXcZw2wOgKlNq4-TnPH0eVgwnE-G9a4EXSD04=.4acea933-5451-43eb-86c5-502f5dcbf1ac@github.com>
Message-ID: <lt-zhwrdlz61ZYE6mh4kkVmo-M49cFGu0TrtwiFCl5c=.1bab99e5-1f59-4862-9af0-0b0c237c59b0@github.com>

On Sun, 1 Jun 2025 18:03:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 344:
>> 
>>> 342: 
>>> 343: // equals operator for JfrSampleRequest
>>> 344: inline bool operator==(const JfrSampleRequest& lhs, const JfrSampleRequest& rhs) {
>> 
>> Can be removed.
>
> Unless you still want to try the ljf JfrSampleRequest optimization for the native ljf, which I kind of like now that I understand it.

As I said, it's a great optimization. But it needs some work. I therefore remove this method for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120511048

From kevinw at openjdk.org  Mon Jun  2 09:16:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 2 Jun 2025 09:16:56 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v3]
In-Reply-To: <XSomyaIAVYGD_Ogt5dQQ2TmwYXqZ2pQy41Kky2mBWeg=.9cf9f1ce-4afe-4af5-80fb-c87216273787@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <3EYLo1tSB8GfKr6pkZryIn67hGT-5m9Fcf98KCE3Jbw=.00529528-34bb-4b34-90e6-a5289ddaa477@github.com>
 <eWNYeOoALGf7BblhHMv5k1nIP-miUDxFI9JQggk3RVo=.f223cdd6-b5c7-4403-b1d7-241da832cfd8@github.com>
 <XSomyaIAVYGD_Ogt5dQQ2TmwYXqZ2pQy41Kky2mBWeg=.9cf9f1ce-4afe-4af5-80fb-c87216273787@github.com>
Message-ID: <1HQxixfzldeYWk_FS2UqcgtLx_2XWJw5f2T_Ver5_Tk=.c403179d-5c0e-42a4-b03b-f00f7f4aec2c@github.com>

On Fri, 30 May 2025 18:15:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 180:
>> 
>>> 178:     }
>>> 179: 
>>> 180:     private static void dumpThread(Thread thread, TextWriter writer) {
>> 
>> On the non-json text format for locks: here we're creating a new comment-like style:
>> // parked on ..etc...
>> 
>> In the regular Thread.print we always used a "-" prefix, and always printed the frame, then the relevant locks, like:
>> 
>>         at ThreadsMem$2.run(ThreadsMem.java:38)
>>         - waiting to lock <0x0000000630817da0> (a java.lang.Object)
>> 
>>         at java.lang.ref.ReferenceQueue.remove(java.base at 25-internal/ReferenceQueue.java:215)
>>         - locked <0x0000000630802350> (a java.lang.ref.ReferenceQueue$Lock)
>> 
>> Could we use the same?  We have a lot of history reading the established style. 8-)
>> Can we match the old-style "waiting to lock" rather than "waiting on" ?
>> 
>> I realise I'm asking to move the printing of "waiting to lock" into the loop over the stackframes, and it affects various tests.
>
> When parked and there is a parkBlocker, blocked entering a monitor, or waiting in Object.wait, then it gets printed between the summary/state (first line) and the stack trace. I think this is a bit clearer that printing it after the top frame but okay to change. Note that the output isn't going to look the same as the traditional thread dump as it prints the object's identity hashcode rather than the address.
> 
> For the "locked" output then you may have a point, been back and forth on this. For synchronized methods then I think it's clearer when it is printed between the caller and synchronized callee. For synchronized blocks then it's clearer when to see which method has entered the monitor. Picking one means it's not clear in all cases but maybe people are just so used to "- locked" and don't notice. Can look at this again, it's trivial to swap between the two.

Thanks yes I do like this update -  I think it reads how we are used to seeing these things (without aiming to be exactly the same format as Thread.print). 

(oops my comment suggested waiting on, and waiting to lock, are the same, but they are not)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25429#discussion_r2120533850

From jbechberger at openjdk.org  Mon Jun  2 09:28:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 09:28:01 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>
Message-ID: <rtV4SDWYrn4P64uGvC5yAw_8qzeCUMeOwz7Ly7I9EZA=.32e3ceba-ff3d-42f1-aa0f-3e60606ad03f@github.com>

On Mon, 2 Jun 2025 04:28:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactoring
>>  - Remove convoluted native trace logic
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 119:
> 
>> 117:   _data = new_data;
>> 118:   _capacity = capacity;
>> 119: }
> 
> I assume there is a lock protecting this so it happens atomically?

This happens before the signal handler is attached to thread. So it does happen before any parallelism is introduced on thread creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120557327

From kevinw at openjdk.org  Mon Jun  2 09:32:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 2 Jun 2025 09:32:56 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v4]
In-Reply-To: <gVA_dqfomf3faG6jw9gEX7TebYD78N4rEjT7aBdDyWI=.222fdc7d-0b62-42e0-9e2b-fe5ebb1b4841@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <gVA_dqfomf3faG6jw9gEX7TebYD78N4rEjT7aBdDyWI=.222fdc7d-0b62-42e0-9e2b-fe5ebb1b4841@github.com>
Message-ID: <qPRH-N-LvswGZoclUil6riyIQZiM5sMOxN0ddAk_RJw=.e0ee164c-d856-4c38-85fe-d688e8e7f254@github.com>

On Sat, 31 May 2025 08:07:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Temp fixed until fixed in pull/25425
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Initial commit

Looks good!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25429#pullrequestreview-2887532349

From ayang at openjdk.org  Mon Jun  2 10:51:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 10:51:06 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v9]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <-mRIrbyrBpxq1lZ2tfcxIuxRLh5lcoURlM-woAXM45k=.7c152a76-e34f-42ba-b9a7-323102b19371@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 2 more: https://git.openjdk.org/jdk/compare/83cb0c6d...08bc74e1

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=08
  Stats: 4375 lines in 31 files changed: 522 ins; 3454 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From mgronlun at openjdk.org  Mon Jun  2 11:26:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:26:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
Message-ID: <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>

On Mon, 2 Jun 2025 08:58:28 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> How so?
>
> Because we need to add the threads from the signal handler. So any kind of growing array or set would not work, especially if we want to remove the threads from within the signal handler again.
> 
> This is certainly an area of future optimization, albeit this doesn't seem to have any measurable performance impact in my renaissance benchmark runs.

I don't understand what allocation has to do with anything. I'm talking about code branch layout to avoid having to test "has_cpu_time_jfr_requests()" when we know it will be false by default.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120846868

From mgronlun at openjdk.org  Mon Jun  2 11:28:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:28:59 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <kjtklorYzkvVeGAK8ei4bmKWxHn-r66MkW06sLNLdKM=.dcd25136-5252-4389-b292-f9aa98f0350d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <kjtklorYzkvVeGAK8ei4bmKWxHn-r66MkW06sLNLdKM=.dcd25136-5252-4389-b292-f9aa98f0350d@github.com>
Message-ID: <7Cy88EZJj1ZgHXaAoCY9m1PnB6UAGDJxgK9PI3BVYBQ=.a4fbad7a-19fa-4e1e-999e-8773d2fd7fb1@github.com>

On Mon, 2 Jun 2025 09:02:05 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.
>> 
>> I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.
>
> The problem is when in between queue processing a new JFR chunk is started. This caused problems before.
> 
> I would leave these kinds of optimizations for later.

Then I would recommend you drain immediately when the thread is in native, not waiting for the queue to fill up to 2/3. The reason is because the solution is based on CPU time samples and most threads that are _thread_in_native are waiting (i.e. they will not get their queues filled while in native).

I would recommend dropping the second clause about testing the queue size altogether.

That way you will not get threads stuck with a lot of events a long time in native, not being delivered.

Revive it later when you begin to attack the optimizations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120855119

From jbechberger at openjdk.org  Mon Jun  2 11:32:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:32:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Tiny fixes
 - Minor changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/439763a3..6a83d759

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=25-26

  Stats: 90 lines in 9 files changed: 24 ins; 29 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From jbechberger at openjdk.org  Mon Jun  2 11:40:00 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:40:00 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
 <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
Message-ID: <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>

On Mon, 2 Jun 2025 11:22:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Because we need to add the threads from the signal handler. So any kind of growing array or set would not work, especially if we want to remove the threads from within the signal handler again.
>> 
>> This is certainly an area of future optimization, albeit this doesn't seem to have any measurable performance impact in my renaissance benchmark runs.
>
> I don't understand what allocation has to do with anything. I'm talking about code branch layout to avoid having to test "has_cpu_time_jfr_requests()" when we know it will be false by default.

Ah. Sorry. Is it about reading the atomic boolean flag again?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120882396

From mgronlun at openjdk.org  Mon Jun  2 11:40:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:40:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
Message-ID: <yws6UutVipWNH_X-1TlXn5fdStmMPVwYPHoQ08i50yU=.a1be8704-fa72-4e42-b659-8c8d5a820905@github.com>

On Mon, 2 Jun 2025 11:32:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tiny fixes
>  - Minor changes

src/hotspot/share/runtime/thread.hpp line 59:

> 57: class SafeThreadsListPtr;
> 58: class ThreadClosure;
> 59: class ThreadCrashProtection;

Should not be needed.

src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java line 276:

> 274:      * Set the maximum event emission rate for the CPU time sampler
> 275:      *
> 276:      * Setting rate to 0 turns off the CPU time method sampler.

"CPU time method sampler" -> "CPU time sampler"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120878701
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120882161

From jbechberger at openjdk.org  Mon Jun  2 11:51:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:51:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v28]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <sVaHpNMgf-TsfTtdtJxjTnuDOwh7mXSpyFlmRarJbm0=.b39f6f38-73ea-433d-bab4-73cf82bae3a3@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:

 - Remove header includes
 - Always trigger async processing
 - Remove one atomic read

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/6a83d759..e482ad37

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

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

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

From mgronlun at openjdk.org  Mon Jun  2 11:51:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:51:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
Message-ID: <XvGb3wmX32U98zV_WzO_f4t2TOKE8BvWTzGruWNMEpM=.0d58117a-c8ff-4f24-aea4-ead1a707abde@github.com>

On Mon, 2 Jun 2025 11:32:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tiny fixes
>  - Minor changes

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 35:

> 33: 
> 34: #include "jfr/recorder/jfrRecorder.hpp"
> 35: #include "jfr/recorder/service/jfrRecorderService.hpp"

The two includes above are not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120890097

From mgronlun at openjdk.org  Mon Jun  2 11:51:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 11:51:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
 <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
 <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>
Message-ID: <TehCtTdgnEpUSwB-Uzu9sLEY8IogJy0CU9iPfWN8lzw=.c1cfb727-5b39-4a89-8c7e-97b0a8a0df0b@github.com>

On Mon, 2 Jun 2025 11:37:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> I don't understand what allocation has to do with anything. I'm talking about code branch layout to avoid having to test "has_cpu_time_jfr_requests()" when we know it will be false by default.
>
> Ah. Sorry. Is it about reading the atomic boolean flag again?

Right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120897042

From jbechberger at openjdk.org  Mon Jun  2 11:51:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 11:51:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <TehCtTdgnEpUSwB-Uzu9sLEY8IogJy0CU9iPfWN8lzw=.c1cfb727-5b39-4a89-8c7e-97b0a8a0df0b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <BiL_tQ8b1ZKTFcLI2s-O_ivw-_ypugNTdI2s6QEAUAI=.7bd94da0-a6c5-412d-825c-9f3db84ba131@github.com>
 <aim8HpMbt81kYOUGPo9En9WEe2I1TJ0OD_ZLVglbEQY=.ec5771d4-0cb0-42a3-be6d-56f51a7c20be@github.com>
 <sJkNc4cwqATKtDA6XrdojGf6ynVoLfww5BQD_NX_89c=.05027ac0-7c9d-4a43-9531-4e1fe8d629a5@github.com>
 <akZ63aXYEl51AnRTl3iv4dSlBjyPq6Y0e-NRO4b7TOU=.894d0627-8399-4d5e-b704-84021bfa6907@github.com>
 <45mCuuxToelhOdhbJlap5NCUMfgDBrVGIUDGJHAk2Rg=.1dd9d5a6-f2b5-4214-8815-d0a9f0cbddbb@github.com>
 <D0cVaWMAF8B0cnFiPtsXFWq9Yw5O9NxLAUtLF4MlrUM=.add9b9ef-37c6-4961-bf36-29df3facc0a5@github.com>
 <TehCtTdgnEpUSwB-Uzu9sLEY8IogJy0CU9iPfWN8lzw=.c1cfb727-5b39-4a89-8c7e-97b0a8a0df0b@github.com>
Message-ID: <ypAajeBnvOXtI7KLkPb7CXV1cK982tqyo4ZduXD6cVg=.a58b69a3-3045-4070-b500-cd22dc97cb31@github.com>

On Mon, 2 Jun 2025 11:43:54 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Ah. Sorry. Is it about reading the atomic boolean flag again?
>
> Right.

I pass it through now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120906973

From kevinw at openjdk.org  Mon Jun  2 11:54:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 2 Jun 2025 11:54:54 GMT
Subject: RFR: 8345745: Update mode of the Attach API communication pipe.
In-Reply-To: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>
References: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>
Message-ID: <7RBeFDW1BUysN3VH38AYxu-JFsRDKZrZS8PwEdRgv0s=.4f129313-4a80-46d5-86b9-c36b80df0426@github.com>

On Thu, 29 May 2025 19:21:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this small fix to update pipe mode for attach operation communication.
> - `FILE_FLAG_FIRST_PIPE_INSTANCE`: there is "retry" logic if pipe creation failed [1], with this flag `CreateNamedPipe` fails when pipe with the same name already exists;
> - `PIPE_REJECT_REMOTE_CLIENTS`: attach works only for local processes, the flag adds extra protection from remote connections.
> 
> [1]: https://github.com/openjdk/jdk/blob/master/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java#L93
> 
> Testing: tier1..4, hs-tier5-svc

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25530#pullrequestreview-2888050099

From rvansa at openjdk.org  Mon Jun  2 13:09:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Jun 2025 13:09:31 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v18]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <5wG8n_0XjBYjFprdBfdLMIj17sBHnJEtPdBdbi-5yxg=.6896113b-ef76-4a5b-973c-3c286554205f@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Rename pivot -> key, payload -> value, add comments
 - Add gtest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/c592ea59..456e1505

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

  Stats: 193 lines in 4 files changed: 131 ins; 5 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

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

From rvansa at openjdk.org  Mon Jun  2 13:19:50 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Jun 2025 13:19:50 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v19]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <l8EOdOVLsJILkZzcLp5gv6HFyk_Zh_HzxaPu5RiT7Wc=.06cedcfc-26ff-4362-9f4f-a3dde2303901@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Add gtests for number of bytes used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/456e1505..e214a8ec

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

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

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

From rvansa at openjdk.org  Mon Jun  2 13:31:57 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Jun 2025 13:31:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v19]
In-Reply-To: <l8EOdOVLsJILkZzcLp5gv6HFyk_Zh_HzxaPu5RiT7Wc=.06cedcfc-26ff-4362-9f4f-a3dde2303901@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <l8EOdOVLsJILkZzcLp5gv6HFyk_Zh_HzxaPu5RiT7Wc=.06cedcfc-26ff-4362-9f4f-a3dde2303901@github.com>
Message-ID: <r_hCe799Oowun391-WsELnLjW4BV7TIaWaBibyAXMy8=.e46cd232-d906-4fc0-8a9f-6856bd76fab1@github.com>

On Mon, 2 Jun 2025 13:19:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add gtests for number of bytes used

Fixed the CI failure, and added a gtest for all allowed bit widths and sizes of table from 0 to 99 and 10000. For better testability and reusability (how do I allocate the Array<u1> without a classloader?) I've replaced this with pointer + length argument.

@rose00 While your suggestion makes sense, when there's a working implementation I would leave it this way for now and leave reading with a different offset up for future improvement: we can have a microbenchmark that would justify this. I would guess that CPU caches would hide multiple memory accesses, and the loop would be unrolled (maybe to even form 4-byte access instead of 4 1-byte...). Also when not using `Array<u1>` we can no longer rely on having the 4-byte header.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2930732550

From jbechberger at openjdk.org  Mon Jun  2 13:50:49 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 13:50:49 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Fix bug related to async stack walking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/e482ad37..09ca4fed

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

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

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

From mgronlun at openjdk.org  Mon Jun  2 14:52:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 14:52:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <JE0Ncb1yoA_5a1zaUVn9lFW7aWNyJUrqcHLhCdtu-ws=.c1e6fdee-2017-49ad-bf4c-a2c8f7e5c3fd@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 349:

> 347:   const frame top_frame = thread->last_frame();
> 348:   bool in_continuation = is_in_continuation(top_frame, thread);
> 349:   for (u4 i = 0; i < queue.size(); i++) {

Realized this drainage is entirely wrong!

You are not using the sample requests in the queue to build individual stack traces for events; instead, you are using the same top frame (the last Java frame) for all of them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121391177

From mgronlun at openjdk.org  Mon Jun  2 15:04:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:04:12 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

src/hotspot/share/jfr/jfr.inline.hpp line 41:

> 39: inline void Jfr::check_and_process_sample_request(JavaThread* jt) {
> 40:   JfrThreadLocal* tl = jt->jfr_thread_local();
> 41:   bool has_cpu_time_sample_request = tl->has_cpu_time_jfr_requests();

Why this change?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 191:

> 189:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
> 190: 
> 191:   // process the queues for all threads that are in native state (and requested to be sampled)

"requested to be processed" I guess.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 270:

> 268: void JfrCPUTimeThreadSampler::enroll() {
> 269:   if (Atomic::cmpxchg(&_disenrolled, true, false)) {
> 270:     log_info(jfr)("Enrolling CPU thread sampler");

log_trace, please.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 279:

> 277: void JfrCPUTimeThreadSampler::disenroll() {
> 278:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
> 279:     log_info(jfr)("Disenrolling CPU thread sampler");

log_trace, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121414317
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121416556
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121426574
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121428073

From jbechberger at openjdk.org  Mon Jun  2 15:04:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 15:04:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
Message-ID: <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>

On Mon, 2 Jun 2025 14:57:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug related to async stack walking
>
> src/hotspot/share/jfr/jfr.inline.hpp line 41:
> 
>> 39: inline void Jfr::check_and_process_sample_request(JavaThread* jt) {
>> 40:   JfrThreadLocal* tl = jt->jfr_thread_local();
>> 41:   bool has_cpu_time_sample_request = tl->has_cpu_time_jfr_requests();
> 
> Why this change?

So I don't read the ` tl->has_cpu_time_jfr_requests()` twice on the hot-path

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 349:
> 
>> 347:   const frame top_frame = thread->last_frame();
>> 348:   bool in_continuation = is_in_continuation(top_frame, thread);
>> 349:   for (u4 i = 0; i < queue.size(); i++) {
> 
> Realized this drainage is entirely wrong!
> 
> You are not using the sample requests in the queue to build individual stack traces for events; instead, you are using the same top frame (the last Java frame) for all of them.

Can I export compute_top_frame and use it here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121424752
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121413413

From jbechberger at openjdk.org  Mon Jun  2 15:04:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 2 Jun 2025 15:04:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
Message-ID: <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>

On Mon, 2 Jun 2025 14:57:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 349:
>> 
>>> 347:   const frame top_frame = thread->last_frame();
>>> 348:   bool in_continuation = is_in_continuation(top_frame, thread);
>>> 349:   for (u4 i = 0; i < queue.size(); i++) {
>> 
>> Realized this drainage is entirely wrong!
>> 
>> You are not using the sample requests in the queue to build individual stack traces for events; instead, you are using the same top frame (the last Java frame) for all of them.
>
> Can I export compute_top_frame and use it here?

Or just create a `Jfr::drain_cpu_time_queue` method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121426469

From mgronlun at openjdk.org  Mon Jun  2 15:12:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:12:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>
Message-ID: <_CAWRT6nKdljf9SDRnD-SfdXP9L9S6Y9f6I1nGB-4q8=.eb524157-7c00-4f01-8d8a-9e9c60ef4dc7@github.com>

On Mon, 2 Jun 2025 15:01:39 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Can I export compute_top_frame and use it here?
>
> Or just create a `Jfr::drain_cpu_time_queue` method?

Try to move the entire:

void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
}

Into JfrThreadSampling.hpp / jfrThreadSampling.cpp - you can send your JfrCPUTimeThreadSampler events from there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121456081

From mgronlun at openjdk.org  Mon Jun  2 15:18:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:18:11 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
Message-ID: <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>

On Mon, 2 Jun 2025 15:01:15 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/jfr.inline.hpp line 41:
>> 
>>> 39: inline void Jfr::check_and_process_sample_request(JavaThread* jt) {
>>> 40:   JfrThreadLocal* tl = jt->jfr_thread_local();
>>> 41:   bool has_cpu_time_sample_request = tl->has_cpu_time_jfr_requests();
>> 
>> Why this change?
>
> So I don't read the ` tl->has_cpu_time_jfr_requests()` twice on the hot-path

Ok, for now. We should try to come up with a better split.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121466027

From mgronlun at openjdk.org  Mon Jun  2 15:18:12 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:18:12 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <_CAWRT6nKdljf9SDRnD-SfdXP9L9S6Y9f6I1nGB-4q8=.eb524157-7c00-4f01-8d8a-9e9c60ef4dc7@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <D2vc3YFbY_xJIQi98jp7LTDIwtlGDOatenQgXQki2Qc=.cae7d49f-70a4-4296-954d-80419f852921@github.com>
 <_CAWRT6nKdljf9SDRnD-SfdXP9L9S6Y9f6I1nGB-4q8=.eb524157-7c00-4f01-8d8a-9e9c60ef4dc7@github.com>
Message-ID: <mRMihpPCAq3lvDOb829eLp10INBukJWfmkaz8ThDpys=.762d9537-ac30-4593-887a-789ca2271171@github.com>

On Mon, 2 Jun 2025 15:09:30 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Or just create a `Jfr::drain_cpu_time_queue` method?
>
> Try to move the entire:
> 
> void JfrCPUTimeThreadSampler::stackwalk_thread_in_native(JavaThread* thread) {
> }
> 
> Into JfrThreadSampling.hpp / jfrThreadSampling.cpp - you can send your JfrCPUTimeThreadSampler events from there.

Of course, rename the routine to something appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121469433

From mgronlun at openjdk.org  Mon Jun  2 15:22:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 15:22:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <k_yXvVRs4Ra9lD64Kkl4VNKm4puJ_ME5wW5QqkSgsI8=.644fe3a9-df4f-4e89-9dc4-60ed256a2a45@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:

> 248:       break;
> 249:     } else {
> 250:       biased = false;

Not correct. There is a top_frame = *current - >biased = true below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121482514

From rvansa at openjdk.org  Mon Jun  2 15:31:46 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 2 Jun 2025 15:31:46 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v20]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Fix error on windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/e214a8ec..7d8b4a19

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

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

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

From mgronlun at openjdk.org  Mon Jun  2 17:29:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 17:29:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <ymnpsQsW76ZANo1bwt3TVupaDCc1J7MmBfE2zHDOrhY=.c6ab6614-89b3-4b12-8bf8-db880007e751@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

src/hotspot/share/memory/resourceArea.hpp line 46:

> 44: // A ResourceArea is an Arena that supports safe usage of ResourceMark.
> 45: class ResourceArea: public Arena {
> 46: 

Changes in this file are unrelated, so revert this entire file.

src/hotspot/share/prims/forte.cpp line 575:

> 573: extern "C" {
> 574: JNIEXPORT
> 575: void AsyncGetCallTrace(ASGCT_CallTrace *trace, jint depth, void* ucontext) {

Unrelated changes, please revert file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121757461
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121757998

From amenkov at openjdk.org  Mon Jun  2 18:15:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 2 Jun 2025 18:15:55 GMT
Subject: Integrated: 8345745: Update mode of the Attach API communication pipe.
In-Reply-To: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>
References: <7JMhn1RvB76NFNOmznDRggA2zeygL3_4hySSm7BcNO8=.bc945f0a-67f9-4863-ae3c-49b39b50cfc0@github.com>
Message-ID: <1W-GAMXMqO3OuUw2_aqgIimebVyFYIKbMwwrgozRR3I=.d24002b4-017a-433b-a7c1-53c1e61f1013@github.com>

On Thu, 29 May 2025 19:21:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Please review this small fix to update pipe mode for attach operation communication.
> - `FILE_FLAG_FIRST_PIPE_INSTANCE`: there is "retry" logic if pipe creation failed [1], with this flag `CreateNamedPipe` fails when pipe with the same name already exists;
> - `PIPE_REJECT_REMOTE_CLIENTS`: attach works only for local processes, the flag adds extra protection from remote connections.
> 
> [1]: https://github.com/openjdk/jdk/blob/master/src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java#L93
> 
> Testing: tier1..4, hs-tier5-svc

This pull request has now been integrated.

Changeset: ec02a87a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec02a87aeef008f6b2f94001fa33bac66bf24627
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8345745: Update mode of the Attach API communication pipe.

Reviewed-by: sspitsyn, kevinw

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

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

From vyazici at openjdk.org  Mon Jun  2 18:39:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 18:39:33 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
Message-ID: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.

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

  Provide fallback for `stdin.encoding`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25542/files
  - new: https://git.openjdk.org/jdk/pull/25542/files/d7751294..45bdc4fd

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

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

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

From shade at openjdk.org  Mon Jun  2 18:47:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:47:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

Scanned this briefly, would do another pass tomorrow.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 117:

> 115: 
> 116: bool JfrCPUTimeTraceQueue::is_empty() const {
> 117:   return Atomic::load(&_head) == 0;

Not entirely clear what is the memory semantics for accessing `_head`. Does it need to be acq/rel? If so, this one should be `::load_acquire`?

src/hotspot/share/memory/resourceArea.hpp line 46:

> 44: // A ResourceArea is an Arena that supports safe usage of ResourceMark.
> 45: class ResourceArea: public Arena {
> 46: 

All the changes in this file are unnecessary, please revert.

src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java line 281:

> 279:      * @param autoadapt true if the rate should be adapted automatically
> 280:      */
> 281:     public static native void setCPUThrottle(double rate, boolean autoadapt);

Suggestion:

    public static native void setCPUThrottle(double rate, boolean autoAdapt);

test/jdk/jdk/jfr/event/profiling/TestSamplingLongPeriod.java line 42:

> 40: public class TestSamplingLongPeriod {
> 41: 
> 42:     static String sampleEvent = EventNames.ExecutionSample;

Does not look necessary to change?

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2888004951
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121900364
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121610476
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121587105
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2121584954

From shade at openjdk.org  Mon Jun  2 18:47:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:47:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v24]
In-Reply-To: <dw0nEvtOhHk5pe5VLBy_RF29x_ACwQ_UTjAVZykGKmc=.41920e11-799a-40a2-a258-3e796c260196@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <xRvOZ-8ktOQkODYswcR02IaDeIbkY97OENZ9EmG1nYo=.6a345516-4fc1-4467-ad85-091597219bed@github.com>
 <FftrHrw6vT87jUKXq769ogIUs7SQUN3RmG7WBRIJS6Q=.765a943c-edaf-4bc8-864d-92e46ff56f38@github.com>
 <-QiSWEqppeW60aedVbLA3WTmnba7Fry53Qr86wE2EPs=.7a6327ce-7ef0-4b1c-bc68-0421ba3fd46f@github.com>
 <dw0nEvtOhHk5pe5VLBy_RF29x_ACwQ_UTjAVZykGKmc=.41920e11-799a-40a2-a258-3e796c260196@github.com>
Message-ID: <c_YDStb7UsPO4JPDnKv9B33xAw4yKAQwqtuKgkeS3AQ=.c09f8335-46d3-498a-9b4e-7bb339bc5b19@github.com>

On Sun, 1 Jun 2025 07:19:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Thanks for catching this mistake. I'll fix it this afternoon.
>
> I fixed it by changing the JEP.

Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120893338

From shade at openjdk.org  Mon Jun  2 18:47:30 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 18:47:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v27]
In-Reply-To: <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <ky8n9KPBy3tkJgX5jTEGCEQOV-pa7brI0mZBlgmspto=.c8f4ff6d-6534-4374-a6df-a449e1e6393f@github.com>
Message-ID: <B42Y_m2MMHoovZ-ronA3urM0XBTMSHMrYxgVXTFOYCo=.df0e5588-d10f-44a7-b0c3-45eb3680ed92@github.com>

On Mon, 2 Jun 2025 11:32:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tiny fixes
>  - Minor changes

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 30:

> 28: #include "runtime/orderAccess.hpp"
> 29: #include "utilities/ticks.hpp"
> 30: #include "jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp"

Include order?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 60:

> 58:   assert(raw_thread->is_Java_thread(), "invariant");
> 59:   JavaThread* jt;
> 60:   if ((jt = JavaThread::cast(raw_thread))->is_exiting()) {

I see no point to be extra-smart with inline assignments here:

Suggestion:

  JavaThread* jt = JavaThread::cast(raw_thread);
  if (jt->is_exiting()) {

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 115:

> 113:   JfrCPUTimeSampleRequest* new_data = JfrCHeapObj::new_array<JfrCPUTimeSampleRequest>(capacity);
> 114:   JfrCHeapObj::free(_data, _capacity * sizeof(JfrCPUTimeSampleRequest));
> 115:   _data = new_data;

A bit of peak memory consumption improvement: don't have two things live at once. Plus, give the native allocator a chance to reuse the same location.

Suggestion:

  JfrCHeapObj::free(_data, _capacity * sizeof(JfrCPUTimeSampleRequest));
  _data = JfrCHeapObj::new_array<JfrCPUTimeSampleRequest>(capacity);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120895107
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120897472
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120909443

From cjplummer at openjdk.org  Mon Jun  2 19:02:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:02:53 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <KmxfpCX7C01W4ZWfeB4VkJ9KUzSNDnioLJY4VO65Yf4=.8ef6039a-22ba-4db7-895a-066353f85236@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110:         Charset charset = Charset.forName(System.getProperty("stdin.encoding"), Charset.defaultCharset());
> 111:         BufferedReader in = new BufferedReader(new InputStreamReader(System.in, charset));

Why in some cases are you special casing the the default charset as you do here, but in other cases you are not? Also, the CharSet.forName() API you are using here is new in 18, which means backports will need to address that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25542#discussion_r2121939764

From cjplummer at openjdk.org  Mon Jun  2 19:07:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:07:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <9JQNK3tYLfg04pRpUiGpPYWoSunSfqWB61lkLxSPxwk=.a781defd-ea0e-4ebf-aa7f-01fff2e63101@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

Can you document why each tests fails so we have it on record? Can be done in the PR or the CR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2932080104

From vyazici at openjdk.org  Mon Jun  2 19:27:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:27:08 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Provide fallback for `stdin.encoding`
 - Revert changes to `Application` and `JavaChild`
   
   There stdin is connected to the parent process rather than the console.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/3da53cc9..ef30c050

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

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

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

From vyazici at openjdk.org  Mon Jun  2 19:27:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:27:09 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <sa8L4ZBywxveDtzE7b5VbcdXy3cLvh3INzrIKv4ja7s=.01a87615-dc77-4022-a52a-2e6225b83f8f@github.com>
Message-ID: <WSL4sRjVbOyRjK8xqSUVuclRvRXa5zwKdptdkG-BETY=.192e259a-1dec-4421-8bc4-e9bdc50493f1@github.com>

On Fri, 30 May 2025 14:23:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Provide fallback for `stdin.encoding`
>>  - Revert changes to `Application` and `JavaChild`
>>    
>>    There stdin is connected to the parent process rather than the console.
>
> test/jdk/com/sun/tools/attach/Application.java line 40:
> 
>> 38: 
>> 39:         try (BufferedReader br = new BufferedReader(new InputStreamReader(
>> 40:                 System.in, System.getProperty("stdin.encoding")))) {
> 
> This "application" is launched by the test so connected to the parent process rather than the console.

Reverted in 2d52ba408.

> test/jdk/java/lang/ProcessHandle/JavaChild.java line 315:
> 
>> 313:                         // children and wait for each to exit
>> 314:                         sendResult(action, "start");
>> 315:                         try (Reader reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 
> I didn't study the test closely but I think this is another case where a child process is launched so System.in is connected to the parent rather than the console.

Reverted in 2d52ba408..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121978546
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121978885

From cjplummer at openjdk.org  Mon Jun  2 19:29:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 19:29:50 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v2]
In-Reply-To: <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
Message-ID: <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>

On Mon, 2 Jun 2025 19:27:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Provide fallback for `stdin.encoding`
>  - Revert changes to `Application` and `JavaChild`
>    
>    There stdin is connected to the parent process rather than the console.

test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141:

> 139:     Thread console(final int num, final int nhits) {
> 140:         final InputStreamReader isr = new InputStreamReader(
> 141:                 System.in, Charset.forName(System.getProperty("stdin.encoding")));

`isr` is not really needed. It is used to create `br`, which is never used. It is also synchronized on, but since there is a unique `isr` for each thread, the synchronization does nothing. I suggest just deleting `isr`, `br`, and the `synchronized` below.

Note there is a hint in a comment as to why it is like this:


                                // This is a tendril from the original jdb test.
                                // It could probably be deleted.


I think this test once used jdb (and had to deal with the jdb console), but no longer does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2121984300

From vyazici at openjdk.org  Mon Jun  2 19:41:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:41:52 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <KmxfpCX7C01W4ZWfeB4VkJ9KUzSNDnioLJY4VO65Yf4=.8ef6039a-22ba-4db7-895a-066353f85236@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <KmxfpCX7C01W4ZWfeB4VkJ9KUzSNDnioLJY4VO65Yf4=.8ef6039a-22ba-4db7-895a-066353f85236@github.com>
Message-ID: <bVByfbVe5ra99AXi1923ZvXy0J8BVlO_121U7KlGF9k=.13e026fc-ed9f-4e05-9ffe-2e19bae3f746@github.com>

On Mon, 2 Jun 2025 19:00:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Why in some cases are you special casing the the default charset as you do here, but in other cases you are not?

@plummercj, as requested in the parent ticket (i.e., [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893)), I added a fallback, except for tests. AFAICT, if `stdin.encoding` is either missing or contains an invalid value in a test, we ideally should fail the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25542#discussion_r2122007106

From vyazici at openjdk.org  Mon Jun  2 19:50:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:50:10 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Clean-up `MultiBreakpointsTarg`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/ef30c050..8f8a6575

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

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

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

From vyazici at openjdk.org  Mon Jun  2 19:50:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 19:50:11 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <P7qUytAQKPn9aH3r34zhHjGHl0eXN7zWHHtnQs5fxMU=.405c8ac9-9fd0-402f-bcf4-0bcd3e021daa@github.com>
 <8V_c_ulLVTPp6ivKsU3vsslAV3l4b41mRhDKbWGv5Qk=.ea887db3-4975-4c23-b907-d02ba90f2b44@github.com>
Message-ID: <oZJozOvTGdWRwxL9ISwdDP49MAHhj1-KM5CRF4w77LQ=.b13d7e0f-f02e-4b94-958b-09fc2f092eef@github.com>

On Mon, 2 Jun 2025 19:27:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean-up `MultiBreakpointsTarg`
>
> test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 141:
> 
>> 139:     Thread console(final int num, final int nhits) {
>> 140:         final InputStreamReader isr = new InputStreamReader(
>> 141:                 System.in, Charset.forName(System.getProperty("stdin.encoding")));
> 
> `isr` is not really needed. It is used to create `br`, which is never used. It is also synchronized on, but since there is a unique `isr` for each thread, the synchronization does nothing. I suggest just deleting `isr`, `br`, and the `synchronized` below.
> 
> Note there is a hint in a comment as to why it is like this:
> 
> 
>                                 // This is a tendril from the original jdb test.
>                                 // It could probably be deleted.
> 
> 
> I think this test once used jdb (and had to deal with the jdb console), but no longer does.

Implemented your suggestion in 8f8a65754 ? took the liberty to remove the unused `done` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2122019203

From mgronlun at openjdk.org  Mon Jun  2 20:07:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 20:07:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <cv9bDy_Zg7iEzbSAR5aFiHolzaWP1SYd6UPzSNAPLiA=.b3dda4d6-e525-4b49-8570-a34873e7744f@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 49:

> 47: 
> 48: static bool is_excluded(JavaThread* thread) {
> 49:   return thread->is_hidden_from_external_view() || thread->jfr_thread_local()->is_excluded();

I think I misled you saying that JfrRecorder_thread would be excluded by the above expression. That was true - but not anymore.

Our exclusion test looks like:

static inline bool is_excluded(JavaThread* jt) {
  assert(jt != nullptr, "invariant");
  return jt->is_Compiler_thread() || jt->is_hidden_from_external_view() || jt->is_JfrRecorder_thread() || jt->jfr_thread_local()->is_excluded();
}

I like you could fold jt->is_Compiler_thread() into jt->is_hidden_from_external_view() - good!.

But can you please again list the condition jt->is_JfrRecorder_thread() ? Sorry, I forgot we had removed it from being considered excluded on the JfrThreadLocal level. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122045043

From sspitsyn at openjdk.org  Mon Jun  2 20:15:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 2 Jun 2025 20:15:52 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v4]
In-Reply-To: <gVA_dqfomf3faG6jw9gEX7TebYD78N4rEjT7aBdDyWI=.222fdc7d-0b62-42e0-9e2b-fe5ebb1b4841@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <gVA_dqfomf3faG6jw9gEX7TebYD78N4rEjT7aBdDyWI=.222fdc7d-0b62-42e0-9e2b-fe5ebb1b4841@github.com>
Message-ID: <Lnl1_TV-Pk8mQttkqoO2zti2lxZQtUvcn-yYFsxdJVI=.04d89400-6179-4841-9932-7348d29641c2@github.com>

On Sat, 31 May 2025 08:07:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Temp fixed until fixed in pull/25425
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Merge branch 'pull/25425' into JDK-8356870
>  - Initial commit

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25429#pullrequestreview-2889804529

From dholmes at openjdk.org  Mon Jun  2 21:56:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Jun 2025 21:56:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>
Message-ID: <ermts7eqxGeuCidfgDMgA-gpV2OweDA0wsMIbOA8yiw=.26448a32-1433-47f0-b748-1c328aefb6c6@github.com>

On Mon, 2 Jun 2025 18:37:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug related to async stack walking
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 117:
> 
>> 115: 
>> 116: bool JfrCPUTimeTraceQueue::is_empty() const {
>> 117:   return Atomic::load(&_head) == 0;
> 
> Not entirely clear what is the memory semantics for accessing `_head`. Does it need to be acq/rel? If so, this one should be `::load_acquire`?

Many of the accesses to head do not appear to synchronize with anything and so do not need acquire semantics. But the overall concurrency properties of this code are very unclear to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122228261

From cjplummer at openjdk.org  Mon Jun  2 22:03:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 22:03:51 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v3]
In-Reply-To: <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <A-d7eoGNEQ-n4RYuRRUfHuu4FT6clqA-Y_sYEScbdQs=.12fb732d-7078-43a2-855f-c8980a3f4de7@github.com>
Message-ID: <ujbbla0V9GPjN2ivoOPSrIY_apfD9lXuiUCXFJkjWpc=.350f1114-42ed-4abf-85f5-7bfbf77d6655@github.com>

On Mon, 2 Jun 2025 19:50:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean-up `MultiBreakpointsTarg`

The src/jdk.jdi and test/jdk/com/sun/jdi changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25544#pullrequestreview-2890059517

From cjplummer at openjdk.org  Mon Jun  2 22:07:52 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 2 Jun 2025 22:07:52 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <-rIQHptI3h_uZTew6KYZLXC--aq6_Sxoe5wg1Xe7xq8=.f41290f7-7c61-4849-80d6-e65cf47d8733@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

Changes look good. Can you clarify your testing?

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25542#pullrequestreview-2890065248

From coleenp at openjdk.org  Tue Jun  3 00:14:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 00:14:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v20]
In-Reply-To: <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>
Message-ID: <f7QBWD5FyOM_VNGVrOnJHvF014lpehRQteTsah8GTPg=.dbb085c8-dbfb-4611-a9f5-332b7ed5aabd@github.com>

On Mon, 2 Jun 2025 15:31:46 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix error on windows

It all seems reasonable until I got to the packing code and it'll take a long time to figure out how it works.  Maybe some comments would help.  I have 3 general comments though:

1. The coding style guide somewhere says that the * belongs with the type and not the name.  This is inconsistent in this code.  Can you fix it?
2. Block comments (except copyright) should use // not /* */
3. The jtreg test directory name should be not the bugid.  I think this test can go in directory runtime/FieldLayout.

src/hotspot/share/utilities/packedTable.hpp line 38:

> 36:   uint32_t _key_mask;
> 37:   unsigned int _value_shift;
> 38:   uint32_t _value_mask;

Aren't all 4 of these types the same?  can you make them all uint32_t or all unsigned int?  (former preferred).

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2890214085
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2122347635

From coleenp at openjdk.org  Tue Jun  3 00:14:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 00:14:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v20]
In-Reply-To: <f7QBWD5FyOM_VNGVrOnJHvF014lpehRQteTsah8GTPg=.dbb085c8-dbfb-4611-a9f5-332b7ed5aabd@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>
 <f7QBWD5FyOM_VNGVrOnJHvF014lpehRQteTsah8GTPg=.dbb085c8-dbfb-4611-a9f5-332b7ed5aabd@github.com>
Message-ID: <sQsU-pujWZmu5HX-UDABwPI5ZW_bjMycXPwkUGicKxk=.3935e052-920f-4e94-8921-cfb6037bf9b0@github.com>

On Mon, 2 Jun 2025 23:49:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix error on windows
>
> src/hotspot/share/utilities/packedTable.hpp line 38:
> 
>> 36:   uint32_t _key_mask;
>> 37:   unsigned int _value_shift;
>> 38:   uint32_t _value_mask;
> 
> Aren't all 4 of these types the same?  can you make them all uint32_t or all unsigned int?  (former preferred).

Can you explain somewhere how fields are mapped to this?  I assume they're sorted, for some reason I expected the packed table to be {name-cp-index, sig-cp-index, offset-in-fieldstream-for-direct-access}.  Does every field get 4 ints ?  So why is it packed into ```Array<u1>``` rather than just use ```Array<u4>```?  So much packing code that I don't know how anyone could ever debug it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2122360613

From dholmes at openjdk.org  Tue Jun  3 00:16:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:16:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v26]
In-Reply-To: <rtV4SDWYrn4P64uGvC5yAw_8qzeCUMeOwz7Ly7I9EZA=.32e3ceba-ff3d-42f1-aa0f-3e60606ad03f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <HexcJYtAjgg1rDSIUkYMJUSs2nA8Nu2HDX6oCatAI-U=.20395b27-49e8-42bb-86ae-425914c5bddb@github.com>
 <YWEPhE1Pluc1GMsLqAmu5FTbkhBu8at9O3M_E347yks=.db226468-9dcc-4e1c-84bb-18c3d96a6a73@github.com>
 <rtV4SDWYrn4P64uGvC5yAw_8qzeCUMeOwz7Ly7I9EZA=.32e3ceba-ff3d-42f1-aa0f-3e60606ad03f@github.com>
Message-ID: <jF47KzRlEdyxYFBpo8PMrj9wbL43EWQoE6Kf3vZ95c8=.fcd9f508-0827-4666-83e3-595c3dc484e3@github.com>

On Mon, 2 Jun 2025 09:24:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 119:
>> 
>>> 117:   _data = new_data;
>>> 118:   _capacity = capacity;
>>> 119: }
>> 
>> I assume there is a lock protecting this so it happens atomically?
>
> This happens before the signal handler is attached to thread. So it does happen before any parallelism is introduced on thread creation.

I'm missing the big picture here unfortunately. This looks like it can get called repeatedly as needed to change capacity. Are you saying it only gets called once before we create the sampler thread? Is the concurrency model described somewhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122365626

From dholmes at openjdk.org  Tue Jun  3 00:28:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:28:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <ermts7eqxGeuCidfgDMgA-gpV2OweDA0wsMIbOA8yiw=.26448a32-1433-47f0-b748-1c328aefb6c6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <P0v0YtPi7wVoULsqUMtksYKvvdiiCqZsI5YQLsfMBsA=.604dc4f2-3570-49ac-a5ad-99779e841eee@github.com>
 <ermts7eqxGeuCidfgDMgA-gpV2OweDA0wsMIbOA8yiw=.26448a32-1433-47f0-b748-1c328aefb6c6@github.com>
Message-ID: <_Q0iW6TuzM0P1qeE2XsMZbTx3lfCgW9QDEsf3-FlRYE=.b6707a06-3d91-4764-a8d8-7eaa76680584@github.com>

On Mon, 2 Jun 2025 21:53:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 117:
>> 
>>> 115: 
>>> 116: bool JfrCPUTimeTraceQueue::is_empty() const {
>>> 117:   return Atomic::load(&_head) == 0;
>> 
>> Not entirely clear what is the memory semantics for accessing `_head`. Does it need to be acq/rel? If so, this one should be `::load_acquire`?
>
> Many of the accesses to head do not appear to synchronize with anything and so do not need acquire semantics. But the overall concurrency properties of this code are very unclear to me.

To be clear, you only need acquire semantics here if after seeing the value 0 you need to access fields that were written before `_head` was set to 0. Similarly for most of the other access to `_head`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122374152

From dholmes at openjdk.org  Tue Jun  3 00:53:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 00:53:57 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <W6YZr5HhYbegTTT6P11bS1OJAX4-ixxPJ7ZYv1oxTII=.341483bf-59a1-4095-a0f2-014e4d5f8c7c@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

Changes look fine but I agree with Chris that we need to document why these tests don't work with ASAN, though I think I'd prefer to see an `@comment` before the `@requires !vm.asan` in the actual test files - assuming the reason can be stated clearly and succinctly.

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2890276148

From rvansa at openjdk.org  Tue Jun  3 05:53:55 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Jun 2025 05:53:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v20]
In-Reply-To: <sQsU-pujWZmu5HX-UDABwPI5ZW_bjMycXPwkUGicKxk=.3935e052-920f-4e94-8921-cfb6037bf9b0@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>
 <f7QBWD5FyOM_VNGVrOnJHvF014lpehRQteTsah8GTPg=.dbb085c8-dbfb-4611-a9f5-332b7ed5aabd@github.com>
 <sQsU-pujWZmu5HX-UDABwPI5ZW_bjMycXPwkUGicKxk=.3935e052-920f-4e94-8921-cfb6037bf9b0@github.com>
Message-ID: <chn4VYP2pY1Exufkwbg7Syf5hsJkEL02DKqBjGNdNxw=.23e67ff9-02a1-4baf-8915-0ed7c3f76ca0@github.com>

On Tue, 3 Jun 2025 00:05:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/packedTable.hpp line 38:
>> 
>>> 36:   uint32_t _key_mask;
>>> 37:   unsigned int _value_shift;
>>> 38:   uint32_t _value_mask;
>> 
>> Aren't all 4 of these types the same?  can you make them all uint32_t or all unsigned int?  (former preferred).
>
> Can you explain somewhere how fields are mapped to this?  I assume they're sorted, for some reason I expected the packed table to be {name-cp-index, sig-cp-index, offset-in-fieldstream-for-direct-access}.  Does every field get 4 ints ?  So why is it packed into ```Array<u1>``` rather than just use ```Array<u4>```?  So much packing code that I don't know how anyone could ever debug it.

Yes, in practice these all are of the same size, but in case of the masks (as well as in case of arguments in API) I want to stress out that these are 32 bit numbers. The `unsigned int`s are just 'some not too big number'.
Is there any general guidance on deciding between `unsigned int` (I suppose just `unsigned` is not recommended), `uint32_t` and `u4`?

I was hoping that the comment on line 68 explains the intended use, but I can be more verbose and document each method. When the packed table is used for fieldinfo, it's { offset-in-fieldstream, index-in-fieldstream }. The Comparator implementation can translate offset-in-fieldstream -> { name, signature } and then do the comparison. The `index-in-fieldstream` is kind of second-class citizen; we need to fill it into `FieldInfo` and it is not encoded in the stream, therefore we need to encode it in the packed table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2122780819

From jbechberger at openjdk.org  Tue Jun  3 06:58:03 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 06:58:03 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
Message-ID: <GebM_7E8Zpil6ckH6wYx4izFkdoWT0IwW5_oKPBrYJ4=.46da4495-e7a4-4f85-9527-6ca0da9a2f09@github.com>

On Mon, 2 Jun 2025 13:50:49 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug related to async stack walking

Regarding https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783


raw_thread == nullptr


This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933774229

From jbechberger at openjdk.org  Tue Jun  3 07:05:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:05:47 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v30]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <QaYQnf_1OBfk55Ppt_C_WcWAJTN9fRh5xj7aHq3nlEs=.e99a7873-e243-4e86-a193-cda9f720842a@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Check for raw_thread == nullptr
 - Move async stackwalking to JFR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/09ca4fed..bef52132

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

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

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

From jbechberger at openjdk.org  Tue Jun  3 07:12:46 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:12:46 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Small fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/bef52132..c3dedefb

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

  Stats: 17 lines in 4 files changed: 2 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From rvansa at openjdk.org  Tue Jun  3 07:16:47 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Jun 2025 07:16:47 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:

 - Moved jtreg test
 - Improved documentation
 - Fix coding style (asterisk placement)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/7d8b4a19..862b264b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=19-20

  Stats: 99 lines in 11 files changed: 31 ins; 2 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

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

From jbechberger at openjdk.org  Tue Jun  3 07:17:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:17:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <cv9bDy_Zg7iEzbSAR5aFiHolzaWP1SYd6UPzSNAPLiA=.b3dda4d6-e525-4b49-8570-a34873e7744f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <cv9bDy_Zg7iEzbSAR5aFiHolzaWP1SYd6UPzSNAPLiA=.b3dda4d6-e525-4b49-8570-a34873e7744f@github.com>
Message-ID: <G1Iao_wSPalg0_uQglKFwWi6j4UWtH59ggkQZ7mZy3E=.33bdd35a-a685-44d0-9656-997985fc86f8@github.com>

On Mon, 2 Jun 2025 20:02:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug related to async stack walking
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 49:
> 
>> 47: 
>> 48: static bool is_excluded(JavaThread* thread) {
>> 49:   return thread->is_hidden_from_external_view() || thread->jfr_thread_local()->is_excluded();
> 
> I think I misled you saying that JfrRecorder_thread would be excluded by the above expression. That was true - but not anymore.
> 
> Our exclusion test looks like:
> 
> static inline bool is_excluded(JavaThread* jt) {
>   assert(jt != nullptr, "invariant");
>   return jt->is_Compiler_thread() || jt->is_hidden_from_external_view() || jt->is_JfrRecorder_thread() || jt->jfr_thread_local()->is_excluded();
> }
> 
> I like you could fold jt->is_Compiler_thread() into jt->is_hidden_from_external_view() - good!.
> 
> But can you please again list the condition jt->is_JfrRecorder_thread()? Sorry, I forgot we had removed it from being considered excluded on a per JfrThreadLocal level. Thanks.

No problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2122934873

From rvansa at openjdk.org  Tue Jun  3 07:18:58 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 3 Jun 2025 07:18:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v15]
In-Reply-To: <UNr0VrW0ftFAlJOt7dnlb75G2NHjKctDSU_JLwixNwg=.152290e5-d819-46d1-9b6c-bbfe20375e0d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
 <UNr0VrW0ftFAlJOt7dnlb75G2NHjKctDSU_JLwixNwg=.152290e5-d819-46d1-9b6c-bbfe20375e0d@github.com>
Message-ID: <o_aebFjhK8CLTQGEyFkuI2ghGU_k8j-xSpVZK9g4E00=.2e447285-f08b-4258-ad7e-074955dbcd58@github.com>

On Sat, 31 May 2025 14:49:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More debug logs
>
> I can reproduce the crash when building slowdebug on linux-x64.

@coleenp I fixed the coding style (I wish OpenJDK had a linter, or at least a checker... the asterisk placement is hard to get used to), improved docs and moved the jtreg test to runtime/FieldStream (I think that FieldLayout checks how are fields placed within an instance).

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2933845743

From dholmes at openjdk.org  Tue Jun  3 07:39:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Jun 2025 07:39:02 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
Message-ID: <aw1krGUp1fbgU8GLgIiJ2wQ3k_biKBazNCq9dNhZew0=.d44b11e9-5853-4337-8f0b-f0d55fe86809@github.com>

On Tue, 3 Jun 2025 07:12:46 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Small fixes

> Regarding [#25302 (comment)](https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783)
> 
> ```
> raw_thread == nullptr
> ```
> 
> This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)

That is interesting. The signal appears to be being handled on an unattached thread during shutdown, and there is no stack left to show any VM involvement. Possibly we need to block the signal as part of thread termination, before we clear the current thread. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933916367

From jbechberger at openjdk.org  Tue Jun  3 07:44:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:44:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v32]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <iNwRQeUlur9y6sm3QRLH9_ooILlyzOdYbzxSlBf_DZM=.8cec5ec7-2efb-4990-aa1c-a6747f8842d3@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Remove includes and other lines
 - Fix is_excluded

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/c3dedefb..ab47f680

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

  Stats: 25 lines in 17 files changed: 4 ins; 5 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From jbechberger at openjdk.org  Tue Jun  3 07:44:34 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 07:44:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
Message-ID: <PyJV7DdapZ82m3biASyj6vhrb74OMiG6FpFaPas_ZNU=.1c5f57ab-2147-4c04-9f9f-875ac7a8ede8@github.com>

On Tue, 3 Jun 2025 07:12:46 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>    
>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>  - Small fixes

We already do:


void JfrCPUTimeThreadSampler::on_javathread_terminate(JavaThread* thread) {
  JfrThreadLocal* tl = thread->jfr_thread_local();
  assert(tl != nullptr, "invariant");
  timer_t* timer = tl->cpu_timer();
  if (timer == nullptr) {
    return; // no timer was created for this thread
  }
  timer_delete(*timer);

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2933945034

From vyazici at openjdk.org  Tue Jun  3 07:55:06 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 07:55:06 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Fix missing `java.io.Reader` import in `Ktab`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/8f8a6575..78e8de51

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

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

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

From jbechberger at openjdk.org  Tue Jun  3 08:42:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 08:42:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v33]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <PAEbbcgVvoCbXPc69QgUgGFfGLFr2KYnRNfEcRWBPPE=.a236f65f-92f6-4854-8b82-e8500d75409c@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Fix non Linux builds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ab47f680..ef9f9cd1

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

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

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

From vyazici at openjdk.org  Tue Jun  3 09:26:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 09:26:05 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <-rIQHptI3h_uZTew6KYZLXC--aq6_Sxoe5wg1Xe7xq8=.f41290f7-7c61-4849-80d6-e65cf47d8733@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <-rIQHptI3h_uZTew6KYZLXC--aq6_Sxoe5wg1Xe7xq8=.f41290f7-7c61-4849-80d6-e65cf47d8733@github.com>
Message-ID: <qEkAQ_qddaxGTU2r3ZgGSbUXJ3DuSKFjGa7-gE-M-CI=.b2db3e01-dbb2-4e73-8982-c73e3eb1873e@github.com>

On Mon, 2 Jun 2025 22:04:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Can you clarify your testing?

@plummercj, green `tier1,2` results on 45bdc4fdaa1 are attached to the ticket. Would they suffice?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2934323998

From jbechberger at openjdk.org  Tue Jun  3 11:32:18 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 11:32:18 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v31]
In-Reply-To: <aw1krGUp1fbgU8GLgIiJ2wQ3k_biKBazNCq9dNhZew0=.d44b11e9-5853-4337-8f0b-f0d55fe86809@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <_4vRA_P9_dLG022vs8ZinaZmqC48drRAwdOSiDG9Wjk=.25880197-6c87-4faf-8259-12d6c0f10f2e@github.com>
 <aw1krGUp1fbgU8GLgIiJ2wQ3k_biKBazNCq9dNhZew0=.d44b11e9-5853-4337-8f0b-f0d55fe86809@github.com>
Message-ID: <iijJRrJgOxlvWSA3hrQTgE7SJgqnHfIwZ9FQGfhws3U=.e5d88557-1006-4c72-9986-c7f3b7722130@github.com>

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

>> Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>>    
>>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>>  - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
>>    
>>    Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
>>  - Small fixes
>
>> Regarding [#25302 (comment)](https://github.com/openjdk/jdk/pull/25302#discussion_r2119984783)
>> 
>> ```
>> raw_thread == nullptr
>> ```
>> 
>> This seems to happen rarely on (abrupt) shutdowns. I attached an hs_err file: [hs_err_pid1688961.log](https://github.com/user-attachments/files/20563594/hs_err_pid1688961.log)
> 
> That is interesting. The signal appears to be being handled on an unattached thread during shutdown, and there is no stack left to show any VM involvement. Possibly we need to block the signal as part of thread termination, before we clear the current thread. ?

Regarding the acquire-release-semantics (cc @dholmes-ora): I currently use it, because it works and is fast enough. Using a weaker semantics is a good optimization, but I would abstain it for new due to time constraints.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934793239

From jbechberger at openjdk.org  Tue Jun  3 11:42:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 11:42:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v34]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <NY5XG0lZkmWMi7UGr6WgzeiNzUJvRx5DYk8Ec8A3XdE=.e351aea6-faa4-41e7-8e08-55891766cefd@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Use store-release semantics
 - Log error when timer_create fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ef9f9cd1..93b5a189

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

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

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

From jbechberger at openjdk.org  Tue Jun  3 12:12:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:12:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Fix include order
 - Tiny refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/93b5a189..71611f1e

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

  Stats: 19 lines in 4 files changed: 8 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From egahlin at openjdk.org  Tue Jun  3 12:19:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 12:19:04 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
Message-ID: <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>

On Mon, 26 May 2025 15:42:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>>> This is added automatically. If I add "(Experimental)" to the title, then I get "X (Experimental) (Experimental)"
>> 
>> Sweet.
>> 
>>> I'm unsure how to implement this using the SQL version that is used for the views
>> 
>> I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.
>
>> I will see if I can create an example with some other events that show the syntax, and then you can fill in the CPU-Time events.
> 
> I have a Mac, so I could not try it with an actual recording, but something like this:
> 
> [application.cpu-time-statistics]
> label = "CPU Time Samples Statistics"
> form = "COLUMN 'Successful Samples', 'Failed Samples', 'Total Samples', 'Lost Samples'
>         SELECT COUNT(S.startTime), COUNT(F.startTime), Count(A.startTime), SUM(L.lostSamples)
>         FROM 
>           CPUTimeSample AS S,
>           CPUTimeSample AS F,
>           CPUTimeSample AS A,
>           CPUTimeSampleLoss AS L
>         WHERE
>           S.failed = 'false' AND
>           F.failed = 'true'"
> 
> 
>  I removed biased, because I wonder If we should have such a field? There can be many types of biases, and the implementation may change in the future.

> Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime in here.

Lost might be better.

I wonder if `<Field type="Thread" name="eventThread" label="Thread" />` is needed,  instead of thread = true?

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934959447

From jbechberger at openjdk.org  Tue Jun  3 12:19:05 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:19:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
 <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
Message-ID: <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>

On Tue, 3 Jun 2025 12:15:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I wonder if <Field type="Thread" name="eventThread" label="Thread" /> is needed, instead of thread = true?

We had these discussions before on the old PR and then decided to end up with eventThread (as the other events do to),

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2934963523

From mgronlun at openjdk.org  Tue Jun  3 12:19:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:19:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
Message-ID: <fkXDN7qy0lQ2si3il714rKAQ6HmUTyt1e8OZpDnRSZg=.d88ce69a-357f-4d3b-a29e-cd6dfeb7d80d@github.com>

On Tue, 3 Jun 2025 12:12:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix include order
>  - Tiny refactoring

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 67:

> 65:   }
> 66: 
> 67:   if (is_excluded(jt)) {

I think move this before the jt->is_exiting() check - excluded is much much more common than exiting...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123633391

From mgronlun at openjdk.org  Tue Jun  3 12:25:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:25:05 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
Message-ID: <e87wWtBns9NxmIlA4-ycnt015LIpn52ob9VcL2UEhww=.c500f54a-1b71-43bc-b122-b036fa975f54@github.com>

On Tue, 3 Jun 2025 12:12:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix include order
>  - Tiny refactoring

src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 371:

> 369:   timer_t* cpu_timer() const;
> 370: 
> 371:   // The CPU time JFR lock has four different states:

Only three different states now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123651646

From jbechberger at openjdk.org  Tue Jun  3 12:29:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:29:48 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v36]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <gTBCzFTywdIwThuNzoXcpxf8tzTIJE4BxklK_uiil7k=.aa48a78e-973e-498f-9738-af13c0f4db33@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - CPUTimeSampleLoss -> CPUTimeSamplesLost
 - Move is_excluded forward

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/71611f1e..a419daba

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

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

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

From azafari at openjdk.org  Tue Jun  3 12:34:55 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 3 Jun 2025 12:34:55 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <6HSruHtZNPOZJp4vNFnwMns6-_rP_MEHtnnvAP7S5QU=.e91023a2-089c-4541-86a5-ae8d4adeb99d@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

In ASAN built JDK, some gtests and some other JTREG tests in runtime/ErrorHandling also fail.
Do we exclude these in another PR? or should they also be handled/excluded here?

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2935018245

From jbechberger at openjdk.org  Tue Jun  3 12:35:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:35:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v37]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <WlHvbZE4QvzY_ZRproz5Jy6EV3G5JYviDtedkEZGsXE=.0917cf57-85b5-4c50-b59e-917bc073d9e1@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Fix tiny mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/a419daba..44c37d17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=35-36

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

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

From mgronlun at openjdk.org  Tue Jun  3 12:35:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:35:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
Message-ID: <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>

On Tue, 3 Jun 2025 12:12:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix include order
>  - Tiny refactoring

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 235:

> 233: 
> 234: void JfrCPUTimeThreadSampler::on_javathread_create(JavaThread* thread) {
> 235:   if (thread->is_Compiler_thread()) {

is_hidden_from_external_view() + is_JfrRecorderThread() instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123668189

From jbechberger at openjdk.org  Tue Jun  3 12:39:47 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:39:47 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Restrict threads for which timers are created

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/44c37d17..83b55f58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=36-37

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

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

From mgronlun at openjdk.org  Tue Jun  3 12:39:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:39:49 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
 <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
Message-ID: <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>

On Tue, 3 Jun 2025 12:29:39 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix include order
>>  - Tiny refactoring
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 235:
> 
>> 233: 
>> 234: void JfrCPUTimeThreadSampler::on_javathread_create(JavaThread* thread) {
>> 235:   if (thread->is_Compiler_thread()) {
> 
> is_hidden_from_external_view() + is_JfrRecorderThread() instead?

tl->is_excluded() is volatile and can change during runtime, so it's better to add a timer unconditionally there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123669984

From jbechberger at openjdk.org  Tue Jun  3 12:39:49 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:39:49 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
 <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
 <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>
Message-ID: <mEryQDWQA3DXeD2cgsY-jDd_7thpuckPP5e7nzmjWOI=.42fa317f-8d37-49f4-aad7-25657372fcee@github.com>

On Tue, 3 Jun 2025 12:30:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 235:
>> 
>>> 233: 
>>> 234: void JfrCPUTimeThreadSampler::on_javathread_create(JavaThread* thread) {
>>> 235:   if (thread->is_Compiler_thread()) {
>> 
>> is_hidden_from_external_view() + is_JfrRecorderThread() instead?
>
> tl->is_excluded() is volatile and can change during runtime, so it's better to add a timer unconditionally there.

why not just `is_excluded`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123673323

From mgronlun at openjdk.org  Tue Jun  3 12:44:09 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:44:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
Message-ID: <23UojxlSZeRcCB38B1d2hDIcyXbgRnmbi8Vu3cfUmM4=.ba379d71-7bc7-4721-bda0-6d5f469a45f7@github.com>

On Tue, 3 Jun 2025 12:39:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 63:

> 61:   assert(raw_thread->is_Java_thread(), "invariant");
> 62:   JavaThread* jt = JavaThread::cast(raw_thread);
> 63:   if (is_excluded(jt)) {

and now:

 if (is_excluded(jt) || jt->is_exiting()) {
   return nullptr;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123692657

From jbechberger at openjdk.org  Tue Jun  3 12:47:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 12:47:48 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v39]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <yP4vUHQv7wtT0hC3ojJQ7_r7l-itvez20Nwer9qvIWk=.6c4778f4-a825-4a2a-ad7c-86723ecda9cf@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Tiny refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/83b55f58..2b8c6db4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=37-38

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

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

From mgronlun at openjdk.org  Tue Jun  3 12:51:13 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 12:51:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
Message-ID: <WSVxq1bpLMdJWWO90qjN8icWwa2bXRqXO51yXz3L7d8=.42df9e65-a9a3-49b9-bf79-d395baf73505@github.com>

On Tue, 3 Jun 2025 12:39:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 327:

> 325:     JfrThreadLocal* tl = jt->jfr_thread_local();
> 326:     if (tl->wants_async_processing_of_cpu_time_jfr_requests()) {
> 327:       if (!jt->has_last_Java_frame() || jt->thread_state() != _thread_in_native || !tl->try_acquire_cpu_time_jfr_dequeue_lock()) {

I recommend this order for higher probability:

1. jt->thread_state() != _thread_in_native
2. !tl->try_acquire_cpu_time_jfr_dequeue_lock()
3. !jt->has_last_Java_frame()

You need to restructure of course, to get the unlocking correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123711980

From coleenp at openjdk.org  Tue Jun  3 12:55:05 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Jun 2025 12:55:05 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
Message-ID: <BToJzEd5bBn3oyB2Jek3RzuJDZfOldgBkRjufi5z-hE=.27dac2c7-57aa-4e6b-aee3-205d214c3caf@github.com>

On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Moved jtreg test
>  - Improved documentation
>  - Fix coding style (asterisk placement)

Thanks for these coding style fixes.  Some IDEs choose the other placement for the asterisk which makes it annoying.  Thanks for moving the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2935098090

From mgronlun at openjdk.org  Tue Jun  3 13:00:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 13:00:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v38]
In-Reply-To: <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <KD2vtHRzpvVxgG66EoNC6bx4reVLNynOIACwwTCiAYw=.d88d6e2a-e002-4826-8bc6-5802930ef98f@github.com>
Message-ID: <SQrM358KIiTM8NFrGofKFH5pffthpwFe0XE5opYW0Uo=.85b4e04e-1083-45ff-8310-caf337b024d5@github.com>

On Tue, 3 Jun 2025 12:39:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 479:

> 477: 
> 478: // Entry point for a thread that has been sampled in native code and has a pending JFR CPU time request.
> 479: void JfrThreadSampling::process_cpu_time_request(JavaThread* jt, JfrThreadLocal* tl, Thread* current, bool lock) {

Can you move this up to be co-located with  "drain_enqueued_cpu_time_requests"? Thanks.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.hpp line 40:

> 38:  public:
> 39:   static void process_sample_request(JavaThread* jt, bool has_cpu_time_sample_request);
> 40:   static void process_cpu_time_request(JavaThread* jt, JfrThreadLocal* tl, Thread* current, bool lock);

Put this under private and add JfrCPUTimeThreadSampler as a friend (like above with JfrSamplerThread and "process_native_sample_requests"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123728400
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123726144

From jbechberger at openjdk.org  Tue Jun  3 13:00:06 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 13:00:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v40]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <XBx9ygN3h-Q2WFXj4N3fnSvyd2fYAscvxYV2ZTaoqSg=.4b59177b-f34e-44fd-97f7-36825bca89cd@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Reorder condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/2b8c6db4..56ce2b05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=38-39

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

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

From jbechberger at openjdk.org  Tue Jun  3 13:33:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 13:33:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v41]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <dFc1zKdrVaiDvJRX3kyCltXFcamagWNpd5Sgx3sbogA=.0045581e-6b64-4595-b536-b3208a1fb2ca@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Make process_cpu_time_request private and move up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/56ce2b05..7561d512

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=39-40

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

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

From jbechberger at openjdk.org  Tue Jun  3 14:09:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 3 Jun 2025 14:09:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Rename autoadapt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/7561d512..ae55610c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=40-41

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

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

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 mgronlun at openjdk.org  Tue Jun  3 16:25:07 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 16:25:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v35]
In-Reply-To: <mEryQDWQA3DXeD2cgsY-jDd_7thpuckPP5e7nzmjWOI=.42fa317f-8d37-49f4-aad7-25657372fcee@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Zej_R8m-3NFUiqDiuV_nNShcRD8gPJtkTcZ7gksB1x8=.9292446c-3d62-4545-8835-8c5c19afe631@github.com>
 <T8rqxaVhVR6a2SD3YsNV7-Jn5EQvc190gKXqh3eDYjM=.f4a1c92f-ef85-469f-9d5f-757b2a5e109e@github.com>
 <MLvY8kY0uQYnyBDNuj2rxk6IfqW0FG5tUVPaEtcazJA=.299d2387-8ba2-4c6f-a8fc-3c633e6b6a2a@github.com>
 <mEryQDWQA3DXeD2cgsY-jDd_7thpuckPP5e7nzmjWOI=.42fa317f-8d37-49f4-aad7-25657372fcee@github.com>
Message-ID: <hLrPEyDdl4DzUt6J9zKLMBf9_1RWL-YC9PEwYk450dc=.a0ca4e15-5754-4276-955f-057fee563626@github.com>

On Tue, 3 Jun 2025 12:31:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> tl->is_excluded() is volatile and can change during runtime, so it's better to add a timer unconditionally there.
>
> why not just `is_excluded`?

because tl->is_excluded() can get included and excluded many times during runtime. Its not a static property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124366551

From weijun at openjdk.org  Tue Jun  3 16:37:53 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Jun 2025 16:37:53 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
 <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
Message-ID: <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>

On Fri, 30 May 2025 13:59:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> > Have you thought about creating a helper method for this purpose even if it's internal? At least, for the tests you can create one in `/test/lib`.
> 
> Required changes are pretty minimal ? passing `System.getProperty("stdin.encoding")` as an argument to the ctor. I doubt adding an extra layer of indirection (plus the need for changes in `@build` and `@library` tags) will worth it.

I?m just not sure if we?ll end up changing the rule again in the future. Hardcoding the system property name makes me a bit uneasy, and the default fallback being hardcoded as well adds to that concern.

That said, the changes to the security tools look good and should work as expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936243501

From lmesnik at openjdk.org  Tue Jun  3 16:46:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 3 Jun 2025 16:46:55 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <Rne99jLEkp4RdDCPJq7uGSy7r4bYsiQsWJ2851ZXq00=.9e360810-693a-4c23-9489-b54f6be232fd@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

Thank you for implementing exclusion this way.  I'll approve PR once you address feedback about commenting.

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2893319737

From lmesnik at openjdk.org  Tue Jun  3 16:57:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 3 Jun 2025 16:57:50 GMT
Subject: RFR: 8358178: Some nsk/jdi tests should be run with
 includevirtualthreads=y even though they pass without
In-Reply-To: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
References: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
Message-ID: <yP0vHqq6lOKKt5Ct9G6lgs_xLZrRTrIhmIEENzDc3Gk=.4a8f2df3-0803-411b-b7d2-8493bb87056f@github.com>

On Fri, 30 May 2025 20:56:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use -includevirtualthreads with tests use vm.allThreads() and pass with or without it. Using -includevirtualthreads gives us better virtual thread test coverage. Otherwise only the returned platform threads get tested.
> 
> Tested by running affected tests locally.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25557#pullrequestreview-2893348027

From duke at openjdk.org  Tue Jun  3 17:11:54 2025
From: duke at openjdk.org (duke)
Date: Tue, 3 Jun 2025 17:11:54 GMT
Subject: RFR: 8358077:
 sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks
 file handles after JDK-8327114
In-Reply-To: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
References: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
Message-ID: <F7jPtiagxHSOyDDiYHgJZ9Jzpb76Uj-WH7s1DiJStUs=.8df1a7cf-46a5-454d-b459-e8437f30a5fb@github.com>

On Thu, 29 May 2025 19:14:06 GMT, Larry Cable <duke at openjdk.org> wrote:

> JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114
> 
> modified the code to place the `Files::lines` in a `try-with-resources` block in order to autoclose the `Stream` and underlying file resources immediately.

@larry-cable 
Your change (at version c30a4b3120c326fca626f02a2a92a18c98037c55) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25529#issuecomment-2936356013

From duke at openjdk.org  Tue Jun  3 17:15:57 2025
From: duke at openjdk.org (Larry Cable)
Date: Tue, 3 Jun 2025 17:15:57 GMT
Subject: Integrated: 8358077:
 sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks
 file handles after JDK-8327114
In-Reply-To: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
References: <7aCzRsThkWbkX0QZtW_GYxvm8_lt5B9uDk4euRldWyc=.7f73a955-b88f-4e21-a417-3e98c705b3d9@github.com>
Message-ID: <aUATURQFzjQ665V8lfIsyfyUXuBZ1Q5g3ZwrUtQAnUU=.9fdd1747-804f-43f9-8a06-16d4a4bc597e@github.com>

On Thu, 29 May 2025 19:14:06 GMT, Larry Cable <duke at openjdk.org> wrote:

> JDK-8358077:sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114
> 
> modified the code to place the `Files::lines` in a `try-with-resources` block in order to autoclose the `Stream` and underlying file resources immediately.

This pull request has now been integrated.

Changeset: 44d62c8e
Author:    Larry Cable <larry.cable at oracle.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44d62c8e21fb09381f9f86a081f70549cc321b1e
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8358077: sun.tools.attach.VirtualMachineImpl::checkCatchesAndSendQuitTo on Linux leaks file handles after JDK-8327114

Reviewed-by: kevinw, sspitsyn, syan

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

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

From cjplummer at openjdk.org  Tue Jun  3 17:21:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Jun 2025 17:21:56 GMT
Subject: RFR: 8358178: Some nsk/jdi tests should be run with
 includevirtualthreads=y even though they pass without
In-Reply-To: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
References: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
Message-ID: <uK5EbVlu-i1ow_Bt5trlsWFKJTKB1HeyWFOjmRsZ9JY=.18427653-0e51-4bc4-a62a-6aaebab8101a@github.com>

On Fri, 30 May 2025 20:56:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use -includevirtualthreads with tests use vm.allThreads() and pass with or without it. Using -includevirtualthreads gives us better virtual thread test coverage. Otherwise only the returned platform threads get tested.
> 
> Tested by running affected tests locally.

Thank you for the reviews Serguei and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/25557#issuecomment-2936386052

From cjplummer at openjdk.org  Tue Jun  3 17:21:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Jun 2025 17:21:57 GMT
Subject: Integrated: 8358178: Some nsk/jdi tests should be run with
 includevirtualthreads=y even though they pass without
In-Reply-To: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
References: <b2nk7JiN-Q79CEyF4ghN-7SGd5TZaKt6EiwHREJFkZs=.914be47a-e2ff-41e4-950b-b4e1d30c038a@github.com>
Message-ID: <9AUgn4Y2eUBYLvmiXk9r5xgiHYfvQE-e-sSlLg-HfZ0=.48ad71ff-93e3-4f5e-8cdd-b1f12e2aa824@github.com>

On Fri, 30 May 2025 20:56:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Use -includevirtualthreads with tests use vm.allThreads() and pass with or without it. Using -includevirtualthreads gives us better virtual thread test coverage. Otherwise only the returned platform threads get tested.
> 
> Tested by running affected tests locally.

This pull request has now been integrated.

Changeset: c382da57
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c382da579884c28f2765b2c6ba68c0ad4fdcb2ce
Stats:     20 lines in 10 files changed: 10 ins; 0 del; 10 mod

8358178: Some nsk/jdi tests should be run with includevirtualthreads=y even though they pass without

Reviewed-by: sspitsyn, lmesnik

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

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

From cjplummer at openjdk.org  Tue Jun  3 18:11:23 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Jun 2025 18:11:23 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

> > Can you clarify your testing?
> 
> @plummercj, green `tier1,2` results on [45bdc4f](https://github.com/openjdk/jdk/commit/45bdc4fdaa17d0e9579154578cb9e3917e62c5c5) are attached to the ticket. Would they suffice?

That's not going to be sufficient. The nsk tests are not being run until tier5.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2936567479

From amenkov at openjdk.org  Tue Jun  3 18:49:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 3 Jun 2025 18:49:28 GMT
Subject: Integrated: 8357650: ThreadSnapshot to take snapshot of thread for
 thread dumps
In-Reply-To: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
References: <qurIpn4meeJJeXeylRtL3XDAvYhkG03NUB1oklHz7f4=.a107daea-d7af-458e-bdeb-ca2121124852@github.com>
Message-ID: <cWIoepQaBN5lrliNW5-uxTqnS2LhuuizmD_UMKxdhds=.ca42ded0-dd6a-49ac-a8e9-633822f31e97@github.com>

On Sat, 24 May 2025 00:17:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is first (hotspot) part of the update for `HotSpotDiagnosticMXBean.dumpThreads` and `jcmd Thread.dump_to_file` to include lock information in thread dumps (JDK-8356870).
> The update has been split into parts to simplify reviewing.
> The fix contains an implementation of `jdk.internal.vm.ThreadSnapshot` class to gather required information about a thread.
> Second (dependent) part includes changes in `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file`, spec updates and tests for the functionality.
> 
> Testing: new `HotSpotDiagnosticMXBean.dumpThreads`/`jcmd Thread.dump_to_file` functionality was tested in loom repo;
>   sanity tier1 (this fix only)

This pull request has now been integrated.

Changeset: 406f1bc5
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/406f1bc5b94408778063b885cdac807fd1501e44
Stats:     716 lines in 10 files changed: 712 ins; 0 del; 4 mod

8357650: ThreadSnapshot to take snapshot of thread for thread dumps

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Alex Menkov <amenkov at openjdk.org>
Reviewed-by: sspitsyn, kevinw

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

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

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 vyazici at openjdk.org  Tue Jun  3 19:08:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 19:08:17 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <bDqDySX1BG1Y7OOoTeFjpGVoUhOOB5tb8PiaYOaYqas=.6fe24483-812e-4761-8fd7-2dadfe97d69d@github.com>
 <E9b9UD8T3CZoDC8h06KoWMmmFikmVjRpmltbpnCcbpM=.7dd730d3-e0b6-4318-87d3-29ba4152bd04@github.com>
 <Vl-kbwNIBs0PMNSVHDHbicUBj6_gqwSHN-8rqUI1BvA=.35f594fc-e149-4ccb-b0c5-7f02ad047b1f@github.com>
Message-ID: <wYx8GmUa9k8P3LWrlcgLIGdsNsb-iAFq68A8mCYNFi0=.0e5b689f-6d56-4278-bafa-87ea1db6ac2c@github.com>

On Tue, 3 Jun 2025 16:35:01 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I?m just not sure if we?ll end up changing the rule again in the future. Hardcoding the system property name makes me a bit uneasy, and the default fallback being hardcoded as well adds to that concern.

Thanks so much for the review @wangweij. What would be your preference?

1. Leave things as is
2. Add an internal method to create stdin-aware `Scanner`/`InputStreamReader` (If this is your preference, any hints on which class I shall use? Shall I create a new `src/java.base/share/classes/jdk/internal/io/StdinAware.java`? Something else?)
3. Add a test utility method to create stdin-aware `Scanner`/`InputStreamReader`
4. Something else

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936772995

From alanb at openjdk.org  Tue Jun  3 19:20:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 19:20:52 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v5]
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <J63XeArye1YE7y5ixLbr5C5Bqpc3F0gzoAZSTvGVX4A=.414e3d34-e47f-4b06-9e38-7b4ab3bdc602@github.com>

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' into JDK-8356870
 - Sync up from loom repo, includes review comments
 - Merge branch 'pull/25425' into JDK-8356870
 - typo
 - feedback
 - Update src/hotspot/share/services/threadService.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Temp fixed until fixed in pull/25425
 - Sync up from loom repo, includes review comments
 - Merge branch 'pull/25425' into JDK-8356870
 - removed retry_handshake logic
 - ... and 9 more: https://git.openjdk.org/jdk/compare/406f1bc5...127814d9

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

Changes: https://git.openjdk.org/jdk/pull/25429/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25429&range=04
  Stats: 1668 lines in 9 files changed: 1247 ins; 121 del; 300 mod
  Patch: https://git.openjdk.org/jdk/pull/25429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25429/head:pull/25429

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

From sspitsyn at openjdk.org  Tue Jun  3 19:39:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 3 Jun 2025 19:39:24 GMT
Subject: RFR: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates [v5]
In-Reply-To: <J63XeArye1YE7y5ixLbr5C5Bqpc3F0gzoAZSTvGVX4A=.414e3d34-e47f-4b06-9e38-7b4ab3bdc602@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
 <J63XeArye1YE7y5ixLbr5C5Bqpc3F0gzoAZSTvGVX4A=.414e3d34-e47f-4b06-9e38-7b4ab3bdc602@github.com>
Message-ID: <_E2NoCFJTxo5q4u1t9uTrKRANWs6qGuC_iwSb36QOh4=.e4d2b452-f189-4609-8c04-33ec8f721e79@github.com>

On Tue, 3 Jun 2025 19:20:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
>> 
>> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
>> 
>> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
>> 
>> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' into JDK-8356870
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - typo
>  - feedback
>  - Update src/hotspot/share/services/threadService.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Temp fixed until fixed in pull/25425
>  - Sync up from loom repo, includes review comments
>  - Merge branch 'pull/25425' into JDK-8356870
>  - removed retry_handshake logic
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/406f1bc5...127814d9

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25429#pullrequestreview-2893843780

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 weijun at openjdk.org  Tue Jun  3 20:02:27 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 3 Jun 2025 20:02:27 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <vHzpavpczSKL0Mt6tcnqTJ86WVo8GXMBnJRyCKbUh40=.20742ec0-3fe4-4480-86f9-32807e5128d5@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

Personally I think both 2 and 3 are good. However, I'm totally OK with keeping your current code if no one else think it's worth a rewrite.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2936969327

From naoto at openjdk.org  Tue Jun  3 20:12:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 20:12:17 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

I was thinking if someone made a typo for "stdin.encoding" and then it unknowingly defaults to the fallback. Turned out it immediately fails with "java.lang.IllegalArgumentException: Null charset name" so I think it should be OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2937031130

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 mgronlun at openjdk.org  Tue Jun  3 21:00:36 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:00:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <wVrBhx6WXHPg7K03wGDCFlYf3GYhKd2uMz8r_lv_dL0=.bb3e8f70-996e-45a4-b049-f5391356dba4@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 31:

> 29: 
> 30: class JavaThread;
> 31: class NonJavaThread;

NonJavaThread fwd not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124913821

From mgronlun at openjdk.org  Tue Jun  3 21:11:32 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:11:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <aevO8AUuhhxjYpl2F7Se3lIBADa0oLHW8htoCP4_MA4=.e3cfcb3c-fc5a-4eed-a654-6fe80053396a@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 79:

> 77: 
> 78: bool JfrCPUTimeTraceQueue::enqueue(JfrCPUTimeSampleRequest& request) {
> 79:   assert(JavaThread::current()->jfr_thread_local()->is_cpu_time_jfr_enqueue_locked(), "invariant");

What is preventing another thread from enqueuing a request here? We only know it holds a thread-local lock? Let's make it explicit at this site that the current queue corresponds to the thread-local queue for the current thread.

+ assert(&JavaThread::current()->jfr_thread_local()->cpu_time_jfr_queue() == this, "invariant");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124934207

From mgronlun at openjdk.org  Tue Jun  3 21:18:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:18:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <rHqPQU-V8MLLm8oRdk04ek_TiBs4a6OWykEIUZkVQsU=.1b21a346-2a48-4c53-9720-3c2c46023c80@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 96:

> 94: }
> 95: 
> 96: volatile u4 _lost_samples_sum = 0;

static volatile

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124941941

From mgronlun at openjdk.org  Tue Jun  3 21:45:29 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 21:45:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <1RLKF0E-I7CjQRNUqb7k0mEIvoSCO010FUaKnmLVPSI=.4c6876fb-ac9c-47d2-8379-ccafdbdbaabe@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 520:

> 518:   // the sampling period might be too low for the current Linux configuration
> 519:   // so samples might be skipped and we have to compute the actual period
> 520:   int64_t period = get_sampling_period() * (info->si_overrun + 1);

Does this calculation have to be done on every signal, by every thread? It seems like something that could be precalculated when the period is set?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124980054

From mgronlun at openjdk.org  Tue Jun  3 22:01:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 22:01:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <hhQ2qjqC1JjLPwC9l7-rGLp8NuUsOvNLN6Iwjn86rPM=.3e5625fa-60b4-4404-b6ed-b1aae6055e67@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 360:

> 358:   tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 359:   if (lock) {
> 360:     tl->acquire_cpu_time_jfr_dequeue_lock();

This is your synchronization point on return from native code, which is effectively a spinlock. This can cause problems when a large number of threads are being processed by the "do_async_processing" request call.

We should fix this as a bug after integration (use a proper Monitor as a synchronization point).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124997140

From mgronlun at openjdk.org  Tue Jun  3 22:04:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 22:04:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <yl3LkvLqVPJ0Yf6dRuQW5b82F8H8efdsfRc_4_c3Uzw=.474a65a0-c982-4d81-9b19-7bd7f1f18c01@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 143:

> 141:       JavaThread *const jt = JavaThread::cast(t);
> 142:       send_java_thread_start_event(jt);
> 143:       JfrCPUTimeThreadSampling::on_javathread_create(jt);

Move before send_java_thread...to have that captured by the timer?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125004892

From apangin at openjdk.org  Wed Jun  4 03:15:36 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 03:15:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
Message-ID: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>

On Tue, 3 Jun 2025 14:09:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename autoadapt

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 51:

> 49: static bool is_excluded(JavaThread* jt) {
> 50:   return jt->is_hidden_from_external_view() ||
> 51:          jt->jfr_thread_local()->is_excluded() ||

These restrictions cause a large blind spot in observability. There is no technical limitation for recording cpu samples for internal threads too, even without a Java stack trace. Consider removing this restriction, although not in this PR.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 135:

> 133:   while ((new_lost_samples = Atomic::cmpxchg(&_lost_samples, lost_samples, 0)) != lost_samples) {
> 134:     lost_samples = new_lost_samples;
> 135:   }

Why not `Atomic::xchg`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 161:

> 159:     return 0;
> 160:   }
> 161:   return os::active_processor_count() * 1000000000.0 / rate;

If sampling period is configured as an absolute number in milliseconds, this value must be passed as is.
Double conversion via `Runtime.availableProcessors()` / `active_processor_count()` is unobvious and error-prone. First, because of asymmetry: e.g. `Runtime.availableProcessors()` may be redefined by an agent so that its value is not aligned with `active_processor_count()`. Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 198:

> 196:   virtual void post_run();
> 197: public:
> 198:   virtual const char* name() const { return "JFR CPU Time Thread Sampler"; }

Thread name is too long and does not sound right. Logically, it is not "Thread Sampler", but rather "Sampler Thread", which also aligns with the existing "JFR Sampler Thread". But I'd simplify it to `JFR CPU Time Sampler` or maybe `JFR CPU Sampler Thread`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 202:

> 200:   void run();
> 201:   void on_javathread_create(JavaThread* thread);
> 202:   bool create_timer_for_thread(JavaThread* thread, timer_t &timerid);

Should it be `private`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 252:

> 250:   timer_delete(*timer);
> 251:   tl->unset_cpu_timer();
> 252:   tl->deallocate_cpu_time_jfr_queue();

Either this line is not needed or there is a possible resource leak: if `create_timer_for_thread` fails, queue is allocated but not deallocated.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:

> 279:     stop_timer();
> 280:     Atomic::store(&_stop_signals, true);
> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {

There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 308:

> 306: 
> 307:     if (Atomic::load_acquire(&_is_async_processing_of_cpu_time_jfr_requests_triggered)) {
> 308:       Atomic::release_store(&_is_async_processing_of_cpu_time_jfr_requests_triggered, false);

acquire/release seem to be used for no good reason. Also, this could be a single `cmpxchg`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 326:

> 324:       if (jt->thread_state() != _thread_in_native || !tl->try_acquire_cpu_time_jfr_dequeue_lock()) {
> 325:         tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
> 326:         continue; // thread doesn't have a last Java frame or queue is already being processed

This comment may sound confusing, since `has_last_Java_frame` is checked separately below.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:

> 470: 
> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
> 472:   assert(_instance != nullptr, "invariant");

There can be an arbitrary delay in async signal delivery.
It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 477:

> 475: 
> 476: 
> 477: void JfrCPUTimeThreadSampling::handle_timer_signal(siginfo_t* info, void* context) {

It may be a good idea to validate `info->si_code` in order to protect from things like `kill -SIGPROF` after profiling has stopped. For a similar reason, `_sampler->_stop_signals` should default to `true` whenever profiler is not running.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 509:

> 507:   JfrCPUTimeTraceQueue& queue = tl->cpu_time_jfr_queue();
> 508:   if (!check_state(jt)) {
> 509:       queue.increment_lost_samples();

nit: wrong indent

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 576:

> 574:   }
> 575:   if (timer_create(clock, &sev, &t) < 0) {
> 576:     log_error(jfr)("Failed to register the signal handler for thread sampling: %s", os::strerror(os::get_last_error()));

If an application has many threads and current RLIMIT_SIGPENDING is low, logs will be flooded with this error message.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 606:

> 604: void JfrCPUTimeThreadSampler::init_timers() {
> 605:   // install sig handler for sig
> 606:   PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal);

SIGPROF is also used by external profilers. Need to check if SIGPROF handler is already installed and warn user.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 58:

> 56:   volatile u4 _head;
> 57: 
> 58:   volatile s4 _lost_samples;

Why signed int? Can it be negative?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 128:

> 126:   static void send_lost_event(const JfrTicks& time, traceid tid, s4 lost_samples);
> 127: 
> 128:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread

typo: separate

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 558:

> 556: void JfrThreadLocal::set_cpu_timer(timer_t* timer) {
> 557:   if (_cpu_timer == nullptr) {
> 558:     _cpu_timer = JfrCHeapObj::new_array<timer_t>(1);

`timer_t` is a primitive type, at most one machine word. Why extra indirection and allocation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124528320
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124503100
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125157311
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125128723
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125130332
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125190998
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125203700
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125342289
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125249171
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125230422
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125241099
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125320255
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125411074
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125430231
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2124507884
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125333563
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125183931

From alanb at openjdk.org  Wed Jun  4 04:13:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 04:13:31 GMT
Subject: Integrated: 8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd
 Thread.dump_to_file updates
In-Reply-To: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
References: <3avXpsIbMYIQBAr6mO9K3MhewKnNRt6JthztMleZEGI=.f806b009-3c4f-43c2-8728-7cec95048ae0@github.com>
Message-ID: <zkPROM26A1z7e5gQsw_X44PFi-lPNxqdTbD1NBitA88=.7bf34e03-c7fa-4240-98f3-95711f7139fe@github.com>

On Sat, 24 May 2025 06:57:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updates the thread dump generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file to include thread state and lock information. Also update the HotSpotDiagnosticMXBean.dumpThreads API description to link to a description of the JSON format dump as that format is intended to be parseable/read by tools.
> 
> This PR is dependent on [pull/25425](https://github.com/openjdk/jdk/pull/25425). As noted in that PR, the changes accumulated in the loom repo, and have been split up to make it easier to review.
> 
> The changes include some re-implementation of ThreadDumper. This is because it used PrintStream and didn't fail if there was an I/O error, e.g. file system full. Furthermore, the indentation to pretty print the json was fragile and hard to maintain so this is changed to use a supporting writer class to do this.
> 
> Test coverage is significantly expanded, including updating the test library that is used by several tests to parse the thread dump.
> 
> Testing: tier1-6

This pull request has now been integrated.

Changeset: f17b2bc0
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f17b2bc06ad358933481c0e2cffd57c842bc0e76
Stats:     1668 lines in 9 files changed: 1247 ins; 121 del; 300 mod

8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates

Reviewed-by: sspitsyn, kevinw

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

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

From dholmes at openjdk.org  Wed Jun  4 04:53:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 04:53:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
 <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
 <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>
Message-ID: <CrLB3PxTonY2tagR-vsH1x3v45HK8ikUTEc0MC11mg8=.fe97c0cf-11b1-42ee-bcdc-113f0464d0ee@github.com>

On Tue, 3 Jun 2025 12:16:32 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>>> Hold on, shouldn't this really be "Lost"? @egahlin and @mgronlun need to chime in here.
>> 
>> Lost might be better.
>> 
>> I wonder if `<Field type="Thread" name="eventThread" label="Thread" />` is needed,  instead of thread = true?
>
>> I wonder if <Field type="Thread" name="eventThread" label="Thread" /> is needed, instead of thread = true?
> 
> We had these discussions before on the old PR and then decided to end up with eventThread (as the other events do to),

@parttimenerd  I would really like to see some kind of design description for this which explains what the threading model is, how the signals are used, and how all the pieces interact. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2938512151

From jbechberger at openjdk.org  Wed Jun  4 05:32:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 05:32:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
Message-ID: <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>

On Wed, 4 Jun 2025 00:13:07 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 161:
> 
>> 159:     return 0;
>> 160:   }
>> 161:   return os::active_processor_count() * 1000000000.0 / rate;
> 
> If sampling period is configured as an absolute number in milliseconds, this value must be passed as is.
> Double conversion via `Runtime.availableProcessors()` / `active_processor_count()` is unobvious and error-prone. First, because of asymmetry: e.g. `Runtime.availableProcessors()` may be redefined by an agent so that its value is not aligned with `active_processor_count()`. Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.

Is this something for a later PR?

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:
> 
>> 279:     stop_timer();
>> 280:     Atomic::store(&_stop_signals, true);
>> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {
> 
> There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.

Amy idea on how to fix it?

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:
> 
>> 470: 
>> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
>> 472:   assert(_instance != nullptr, "invariant");
> 
> There can be an arbitrary delay in async signal delivery.
> It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.

Any ideas? Or is it something for a later PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125678084
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125680345
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125681876

From jbechberger at openjdk.org  Wed Jun  4 06:02:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:02:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v10]
In-Reply-To: <CrLB3PxTonY2tagR-vsH1x3v45HK8ikUTEc0MC11mg8=.fe97c0cf-11b1-42ee-bcdc-113f0464d0ee@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <SFVriT7h6djH5w2FS2ygu4r3XBTNP-8IBCme5TuNl2s=.67cd9d1e-8197-4412-b323-2a6fd28551b4@github.com>
 <EVL4AnTSVDlnWrcpRfCMnhczs3zx-8W2ekJ1_tB-LXw=.70ec29f5-4ec0-4ee1-a49e-5409db8b0698@github.com>
 <hJEbeKoOp6p385NLSO_SlrmQRlWcnif-k9s8jIBsO4E=.21ca9fbf-2322-4b00-8875-013b4862a5fc@github.com>
 <PQDkEQM6zL6lDq94HQ_1KFfLdJA9XPPKPCehDReB5Jo=.514f228d-8f82-463c-92e6-733448db29d0@github.com>
 <jxyCdtPv6UFkf3koPLUkVcqrjKgA5-FrggWm5N4rNr0=.5ba75efb-4409-4d4d-a137-27180494b5ab@github.com>
 <8ESOaNI_qHLzLquiZT7RZR43lit-o8_5rTky1nJFjH4=.a81b8882-1470-4f76-8c9a-cdc2a7b50070@github.com>
 <1JqKzjCGoZ9N_ez_gMKOlR1lbWPte0LkQS3bSb81ua0=.3c4c006b-18c0-4444-a867-8c774899b5b9@github.com>
 <CrLB3PxTonY2tagR-vsH1x3v45HK8ikUTEc0MC11mg8=.fe97c0cf-11b1-42ee-bcdc-113f0464d0ee@github.com>
Message-ID: <81dLp_39MhU-TuDD3EDt7iTX8HyEDZfj6nvCPwE5Ol4=.7d564cda-b7ae-4623-9705-704770b2b118@github.com>

On Wed, 4 Jun 2025 04:50:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I wonder if <Field type="Thread" name="eventThread" label="Thread" /> is needed, instead of thread = true?
>> 
>> We had these discussions before on the old PR and then decided to end up with eventThread (as the other events do to),
>
> @parttimenerd  I would really like to see some kind of design description for this which explains what the threading model is, how the signals are used, and how all the pieces interact. Thanks

@dholmes-ora I attempt a first version here:

The design consists of four main parts:
- setup code: This sets up the signal handlers for every new thread and deletes them afterwards
- the per-thread signal handlers: They check first that the current thread is valid, increment that they are currently active and check that they shouldn't stop (because the profiler is disabled). Now they acquire the thread-local enqueue lock for the current thread's request queue and push the sampling requests in (see https://openjdk.org/jeps/518 + the current period). It triggers/arms a safepoint. If the current thread is in native, they trigger (set a flag) the asynchronous stackwalking. This prevents long native periods of overflowing the request queue. Finally, the enqueue lock is released.
- the safepoint handler: In the safepoint handler, we check if the thread-local queue is not empty. If so, we acquire a dequeue lock and process all entries of the queue, thereby creating JFR events. We also untrigger the async-stack-walking request for the thread. We then release the lock.
- the sampler thread: Its task is to regularly update the timers if needed (configuration changes) and to walk the thread list to find any task that wants to be asynchronously stack-walked. For every of these threads, the dequeue lock is acquired (skipping if already set to enqueue) and the queue is processed as at the safepoint. Then the lock is released.

On shutdown: Whenever the sampler is shut down, we first set the `_stop_signals` flag to prevent new signal handlers from entering the request creation code (and thereby accessing data structures that we already deallocated), we disable the timers for all threads and then wait till no signal handler is engaged anymore.

It is important to note that there is only one thread-local lock used, but it has three states:
- enqueue
- dequeue
- unlocked

This prevents these phases from overlapping.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2938677600

From jbechberger at openjdk.org  Wed Jun  4 06:10:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:10:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <1RLKF0E-I7CjQRNUqb7k0mEIvoSCO010FUaKnmLVPSI=.4c6876fb-ac9c-47d2-8379-ccafdbdbaabe@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <1RLKF0E-I7CjQRNUqb7k0mEIvoSCO010FUaKnmLVPSI=.4c6876fb-ac9c-47d2-8379-ccafdbdbaabe@github.com>
Message-ID: <mC6pwnHod4ewPHh6ULKKK97AN5LsB6sfqlMFJj7oF6I=.25abb82a-653c-49b0-bccb-fd69c39a3a5d@github.com>

On Tue, 3 Jun 2025 21:42:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 520:
> 
>> 518:   // the sampling period might be too low for the current Linux configuration
>> 519:   // so samples might be skipped and we have to compute the actual period
>> 520:   int64_t period = get_sampling_period() * (info->si_overrun + 1);
> 
> Does this calculation have to be done on every signal, by every thread? It seems like something that could be precalculated when the period is set?

This might change dynamically, so probably no. Only caching would work, but this is a small optimization for later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125725230

From mbaesken at openjdk.org  Wed Jun  4 06:23:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Jun 2025 06:23:17 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <Pl5-QJpM6UcSi-Ljyfvgwcy3sLCRFPLKuiCxOVnLG58=.aa54e5c5-3272-40b0-8853-4bb8c366ed03@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java
---------------------------------------------------------------
 stderr: [==46460==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==46460==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v

ulimit clashes with the memory requirements of ASAN


runtime/Thread/TestBreakSignalThreadDump.java
---------------------------------------------------------------
stderr: [==18432==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

loading of the jsig lib does currently not work well with ASAN lib



runtime/XCheckJniJsig/XCheckJSig.java
---------------------------------------------------------------
 stderr: [==71228==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

loading of the jsig lib does currently not work well with ASAN lib 

 

runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java
---------------------------------------------------------------
reports ==35621==ERROR: AddressSanitizer: heap-buffer-overflow on address ...

this will be fixed hopefully so we could maybe remove the !asan tagging


serviceability/dcmd/vm/SystemDumpMapTest.java
---------------------------------------------------------------
Missing patterns in dump:
0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[heap\]
test SystemDumpMapTest.jmx(): failure [410ms]

ASAN changes the memory map dump slightly, but the test has rather strict requirements



serviceability/dcmd/vm/SystemMapTest.java
---------------------------------------------------------------
test SystemMapTest.jmx(): failure [381ms]
java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[rwsxp-]+ +\\d+ +\\d+ +(4K|8K|16K|64K|2M|16M|64M) +com.*\[heap\]' missing from stdout/stderr


ASAN changes the memory map dump slightly, but the test has rather strict requirements


serviceability/sa/ClhsdbCDSCore.java
---------------------------------------------------------------
Output and diagnostic info for process 45808 was saved into 'pid-45808-output.log'
crashOutputString = [[0.028s][error][cds] An error has occurred while processing the shared archive file. Run with -Xlog:aot,cds for details.
[0.029s][error][cds] Mismatched values for property jdk.module.addexports: java.base/jdk.internal.misc=ALL-UNNAMED specified during runtime but not during dump time
[0.029s][error][cds] Disabling optimized module handling
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000014d4d60ef8d2, pid=45808, tid=46654
#
# JRE version: OpenJDK Runtime Environment (25.0.0.1) (build 25.0.0.1-internal-adhoc.myuser.jdk)
# Java VM: OpenJDK 64-Bit Server VM (25.0.0.1-internal-adhoc.myuser.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x3d6b8d2]  Unsafe_PutInt+0x592
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false
	at ClhsdbCDSCore.main(ClhsdbCDSCore.java:171)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false


Seems no core was written, maybe ASAN is to blame or my test environment ?



serviceability/sa/ClhsdbFindPC.java
---------------------------------------------------------------
java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false
	at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:317)
	at ClhsdbFindPC.main(ClhsdbFindPC.java:339)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: java.lang.RuntimeException: Output doesn't contain the location of core file.: expected true, was false


Looks similar to ClhsdbCDSCore issue

Turns out  cds/appcds/aotCode/AOTCodeCompressedOopsTest.java  was a real bug, so I guess we should remove it from this exclusion.  Are you fine with the short explanations given,  if yes I would add them as comment to the tests .

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2938728030
PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2938732660

From mbaesken at openjdk.org  Wed Jun  4 06:28:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Jun 2025 06:28:17 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <6HSruHtZNPOZJp4vNFnwMns6-_rP_MEHtnnvAP7S5QU=.e91023a2-089c-4541-86a5-ae8d4adeb99d@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <6HSruHtZNPOZJp4vNFnwMns6-_rP_MEHtnnvAP7S5QU=.e91023a2-089c-4541-86a5-ae8d4adeb99d@github.com>
Message-ID: <Aa4AY9YDnDYtxcRcd0_aw6LK7H6Guh2QPWF57Xf5osE=.f0129d01-86c2-4ef0-9c9a-c25ced6e4029@github.com>

On Tue, 3 Jun 2025 12:31:51 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In ASAN built JDK, some gtests and some other JTREG tests in runtime/ErrorHandling also fail. Do we exclude these in another PR? or should they also be handled/excluded here? The 'some' word in the PR's title is not strict, IMO.

Yes it is not strict ;  I did mostly tests with ASAN on Linux x86_64 and Linux ppc64le so far  .
On x86_64 I saw a few more tests have issues with ASAN, but the intention of this PR was to just include the ones where it was clear to me what happens and where a 'fix'  is not likely  (and mostly also the ones I saw failing across the 2 OS/CPU platforms I mentioned).
Maybe that's why we should better remove the exclusion of AOTCodeCompressedOopsTest  , because this is not some kind of incompatibility of ASAN with special test requirements, but a real memory issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2938748695

From jbechberger at openjdk.org  Wed Jun  4 06:34:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:34:29 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
Message-ID: <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>

On Wed, 4 Jun 2025 05:28:21 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:
>> 
>>> 279:     stop_timer();
>>> 280:     Atomic::store(&_stop_signals, true);
>>> 281:     while (Atomic::load_acquire(&_active_signal_handlers) > 0) {
>> 
>> There can be a race when `handle_timer_signal` has already passed `_stop_signals` check but has not yet incremented `_active_signal_handlers`.
>
> Amy idea on how to fix it?

I added another _static_stop_signals field which should prevent this.

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:
>> 
>>> 470: 
>>> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
>>> 472:   assert(_instance != nullptr, "invariant");
>> 
>> There can be an arbitrary delay in async signal delivery.
>> It's unlikely, but not impossible for `_instance` to be deleted by the time signal handler is called. There should be a better way to synchronize with JFR shutdown.
>
> Any ideas? Or is it something for a later PR?

I added another `_static_stop_signals` field which should prevent this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125756115
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125755428

From jbechberger at openjdk.org  Wed Jun  4 06:34:30 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 06:34:30 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
Message-ID: <PSQGMGCpH-7_AXOlrjZ1x-loj1PEfQXF1SqA4G4w8B8=.39e6dace-3fe2-43e5-bb70-80f10ba7f7f5@github.com>

On Wed, 4 Jun 2025 00:28:46 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 558:
> 
>> 556: void JfrThreadLocal::set_cpu_timer(timer_t* timer) {
>> 557:   if (_cpu_timer == nullptr) {
>> 558:     _cpu_timer = JfrCHeapObj::new_array<timer_t>(1);
> 
> `timer_t` is a primitive type, at most one machine word. Why extra indirection and allocation?

@mgronlun wanted this indirection to move it abstract from implementation details

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125758074

From jbechberger at openjdk.org  Wed Jun  4 07:00:51 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 07:00:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v43]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ae55610c..55c30aef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=41-42

  Stats: 87 lines in 6 files changed: 26 ins; 10 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From mgronlun at openjdk.org  Wed Jun  4 08:17:31 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 08:17:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>
Message-ID: <AUdBBwPJHu_G8QgU_RFIH_zuRMBJopJLPYQZCUkHp3U=.a12504ca-8417-4016-b2ce-c9950e27f2a1@github.com>

On Wed, 4 Jun 2025 06:29:59 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Any ideas? Or is it something for a later PR?
>
> I added another `_static_stop_signals` field which should prevent this.

The _instance is only ever deleted in case a JFR startup attempt fails as part of JfrRecorder::create(). The sampler must have a rate and become enrolled to serve clients (by installing timers). The rate is set post JfrRecorder::create() using the setting system, which implies that _instance != nullptr should be invariant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125976370

From jbechberger at openjdk.org  Wed Jun  4 08:21:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 08:21:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <AUdBBwPJHu_G8QgU_RFIH_zuRMBJopJLPYQZCUkHp3U=.a12504ca-8417-4016-b2ce-c9950e27f2a1@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <P6NX6iE8HLt8WRTRXtuNLumuSMzNR1YIHs7qWtuTmuQ=.0df20fd4-e2eb-4994-9649-24428d71e766@github.com>
 <AUdBBwPJHu_G8QgU_RFIH_zuRMBJopJLPYQZCUkHp3U=.a12504ca-8417-4016-b2ce-c9950e27f2a1@github.com>
Message-ID: <CkrqpqeNd5SCH7AoPHP57IV8Qaa-NFvXmgTHR4CXfIs=.4072dafb-eb41-43c1-b649-5fef4f46b3c2@github.com>

On Wed, 4 Jun 2025 08:14:11 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I added another `_static_stop_signals` field which should prevent this.
>
> The _instance is only ever deleted in case a JFR startup attempt fails as part of JfrRecorder::create(). The sampler must have a rate and become enrolled to serve clients (by installing timers). The rate is set post JfrRecorder::create() using the setting system, which implies that _instance != nullptr should be invariant.

Yes, you're right. I'll update the code and combine `_active_signal_handlers` and `_stop_signals` in one, so that a CAS loop prevents `_active_signal_handlers` from being incremented when `_stop_signals` is true. This should solve the other data race.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125985412

From mgronlun at openjdk.org  Wed Jun  4 08:43:37 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 08:43:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
Message-ID: <jkO0SbSmolLqmXPMAojUSak8QgB5xQYqttBaGZAgs0w=.9ba426c9-f5c6-44ea-9db3-0397f1daa0aa@github.com>

On Wed, 4 Jun 2025 03:07:52 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 606:
> 
>> 604: void JfrCPUTimeThreadSampler::init_timers() {
>> 605:   // install sig handler for sig
>> 606:   PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal);
> 
> SIGPROF is also used by external profilers. Need to check if SIGPROF handler is already installed and warn user.

This is *very* important to have a robust failure mechanism when existing handlers are already installed. Why? JFR can be turned on dynamically from the outside, at any time, during runtime. A lot of agents could have installed their handlers by then.

Please describe how you intend to handle the case where someone starts JFR late during runtime and the signal handler cannot be installed.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 128:
> 
>> 126:   static void send_lost_event(const JfrTicks& time, traceid tid, s4 lost_samples);
>> 127: 
>> 128:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
> 
> typo: separate

And again, its not "sampling" that is triggered. It is async processing of the queue holding existing samples.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126029865
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126025355

From ayang at openjdk.org  Wed Jun  4 09:11:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 4 Jun 2025 09:11:04 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v10]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <wQPxmGNk9EpxXZh8P8rKHSd56WNYcjCDLjC4WSUqImc=.c341f3cc-ff9b-426c-a9dd-257f969cc81d@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 4 more: https://git.openjdk.org/jdk/compare/ab235000...72645267

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=09
  Stats: 4373 lines in 31 files changed: 522 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From kevinw at openjdk.org  Wed Jun  4 09:31:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Jun 2025 09:31:19 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v10]
In-Reply-To: <wQPxmGNk9EpxXZh8P8rKHSd56WNYcjCDLjC4WSUqImc=.c341f3cc-ff9b-426c-a9dd-257f969cc81d@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <wQPxmGNk9EpxXZh8P8rKHSd56WNYcjCDLjC4WSUqImc=.c341f3cc-ff9b-426c-a9dd-257f969cc81d@github.com>
Message-ID: <xDv3NkgKarq8jdrvU9k0HEmq6AMctX555bzW3B5HHoo=.b6f7bd9f-ec98-40d7-afc6-0aea7b389037@github.com>

On Wed, 4 Jun 2025 09:11:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/ab235000...72645267

Thanks for the aliasmap update, looks good.

I think alias sun.gc.policy.boundaryMoved is removed here as it's already redundant, the rest all match with the counter being removed in the change.

There is a case for removing those old e.g. 1.4.1 aliases separately, in a future change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-2939297086

From jbechberger at openjdk.org  Wed Jun  4 11:13:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:13:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v44]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <35LXUV5UP0dcnU2ImfP7ny2SyPmJBTYhRT6JbADqWA4=.22d4360e-639c-4e65-86a3-62aad45a2606@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Add error message on signal handler install failure
 - Fix signal handler synchronization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/55c30aef..4a258e96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=42-43

  Stats: 71 lines in 2 files changed: 44 ins; 19 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From jbechberger at openjdk.org  Wed Jun  4 11:13:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:13:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <jkO0SbSmolLqmXPMAojUSak8QgB5xQYqttBaGZAgs0w=.9ba426c9-f5c6-44ea-9db3-0397f1daa0aa@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <jkO0SbSmolLqmXPMAojUSak8QgB5xQYqttBaGZAgs0w=.9ba426c9-f5c6-44ea-9db3-0397f1daa0aa@github.com>
Message-ID: <YynPzC8e9wMwYPtS-3OJ6z7Mp9UYJXfbsqB6qyYG3qc=.c8c6c5e0-6b9b-440d-b74e-78c24a2a3cb8@github.com>

On Wed, 4 Jun 2025 08:40:34 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 606:
>> 
>>> 604: void JfrCPUTimeThreadSampler::init_timers() {
>>> 605:   // install sig handler for sig
>>> 606:   PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal);
>> 
>> SIGPROF is also used by external profilers. Need to check if SIGPROF handler is already installed and warn user.
>
> This is *very* important to have a robust failure mechanism when existing handlers are already installed. Why? JFR can be turned on dynamically from the outside, at any time, during runtime. A lot of agents could have installed their handlers by then.
> 
> Please describe how you intend to handle the case where someone starts JFR late during runtime and the signal handler cannot be installed.

I added a log_error to tell the user

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp line 128:
>> 
>>> 126:   static void send_lost_event(const JfrTicks& time, traceid tid, s4 lost_samples);
>>> 127: 
>>> 128:   // Trigger sampling while a thread is not in a safepoint, from a seperate thread
>> 
>> typo: separate
>
> And again, its not "sampling" that is triggered. It is async processing of the queue holding existing samples.

I removed the comment, as the method name itself is pretty self-explanatory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126330036
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126332382

From jbechberger at openjdk.org  Wed Jun  4 11:18:52 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:18:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:

 - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
 - Add error message on signal handler install failure
 - Fix signal handler synchronization
 - Improve
 - Rename autoadapt
 - Make process_cpu_time_request private and move up
 - Reorder condition
 - Tiny refactoring
 - Restrict threads for which timers are created
 - Fix tiny mistake
 - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

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

Changes: https://git.openjdk.org/jdk/pull/25302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=44
  Stats: 2308 lines in 39 files changed: 2164 ins; 128 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From jbechberger at openjdk.org  Wed Jun  4 11:28:51 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:28:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve error message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/4fd4b673..8fe07614

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=44-45

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

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

From apangin at openjdk.org  Wed Jun  4 11:28:51 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 11:28:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
Message-ID: <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>

On Wed, 4 Jun 2025 05:26:42 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 161:
>> 
>>> 159:     return 0;
>>> 160:   }
>>> 161:   return os::active_processor_count() * 1000000000.0 / rate;
>> 
>> If sampling period is configured as an absolute number in milliseconds, this value must be passed as is.
>> Double conversion via `Runtime.availableProcessors()` / `active_processor_count()` is unobvious and error-prone. First, because of asymmetry: e.g. `Runtime.availableProcessors()` may be redefined by an agent so that its value is not aligned with `active_processor_count()`. Second, because number of available processors may change at runtime, e.g., by adjusting cgroup quotas.
>
> Is this something for a later PR?

I'm OK with fixing this separately.

>> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 558:
>> 
>>> 556: void JfrThreadLocal::set_cpu_timer(timer_t* timer) {
>>> 557:   if (_cpu_timer == nullptr) {
>>> 558:     _cpu_timer = JfrCHeapObj::new_array<timer_t>(1);
>> 
>> `timer_t` is a primitive type, at most one machine word. Why extra indirection and allocation?
>
> @mgronlun wanted this indirection to move it abstract from implementation details

I don't see how it is an abstraction when the pointer still has concrete `timer_t` type.
All POSIX timer functions accept `timer_t` rather than `timer_t*`.
This is not a big issue, though, just a minor inefficiency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126360330
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126304082

From apangin at openjdk.org  Wed Jun  4 11:28:52 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 11:28:52 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v43]
In-Reply-To: <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>
Message-ID: <uYwvyjIRqoj8BqdtAmAA5MbkuKNKG6Z-ywnsoKN3YF8=.d36d8579-e1d7-45c3-8991-d3bbb5c7a303@github.com>

On Wed, 4 Jun 2025 07:00:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 238:

> 236:   tl->cpu_time_jfr_queue().resize_for_period(_current_sampling_period_ns / 1000000);
> 237:   timer_t timerid;
> 238:   if (create_timer_for_thread(thread, timerid)) {

Timer creation failure is not an impossible situation, we should somehow let user know that not all threads are being profiled but without flooding in logs. One warning per profiling session may be a good compromise.
You can verify failure condition by setting low `ulimit -i`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 492:

> 490:   assert(_sampler != nullptr, "invariant");
> 491:   if (info->si_signo != SIGPROF) {
> 492:     // not the signal we are interested in

No, I meant checking `si_code`. `si_signo` will always be the right one.
And this check should come first, before any assertions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126338737
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126316533

From apangin at openjdk.org  Wed Jun  4 11:28:54 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 11:28:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
Message-ID: <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>

On Wed, 4 Jun 2025 11:18:52 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
> 
>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>  - Add error message on signal handler install failure
>  - Fix signal handler synchronization
>  - Improve
>  - Rename autoadapt
>  - Make process_cpu_time_request private and move up
>  - Reorder condition
>  - Tiny refactoring
>  - Restrict threads for which timers are created
>  - Fix tiny mistake
>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 611:

> 609:   // increment the count of active signal handlers
> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {

Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126354062

From mgronlun at openjdk.org  Wed Jun  4 11:28:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 11:28:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
Message-ID: <r6xxXYeirwBZWWCyzM9fRE6OI-2b1wRK406TY4J5AYM=.4f71451f-8790-4025-87f1-2e879015734f@github.com>

On Wed, 4 Jun 2025 11:18:52 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
> 
>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>  - Add error message on signal handler install failure
>  - Fix signal handler synchronization
>  - Improve
>  - Rename autoadapt
>  - Make process_cpu_time_request private and move up
>  - Reorder condition
>  - Tiny refactoring
>  - Restrict threads for which timers are created
>  - Fix tiny mistake
>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 647:

> 645:   // install sig handler for sig
> 646:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
> 647:     log_error(jfr)("Failed to install signal handler for CPU thread sampling, possibly because another profiler is active: %s", os::strerror(os::get_last_error()));

That we are using a signal handler to provide the user with CPU time information is an implementation detail. Its good to provide an error message, but I think it should reflect back on something the user is expecting.

Perhaps add a line that says something along the lines of "CPUTimeSample events will not be recorded."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126357345

From jbechberger at openjdk.org  Wed Jun  4 11:28:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:28:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <r6xxXYeirwBZWWCyzM9fRE6OI-2b1wRK406TY4J5AYM=.4f71451f-8790-4025-87f1-2e879015734f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
 <r6xxXYeirwBZWWCyzM9fRE6OI-2b1wRK406TY4J5AYM=.4f71451f-8790-4025-87f1-2e879015734f@github.com>
Message-ID: <1vlVzhpxsamhKyaKX4ixcG-JZj4Qxgc0Au3mEnjs_So=.91d8a5a1-7b1b-46c6-991c-a5c61c77e39e@github.com>

On Wed, 4 Jun 2025 11:23:57 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
>> 
>>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>>  - Add error message on signal handler install failure
>>  - Fix signal handler synchronization
>>  - Improve
>>  - Rename autoadapt
>>  - Make process_cpu_time_request private and move up
>>  - Reorder condition
>>  - Tiny refactoring
>>  - Restrict threads for which timers are created
>>  - Fix tiny mistake
>>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 647:
> 
>> 645:   // install sig handler for sig
>> 646:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
>> 647:     log_error(jfr)("Failed to install signal handler for CPU thread sampling, possibly because another profiler is active: %s", os::strerror(os::get_last_error()));
> 
> That we are using a signal handler to provide the user with CPU time information is an implementation detail. Its good to provide an error message, but I think it should reflect back on something the user is expecting.
> 
> Perhaps add a line that says something along the lines of "CPUTimeSample events will not be recorded."

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126360801

From jbechberger at openjdk.org  Wed Jun  4 11:37:34 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:37:34 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v43]
In-Reply-To: <uYwvyjIRqoj8BqdtAmAA5MbkuKNKG6Z-ywnsoKN3YF8=.d36d8579-e1d7-45c3-8991-d3bbb5c7a303@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <-BGoOClpsfsd4Q8Wq-H57L3tIvoaLGauYtRBEDPO-_w=.97e25e4f-879d-45f6-bd00-ad53e2463a8d@github.com>
 <uYwvyjIRqoj8BqdtAmAA5MbkuKNKG6Z-ywnsoKN3YF8=.d36d8579-e1d7-45c3-8991-d3bbb5c7a303@github.com>
Message-ID: <3tt6-HjldmHpRIKHFqWHaLcC7FRZLwiCZl__j7Ht7Gw=.a14d3aa8-4780-49e2-b9ec-d24a828a1948@github.com>

On Wed, 4 Jun 2025 11:13:30 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 238:
> 
>> 236:   tl->cpu_time_jfr_queue().resize_for_period(_current_sampling_period_ns / 1000000);
>> 237:   timer_t timerid;
>> 238:   if (create_timer_for_thread(thread, timerid)) {
> 
> Timer creation failure is not an impossible situation, we should somehow let user know that not all threads are being profiled but without flooding in logs. One warning per profiling session may be a good compromise.
> You can verify failure condition by setting low `ulimit -i`.

I added a "Failed to create timer for a thread" warning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126373721

From jbechberger at openjdk.org  Wed Jun  4 11:37:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:37:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
 <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>
Message-ID: <URHFhmpIcFdnX3d29D57R_JJ76hBo7gAm9zXGOfLxZs=.4aed11f9-2afa-417c-b67c-60fb2806a0bb@github.com>

On Wed, 4 Jun 2025 11:21:57 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
>> 
>>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>>  - Add error message on signal handler install failure
>>  - Fix signal handler synchronization
>>  - Improve
>>  - Rename autoadapt
>>  - Make process_cpu_time_request private and move up
>>  - Reorder condition
>>  - Tiny refactoring
>>  - Restrict threads for which timers are created
>>  - Fix tiny mistake
>>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 611:
> 
>> 609:   // increment the count of active signal handlers
>> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
>> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {
> 
> Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.

I don't see how `Atomic::cmpxchg` would make the code easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126375482

From dtabata at openjdk.org  Wed Jun  4 11:43:31 2025
From: dtabata at openjdk.org (Daishi Tabata)
Date: Wed, 4 Jun 2025 11:43:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
Message-ID: <SBMAGcag8zgg4wJ5-mKhtJJT9GKydtBebIg8D_CJmqI=.f5178cd8-1ba9-4c01-b220-12f90840eb22@github.com>

On Wed, 4 Jun 2025 11:28:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve error message

https://github.com/openjdk/jdk/pull/25302/commits/a419dabab213e78a2ff7f3c62cd4af72a0fdabed
Since the implementation has changed from Loss to Lost, the JEP document needs to be changed back to the original, Lost.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2939698219

From jbechberger at openjdk.org  Wed Jun  4 11:43:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:43:32 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v45]
In-Reply-To: <URHFhmpIcFdnX3d29D57R_JJ76hBo7gAm9zXGOfLxZs=.4aed11f9-2afa-417c-b67c-60fb2806a0bb@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <yXsW5cO7aLoG9bUFQsqXmJgOU87jLuczeasNnn9oHm4=.c8a6e84d-2620-4141-ba4e-815d406d3330@github.com>
 <hEnBBImZUWCn3x2YKNmfV_MvV1zxyHeGKGtGR2vOS3I=.69e9be31-69f4-4ba2-9649-9ef46af4ac0e@github.com>
 <URHFhmpIcFdnX3d29D57R_JJ76hBo7gAm9zXGOfLxZs=.4aed11f9-2afa-417c-b67c-60fb2806a0bb@github.com>
Message-ID: <6e2kCVaBWwL4UY_zXxuwRDYQKksbEo_uaRH7P8gBDJU=.f52500af-d413-4b2e-bc19-32d2248aa48e@github.com>

On Wed, 4 Jun 2025 11:34:44 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 611:
>> 
>>> 609:   // increment the count of active signal handlers
>>> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
>>> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {
>> 
>> Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.
>
> I don't see how `Atomic::cmpxchg` would make the code easier.

With my current code, I avoid having a loop, and in the fast path, I only have one atomic instruction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126383576

From jbechberger at openjdk.org  Wed Jun  4 11:49:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 11:49:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
Message-ID: <kNwYb_xwjLiKCL5w0DxTdCkfwonsejfo3vaggLM1os4=.2eab93e1-efb6-4a23-b446-2fa95572582c@github.com>

On Wed, 4 Jun 2025 11:28:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve error message

> [a419dab](https://github.com/openjdk/jdk/commit/a419dabab213e78a2ff7f3c62cd4af72a0fdabed)
> Since the implementation has changed from Loss to Lost, the JEP document needs to be changed back to the original, Lost.

Good catch, I updated the JEP.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2939723399

From jbechberger at openjdk.org  Wed Jun  4 12:05:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:05:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v47]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <7XHQamQvo__d4VCHVNQQqwNEmPLoKh8wtpES1a3ZRDg=.2bc3d95c-c00d-4487-90e2-2341a8da9173@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8fe07614..fe53990d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=45-46

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

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

From mgronlun at openjdk.org  Wed Jun  4 12:05:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 12:05:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v46]
In-Reply-To: <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <m6PnZXjOrFg_uYEG2SYUeMlhYtVqWUVEGe5x5mKKjOQ=.9f4db170-d68c-4ed7-be93-cc4e6eb4e544@github.com>
Message-ID: <RtuCzD-Jwn5fKo8_9p06yAMQaH8IAA2T3rcanP3DAIA=.6fdd2062-b006-4cd9-b713-ea3143961f93@github.com>

On Wed, 4 Jun 2025 11:28:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve error message

I am approving this PR for the following reasons:

1. We have reached a state that is "good enough" - I no longer see any fundamental design issues that can not be handled by follow-up bug fixes.
2. There are still many vague aspects included with this PR, as many has already pointed out, mostly related to the memory model and thread interactions - all those can, and should, be clarified, explained and exacted post-integration.
3. The feature as a whole is experimental and turned off by default.
4. Today is the penultimate day before JDK 25 cutoff. To give the feature a fair chance for making JDK25, it needs approval now.

Thanks a lot Johannes and all involved for your hard work getting this feature ready.

Many thanks
Markus

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896467191

From mbaesken at openjdk.org  Wed Jun  4 12:08:18 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Jun 2025 12:08:18 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <Aa4AY9YDnDYtxcRcd0_aw6LK7H6Guh2QPWF57Xf5osE=.f0129d01-86c2-4ef0-9c9a-c25ced6e4029@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <6HSruHtZNPOZJp4vNFnwMns6-_rP_MEHtnnvAP7S5QU=.e91023a2-089c-4541-86a5-ae8d4adeb99d@github.com>
 <Aa4AY9YDnDYtxcRcd0_aw6LK7H6Guh2QPWF57Xf5osE=.f0129d01-86c2-4ef0-9c9a-c25ced6e4029@github.com>
Message-ID: <hIzgehmpMon2RmnYA3akfNZkLDgUMSH1n8fHyQxKZeg=.990aeb39-86b8-46c5-8423-54cf31687538@github.com>

On Wed, 4 Jun 2025 06:26:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In ASAN built JDK, some gtests and some other JTREG tests in runtime/ErrorHandling also fail.

btw I did not check ALL gtests but the HS `:tier1`  gtests work for me now on Linux x86_64.  But make sure the very recent change 
https://bugs.openjdk.org/browse/JDK-8357155
8357155: [asan] ZGC does not work
is included.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2939781272

From jbechberger at openjdk.org  Wed Jun  4 12:10:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:10:17 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Fix timer creation warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/fe53990d..8d545e74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=46-47

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

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

From mbaesken at openjdk.org  Wed Jun  4 12:18:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Jun 2025 12:18:20 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <R1F98xQkcJftZWk1FcOC8J4EfRPfoeduDTEJ6T-ziMA=.10d4e52e-2b82-419f-9153-58b52c34f028@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

The test AOTCodeCompressedOopsTest.java has the memory error mentioned above fixed now with recent changes , but shows another issue

runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java
---------------------------------------------------------------
java.lang.RuntimeException: Pattern "narrow_oop_base = 0x(\\d+), narrow_oop_shift = (\\d)" not found in the output
	at AOTCodeCompressedOopsTest$Tester.checkExecution(AOTCodeCompressedOopsTest.java:184)
	at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:221)
	at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:427)
	at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:392)
	at AOTCodeCompressedOopsTest.main(AOTCodeCompressedOopsTest.java:58)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1474)

Maybe we should  ask an AOT expert about this, not sure what that means.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2939805054

From jbechberger at openjdk.org  Wed Jun  4 12:23:13 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:23:13 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v49]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <4aLbfK7e6pncU0QwXORueBxt8WEOz5KYO1pKnpjFOC0=.cf78fb29-a30f-4084-bee7-76c1e6e81f31@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8d545e74..fbaf1da6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=47-48

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

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

From apangin at openjdk.org  Wed Jun  4 12:38:21 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 12:38:21 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
Message-ID: <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>

On Wed, 4 Jun 2025 12:10:17 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix timer creation warning

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 491:

> 489: 
> 490: void JfrCPUTimeThreadSampling::handle_timer_signal(siginfo_t* info, void* context) {
> 491:   if (info->si_code != SIGPROF) {

The correct check is
`if (info->si_code != SI_TIMER)`

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 652:

> 650: bool JfrCPUSamplerThread::init_timers() {
> 651:   // install sig handler for sig
> 652:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {

Comparing return value to `(void*)-1` would be cleaner.
But the main problem is that it only checks for `sigaction` failure (which normally never happens), however, we should also check if there was a custom signal handler set _before_ installing our own handler, i.e. old handler is not SIG_IGN or SIG_DFL or `handle_timer_signal`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126447823
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126488937

From jbechberger at openjdk.org  Wed Jun  4 12:47:36 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:47:36 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
 <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
Message-ID: <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>

On Wed, 4 Jun 2025 12:33:45 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix timer creation warning
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 652:
> 
>> 650: bool JfrCPUSamplerThread::init_timers() {
>> 651:   // install sig handler for sig
>> 652:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
> 
> Comparing return value to `(void*)-1` would be cleaner.
> But the main problem is that it only checks for `sigaction` failure (which normally never happens), however, we should also check if there was a custom signal handler set _before_ installing our own handler, i.e. old handler is not SIG_IGN or SIG_DFL or `handle_timer_signal`.

Using `sigaction(SIG, NULL, &sa)` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126510947

From rvansa at openjdk.org  Wed Jun  4 12:50:35 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 4 Jun 2025 12:50:35 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v15]
In-Reply-To: <5gclUhzEQCai7QGUBDA16OcIrQcmesMGR1pJd2Hbgbw=.79a0d71a-a246-4a84-9794-43f7ef738b09@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <t1ZJ4jiHSIIaApv79RbArK147r0Fx7I8gFvfuij0IcI=.f4fe76de-5d80-4396-b98e-02bae7290cd6@github.com>
 <5gclUhzEQCai7QGUBDA16OcIrQcmesMGR1pJd2Hbgbw=.79a0d71a-a246-4a84-9794-43f7ef738b09@github.com>
Message-ID: <Yn_K95QlYZQY-HmORht03byD5WaGZgyoSgF5k6VH_7U=.3a457ac5-3639-4f14-9c24-974b097c0947@github.com>

On Fri, 30 May 2025 21:14:53 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Radim Vansa has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
>> I like the idea of mapping each element in the table as raw bits, though handling of access to the end of the array would be a bit inconvenient (or we would have to allocate a few extra bytes).
> 
> The code snippet I shared above shows a better way:  You load a full 8 (or 4) bytes where the END (not the START) of the word lines up with the LAST (not FIRST) byte.  Then you will never run past the end of the array!  So, fine, but what about the start of the array?  Well, it's inside an `Array<u1>` object, which has a length header, which is guaranteed to be safe to load (under a cast or bytewise or whatever).  Problem solved.  The only thing to avoid is to load an 8-byte word when the packed word size is 1..5 bytes; then you load a 4-byte word.  You can load both components at once, and then use a configurable shift (from one machine word) to separate them.  This is why I say it saves a half-byte on average.
> 
> These tweaky ideas have three effects:  They probably make the code a little simpler (or at least no worse), they reduce the number of memory operations to query a packed array, and they probably use fewer ALU instructions overall.  They are certainly worth considering for the general-purpose "searchable packed array" I am envisioning; they are optional for this particular bug, viewed in isolation.
> 
>> I've changed the algorithm to use unsigned integers; in fact I find a bit annoying that most of the indices used throughout the related code are signed.
> 
> Yes, it annoys me also.  It's playing with fire (or walking the firepit).
> 
>> I've also added a test generating class with a different number of fields, though running it through the full range of fields (0-65535, though in practice the upper bound is rather 26k) would be excessive; even now it takes more than a minute on my machine. Also, I realize that varying the number of fields does not result in full coverage of possible stream sizes; per-field records have probably rather uniform lengths.
> 
> Yeah, a gtest on the binary search would cover most of those issues, faster and cleaner.  Then loading many gigantic classfiles will be unnecessary.  Just a few classfiles at several scales, probably, and thorough gtest-level unit testing, gets a better result in less time.  As I said above, I'm willing to put off some of the refactoring, given that it should cover other, prior occurrences of binary search (so it's got a larger scope than this bug).
> 
>> @rose00 OK, so I have refactored out the PackedTable that now h...

@rose00 Hi, would you be OK with the current implementation?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2939915008

From jbechberger at openjdk.org  Wed Jun  4 12:56:22 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 12:56:22 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/fbaf1da6..e4558a6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=48-49

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

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

From jbechberger at openjdk.org  Wed Jun  4 13:07:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 13:07:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
 <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
 <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>
Message-ID: <-JmnqMbD8vGy_dVeVUv59WrjuCavWV3F3w9HMTxhAQM=.2c079574-0729-4c70-af86-946a3204f7b6@github.com>

On Wed, 4 Jun 2025 12:44:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 652:
>> 
>>> 650: bool JfrCPUSamplerThread::init_timers() {
>>> 651:   // install sig handler for sig
>>> 652:   if ((s8)PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == -1) {
>> 
>> Comparing return value to `(void*)-1` would be cleaner.
>> But the main problem is that it only checks for `sigaction` failure (which normally never happens), however, we should also check if there was a custom signal handler set _before_ installing our own handler, i.e. old handler is not SIG_IGN or SIG_DFL or `handle_timer_signal`.
>
> Using `sigaction(SIG, NULL, &sa)` ?

I'm currently implementing the check against SIG_IGN and SIG_DFL, as `handle_timer_signal` should never occur.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126551278

From alanb at openjdk.org  Wed Jun  4 13:24:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 13:24:54 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
Message-ID: <vVJj7EKjUfJujEo4I22-RWzmJOJjtGiusyJzk0f1kg0=.136a793a-5a30-40d6-8b52-a9717f9f99b0@github.com>

On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `serviceability/`

Not an issue but clearer to define it as a static class.

(I've fixed the labels on this PR as this is serviceability code).

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25638#pullrequestreview-2896719812

From alanb at openjdk.org  Wed Jun  4 13:31:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 13:31:52 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
Message-ID: <gzUQQPdf_IB1lMcBs55aJS4KtkQD7YU3ip7gXKvAIXI=.d0299e1e-6b6e-4c08-b12b-58f5c65a406f@github.com>

On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `serviceability/`

The tests in test/jdk/com/sun/management/HotSpotDiagnosticMBean is the quickest way to exercise this code.

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

PR Comment: https://git.openjdk.org/jdk/pull/25638#issuecomment-2940053160

From shade at openjdk.org  Wed Jun  4 13:39:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 13:39:51 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <gzUQQPdf_IB1lMcBs55aJS4KtkQD7YU3ip7gXKvAIXI=.d0299e1e-6b6e-4c08-b12b-58f5c65a406f@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
 <gzUQQPdf_IB1lMcBs55aJS4KtkQD7YU3ip7gXKvAIXI=.d0299e1e-6b6e-4c08-b12b-58f5c65a406f@github.com>
Message-ID: <0kgPZAsNJzgpPqpczSxR-awsEnN4eYtKUps45y5egZw=.7bb7be88-133d-47cb-b97a-f7cdd94b9d0b@github.com>

On Wed, 4 Jun 2025 13:29:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The tests in test/jdk/com/sun/management/HotSpotDiagnosticMBean is the quickest way to exercise this code.

Thanks! I just ran the entire `jdk_management` test group without any problems.

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

PR Comment: https://git.openjdk.org/jdk/pull/25638#issuecomment-2940078372

From mdoerr at openjdk.org  Wed Jun  4 14:01:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Jun 2025 14:01:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
Message-ID: <YKYZ-XyOaQP9gG1Mr4xbFzNC2cE1fvHbsuNyQDR21n4=.c396c57b-6575-44ed-891d-ae16e5cea22c@github.com>

On Wed, 4 Jun 2025 12:56:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

I've looked over it and couldn't spot any critical issue. I think it's good enough for an experimental feature if we do further cleanups and improvements later.
What I'd like to see as a follow-up is a review of the usage of `Atomic` functions. I've never seen so many of them in such a density.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896853345

From pchilanomate at openjdk.org  Wed Jun  4 14:15:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:15:53 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
Message-ID: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>

On Wed, 4 Jun 2025 12:56:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

I took a look at this. I only found one issue that needs fixing before integration and then a few comments. Thanks.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 59:

> 57:   Thread* raw_thread = Thread::current_or_null_safe();
> 58:   if (raw_thread == nullptr) {
> 59:     // probably while shutting down

Do you remember which test fail because of this? It would be interesting to know, since I don?t see how it could be null here.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:

> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
> 329:   ResourceMark rm;
> 330:   MutexLocker tlock(Threads_lock);

What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 430:

> 428: void JfrCPUTimeThreadSampling::create_sampler(double rate, bool auto_adapt) {
> 429:   assert(_sampler == nullptr, "invariant");
> 430:   _sampler = new JfrCPUSamplerThread(rate, auto_adapt);

If we start a recording on an already running process we have a race here where a new thread can create and set its timer before we call init_timers() where the signal handler is installed. In that case the program will terminate with message ?Profiling timer expired" (default action for SIGPROF). It can be easily reproduced by adding a delay here and starting a recording on a simple test that just creates new threads. We need to add some extra check in create_timer_for_thread() or install the signal handler earlier.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 584:

> 582:   sev.sigev_notify = SIGEV_THREAD_ID;
> 583:   sev.sigev_signo = SIG;
> 584:   sev.sigev_value.sival_ptr = &t;

Why setting the address of `t` which is a local variable here?

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896813404
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126661443
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126670024
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126651264
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126666505

From pchilanomate at openjdk.org  Wed Jun  4 14:15:54 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:15:54 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>
Message-ID: <Vdk2TBsN_nRj3_l2VB4SyTY_TJh1Bvy7zqwfsILH354=.2f927c67-40d8-4fa8-bb18-70bb5320d332@github.com>

On Mon, 2 Jun 2025 15:13:54 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> So I don't read the ` tl->has_cpu_time_jfr_requests()` twice on the hot-path
>
> Ok, for now. We should try to come up with a better split.

If there are sample requests then we are already in the slow path so loading again `has_cpu_time_jfr_requests()` later won't change anything. My suggestion would be to avoid passing this boolean around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126692802

From jbechberger at openjdk.org  Wed Jun  4 14:15:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:15:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v48]
In-Reply-To: <-JmnqMbD8vGy_dVeVUv59WrjuCavWV3F3w9HMTxhAQM=.2c079574-0729-4c70-af86-946a3204f7b6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <cmhKP9x0vP4PWNd89kCEZXf6AZwJDdG83yhbHODoZ4U=.2dc3ca55-c405-4c06-83d0-9c5d1c057f05@github.com>
 <IeH0GO8z-NvmR-G_h9tPrT_bgDyCUZGy5oqXzog5SaQ=.95a0a442-6233-47e9-9420-33d0c08d0735@github.com>
 <gIjB68OUx-pnMc9Hgl6qkXmQ6ZTkTJUSAZWjDRCN_0M=.c1030408-3dfb-488b-a6a9-a8aee4be0124@github.com>
 <-JmnqMbD8vGy_dVeVUv59WrjuCavWV3F3w9HMTxhAQM=.2c079574-0729-4c70-af86-946a3204f7b6@github.com>
Message-ID: <b-puA8U0ATu7kbUIIgsqrbbUavd5klDl2b-GAsh8vUA=.98fe85f1-01e2-479b-b61b-c265990bffee@github.com>

On Wed, 4 Jun 2025 13:04:28 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Using `sigaction(SIG, NULL, &sa)` ?
>
> I'm currently implementing the check against SIG_IGN and SIG_DFL, as `handle_timer_signal` should never occur.

I implemented what you want. This prevents confusion of users.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126701277

From jbechberger at openjdk.org  Wed Jun  4 14:15:48 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:15:48 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v51]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <L5JSoB8VKtSPrybxRzQinXlzK96mA1Ak3f58KuYKM_g=.ea4aa9b2-d556-4728-be11-efdf0f4d2a74@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Check if signal handler is already installed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/e4558a6e..762da321

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=49-50

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

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

From mbaesken at openjdk.org  Wed Jun  4 14:17:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 4 Jun 2025 14:17:52 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <6lt1R3T4xH4FQGEDE7GzuThv4MaGmGynK-KG5o17-Q8=.164c5a02-d5f4-4791-988a-5e29fa6463bc@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

Had a look at HS tier3 tests too and the whole runtime/signal/TestSig*  tests fail with asan like this
e.g. runtime/signal/TestSigalrm.java

 stdout: [];
 stderr: [==3863397==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.


So maybe we should mark them too ?
Seems to be the same kind of issue as in the HS tier1 jsig  related tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2940211436

From jbechberger at openjdk.org  Wed Jun  4 14:21:07 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:21:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
Message-ID: <EDtZkOHaeA3hIKutgg4O1o1mmiG1VhEiG0pBb-LCZy8=.72b00371-19f1-4cf4-ad83-45d96dd20b1e@github.com>

On Wed, 4 Jun 2025 13:51:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 59:
> 
>> 57:   Thread* raw_thread = Thread::current_or_null_safe();
>> 58:   if (raw_thread == nullptr) {
>> 59:     // probably while shutting down
> 
> Do you remember which test fail because of this? It would be interesting to know, since I don?t see how it could be null here.

I just ran the renaissance benchmark with https://github.com/parttimenerd/basic-profiler-tests for a few hours.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126728665

From jbechberger at openjdk.org  Wed Jun  4 14:27:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:27:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
Message-ID: <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>

On Wed, 4 Jun 2025 13:55:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:
> 
>> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
>> 329:   ResourceMark rm;
>> 330:   MutexLocker tlock(Threads_lock);
> 
> What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.

You're right.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 584:
> 
>> 582:   sev.sigev_notify = SIGEV_THREAD_ID;
>> 583:   sev.sigev_signo = SIG;
>> 584:   sev.sigev_value.sival_ptr = &t;
> 
> Why setting the address of `t` which is a local variable here?

Because this is how the API works. You store the location where the timer should be stored.

See https://www.man7.org/linux/man-pages/man2/timer_create.2.html for more information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126741491
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126735519

From jbechberger at openjdk.org  Wed Jun  4 14:31:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:31:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v29]
In-Reply-To: <Vdk2TBsN_nRj3_l2VB4SyTY_TJh1Bvy7zqwfsILH354=.2f927c67-40d8-4fa8-bb18-70bb5320d332@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <UbKAIQ7Hvh904pWvMKxH6zKz8nYQAo-fRRPIXg8lJI0=.9a39ea2f-d5f9-40b4-9b16-eabcb6416390@github.com>
 <zPG4XpqxqUM4H1REnQ7VBKqZsoBT3BAjyzb798fDq8U=.d94de17a-5263-4b89-a689-fbcdd55c6120@github.com>
 <QJxnm3XsK48_R6wzyARB9dEVSMNaM2n2mZHfvEf7I7w=.7b76e374-b95d-4797-9bea-ff7ef439707c@github.com>
 <QZJR4MQ5iTABIYzlU5yXTWc7PYvdkR57jonexvnnBwg=.cdc4ae92-17c4-470b-9f0a-ea080d05a97d@github.com>
 <Vdk2TBsN_nRj3_l2VB4SyTY_TJh1Bvy7zqwfsILH354=.2f927c67-40d8-4fa8-bb18-70bb5320d332@github.com>
Message-ID: <8K2UKh2c90_9WYibMs0LoKZr5GNFAGZkINV11POsvac=.8150ba38-e33e-4780-bb08-2783640b6a3a@github.com>

On Wed, 4 Jun 2025 14:04:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Ok, for now. We should try to come up with a better split.
>
> If there are sample requests then we are already in the slow path so loading again `has_cpu_time_jfr_requests()` later won't change anything. My suggestion would be to avoid passing this boolean around.

I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126751794

From jbechberger at openjdk.org  Wed Jun  4 14:45:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:45:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
Message-ID: <ZFbJAFMki4I2l3iekCNiLgPpQZkROMF2j6GIKjCWkQM=.d285a9cc-5279-4ebb-93f2-3605f4e72c66@github.com>

On Wed, 4 Jun 2025 13:47:01 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 430:
> 
>> 428: void JfrCPUTimeThreadSampling::create_sampler(double rate, bool auto_adapt) {
>> 429:   assert(_sampler == nullptr, "invariant");
>> 430:   _sampler = new JfrCPUSamplerThread(rate, auto_adapt);
> 
> If we start a recording on an already running process we have a race here where a new thread can create and set its timer before we call init_timers() where the signal handler is installed. In that case the program will terminate with message ?Profiling timer expired" (default action for SIGPROF). It can be easily reproduced by adding a delay here and starting a recording on a simple test that just creates new threads. We need to add some extra check in create_timer_for_thread() or install the signal handler earlier.

I created a `has_timer` flag that is checked by `create_timer_for_thread()` before creating timers and set by `init_timers`. Is this what you envisioned?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126783367

From pchilanomate at openjdk.org  Wed Jun  4 14:45:21 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:45:21 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
Message-ID: <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>

On Wed, 4 Jun 2025 14:21:31 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 584:
>> 
>>> 582:   sev.sigev_notify = SIGEV_THREAD_ID;
>>> 583:   sev.sigev_signo = SIG;
>>> 584:   sev.sigev_value.sival_ptr = &t;
>> 
>> Why setting the address of `t` which is a local variable here?
>
> Because this is how the API works. You store the location where the timer should be stored.
> 
> See https://www.man7.org/linux/man-pages/man2/timer_create.2.html for more information.

Sorry where does it say that? I think you are looking at the example in that page which makes use of sival_ptr in the signal handler. In that example reading from that timer address in the handler is valid but for us we would be accessing invalid memory. Plus we are not really reading it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126787035

From jbechberger at openjdk.org  Wed Jun  4 14:49:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:49:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
Message-ID: <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>

On Wed, 4 Jun 2025 14:41:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Because this is how the API works. You store the location where the timer should be stored.
>> 
>> See https://www.man7.org/linux/man-pages/man2/timer_create.2.html for more information.
>
> Sorry where does it say that? I think you are looking at the example in that page which makes use of sival_ptr in the signal handler. In that example reading from that timer address in the handler is valid but for us we would be accessing invalid memory. Plus we are not really reading it.

Why would we be accessing invalid memory?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126798263

From jbechberger at openjdk.org  Wed Jun  4 14:59:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v52]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <skECGGRF1Q7nVu1BKWauGA5qz0pkpCKsVYGBuIx3FXg=.d370e0f8-6c3a-47ae-82ef-469121ff62f0@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Small changes
  
  Suggested by @pchilano

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/762da321..20b8db28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=50-51

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

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

From jbechberger at openjdk.org  Wed Jun  4 14:59:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
Message-ID: <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>

On Wed, 4 Jun 2025 14:46:27 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Sorry where does it say that? I think you are looking at the example in that page which makes use of sival_ptr in the signal handler. In that example reading from that timer address in the handler is valid but for us we would be accessing invalid memory. Plus we are not really reading it.
>
> Why would we be accessing invalid memory?

Which differences to the example code are you seeing?


 sev.sigev_notify = SIGEV_SIGNAL;
           sev.sigev_signo = SIG;
           sev.sigev_value.sival_ptr = &timerid;
           if (timer_create(CLOCKID, &sev, &timerid) == -1)
               errExit("timer_create");

           printf("timer ID is %#jx\n", (uintmax_t) timerid);

           /* Start the timer. */

           freq_nanosecs = atoll(argv[2]);
           its.it_value.tv_sec = freq_nanosecs / 1000000000;
           its.it_value.tv_nsec = freq_nanosecs % 1000000000;
           its.it_interval.tv_sec = its.it_value.tv_sec;
           its.it_interval.tv_nsec = its.it_value.tv_nsec;



Is similar to:


 ((int*)&sev.sigev_notify)[1] = thread->osthread()->thread_id();
  clockid_t clock;
  int err = pthread_getcpuclockid(thread->osthread()->pthread_id(), &clock);
  if (err != 0) {
    log_error(jfr)("Failed to get clock for thread sampling: %s", os::strerror(err));
    return false;
  }
  if (timer_create(clock, &sev, &t) < 0) {
    return false;
  }
  int64_t period = get_sampling_period();
  if (period != 0) {
    set_timer_time(t, period);
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126810984

From pchilanomate at openjdk.org  Wed Jun  4 14:59:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
Message-ID: <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>

On Wed, 4 Jun 2025 14:52:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Why would we be accessing invalid memory?
>
> Which differences to the example code are you seeing?
> 
> 
>  sev.sigev_notify = SIGEV_SIGNAL;
>            sev.sigev_signo = SIG;
>            sev.sigev_value.sival_ptr = &timerid;
>            if (timer_create(CLOCKID, &sev, &timerid) == -1)
>                errExit("timer_create");
> 
>            printf("timer ID is %#jx\n", (uintmax_t) timerid);
> 
>            /* Start the timer. */
> 
>            freq_nanosecs = atoll(argv[2]);
>            its.it_value.tv_sec = freq_nanosecs / 1000000000;
>            its.it_value.tv_nsec = freq_nanosecs % 1000000000;
>            its.it_interval.tv_sec = its.it_value.tv_sec;
>            its.it_interval.tv_nsec = its.it_value.tv_nsec;
> 
> 
> 
> Is similar to:
> 
> 
>  ((int*)&sev.sigev_notify)[1] = thread->osthread()->thread_id();
>   clockid_t clock;
>   int err = pthread_getcpuclockid(thread->osthread()->pthread_id(), &clock);
>   if (err != 0) {
>     log_error(jfr)("Failed to get clock for thread sampling: %s", os::strerror(err));
>     return false;
>   }
>   if (timer_create(clock, &sev, &t) < 0) {
>     return false;
>   }
>   int64_t period = get_sampling_period();
>   if (period != 0) {
>     set_timer_time(t, period);
>   }

The `sigev_value` member is used to pass data that you can read in the signal handler. The address of `t` won't be valid anymore once you return from this function. In that example the address of `timerid ` is still valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126817165

From jbechberger at openjdk.org  Wed Jun  4 14:59:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 14:59:33 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
Message-ID: <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>

On Wed, 4 Jun 2025 14:54:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Which differences to the example code are you seeing?
>> 
>> 
>>  sev.sigev_notify = SIGEV_SIGNAL;
>>            sev.sigev_signo = SIG;
>>            sev.sigev_value.sival_ptr = &timerid;
>>            if (timer_create(CLOCKID, &sev, &timerid) == -1)
>>                errExit("timer_create");
>> 
>>            printf("timer ID is %#jx\n", (uintmax_t) timerid);
>> 
>>            /* Start the timer. */
>> 
>>            freq_nanosecs = atoll(argv[2]);
>>            its.it_value.tv_sec = freq_nanosecs / 1000000000;
>>            its.it_value.tv_nsec = freq_nanosecs % 1000000000;
>>            its.it_interval.tv_sec = its.it_value.tv_sec;
>>            its.it_interval.tv_nsec = its.it_value.tv_nsec;
>> 
>> 
>> 
>> Is similar to:
>> 
>> 
>>  ((int*)&sev.sigev_notify)[1] = thread->osthread()->thread_id();
>>   clockid_t clock;
>>   int err = pthread_getcpuclockid(thread->osthread()->pthread_id(), &clock);
>>   if (err != 0) {
>>     log_error(jfr)("Failed to get clock for thread sampling: %s", os::strerror(err));
>>     return false;
>>   }
>>   if (timer_create(clock, &sev, &t) < 0) {
>>     return false;
>>   }
>>   int64_t period = get_sampling_period();
>>   if (period != 0) {
>>     set_timer_time(t, period);
>>   }
>
> The `sigev_value` member is used to pass data that you can read in the signal handler. The address of `t` won't be valid anymore once you return from this function. In that example the address of `timerid ` is still valid.

Why is this a problem? We don't leak `&t` outside of `create_timer_for_thread`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126820560

From jbechberger at openjdk.org  Wed Jun  4 15:06:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:06:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v53]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <40QHcJ9vY8NkXNVIhF-84WqMoSTRwxGsQfENcTJNEHI=.d1753def-3f74-4646-a574-952612dddaec@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve create_timer_for_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/20b8db28..45f915b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=51-52

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

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

From jbechberger at openjdk.org  Wed Jun  4 15:06:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:06:16 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
Message-ID: <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>

On Wed, 4 Jun 2025 14:56:10 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> The `sigev_value` member is used to pass data that you can read in the signal handler. The address of `t` won't be valid anymore once you return from this function. In that example the address of `timerid ` is still valid.
>
> Why is this a problem? We don't leak `&t` outside of `create_timer_for_thread`.

But I can start using the passed-in parameter `timerid` directly, which should make the code less confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126829360

From jbechberger at openjdk.org  Wed Jun  4 15:19:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:19:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
 <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
Message-ID: <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYrV9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>

On Wed, 4 Jun 2025 15:00:07 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Why is this a problem? We don't leak `&t` outside of `create_timer_for_thread`.
>
> But I can start using the passed-in parameter `timerid` directly, which should make the code less confusing.

I pushed the modifications.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126863235

From shade at openjdk.org  Wed Jun  4 15:32:26 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
Message-ID: <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>

On Wed, 4 Jun 2025 12:56:22 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

Some more cosmetics/nits.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 264:

> 262:   }
> 263:   timer_delete(*timer);
> 264:   tl->unset_cpu_timer();

Should this deletion be right in `unset_cpu_timer`?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 729:

> 727: #else
> 728: 
> 729: static bool _showed_warning = false;

`_displayed_warning`? Actually, I think you can move this straight into `warn()` body.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:

> 248:     }
> 249: 
> 250: 

Unnecessary?

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 582:

> 580: }
> 581: 
> 582: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() {

This sounds like `try_acquire_cpu_time_jfr_enqueue_lock`, emphasis on `try_`. It does not actually guarantee to lock.

src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 586:

> 584: }
> 585: 
> 586: bool JfrThreadLocal::try_acquire_cpu_time_jfr_dequeue_lock() {

...and this one is not `try_`, but the actual "blocking" acquire.

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2896958686
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126882197
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126868308
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126736956
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126831195
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126844713

From jbechberger at openjdk.org  Wed Jun  4 15:32:25 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:32:25 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v54]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <8m6_JMIlbofV7pazQz-ZmfzLDOmVt-bXpmOMtQQFhpg=.121c7602-81c0-4a8a-81ea-dc753bd4ca87@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve create_timer_for_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/45f915b4..8f237898

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=52-53

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

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

From apangin at openjdk.org  Wed Jun  4 15:32:26 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYrV9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
 <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
 <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYr
 V9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>
Message-ID: <BePzKNIhTPBfpooLDVE1u8PUUdPhWgoohU-3g0eD0Ow=.2ad957e1-054b-4b66-ab4a-cc5bcad2d754@github.com>

On Wed, 4 Jun 2025 15:16:16 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> But I can start using the passed-in parameter `timerid` directly, which should make the code less confusing.
>
> I pushed the modifications.

Simply set `sival_ptr` to `NULL`, the value is never used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126880196

From jbechberger at openjdk.org  Wed Jun  4 15:32:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <BePzKNIhTPBfpooLDVE1u8PUUdPhWgoohU-3g0eD0Ow=.2ad957e1-054b-4b66-ab4a-cc5bcad2d754@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <NttH4KTELd8fH2lIOrQK5NiLV-pivhPB5qsTaJDbngU=.414ece6b-4e48-4c91-8900-ff4f6842510b@github.com>
 <LNbDLTJGxlITV6HUq5L5Jzloqzdih6VEjp6ytp_DFf4=.a154a9cf-7652-4737-8e5f-b8649897db51@github.com>
 <uNRsENa0Owo8DtHlrxdz6tzHOLITYVjqPGuYxOwWa7U=.6629032a-741a-4acb-8c16-aa1855630465@github.com>
 <khjF5ZG9hrDL9dYEC382F5UJphVTQxUYhQ5FYoDNzDI=.de5e3189-67de-49d9-b947-c2c150d112be@github.com>
 <HqpS7SIykL1cADVLKAM0JNPrbenkFqC9MUAD4_dimSo=.f7c1ee6f-92f9-4132-aac2-2ce85394e57e@github.com>
 <FdLN3m2FX0DZDgA_9zTiWO5S_mQtYnghyltZJCK33-Y=.f300da19-77e2-43f8-90c3-2a8691cae3e6@github.com>
 <HFADy0fL9GUEqhV6-pBanyaFs136hLsVWYr
 V9pxPUnU=.512f6ebf-0651-4d71-8547-4d03a22c6b6c@github.com>
 <BePzKNIhTPBfpooLDVE1u8PUUdPhWgoohU-3g0eD0Ow=.2ad957e1-054b-4b66-ab4a-cc5bcad2d754@github.com>
Message-ID: <YlgBcy7lN1pd5zNAF-RwFOvEo9Kmbc-6dhhN2w199mM=.bddce2c1-85da-42e0-851d-32f8f756151c@github.com>

On Wed, 4 Jun 2025 15:23:55 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> I pushed the modifications.
>
> Simply set `sival_ptr` to `NULL`, the value is never used.

You're right, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126886264

From jbechberger at openjdk.org  Wed Jun  4 15:32:26 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:32:26 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
Message-ID: <Da68pFmCN9F7Vx-OduGkqSrEZKlday2JavfUUVGf6Fs=.312bd07b-e421-4bb5-a1d2-5490df2c5f74@github.com>

On Wed, 4 Jun 2025 14:22:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 250:
> 
>> 248:     }
>> 249: 
>> 250: 
> 
> Unnecessary?

Yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126890693

From jbechberger at openjdk.org  Wed Jun  4 15:40:06 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:40:06 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <aHTGGJp0KjlZeTtZCRciDMkuZeGCyJ-qZYk7vaOqh7k=.567b9e20-ada1-4b40-aa9d-340e74e2233f@github.com>
Message-ID: <DlRlcXVrIpxbq-tDJaGWxAcy6kzmx7a_8WmRDSqKp8o=.ae9f0ba0-2ecc-45ef-b146-0550219d178f@github.com>

On Wed, 4 Jun 2025 15:07:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build
>
> src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 586:
> 
>> 584: }
>> 585: 
>> 586: bool JfrThreadLocal::try_acquire_cpu_time_jfr_dequeue_lock() {
> 
> ...and this one is not `try_`, but the actual "blocking" acquire.

But it fails if the lock state is already on `DEQUEUE`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2126907622

From jbechberger at openjdk.org  Wed Jun  4 15:48:31 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 15:48:31 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v55]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/8f237898..3a486817

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=53-54

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

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

From mgronlun at openjdk.org  Wed Jun  4 17:09:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 17:09:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
Message-ID: <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>

On Wed, 4 Jun 2025 14:24:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:
>> 
>>> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
>>> 329:   ResourceMark rm;
>>> 330:   MutexLocker tlock(Threads_lock);
>> 
>> What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.
>
> You're right.

The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127062451

From sspitsyn at openjdk.org  Wed Jun  4 17:12:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 4 Jun 2025 17:12:51 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
Message-ID: <3tJxS_FmBSfMwWZvKF7weGK7-lfK8_--SN40GF3jQps=.7fb35ada-2dc5-4110-9c07-5943afbab704@github.com>

On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/`
>  - [x] Linux x86_64 server fastdebug, `jdk_management`

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25638#pullrequestreview-2897502213

From jbechberger at openjdk.org  Wed Jun  4 17:22:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:22:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Readd lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/3a486817..53d3ed4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=54-55

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

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

From jbechberger at openjdk.org  Wed Jun  4 17:22:37 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:22:37 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>
Message-ID: <-YJusSw4Vn4Dx_is7mRjOT6clvj3Uh5F5tcLsPIwUAk=.fda1546c-22b0-4a57-900e-2e752841b617@github.com>

On Wed, 4 Jun 2025 17:04:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> You're right.
>
> The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602

I readded the lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127082776

From shade at openjdk.org  Wed Jun  4 17:27:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Jun 2025 17:27:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v55]
In-Reply-To: <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>
Message-ID: <o56EXvgyVDG1x31cDH9l6agnFwGc0xh_fXlJAXyy6UA=.17cf60fc-fe7d-4907-b5c4-1bd52cdec9ae@github.com>

On Wed, 4 Jun 2025 15:48:31 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve

I admit I am leaning pretty hard on JFR folks expertise here.

I agree this code passes the bar for experimental feature: it does not seem to affect non-JFR paths, does not seem to interact with JFR in obviously incorrect manner, and in itself looks more or less sensible.

Please file the follow-ups to figure out the memory ordering story in `JfrCPUTimeTraceQueue`.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 640:

> 638: 
> 639:   VM_CPUTimeSamplerThreadInitializer(JfrCPUSamplerThread* sampler) : _sampler(sampler) {
> 640:   }

Suggestion:

 private:
  JfrCPUSamplerThread* const _sampler;
  
 public:
  VM_CPUTimeSamplerThreadInitializer(JfrCPUSamplerThread* sampler) : _sampler(sampler) {}

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 671:

> 669: 
> 670:   VM_CPUTimeSamplerThreadTerminator(JfrCPUSamplerThread* sampler) : _sampler(sampler) {
> 671:   }

Suggestion:

 private:
  JfrCPUSamplerThread* const _sampler;

 public:
  VM_CPUTimeSamplerThreadTerminator(JfrCPUSamplerThread* sampler) : _sampler(sampler) {}

src/hotspot/share/runtime/vmOperation.hpp line 119:

> 117:   template(RendezvousGCThreads)                   \
> 118:   template(CPUTimeSamplerThreadInitializer)       \
> 119:   template(CPUTimeSamplerThreadTerminator)        \

I think these better be prefixed with `JFR`. E.g.: `JFRInitializeCPUTimeSampler` / `JFRTerminateCPUTimeSampler`?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2897511962
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127078325
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127079549
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127090498

From jbechberger at openjdk.org  Wed Jun  4 17:49:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:49:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v57]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <I3MalT4D4ZSk6QLBeCSgCFfX6q2I47VeQejwnmrCsOc=.43b62b63-9f2b-44d7-92d6-64d6a67c753a@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with three additional commits since the last revision:

 - Renaming of VM ops
 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>
 - Update src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp
   
   Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/53d3ed4a..f3ef7908

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=56
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=55-56

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

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

From jbechberger at openjdk.org  Wed Jun  4 17:49:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:49:27 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v55]
In-Reply-To: <o56EXvgyVDG1x31cDH9l6agnFwGc0xh_fXlJAXyy6UA=.17cf60fc-fe7d-4907-b5c4-1bd52cdec9ae@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Us02Njophu5a815U6DJrqY7RP9yY7W_MCpDgIXnaBAQ=.03d2dd31-12d7-44bf-8515-321d3dd7e311@github.com>
 <o56EXvgyVDG1x31cDH9l6agnFwGc0xh_fXlJAXyy6UA=.17cf60fc-fe7d-4907-b5c4-1bd52cdec9ae@github.com>
Message-ID: <mUXSwVZZCVWg3zz7bVBzpP8MoT0KpnvZPwP3zP36dk4=.c682f285-6365-4477-92ab-080727639b74@github.com>

On Wed, 4 Jun 2025 17:24:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Please file the follow-ups to figure out the memory ordering story in `JfrCPUTimeTraceQueue`.

I created a preliminary issue at https://bugs.openjdk.org/browse/JDK-8358616

> src/hotspot/share/runtime/vmOperation.hpp line 119:
> 
>> 117:   template(RendezvousGCThreads)                   \
>> 118:   template(CPUTimeSamplerThreadInitializer)       \
>> 119:   template(CPUTimeSamplerThreadTerminator)        \
> 
> I think these better be prefixed with `JFR`. E.g.: `JFRInitializeCPUTimeSampler` / `JFRTerminateCPUTimeSampler`?

Good point

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2940863550
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127113247

From mgronlun at openjdk.org  Wed Jun  4 17:49:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 17:49:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
Message-ID: <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>

On Wed, 4 Jun 2025 17:22:37 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readd lock

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 300:

> 298:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
> 299:     log_trace(jfr)("Disenrolling CPU thread sampler");
> 300:     if (Atomic::fetch_then_and(&_signal_handler_installed, false)) {

fetch_then_and with false? Must be simpler way to express this? Like Atomic::load(&_signal_handler_installed)?

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 608:

> 606: void JfrCPUSamplerThread::stop_signal_handlers() {
> 607:   // set the stop signal bit
> 608:   Atomic::or_then_fetch(&_active_signal_handlers, STOP_SIGNAL_BIT, memory_order_acq_rel);

Whatever was fetched is gone with the wind...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127117357
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127119596

From jbechberger at openjdk.org  Wed Jun  4 17:49:28 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:49:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
 <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
Message-ID: <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>

On Wed, 4 Jun 2025 17:39:38 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Readd lock
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 300:
> 
>> 298:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
>> 299:     log_trace(jfr)("Disenrolling CPU thread sampler");
>> 300:     if (Atomic::fetch_then_and(&_signal_handler_installed, false)) {
> 
> fetch_then_and with false? Must be simpler way to express this? Like Atomic::load(&_signal_handler_installed)?

I also want to set it. Wanted to do a simple ::xchg, but this doesn't exist for booleans.

> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 608:
> 
>> 606: void JfrCPUSamplerThread::stop_signal_handlers() {
>> 607:   // set the stop signal bit
>> 608:   Atomic::or_then_fetch(&_active_signal_handlers, STOP_SIGNAL_BIT, memory_order_acq_rel);
> 
> Whatever was fetched is gone with the wind...

I didn't find an Atomic::or method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127120548
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127122509

From mgronlun at openjdk.org  Wed Jun  4 17:49:28 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 17:49:28 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
 <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
 <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>
Message-ID: <-1_gEsqoLf4kh7TUZbIXh0n4PwcU7_IuaFMedlvMaAM=.27f3a6c4-79f6-4535-912a-9d2e69587a41@github.com>

On Wed, 4 Jun 2025 17:41:46 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 300:
>> 
>>> 298:   if (!Atomic::cmpxchg(&_disenrolled, false, true)) {
>>> 299:     log_trace(jfr)("Disenrolling CPU thread sampler");
>>> 300:     if (Atomic::fetch_then_and(&_signal_handler_installed, false)) {
>> 
>> fetch_then_and with false? Must be simpler way to express this? Like Atomic::load(&_signal_handler_installed)?
>
> I also want to set it. Wanted to do a simple ::xchg, but this doesn't exist for booleans.

1 & 0 -> 0, are you setting _signal_handler_installed to false? Why?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127125344

From iklam at openjdk.org  Wed Jun  4 17:51:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 4 Jun 2025 17:51:55 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <R1F98xQkcJftZWk1FcOC8J4EfRPfoeduDTEJ6T-ziMA=.10d4e52e-2b82-419f-9153-58b52c34f028@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <R1F98xQkcJftZWk1FcOC8J4EfRPfoeduDTEJ6T-ziMA=.10d4e52e-2b82-419f-9153-58b52c34f028@github.com>
Message-ID: <B47In1sYFBd83MudH73j1v3sWJHu8Rs-VTFxTFFMhM0=.84d22f95-521f-4022-a8d0-6a560e23cfae@github.com>

On Wed, 4 Jun 2025 12:13:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test AOTCodeCompressedOopsTest.java has the memory error mentioned above fixed now with recent changes , but shows another issue
> 
> ```
> runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java
> ---------------------------------------------------------------
> java.lang.RuntimeException: Pattern "narrow_oop_base = 0x(\\d+), narrow_oop_shift = (\\d)" not found in the output
> 	at AOTCodeCompressedOopsTest$Tester.checkExecution(AOTCodeCompressedOopsTest.java:184)
> 	at jdk.test.lib.cds.CDSAppTester.executeAndCheck(CDSAppTester.java:221)
> 	at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:427)
> 	at jdk.test.lib.cds.CDSAppTester.productionRun(CDSAppTester.java:392)
> 	at AOTCodeCompressedOopsTest.main(AOTCodeCompressedOopsTest.java:58)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
> 	at java.base/java.lang.Thread.run(Thread.java:1474)
> ```
> 
> Maybe we should ask an AOT expert about this, not sure what that means.

Please file a bug against this test and we will look into it. I haven't used asan before. Is it as simple as adding `--enable-asan` when running `configure`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2940883167

From jbechberger at openjdk.org  Wed Jun  4 17:54:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:54:50 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve disenroll

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/f3ef7908..db093a28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=56-57

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

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

From jbechberger at openjdk.org  Wed Jun  4 17:54:51 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 17:54:51 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v56]
In-Reply-To: <-1_gEsqoLf4kh7TUZbIXh0n4PwcU7_IuaFMedlvMaAM=.27f3a6c4-79f6-4535-912a-9d2e69587a41@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <pX3-Cg-gT_A7579Xq5hrGa4JjCdpo8egQhRJmhAHUck=.54c3b809-2e56-48bd-a14d-61b8ca7dd4d8@github.com>
 <AMa4hLg-L3oGUKZ3-DHdUv0RY9kJWnCHP7Qi38F8B5Y=.e23eb520-1487-421b-a15f-eab29de18432@github.com>
 <OOBWJ_VHdyXAtE5jSb0uoqvTdpMGIkYqqrOo9u66K3o=.5fb29159-3933-4b6a-9c09-0af5313a344c@github.com>
 <-1_gEsqoLf4kh7TUZbIXh0n4PwcU7_IuaFMedlvMaAM=.27f3a6c4-79f6-4535-912a-9d2e69587a41@github.com>
Message-ID: <w13b4jXcmAL9nInnd6wcg8fJUqvH3iYaUPsTvf5wUbU=.7f7c04ac-8848-4438-8189-4a47ee9ab5de@github.com>

On Wed, 4 Jun 2025 17:44:45 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I also want to set it. Wanted to do a simple ::xchg, but this doesn't exist for booleans.
>
> 1 & 0 -> 0, are you setting _signal_handler_installed to false? Why?

You're right, it's not required. I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127135816

From amenkov at openjdk.org  Wed Jun  4 18:15:52 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 4 Jun 2025 18:15:52 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
Message-ID: <hp11TmZXwuFuB0rDzVXOieFwOvUPky3kcfuSMM6s3VI=.b7a4e934-ddeb-4a6b-829c-11bf1686d322@github.com>

On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/`
>  - [x] Linux x86_64 server fastdebug, `jdk_management`

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25638#pullrequestreview-2897668364

From mgronlun at openjdk.org  Wed Jun  4 18:41:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 18:41:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>
Message-ID: <S-OniZT7w7UyZ3mDujAP36jVd2kQ9_xooLYBQtQFNwM=.5489df05-b52d-48a9-be34-b765ddbaadf1@github.com>

On Wed, 4 Jun 2025 11:25:44 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Is this something for a later PR?
>
> I'm OK with fixing this separately.

Please ensure that you file a follow-up issue on this matter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127213771

From jbechberger at openjdk.org  Wed Jun  4 18:57:07 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 18:57:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <S-OniZT7w7UyZ3mDujAP36jVd2kQ9_xooLYBQtQFNwM=.5489df05-b52d-48a9-be34-b765ddbaadf1@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <3ALqkSc9a0HKOJrA6CW61v725SxX8FcLmasC8Wm4y24=.9d40a91c-a77a-442b-926a-e5785032c415@github.com>
 <RToyoNEbwMxwEH0VSDdK4SvBA8kDwGPZTuvxJIIPXIM=.8114ad4d-8ed7-44ba-be3b-cce816967901@github.com>
 <EfT7ohHo7SOvzDrV06Vw3_vQAVDwrwPLpITbSapU1QY=.7a24994a-8bb4-4d1e-94d7-7716c347c08b@github.com>
 <S-OniZT7w7UyZ3mDujAP36jVd2kQ9_xooLYBQtQFNwM=.5489df05-b52d-48a9-be34-b765ddbaadf1@github.com>
Message-ID: <0PjEBxgqHesjNBoyKSYCW6wGcS2GEqujEz79IeWl_LA=.04c24d78-dfb4-4917-bc50-59420548b854@github.com>

On Wed, 4 Jun 2025 18:38:42 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I'm OK with fixing this separately.
>
> Please ensure that you file a follow-up issue on this matter.

Here it is https://bugs.openjdk.org/browse/JDK-8358619

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127234787

From pchilanomate at openjdk.org  Wed Jun  4 18:57:08 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 18:57:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <-YJusSw4Vn4Dx_is7mRjOT6clvj3Uh5F5tcLsPIwUAk=.fda1546c-22b0-4a57-900e-2e752841b617@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <iQ6SDkVlkasgaz4lraZC8gH-ymYydeqVD9zs5XQCB40=.1eb3b380-928d-4def-bbf1-8d8cd7f2f506@github.com>
 <pbMYSGd4w0ABkq0EUOKCMdLdU2XOte4tMibTx8bs7Ww=.2a9e368f-9fe3-43d5-aa1f-dc5a2eb5c575@github.com>
 <-YJusSw4Vn4Dx_is7mRjOT6clvj3Uh5F5tcLsPIwUAk=.fda1546c-22b0-4a57-900e-2e752841b617@github.com>
Message-ID: <EB5u-oWj4DrVtamqPQiPVGUu8bondWxeuIhek1Q15wc=.c0b57a00-9cd4-42cd-a922-2b43e4bc407f@github.com>

On Wed, 4 Jun 2025 17:17:31 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602
>
> I readded the lock.

Thanks, a comment about that would be nice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127239230

From pchilanomate at openjdk.org  Wed Jun  4 18:57:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 18:57:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]
In-Reply-To: <ZFbJAFMki4I2l3iekCNiLgPpQZkROMF2j6GIKjCWkQM=.d285a9cc-5279-4ebb-93f2-3605f4e72c66@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <4_cKaFGWs_Wf0mcRY-lbaEn5i_DJfUoqpaNPhF8E_pw=.b82280fe-ed5b-42f0-85af-6dd15d297ba0@github.com>
 <RtsjAltxBIrQl6wzRs-tE7Q5JvyrltJhW-4gL8HK-VU=.f182b2df-872a-4100-a957-778f61ffa2ed@github.com>
 <ZFbJAFMki4I2l3iekCNiLgPpQZkROMF2j6GIKjCWkQM=.d285a9cc-5279-4ebb-93f2-3605f4e72c66@github.com>
Message-ID: <OVP5JNgJGVXTubPORLoniMjdVkGNxHKKCFfMo_eMEpk=.35e63358-66b8-4028-92c8-3e842bba153a@github.com>

On Wed, 4 Jun 2025 14:39:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 430:
>> 
>>> 428: void JfrCPUTimeThreadSampling::create_sampler(double rate, bool auto_adapt) {
>>> 429:   assert(_sampler == nullptr, "invariant");
>>> 430:   _sampler = new JfrCPUSamplerThread(rate, auto_adapt);
>> 
>> If we start a recording on an already running process we have a race here where a new thread can create and set its timer before we call init_timers() where the signal handler is installed. In that case the program will terminate with message ?Profiling timer expired" (default action for SIGPROF). It can be easily reproduced by adding a delay here and starting a recording on a simple test that just creates new threads. We need to add some extra check in create_timer_for_thread() or install the signal handler earlier.
>
> I created a `has_timer` flag that is checked by `create_timer_for_thread()` before creating timers and set by `init_timers`. Is this what you envisioned?

Thanks, I verified that fixes the issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127238263

From jbechberger at openjdk.org  Wed Jun  4 19:08:40 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:08:40 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v59]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <egSpnuKJNQ-nq2-cEbrQlM3NJpVLONueZDFD_ndCSMw=.1960dabc-743f-4a3d-9bbb-f4f7e4d3a630@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed merge error
 - Add comment regarding Threads_lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/db093a28..b9def278

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=57-58

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

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

From mgronlun at openjdk.org  Wed Jun  4 19:08:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:08:40 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
Message-ID: <y8H18hv3tKC_bm6VRpkDKYBnJdi92B3oCLUVwFrcbdc=.2fd88708-43b5-48f2-a04c-57d01cc16ff5@github.com>

On Wed, 4 Jun 2025 17:54:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve disenroll

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 396:

> 394: }
> 395: 
> 396: class SampleMonitor : public StackObj {

This is a merge error. SampleMonitor is no longer used and can be deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127252688

From apangin at openjdk.org  Wed Jun  4 19:15:09 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 19:15:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
Message-ID: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>

On Wed, 4 Jun 2025 17:54:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve disenroll

src/hotspot/os/posix/signals_posix.cpp line 1511:

> 1509:   struct sigaction oact;
> 1510:   if (sigaction(sig, (struct sigaction*)nullptr, &oact) == -1) {
> 1511:     return nullptr; // signal not installed

A comment is misleading: sigaction does not fail if a handler for the signal is not installed (i.e. the handler is SIG_IGN).

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 656:

> 654:   if ((prev_handler != SIG_DFL && prev_handler != SIG_IGN && prev_handler != (void*)::handle_timer_signal) ||
> 655:       PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == (void*)-1) {
> 656:     log_error(jfr)("CPUTimeSample events will not be recorded: %p", prev_handler);

A message with some random hex address may look cryptic.
Maybe make it a bit more user-friendly? E.g.

Conflicting SIGPROF handler found: %p. CPUTimeSample events will not be recorded

src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 333:

> 331:     }
> 332:   }
> 333:   request._sample_ticks = JfrTicks::now();

For accurate correlation with other events, timestamp of a sample should be taken as early as possible, preferably in the beginning of `JfrCPUSamplerThread::handle_timer_signal`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127222795
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127266822
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127236706

From mgronlun at openjdk.org  Wed Jun  4 19:15:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:15:10 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v59]
In-Reply-To: <egSpnuKJNQ-nq2-cEbrQlM3NJpVLONueZDFD_ndCSMw=.1960dabc-743f-4a3d-9bbb-f4f7e4d3a630@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <egSpnuKJNQ-nq2-cEbrQlM3NJpVLONueZDFD_ndCSMw=.1960dabc-743f-4a3d-9bbb-f4f7e4d3a630@github.com>
Message-ID: <B8Fz0rIS4eUEiJxALgM_AJz_c2Sm5nZBgYi3aGS5m4o=.ba7af8fe-92da-4543-a284-6af834a0a6f4@github.com>

On Wed, 4 Jun 2025 19:08:40 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed merge error
>  - Add comment regarding Threads_lock

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 633:

> 631: 
> 632: void JfrCPUSamplerThread::allow_signal_handlers() {
> 633:   Atomic::release_store(&_active_signal_handlers, (u4)0);

"allow_signal_handlers" is not the best name for this routine - it suggests that by setting _active_signal_handlers = 0, something is enabled - like an inverted Semaphore. But "signal handlers" are allowed for all W of this value, so the 0 has no bearing on enablement.

Just call it "initialize_active_signal_handler_counter" or whatever.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127267710

From mgronlun at openjdk.org  Wed Jun  4 19:18:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:18:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
Message-ID: <3MKLMJ4-eLHkm1qroOSGU2Kvi1pIYkyeZ9unRVbhHAk=.afeb3c4a-4501-4f70-82b6-f293948bc229@github.com>

On Wed, 4 Jun 2025 19:11:16 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve disenroll
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 656:
> 
>> 654:   if ((prev_handler != SIG_DFL && prev_handler != SIG_IGN && prev_handler != (void*)::handle_timer_signal) ||
>> 655:       PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == (void*)-1) {
>> 656:     log_error(jfr)("CPUTimeSample events will not be recorded: %p", prev_handler);
> 
> A message with some random hex address may look cryptic.
> Maybe make it a bit more user-friendly? E.g.
> 
> Conflicting SIGPROF handler found: %p. CPUTimeSample events will not be recorded

Thanks Andrei.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127272864

From jbechberger at openjdk.org  Wed Jun  4 19:24:11 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:24:11 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
Message-ID: <R4LGgPNj7oq6UXVhPoiIbyUYGN-77QA1AyBCaykrYhM=.d6714403-5a79-4f2a-91f5-5fd90967d62e@github.com>

On Wed, 4 Jun 2025 18:44:23 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve disenroll
>
> src/hotspot/os/posix/signals_posix.cpp line 1511:
> 
>> 1509:   struct sigaction oact;
>> 1510:   if (sigaction(sig, (struct sigaction*)nullptr, &oact) == -1) {
>> 1511:     return nullptr; // signal not installed
> 
> A comment is misleading: sigaction does not fail if a handler for the signal is not installed (i.e. the handler is SIG_IGN).

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127281710

From jbechberger at openjdk.org  Wed Jun  4 19:33:08 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:33:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <3MKLMJ4-eLHkm1qroOSGU2Kvi1pIYkyeZ9unRVbhHAk=.afeb3c4a-4501-4f70-82b6-f293948bc229@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
 <3MKLMJ4-eLHkm1qroOSGU2Kvi1pIYkyeZ9unRVbhHAk=.afeb3c4a-4501-4f70-82b6-f293948bc229@github.com>
Message-ID: <c2Tsu1u-evboeTjBHN5mCXW5EWnVUl0s_qJZ7QwPIng=.e26a627f-f769-4833-9e8c-80ce7b0dc147@github.com>

On Wed, 4 Jun 2025 19:15:19 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 656:
>> 
>>> 654:   if ((prev_handler != SIG_DFL && prev_handler != SIG_IGN && prev_handler != (void*)::handle_timer_signal) ||
>>> 655:       PosixSignals::install_generic_signal_handler(SIG, (void*)::handle_timer_signal) == (void*)-1) {
>>> 656:     log_error(jfr)("CPUTimeSample events will not be recorded: %p", prev_handler);
>> 
>> A message with some random hex address may look cryptic.
>> Maybe make it a bit more user-friendly? E.g.
>> 
>> Conflicting SIGPROF handler found: %p. CPUTimeSample events will not be recorded
>
> Thanks Andrei.

Fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127292777

From jbechberger at openjdk.org  Wed Jun  4 19:33:09 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:33:09 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v58]
In-Reply-To: <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <VFxzJu8BMkvDs2Z82OU_9Iko6wt4YsfmPaZvgBJf4J8=.4ce57342-1a59-4324-837f-bef610c85974@github.com>
 <azZKnLIGVEiZmFFp_Q9Fs7YJdeuyQLG6QKQpK-4Ao98=.e8a037f1-af02-4a3d-9674-58a4a611afa3@github.com>
Message-ID: <Zq60I1hpF1JrzH_J2gFnYmg4tdBkIzTHipM-rQ2Ei7A=.3385b1be-d455-4f67-8793-57e79ce0b0e7@github.com>

On Wed, 4 Jun 2025 18:53:35 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve disenroll
>
> src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp line 333:
> 
>> 331:     }
>> 332:   }
>> 333:   request._sample_ticks = JfrTicks::now();
> 
> For accurate correlation with other events, timestamp of a sample should be taken as early as possible, preferably in the beginning of `JfrCPUSamplerThread::handle_timer_signal`

I moved it up:


void JfrCPUSamplerThread::handle_timer_signal(siginfo_t* info, void* context) {
  JfrTicks now = JfrTicks::now();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127294191

From jbechberger at openjdk.org  Wed Jun  4 19:38:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:38:57 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v60]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Improve

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/b9def278..ab2ac459

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=58-59

  Stats: 22 lines in 4 files changed: 5 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25302/head:pull/25302

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

From mgronlun at openjdk.org  Wed Jun  4 19:38:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:38:58 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v42]
In-Reply-To: <hhQ2qjqC1JjLPwC9l7-rGLp8NuUsOvNLN6Iwjn86rPM=.3e5625fa-60b4-4404-b6ed-b1aae6055e67@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <tWqqHd1swXZACS6QLPOAvH1RrsEpoYRUFzCr0u-FQz8=.fc25a19b-5150-4853-bf8b-8e2016224337@github.com>
 <hhQ2qjqC1JjLPwC9l7-rGLp8NuUsOvNLN6Iwjn86rPM=.3e5625fa-60b4-4404-b6ed-b1aae6055e67@github.com>
Message-ID: <0T2FCxivdxhNus6A9_fGcXDNFDLachuVRGgJbixpU_0=.d51a569d-6f68-4dfa-a0cb-ca71c85f9286@github.com>

On Tue, 3 Jun 2025 21:56:41 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename autoadapt
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 360:
> 
>> 358:   tl->set_do_async_processing_of_cpu_time_jfr_requests(false);
>> 359:   if (lock) {
>> 360:     tl->acquire_cpu_time_jfr_dequeue_lock();
> 
> This is your synchronization point on return from native code, which is effectively a spinlock. This can cause problems when a large number of threads are being processed by the "do_async_processing" request call.
> 
> We should fix this as a bug after integration (use a proper Monitor as a synchronization point).

Filed: https://bugs.openjdk.org/browse/JDK-8358621

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127300632

From mgronlun at openjdk.org  Wed Jun  4 19:50:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 19:50:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v60]
In-Reply-To: <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>
Message-ID: <399lO47PUBfDUPjh-Ve1NztHstmkEF24xiJVQe3FRZI=.693af08b-3df9-4ec5-a589-a1c269bb7837@github.com>

On Wed, 4 Jun 2025 19:38:57 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 634:

> 632: 
> 633: void JfrCPUSamplerThread::allow_signal_handlers() {
> 634:   Atomic::release_store(&_initialize_active_signal_handler_counter, (u4)0);

I think we might be getting a bit tired. I meant the function name, not the variable name, which now looks completely bonkers :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127323120

From jbechberger at openjdk.org  Wed Jun  4 19:55:55 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:55:55 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

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

  Renaming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25302/files
  - new: https://git.openjdk.org/jdk/pull/25302/files/ab2ac459..b1689bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=60
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25302&range=59-60

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

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

From jbechberger at openjdk.org  Wed Jun  4 19:55:56 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 19:55:56 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v60]
In-Reply-To: <399lO47PUBfDUPjh-Ve1NztHstmkEF24xiJVQe3FRZI=.693af08b-3df9-4ec5-a589-a1c269bb7837@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <Pa6GPqcv6Uron9rM30l4R0UoBcwgQktdVWfSbxS-uBQ=.fa478854-146b-48eb-8f73-f488aa8c64a1@github.com>
 <399lO47PUBfDUPjh-Ve1NztHstmkEF24xiJVQe3FRZI=.693af08b-3df9-4ec5-a589-a1c269bb7837@github.com>
Message-ID: <v0-iUypGdp4t_wV1Sl8642l4k1qqLCGX3SBjUmynJfY=.edb3b622-947b-46e6-832b-5599e7c5e8ac@github.com>

On Wed, 4 Jun 2025 19:47:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 634:
> 
>> 632: 
>> 633: void JfrCPUSamplerThread::allow_signal_handlers() {
>> 634:   Atomic::release_store(&_initialize_active_signal_handler_counter, (u4)0);
> 
> I think we might be getting a bit tired. I meant the function name, not the variable name, which now looks completely bonkers :-)

Well, I just misunderstood you :D

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127329186

From cjplummer at openjdk.org  Wed Jun  4 20:12:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Jun 2025 20:12:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <PLDiPQZ6sWQHLo0TyayUwGc_uOvtmzCkLxi7j9_m2Y0=.f5ec35bc-d437-4a87-a30a-96bafa7d3202@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

serviceability/sa/ClhsdbCDSCore.java explicitly says it did not create a core file:

`# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again`

Is there a similar message for serviceability/sa/ClhsdbFindPC.java? What about all the other SA core file tests? Here's a list of all the SA core file tests:

serviceability/sa/ClhsdbCDSCore.java
serviceability/sa/ClhsdbFindPC.java#xcomp-core
serviceability/sa/ClhsdbFindPC.java#no-xcomp-core
serviceability/sa/ClhsdbPmap.java#core
serviceability/sa/ClhsdbPstack.java#core
serviceability/sa/TestJmapCore.java
serviceability/sa/TestJmapCoreMetaspace.java

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2941326294

From mdoerr at openjdk.org  Wed Jun  4 20:48:07 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Jun 2025 20:48:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <8jQ9fsDS_OZA6WYBEy5Rf9WPfZaZJQB1zWB53iHt5i8=.6ebbb1cc-0c6f-4699-88cc-f93e8d9b5a82@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898056841

From apangin at openjdk.org  Wed Jun  4 21:22:07 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Wed, 4 Jun 2025 21:22:07 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <XCwuyt6sbF1TRpAlRnYbhyfhFcklUQNhHs5kRPpbVSA=.f20da6e8-ab56-474b-8bc5-0f3fa0e3b190@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

Marked as reviewed by apangin (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898137302

From mgronlun at openjdk.org  Wed Jun  4 21:47:08 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 21:47:08 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <-H5MPWW5BYrLTBLZIGu8PRcWUw9LxZoLpapnZaDy5ts=.295d136b-d764-4a73-b334-4fb51295a580@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

I am waiting for the basic CI pre-tests to come back green before I approve for integration.

No sweat, the cutoff is in CST :) and branching usually happens later in the day.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941623120

From mgronlun at openjdk.org  Wed Jun  4 22:02:19 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <qrpqeC2JySjI92oILasDkHzE74ERl5EsyOlTJydehoo=.35d0b5b7-6301-4010-8253-e40bef2d54a2@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

Ship it!

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898222436

From pchilanomate at openjdk.org  Wed Jun  4 22:02:19 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <WgIJMhy2pI48a5mUKABBZ4IYe4gi_-tR-z9mdbuVtyU=.1083df29-6522-47c0-82c6-6a1c5b1fce46@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25302#pullrequestreview-2898222664

From jbechberger at openjdk.org  Wed Jun  4 22:02:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <wW9xJ2Att2cQVPqn6-2MAegC7XZQOBFaLkf68a-InzM=.adf7bf15-01fb-40c0-86ec-4dae315a8318@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

I know, but I want to get over it today(ish).

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941671138

From mgronlun at openjdk.org  Wed Jun  4 22:02:19 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:02:19 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <wW9xJ2Att2cQVPqn6-2MAegC7XZQOBFaLkf68a-InzM=.adf7bf15-01fb-40c0-86ec-4dae315a8318@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
 <wW9xJ2Att2cQVPqn6-2MAegC7XZQOBFaLkf68a-InzM=.adf7bf15-01fb-40c0-86ec-4dae315a8318@github.com>
Message-ID: <TLbiEpISmb02-dK-zpLS3aC5Ev0xf13_jbwLDpOfXJg=.895bb82e-8604-4b30-8d57-fd888df7cd41@github.com>

On Wed, 4 Jun 2025 21:56:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> I know, but I want to get over it today(ish).

Go for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941686873

From mgronlun at openjdk.org  Wed Jun  4 22:13:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:13:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <FeE4FA6dSkjoI3Vfgcga7fgCYoSrMwNvxeEbAQK0CfM=.aa19f73a-db08-4a11-94c9-ba741933a5e3@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

Well done - now take some well-deserved rest. I'll monitor the first stages of integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941716415

From jbechberger at openjdk.org  Wed Jun  4 22:13:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 22:13:17 GMT
Subject: Integrated: 8342818: Implement JEP 509: JFR CPU-Time Profiling
In-Reply-To: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
Message-ID: <mnW0AmpnqC8dY3sh7GWbniO42ze334iCntCMS1GbLkc=.bc5dea65-d9ff-4ad3-b268-439a337f5d5f@github.com>

On Mon, 19 May 2025 13:02:20 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
> 
> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
> - ... different heap sizes
> - ... different GCs
> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
> - ... different JFR recording durations
> - ... different chunk-sizes

This pull request has now been integrated.

Changeset: 5b27e9c2
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b27e9c2df8b386b38b0553d941469cd8aa65c28
Stats:     2306 lines in 41 files changed: 2166 ins; 128 del; 12 mod

8342818: Implement JEP 509: JFR CPU-Time Profiling

Reviewed-by: mgronlun, mdoerr, pchilanomate, apangin, shade

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

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

From jbechberger at openjdk.org  Wed Jun  4 22:13:14 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 4 Jun 2025 22:13:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <fWKHOsBA-9c_hob8Z4CGogYpHKDV3sNqVAZbbKM3mgk=.96f37338-270f-4e6c-b52d-5d1c34cf3e94@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

So I'm just waiting for Skara?

Thanks, good night.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941707891
PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941716783

From mgronlun at openjdk.org  Wed Jun  4 22:13:14 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:13:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <fWKHOsBA-9c_hob8Z4CGogYpHKDV3sNqVAZbbKM3mgk=.96f37338-270f-4e6c-b52d-5d1c34cf3e94@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
 <fWKHOsBA-9c_hob8Z4CGogYpHKDV3sNqVAZbbKM3mgk=.96f37338-270f-4e6c-b52d-5d1c34cf3e94@github.com>
Message-ID: <m7lgHs2_834A1QBgXeED4Ukmuk26Xc2mD_6EVEl7XVY=.73e37dd4-6dbf-4abb-99d5-00db64cf18a0@github.com>

On Wed, 4 Jun 2025 22:06:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> So I'm just waiting for Skara?

You can issue the integrate command.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941709310

From mgronlun at openjdk.org  Wed Jun  4 22:47:15 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 22:47:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <oDXY2fuWGwTGWO_zRI5zIK4LlxlOxZbk5RNn6UwyND0=.c1a29d46-bd0f-4ead-a3db-78ecdaf32ffc@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

Hope you have not got to sleep yet:

jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2941820906

From dholmes at openjdk.org  Wed Jun  4 23:57:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Jun 2025 23:57:56 GMT
Subject: RFR: 8358628: [BACKOUT] 8342818: Implement JEP 509: JFR CPU-Time
 Profiling
In-Reply-To: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
References: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
Message-ID: <62oqwYVSGqRO_SeQhJ7Ylhgo9Y_M6fbTDVLYSkb8cK4=.95eba6bd-99ae-41ad-86e3-51cfcf16b0cd@github.com>

On Wed, 4 Jun 2025 23:38:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This reverts commit 5b27e9c2df8b386b38b0553d941469cd8aa65c28.
> 
> There are too many strange issues appearing, memory allocation corruptions, and also some strange activation of the feature that is yet not understood.
> 
> We should back it out as to not block other integrations while we troubleshoot.
> 
> Thanks
> Markus

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25649#pullrequestreview-2898378246

From mgronlun at openjdk.org  Wed Jun  4 23:57:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 4 Jun 2025 23:57:56 GMT
Subject: Integrated: 8358628: [BACKOUT] 8342818: Implement JEP 509: JFR
 CPU-Time Profiling
In-Reply-To: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
References: <fIej6Rk9gpbqrZpqfLYt04rujkfWa6x3HjFQy0QrdtE=.2e9b4f38-4e26-4fab-8665-3258e980edb7@github.com>
Message-ID: <aX9zWDpcxvKsKLTQLBZkTNyAr6VB8OwAbl99tm1LQDw=.f6f2b207-dc21-4057-9876-d8ceed5b2485@github.com>

On Wed, 4 Jun 2025 23:38:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> This reverts commit 5b27e9c2df8b386b38b0553d941469cd8aa65c28.
> 
> There are too many strange issues appearing, memory allocation corruptions, and also some strange activation of the feature that is yet not understood.
> 
> We should back it out as to not block other integrations while we troubleshoot.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 9186cc73
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9186cc7310c0cca2fca776031280f08d84e43b74
Stats:     2306 lines in 41 files changed: 128 ins; 2166 del; 12 mod

8358628: [BACKOUT] 8342818: Implement JEP 509: JFR CPU-Time Profiling

Reviewed-by: pchilanomate, dholmes

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

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

From dholmes at openjdk.org  Thu Jun  5 01:12:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Jun 2025 01:12:14 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <q8sSGxGGdHFo58B9HfLmqNdguipXeMdKO2pGs60jYxk=.e236d467-195f-4537-9498-1e0b8733a35e@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 88:

> 86:       return false;
> 87:     }
> 88:   } while (Atomic::cmpxchg(&_head, elementIndex, elementIndex + 1) != elementIndex);

Why do we need atomic operations if we hold the enqueue lock. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127755502

From syan at openjdk.org  Thu Jun  5 03:17:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Jun 2025 03:17:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <vjAr_e63KTka8aIckhbj1pdVyoj43W9zE_Y00mqrxK0=.625de0dc-8829-4780-81ff-e757f2a7af75@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

Changes requested by syan (Committer).

src/hotspot/share/prims/whitebox.cpp line 1100:

> 1098: #endif
> 1099: 
> 1100: bool WhiteBox::is_asan_enabled() {

Does we need `bool WhileBox::is_lsan_enable()` to check '--enable-lsan           enable LeakSanitizer' enable or not

test/hotspot/jtreg/TEST.ROOT line 94:

> 92:     vm.compiler2.enabled \
> 93:     vm.musl \
> 94:     vm.asan \

Do we need `vm.lsan`

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2898739689
PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2127856663
PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2127857129

From jbechberger at openjdk.org  Thu Jun  5 05:05:22 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 5 Jun 2025 05:05:22 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <q8sSGxGGdHFo58B9HfLmqNdguipXeMdKO2pGs60jYxk=.e236d467-195f-4537-9498-1e0b8733a35e@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
 <q8sSGxGGdHFo58B9HfLmqNdguipXeMdKO2pGs60jYxk=.e236d467-195f-4537-9498-1e0b8733a35e@github.com>
Message-ID: <MnqN0CjSc_S7gfhNxvkf-y7aodI4RXsLBRjmgFhNj3I=.57da8ad9-5b90-462d-88dd-376d69260417@github.com>

On Thu, 5 Jun 2025 01:09:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renaming
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 88:
> 
>> 86:       return false;
>> 87:     }
>> 88:   } while (Atomic::cmpxchg(&_head, elementIndex, elementIndex + 1) != elementIndex);
> 
> Why do we need atomic operations if we hold the enqueue lock. ??

Valid Point, I was probably over cautious.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127957148

From jbechberger at openjdk.org  Thu Jun  5 05:13:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 5 Jun 2025 05:13:15 GMT
Subject: RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v61]
In-Reply-To: <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
References: <NiDKGaDwQlAbiUHT75EScb1S6N85gmrJGg1nNQdCvUA=.a3473897-9bd4-4edb-990e-d8716a4fccd8@github.com>
 <jsaOPuywadj9c9ykZhsWNPWTJO6ck_OLsN2KO97RqEw=.1e56cd27-0d5e-4c1a-942e-5d80646a9c17@github.com>
Message-ID: <nJIkdkY3xwM4SvuI0dxIYGYXhkR1WdYa30V5rlJWqro=.b24ebfa3-77b6-43b7-b8a6-9c3ecafbb521@github.com>

On Wed, 4 Jun 2025 19:55:55 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renaming

I'm on it, darn.

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

PR Comment: https://git.openjdk.org/jdk/pull/25302#issuecomment-2942770368

From iklam at openjdk.org  Thu Jun  5 05:20:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 5 Jun 2025 05:20:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
Message-ID: <dN2E6XXlPFGqYLQ-2lrh_RCUJPpGDs98Iw7o9CE_52U=.26719e6d-c97c-4ea2-b088-e9039cf9eec7@github.com>

On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Moved jtreg test
>  - Improved documentation
>  - Fix coding style (asterisk placement)

I have written a POC that shows that the table must be sorted again when dumping a dynamic CDS archive. See https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f

Explanations are in [here](https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f#diff-fd7608607ecf305bb3535b500bff5d53ec216d2da25e3bad1a1d699f56b09283R199)

I will create an RFE for the JDK mainline that adds built-in debugging support for the `(oldSym > newSym_orig)` condition as describe in the POC. Please wait for that before integrating this PR. I can help you write the code for re-sorting the tables.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2942786527

From vyazici at openjdk.org  Thu Jun  5 05:51:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 05:51:55 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>
Message-ID: <vbkzLujju3ftu2UcPbudkR20YRTnLlgtTtRzsasVEpU=.6828f0da-7002-4ac2-ac89-ff728884ea42@github.com>

On Tue, 3 Jun 2025 18:08:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> That's not going to be sufficient. The nsk tests are not being run until tier5.

@plummercj, I've attached the `tier3,4,5` run report to the ticket, would you mind reviewing them, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2942851679

From mbaesken at openjdk.org  Thu Jun  5 05:52:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 05:52:51 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <uAT9uPSfHfIK4X8kJ_SLjLiFsgdgdNNPAPPXUemb5UA=.a77026cf-271a-4b89-9409-15a8f046558f@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

> Do we need vm.lsan

I worked a bit with ubsan and asan in recent months (and with MSAN https://clang.llvm.org/docs/MemorySanitizer.html too but that is not yet supported in OpenJDK).
Regarding LSAN I haven't looked into it. Maybe we can add this later if needed, I would restrict this PR to asan/ubsan .

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2942852876

From mbaesken at openjdk.org  Thu Jun  5 06:11:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 06:11:51 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <B47In1sYFBd83MudH73j1v3sWJHu8Rs-VTFxTFFMhM0=.84d22f95-521f-4022-a8d0-6a560e23cfae@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <R1F98xQkcJftZWk1FcOC8J4EfRPfoeduDTEJ6T-ziMA=.10d4e52e-2b82-419f-9153-58b52c34f028@github.com>
 <B47In1sYFBd83MudH73j1v3sWJHu8Rs-VTFxTFFMhM0=.84d22f95-521f-4022-a8d0-6a560e23cfae@github.com>
Message-ID: <qMa4275Y5KLH_chMmOKb6aE8Mtqt-Lml-H8YnzAfhuk=.83fe8c5a-59ec-4ecc-a258-33987bd85114@github.com>

On Wed, 4 Jun 2025 17:48:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>Please file a bug against this test and we will look into it. 

Thanks, I created https://bugs.openjdk.org/browse/JDK-8358654 .

>I haven't used asan before. Is it as simple as adding --enable-asan when running configure?

On my Ubuntu and RHEL Linux with gcc yes , it is that simple  (besides installing the asan package with OS package manager).
On SUSE Linux it was a little tricky because of some strange issues with the network stack, but it works too there  (see https://bugs.openjdk.org/browse/JDK-8356970 ).  So it depends a little on the distro but mostly it works fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2942895056

From mbaesken at openjdk.org  Thu Jun  5 06:51:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 06:51:51 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <vjAr_e63KTka8aIckhbj1pdVyoj43W9zE_Y00mqrxK0=.625de0dc-8829-4780-81ff-e757f2a7af75@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <vjAr_e63KTka8aIckhbj1pdVyoj43W9zE_Y00mqrxK0=.625de0dc-8829-4780-81ff-e757f2a7af75@github.com>
Message-ID: <jzWJ27VXHUXINlrxnsdBWAVrs8T_i6A2VIX2b7Y1xJw=.362a15b2-486a-4c4b-bfa1-35a3927e68fe@github.com>

On Thu, 5 Jun 2025 03:14:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBreakSignalThreadDump has issues with asan
>
> test/hotspot/jtreg/TEST.ROOT line 94:
> 
>> 92:     vm.compiler2.enabled \
>> 93:     vm.musl \
>> 94:     vm.asan \
> 
> Do we need `vm.lsan`

Maybe later in a separate PR .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2128081241

From mbaesken at openjdk.org  Thu Jun  5 06:58:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 06:58:33 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v3]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <r8-xhqR7KRZ_0618i4K3WrpNlO_C0OnTJ6SVY_caXf4=.9072f953-ffe2-49c2-93ca-640131e216c1@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  AOTCodeCompressedOopsTest will be handled separately

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/aa796c8a..8b9e3dde

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

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

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

From mbaesken at openjdk.org  Thu Jun  5 07:00:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 07:00:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
Message-ID: <K6urgTEp1hOSXjIx8jaJ89Aav0Cx2cQZR24E36BKDcI=.46940d9f-30ae-4ee4-966d-5861699aa8c8@github.com>

On Mon, 2 Jun 2025 08:07:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBreakSignalThreadDump has issues with asan

I removed the added requires from AOTCodeCompressedOopsTest because we will look into this separately in https://bugs.openjdk.org/browse/JDK-8358654 .

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2942989553

From mbaesken at openjdk.org  Thu Jun  5 07:06:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Jun 2025 07:06:51 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <PLDiPQZ6sWQHLo0TyayUwGc_uOvtmzCkLxi7j9_m2Y0=.f5ec35bc-d437-4a87-a30a-96bafa7d3202@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <PLDiPQZ6sWQHLo0TyayUwGc_uOvtmzCkLxi7j9_m2Y0=.f5ec35bc-d437-4a87-a30a-96bafa7d3202@github.com>
Message-ID: <y_gabn1yyGAgNBQ4lg8nbr2IeTgSadHj2hvmS7XvINU=.9364f8d9-f3eb-4135-9dc6-7b11078fb4c7@github.com>

On Wed, 4 Jun 2025 20:09:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> serviceability/sa/ClhsdbCDSCore.java explicitly says it did not create a core file

The test passes with asan enabled on Linux ppc64le , so probably the failure seen on Linux x86_64 was more machine/environment related than ASAN related ; should I better remove the asan requires from this test ?

Regarding the other serviceability/sa tests you mentioned, seems they work too on Linux ppc64le so they **_can_** work with ASAN , no requires needed for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2943002454

From aturbanov at openjdk.org  Thu Jun  5 09:03:53 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:03:53 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
Message-ID: <Dgsv_uSz55K8txQhEFMYlV1LO2pK9uce85qifdv21hA=.7a279770-1103-4140-a3b2-15503dbb80e8@github.com>

On Tue, 3 Jun 2025 07:55:06 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing `java.io.Reader` import in `Ktab`

test/jdk/com/sun/jdi/MultiBreakpointsTest.java line 181:

> 179: 
> 180:                 }
> 181:             } catch(Exception e) {

Suggestion:

            } catch (Exception e) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2128325755

From shade at openjdk.org  Thu Jun  5 09:04:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 09:04:55 GMT
Subject: RFR: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
Message-ID: <LlhTr1JPepe1TLSF5ZCWbEGV5PXV7xsNt1Dxo5jsPs8=.8c132dde-8601-45e7-a0f4-236a621da15f@github.com>

On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/`
>  - [x] Linux x86_64 server fastdebug, `jdk_management`

Thank you! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25638#issuecomment-2943344344

From shade at openjdk.org  Thu Jun  5 09:04:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 09:04:55 GMT
Subject: Integrated: 8358588: ThreadSnapshot.ThreadLock should be static nested
 class
In-Reply-To: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
References: <yl_murI005bnuwvL1KcpN7jmXlbkivSD69yvW9jldGU=.a1d787d3-16e9-4e18-a3f5-5e0cfcde0a0c@github.com>
Message-ID: <WuA_5iUTmp9rukADzVLqXGIATmjF6sR6HQWsL_haElc=.4910c95e-ac0a-4783-8483-b0c42ea51736@github.com>

On Wed, 4 Jun 2025 12:03:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud points out that ThreadLock class introduced by [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into static nested class. I don't think this shows any real bug yet, as unreferenced enclosing class reference gets nowhere. But it would be nice to be extra crisp here.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `serviceability/`
>  - [x] Linux x86_64 server fastdebug, `jdk_management`

This pull request has now been integrated.

Changeset: dc949003
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc949003ded278805d10c7b630e82348a7d998fe
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358588: ThreadSnapshot.ThreadLock should be static nested class

Reviewed-by: alanb, sspitsyn, amenkov

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

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

From vyazici at openjdk.org  Thu Jun  5 10:13:24 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 10:13:24 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Improve code style
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/78e8de51..92248bb3

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

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

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

From cjplummer at openjdk.org  Thu Jun  5 15:16:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Jun 2025 15:16:54 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <vbkzLujju3ftu2UcPbudkR20YRTnLlgtTtRzsasVEpU=.6828f0da-7002-4ac2-ac89-ff728884ea42@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <GR3wh8a2B_z1CpWtg7yCSsoQV7gZjFAIa1u2us25V84=.718285c6-7e80-4e1b-a4b3-491a22246ab9@github.com>
 <vbkzLujju3ftu2UcPbudkR20YRTnLlgtTtRzsasVEpU=.6828f0da-7002-4ac2-ac89-ff728884ea42@github.com>
Message-ID: <RyB3WpHjKcAKlg9gtxQr6lMp75rwhVazXVMKbroecRs=.29c16890-221e-47d8-ae3b-d9f7e25ceaec@github.com>

On Thu, 5 Jun 2025 05:49:18 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> > That's not going to be sufficient. The nsk tests are not being run until tier5.
> 
> @plummercj, I've attached the `tier3,4,5` run report to the ticket, would you mind reviewing them, please?

Looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2944947156

From cjplummer at openjdk.org  Thu Jun  5 15:16:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Jun 2025 15:16:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <y_gabn1yyGAgNBQ4lg8nbr2IeTgSadHj2hvmS7XvINU=.9364f8d9-f3eb-4135-9dc6-7b11078fb4c7@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <PLDiPQZ6sWQHLo0TyayUwGc_uOvtmzCkLxi7j9_m2Y0=.f5ec35bc-d437-4a87-a30a-96bafa7d3202@github.com>
 <y_gabn1yyGAgNBQ4lg8nbr2IeTgSadHj2hvmS7XvINU=.9364f8d9-f3eb-4135-9dc6-7b11078fb4c7@github.com>
Message-ID: <ppHHbzXr8tzZAtE5u96FP-jRzFJi39v55V1jA1t88Bs=.fd006cff-f400-4890-922a-16dac7a65ebf@github.com>

On Thu, 5 Jun 2025 07:04:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > serviceability/sa/ClhsdbCDSCore.java explicitly says it did not create a core file
> 
> The test passes with asan enabled on Linux ppc64le , so probably the failure seen on Linux x86_64 was more machine/environment related than ASAN related ; should I better remove the asan requires from this test ?

I just think it is odd that this test failed to produce a core file, but the other core file tests passed. It's also unclear to me why serviceability/sa/ClhsdbFindPC.java failed. You didn't include enough of the .jtr file.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2944945645

From sspitsyn at openjdk.org  Thu Jun  5 17:05:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 5 Jun 2025 17:05:51 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <LOvVAvQXHKLk4bqBxNG4whAXfKzevmb7g_Iv2URNZT0=.ac11e579-5cfa-450c-88d9-b58436e6d41f@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

Looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25542#pullrequestreview-2901163257

From coleenp at openjdk.org  Thu Jun  5 20:40:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Jun 2025 20:40:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v20]
In-Reply-To: <chn4VYP2pY1Exufkwbg7Syf5hsJkEL02DKqBjGNdNxw=.23e67ff9-02a1-4baf-8915-0ed7c3f76ca0@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>
 <f7QBWD5FyOM_VNGVrOnJHvF014lpehRQteTsah8GTPg=.dbb085c8-dbfb-4611-a9f5-332b7ed5aabd@github.com>
 <sQsU-pujWZmu5HX-UDABwPI5ZW_bjMycXPwkUGicKxk=.3935e052-920f-4e94-8921-cfb6037bf9b0@github.com>
 <chn4VYP2pY1Exufkwbg7Syf5hsJkEL02DKqBjGNdNxw=.23e67ff9-02a1-4baf-8915-0ed7c3f76ca0@github.com>
Message-ID: <P4WXscvgdWvboAlQMuQUeVgh_CDHc9teNXyQAhn3rqs=.8dccbcb7-f9f8-4a7d-aabc-454f1a851790@github.com>

On Tue, 3 Jun 2025 05:51:38 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Can you explain somewhere how fields are mapped to this?  I assume they're sorted, for some reason I expected the packed table to be {name-cp-index, sig-cp-index, offset-in-fieldstream-for-direct-access}.  Does every field get 4 ints ?  So why is it packed into ```Array<u1>``` rather than just use ```Array<u4>```?  So much packing code that I don't know how anyone could ever debug it.
>
> Yes, in practice these all are of the same size, but in case of the masks (as well as in case of arguments in API) I want to stress out that these are 32 bit numbers. The `unsigned int`s are just 'some not too big number'.
> Is there any general guidance on deciding between `unsigned int` (I suppose just `unsigned` is not recommended), `uint32_t` and `u4`?
> 
> I was hoping that the comment on line 68 explains the intended use, but I can be more verbose and document each method. When the packed table is used for fieldinfo, it's { offset-in-fieldstream, index-in-fieldstream }. The Comparator implementation can translate offset-in-fieldstream -> { name, signature } and then do the comparison. The `index-in-fieldstream` is kind of second-class citizen; we need to fill it into `FieldInfo` and it is not encoded in the stream, therefore we need to encode it in the packed table.

Reading further, I see what this mapping is and intentionally generalized.  I guess a comment like, the key and value are sized to represent the maximum value for each and then compacted, or something like that.  But maybe I haven't figured out the packing.  Are they increments of u1, u2 or u4 or something in between?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130268911

From coleenp at openjdk.org  Thu Jun  5 20:40:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Jun 2025 20:40:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
Message-ID: <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>

On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Moved jtreg test
>  - Improved documentation
>  - Fix coding style (asterisk placement)

With a lot of reading, this looks reasonable, but I still have many questions.

I'm also testing this with tier1-7.

src/hotspot/share/oops/fieldInfo.cpp line 137:

> 135:   int position;
> 136: } field_pos_t;
> 137: field_pos_t* positions = nullptr;

This is unused.

src/hotspot/share/oops/fieldInfo.cpp line 164:

> 162:   r.read_field_counts(&java_fields, &injected_fields);
> 163:   assert(java_fields >= 0, "must be");
> 164:   if (java_fields == 0 || fis->length() == 0 || static_cast<uint>(java_fields) < BinarySearchThreshold) {

I don't know why you only sort Java fields and ignore the injected fields.  JavaClasses::compute_offsets calls find_local_field, so might not find an injected field, I assume in the java.lang.Class (mirror).  Should this sorted cache exclude classes with injected fields? ie if injected_fields > 0?
If you exclude classes with injected fields, you could remove the javaClasses code (and maybe not have to re-sort any fields during dynamic dumping (?))

src/hotspot/share/oops/fieldInfo.cpp line 173:

> 171:   PackedTableBuilder builder(fis->length() - 1, java_fields - 1);
> 172: 
> 173:   Array<u1>* table = MetadataFactory::new_array<u1>(loader_data, java_fields * builder.element_bytes(), CHECK_NULL);

Since this isn't used until you fill the table, can you move this down to just before the 'fill' call?

src/hotspot/share/oops/fieldInfo.cpp line 285:

> 283:     FieldInfo fi;
> 284:     reader.read_field_info(fi);
> 285:     if (fi.field_flags().is_injected()) {

I thought that above, you only process java fields and not the injected fields?

src/hotspot/share/oops/fieldInfo.hpp line 225:

> 223: // Gadget for decoding and reading the stream of field records.
> 224: class FieldInfoReader {
> 225:   UNSIGNED5::Reader<const u1*, int> _r;

I don't like this name _r but it's not your change.

src/hotspot/share/oops/fieldInfo.hpp line 238:

> 236: 
> 237:   private:
> 238:   uint32_t next_uint() { return _r.next_uint(); }

Why did you make this change and have the callers expose _r ?

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2901503494
PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2946136847
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2129643750
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2129856223
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2129865720
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2129890059
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130217134
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130238145

From rvansa at openjdk.org  Thu Jun  5 20:55:03 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Jun 2025 20:55:03 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
Message-ID: <4YvUnJZ6lk5sJbTScP2_oX43fcbMKWatEkfiXSFEhsM=.f8a3afd9-c896-49db-9f13-6f651cf7795c@github.com>

On Thu, 5 Jun 2025 18:54:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Moved jtreg test
>>  - Improved documentation
>>  - Fix coding style (asterisk placement)
>
> src/hotspot/share/oops/fieldInfo.cpp line 164:
> 
>> 162:   r.read_field_counts(&java_fields, &injected_fields);
>> 163:   assert(java_fields >= 0, "must be");
>> 164:   if (java_fields == 0 || fis->length() == 0 || static_cast<uint>(java_fields) < BinarySearchThreshold) {
> 
> I don't know why you only sort Java fields and ignore the injected fields.  JavaClasses::compute_offsets calls find_local_field, so might not find an injected field, I assume in the java.lang.Class (mirror).  Should this sorted cache exclude classes with injected fields? ie if injected_fields > 0?
> If you exclude classes with injected fields, you could remove the javaClasses code (and maybe not have to re-sort any fields during dynamic dumping (?))

I don't build a search table for injected fields because I am trying to fix performance of `InstanceKlass::find_local_field` and this uses `JavaFieldStream` - that is/was ignoring injected fields in the iteration as well.
Classes with injected fields are not excluded, we just don't build the table for them. There's not lookup by name+signature, just `InstanceKlass::field(int index)` which uses iteration through `AllFieldStream`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130327017

From rvansa at openjdk.org  Thu Jun  5 21:04:55 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Jun 2025 21:04:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
Message-ID: <eSuxz_dogVarq3hbPZaNu_oM02lw-XTlkk906oTxA0c=.d68a7761-344b-494b-b7cc-ced3e7fb333d@github.com>

On Thu, 5 Jun 2025 19:02:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Moved jtreg test
>>  - Improved documentation
>>  - Fix coding style (asterisk placement)
>
> src/hotspot/share/oops/fieldInfo.cpp line 285:
> 
>> 283:     FieldInfo fi;
>> 284:     reader.read_field_info(fi);
>> 285:     if (fi.field_flags().is_injected()) {
> 
> I thought that above, you only process java fields and not the injected fields?

`FieldInfoReader` is limited by the full stream, and after iterating through java fields it would start returning injected fields. For java fields we call the lookup below; we know that injected fields don't have a record in the table, and we know that there won't be any more java fields after we encounter the first injected field; that's why we `break` the cycle here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130366971

From rvansa at openjdk.org  Thu Jun  5 21:10:01 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Jun 2025 21:10:01 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
Message-ID: <YQM_PWRF3JSOetjFaZz-EEkQ-BRoi1yKA54BrMO1Zng=.0ebbbcf6-3190-49c5-a4f7-5ae2883e1f53@github.com>

On Thu, 5 Jun 2025 20:28:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Moved jtreg test
>>  - Improved documentation
>>  - Fix coding style (asterisk placement)
>
> src/hotspot/share/oops/fieldInfo.hpp line 238:
> 
>> 236: 
>> 237:   private:
>> 238:   uint32_t next_uint() { return _r.next_uint(); }
> 
> Why did you make this change and have the callers expose _r ?

AFAIU `_r` is not exposed, it's private. My change removes `next_uint()` because it's at wrong level of abstraction: `FieldInfoReader` should expose things java/injected fields counts (and field info itself), not just some 'uint's.
The encapsulation is imperfect as the methods have to be called anyway only in the correct order but to me it seemed as a way forward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130383028

From rvansa at openjdk.org  Thu Jun  5 21:25:56 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Jun 2025 21:25:56 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
Message-ID: <JiB_h6J0U_qTPvPakZtHCv-s_On0Vmz77fONo3NTNl8=.389655b1-0410-4eb1-a5e3-c9dc7356494c@github.com>

On Tue, 3 Jun 2025 07:16:47 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Moved jtreg test
>  - Improved documentation
>  - Fix coding style (asterisk placement)

> Reading further, I see what this mapping is and intentionally generalized. I guess a comment like, the key and value are sized to represent the maximum value for each and then compacted, or something like that. But maybe I haven't figured out the packing. Are they increments of u1, u2 or u4 or something in between?

>From the constructor that accepts the maximum number for each we figure out the number of bits required to store those numbers. Imagine that only as bits (not aligned to byte boundary... yet). Then we concatenate the bits for key and value, and then 'add' 1-7 padding zeroes (high-order bits) to align on bytes. So in the end we have each element in the table consuming 1-8 bytes (case with 0 bits for both key and value is ruled out). In case of the fields search table, the key will be at most the stream length (which in turn has at most 65536 fields and each occupies up to 8 varints which is <= 40 bytes, though normally far less) and value is at most 65535 (# fields in class) so this is 1-5 bytes.

I thought that the presence of `max_key` and `max_value` in constructors along with the comment on `PackedTableBase` saying

> Each element consists of **up to** 32-bit key, and **up to** 32-bit value; these are **packed into a bit-record** with 1-byte alignment.

pretty much says that - shall I place extra comments somewhere else?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2946329561

From rvansa at openjdk.org  Thu Jun  5 21:32:50 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Jun 2025 21:32:50 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v22]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <jvr5EUKE5HgbtdxSiy1X24ihVIyEyrpg1TONPeYj5TU=.c420b90c-2b3c-46da-a364-925e605ab5e6@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Removed extra global var and moved the allocation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/862b264b..14e00d0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=20-21

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

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

From rvansa at openjdk.org  Thu Jun  5 21:32:51 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 5 Jun 2025 21:32:51 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
Message-ID: <BeRrrzIAjPVRRdixU_MYDBzdFQ1zxT1wHltIxdd_M6A=.f3c51a9f-a59d-4dd4-b0af-5e779d6eb3ac@github.com>

On Thu, 5 Jun 2025 18:04:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Moved jtreg test
>>  - Improved documentation
>>  - Fix coding style (asterisk placement)
>
> src/hotspot/share/oops/fieldInfo.cpp line 137:
> 
>> 135:   int position;
>> 136: } field_pos_t;
>> 137: field_pos_t* positions = nullptr;
> 
> This is unused.

Oops, copy-paste error. Thanks for spotting this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2130466647

From coleenp at openjdk.org  Thu Jun  5 21:44:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Jun 2025 21:44:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v22]
In-Reply-To: <jvr5EUKE5HgbtdxSiy1X24ihVIyEyrpg1TONPeYj5TU=.c420b90c-2b3c-46da-a364-925e605ab5e6@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <jvr5EUKE5HgbtdxSiy1X24ihVIyEyrpg1TONPeYj5TU=.c420b90c-2b3c-46da-a364-925e605ab5e6@github.com>
Message-ID: <xAWY4IXnBq50lahAWniW0GGY-ydEI5rE59DqTkyyNk0=.3baf3930-1021-4a07-a442-4c086f892bd2@github.com>

On Thu, 5 Jun 2025 21:32:50 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed extra global var and moved the allocation

Your explanation above really helps.  Can you add that to above the PackedTableBase constructor?  It's easier to understand in prose than reading this constructor even though it's short.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2946409749

From coleenp at openjdk.org  Thu Jun  5 22:16:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Jun 2025 22:16:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <dN2E6XXlPFGqYLQ-2lrh_RCUJPpGDs98Iw7o9CE_52U=.26719e6d-c97c-4ea2-b088-e9039cf9eec7@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <dN2E6XXlPFGqYLQ-2lrh_RCUJPpGDs98Iw7o9CE_52U=.26719e6d-c97c-4ea2-b088-e9039cf9eec7@github.com>
Message-ID: <-fNueN0qDKvh7hmAhaqWAvutzLWlPzu6O0gWgQSFVkY=.be36c9ac-671d-4e81-86d1-03b46fc52785@github.com>

On Thu, 5 Jun 2025 05:17:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Moved jtreg test
>>  - Improved documentation
>>  - Fix coding style (asterisk placement)
>
> I have written a POC that shows that the table must be sorted again when dumping a dynamic CDS archive. See https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f
> 
> Explanations are in [here](https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f#diff-fd7608607ecf305bb3535b500bff5d53ec216d2da25e3bad1a1d699f56b09283R199)
> 
> I will create an RFE for the JDK mainline that adds built-in debugging support for the `(oldSym > newSym_orig)` condition as describe in the POC. Please wait for that before integrating this PR. I can help you write the code for re-sorting the tables.

As @iklam  was saying in above, the table won't work for dynamic dumping for CDS and fails all these tests.

 Array<u1>* FieldInfoStream::create_search_table(ConstantPool* cp, const Array<u1>* fis, ClassLoaderData* loader_data, TRAPS) {
+  if (CDSConfig::is_dumping_dynamic_archive()) {
+    // We cannot call validate_search_table. The _fieldinfo_search_table should be sorted by "requested" addresses,
+    // but validate_search_table will be getting Symbol* addresses from _constants, which has "buffered" addresses.
+    //
+    // For background, see new comments inside allocate_node_impl in symbolTable.cpp
+    return nullptr;
+  }
+

This fixes these tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2946527410

From iklam at openjdk.org  Thu Jun  5 23:14:04 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 5 Jun 2025 23:14:04 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <dN2E6XXlPFGqYLQ-2lrh_RCUJPpGDs98Iw7o9CE_52U=.26719e6d-c97c-4ea2-b088-e9039cf9eec7@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <dN2E6XXlPFGqYLQ-2lrh_RCUJPpGDs98Iw7o9CE_52U=.26719e6d-c97c-4ea2-b088-e9039cf9eec7@github.com>
Message-ID: <0GF59UrB4MHOBgk7V0Ew5R5ekYI4RroXDvxreSu23b8=.b278fd07-3b86-41e6-a05c-a87d6396f841@github.com>

On Thu, 5 Jun 2025 05:17:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Moved jtreg test
>>  - Improved documentation
>>  - Fix coding style (asterisk placement)
>
> I have written a POC that shows that the table must be sorted again when dumping a dynamic CDS archive. See https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f
> 
> Explanations are in [here](https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f#diff-fd7608607ecf305bb3535b500bff5d53ec216d2da25e3bad1a1d699f56b09283R199)
> 
> I will create an RFE for the JDK mainline that adds built-in debugging support for the `(oldSym > newSym_orig)` condition as describe in the POC. Please wait for that before integrating this PR. I can help you write the code for re-sorting the tables.

> As @iklam was saying in above, the table won't work for dynamic dumping for CDS and fails all these tests.
> 
> ```
>  Array<u1>* FieldInfoStream::create_search_table(ConstantPool* cp, const Array<u1>* fis, ClassLoaderData* loader_data, TRAPS) {
> +  if (CDSConfig::is_dumping_dynamic_archive()) {
> +    // We cannot call validate_search_table. The _fieldinfo_search_table should be sorted by "requested" addresses,
> +    // but validate_search_table will be getting Symbol* addresses from _constants, which has "buffered" addresses.
> +    //
> +    // For background, see new comments inside allocate_node_impl in symbolTable.cpp
> +    return nullptr;
> +  }
> +
> ```
> 
> This fixes these tests.

This fix looks good to me. It also obviates the need to re-sort the table for dynamic CDS dump. I am OK with this. We can implement re-sorting for the dynamic CDS archives in a separate RFE if desired.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2946819592

From mbaesken at openjdk.org  Fri Jun  6 06:44:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Jun 2025 06:44:59 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <ppHHbzXr8tzZAtE5u96FP-jRzFJi39v55V1jA1t88Bs=.fd006cff-f400-4890-922a-16dac7a65ebf@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <PLDiPQZ6sWQHLo0TyayUwGc_uOvtmzCkLxi7j9_m2Y0=.f5ec35bc-d437-4a87-a30a-96bafa7d3202@github.com>
 <y_gabn1yyGAgNBQ4lg8nbr2IeTgSadHj2hvmS7XvINU=.9364f8d9-f3eb-4135-9dc6-7b11078fb4c7@github.com>
 <ppHHbzXr8tzZAtE5u96FP-jRzFJi39v55V1jA1t88Bs=.fd006cff-f400-4890-922a-16dac7a65ebf@github.com>
Message-ID: <Bxf6ou8cgWk-B0mE5lJ3PTTgjckOChlu57JrmcnBDTU=.2a90a071-9de3-4317-938d-2875b730ae19@github.com>

On Thu, 5 Jun 2025 15:14:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I just think it is odd that this test failed to produce a core file, but the other core file tests passed.
I don't think they all passed, but can't find a log of the old run ; most likely it was machine specific.
I will remove it from this PR because it is not sure at all that it is ASAN related .

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2948259791

From vyazici at openjdk.org  Fri Jun  6 06:55:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 06:55:58 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

@AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948280027

From vyazici at openjdk.org  Fri Jun  6 06:55:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 06:55:59 GMT
Subject: Integrated: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot]
In-Reply-To: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
Message-ID: <eSlbp4RGgck5nhLN1TpcUtwZBoWC97tksBSqpXyMcBI=.0d552948-b036-4dd0-8fa0-73e35c3e8169@github.com>

On Fri, 30 May 2025 10:50:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.

This pull request has now been integrated.

Changeset: bb2611ad
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb2611ad43a2feaebc2246fdbac2179a40115d67
Stats:     13 lines in 4 files changed: 4 ins; 0 del; 9 mod

8357993: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [hotspot]

Reviewed-by: cjplummer, sspitsyn

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

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

From rvansa at openjdk.org  Fri Jun  6 07:14:21 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Jun 2025 07:14:21 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Add more comments
 - Disable search table with dynamic CDS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/14e00d0f..d75d6240

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=21-22

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

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

From rvansa at openjdk.org  Fri Jun  6 07:19:04 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Jun 2025 07:19:04 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <0GF59UrB4MHOBgk7V0Ew5R5ekYI4RroXDvxreSu23b8=.b278fd07-3b86-41e6-a05c-a87d6396f841@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <dN2E6XXlPFGqYLQ-2lrh_RCUJPpGDs98Iw7o9CE_52U=.26719e6d-c97c-4ea2-b088-e9039cf9eec7@github.com>
 <0GF59UrB4MHOBgk7V0Ew5R5ekYI4RroXDvxreSu23b8=.b278fd07-3b86-41e6-a05c-a87d6396f841@github.com>
Message-ID: <k1ITY89Pyhx-qa3aLPPys4eF7tMugu6JmlOK3YJ_3wM=.26c64591-e778-49eb-9e62-ac9590e78a5b@github.com>

On Thu, 5 Jun 2025 23:11:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I have written a POC that shows that the table must be sorted again when dumping a dynamic CDS archive. See https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f
>> 
>> Explanations are in [here](https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f#diff-fd7608607ecf305bb3535b500bff5d53ec216d2da25e3bad1a1d699f56b09283R199)
>> 
>> I will create an RFE for the JDK mainline that adds built-in debugging support for the `(oldSym > newSym_orig)` condition as describe in the POC. Please wait for that before integrating this PR. I can help you write the code for re-sorting the tables.
>
>> As @iklam was saying in above, the table won't work for dynamic dumping for CDS and fails all these tests.
>> 
>> ```
>>  Array<u1>* FieldInfoStream::create_search_table(ConstantPool* cp, const Array<u1>* fis, ClassLoaderData* loader_data, TRAPS) {
>> +  if (CDSConfig::is_dumping_dynamic_archive()) {
>> +    // We cannot call validate_search_table. The _fieldinfo_search_table should be sorted by "requested" addresses,
>> +    // but validate_search_table will be getting Symbol* addresses from _constants, which has "buffered" addresses.
>> +    //
>> +    // For background, see new comments inside allocate_node_impl in symbolTable.cpp
>> +    return nullptr;
>> +  }
>> +
>> ```
>> 
>> This fixes these tests.
> 
> This fix looks good to me. It also obviates the need to re-sort the table for dynamic CDS dump. I am OK with this. We can implement re-sorting for the dynamic CDS archives in a separate RFE if desired.

Great, I thought that @iklam requested to add something more substantial (and I didn't know that there are existing tests that would fail). Any re-sorting with dynamic CDS can be added as a follow-up.

So do you think we could still squeeze this in before the rampdown? (I'll type /integrate just in case, the timezones create some lag).

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2948325055

From alanb at openjdk.org  Fri Jun  6 07:25:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 07:25:04 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
Message-ID: <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>

On Fri, 6 Jun 2025 06:52:19 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated.

Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948340133

From kevinw at openjdk.org  Fri Jun  6 08:06:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 08:06:02 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
Message-ID: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>

Doc-only cleanup, not part of the API/spec.

Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

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

Commit messages:
 - 8358701: Java API docs for javax.management.remote should not link to JMXMP

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

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

From kevinw at openjdk.org  Fri Jun  6 08:06:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 08:06:03 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
Message-ID: <lMzluFQg8NXGIDKCOdExnokWbqyLe2pa9aFfWQgKo_k=.72b5e646-8cc4-408a-a6b3-42c8e399f9d0@github.com>

On Fri, 6 Jun 2025 07:54:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Doc-only cleanup, not part of the API/spec.
> 
> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

Existing docs:
https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/remote/package-summary.html#

New:
![management_remote_doc](https://github.com/user-attachments/assets/4a56d252-f34a-4690-9f5b-d840faa6ee5f)

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

PR Comment: https://git.openjdk.org/jdk/pull/25670#issuecomment-2948416530

From vyazici at openjdk.org  Fri Jun  6 08:09:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 08:09:00 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
 <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
Message-ID: <PFawmtB_T8jyHMFUmQ7RrDnZwTcg493qwQkt2bZVISQ=.7e6fab7d-598e-4cd6-a708-a057bbf3e67a@github.com>

On Fri, 6 Jun 2025 07:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

@AlanBateman, I only skipped the practice of passing `stdin.encoding` to `InputStreamReader`/`Scanner` ctors whenever it is obvious that the `System.in` referred there is not the console. Do you imply I was mistaken while assessing `BindServer` and `attach010Agent00`? If so, which ones, and [to learn what I missed] why? I can create a follow-up ticket+PR to amend them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948435515

From dfuchs at openjdk.org  Fri Jun  6 08:20:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:20:52 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
Message-ID: <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>

On Fri, 6 Jun 2025 07:54:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Doc-only cleanup, not part of the API/spec.
> 
> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

src/java.management/share/classes/javax/management/remote/package-info.java line 56:

> 54:  *     JMXConnectorFactory} and, optionally, the Generic Connector
> 55:  *     (not part of this bundle, see note below).
> 56:  *     </ul>

I wonder if we should keep the first part of the note - without the link. Something like:


 *
 *       <p><u>Note</u>: The historical JMX Remote API specification
 *         also defined an optional part; optional packages implementing
 *         the optional part of the <em>JMX Remote API</em>
 *         are not part of the <em>Java SE Platform</em>.</p>
 *
 ```
 
 @AlanBateman do you think that would be helpful to keep?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131740357

From mbaesken at openjdk.org  Fri Jun  6 08:23:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Jun 2025 08:23:52 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v3]
In-Reply-To: <r8-xhqR7KRZ_0618i4K3WrpNlO_C0OnTJ6SVY_caXf4=.9072f953-ffe2-49c2-93ca-640131e216c1@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <r8-xhqR7KRZ_0618i4K3WrpNlO_C0OnTJ6SVY_caXf4=.9072f953-ffe2-49c2-93ca-640131e216c1@github.com>
Message-ID: <rXm1LbSCaVC_xF18G8O8i8Qlpabag_o9ztZI909U4Co=.512778e0-9f90-4d68-846e-32374a707540@github.com>

On Thu, 5 Jun 2025 06:58:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AOTCodeCompressedOopsTest will be handled separately

build/AbsPathsInImage.java fails with ASAN because it reports a lot of 'unwanted' paths in the binaries

java.lang.Exception: Test failed
	at AbsPathsInImage.main(AbsPathsInImage.java:122)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)

but the test is already skipped for debug builds , so we can skip it for ASAN too, we  most likely don't want to deliver asan-enabled builds to customers.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2948471473

From alanb at openjdk.org  Fri Jun  6 08:33:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 08:33:53 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
Message-ID: <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>

On Fri, 6 Jun 2025 08:18:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Doc-only cleanup, not part of the API/spec.
>> 
>> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.
>
> src/java.management/share/classes/javax/management/remote/package-info.java line 56:
> 
>> 54:  *     JMXConnectorFactory} and, optionally, the Generic Connector
>> 55:  *     (not part of this bundle, see note below).
>> 56:  *     </ul>
> 
> I wonder if we should keep the first part of the note - without the link. Something like:
> 
> 
>  *
>  *       <p><u>Note</u>: The historical JMX Remote API specification
>  *         also defined an optional part; optional packages implementing
>  *         the optional part of the <em>JMX Remote API</em>
>  *         are not part of the <em>Java SE Platform</em>.</p>
>  *
>  ```
>  
>  @AlanBateman do you think that would be helpful to keep?

What would you think about dropping the sentence "The JMX Remote API allows the use of different type of connectors" and drop "User-defined" from the last list item?  Doing that makes it much easier to say that the RMI Connector is standard and that other Connectors are possible using using the JMXConnectorFactory. It removes any discussion as to whether there are two or three "difference types".

I think we want "RMI Connector" to link to either RMIConnector or to the java.management.rmi module description.

My concern with having a historical note is that it invites readers to search for these other "interesting" optional parts, and they will be disappointed. If you do have a historical note then I think it need to say more than "are not part of the Java Platform", it will also need to say that they are not included in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131764059

From dfuchs at openjdk.org  Fri Jun  6 08:37:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:37:50 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
 <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>
Message-ID: <LB-kO58ZC2ptOCKyJumghyxmUnb_mj99YAkh74jwlOE=.50174c92-2b92-4c33-af69-4b49ea1c0826@github.com>

On Fri, 6 Jun 2025 08:31:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/remote/package-info.java line 56:
>> 
>>> 54:  *     JMXConnectorFactory} and, optionally, the Generic Connector
>>> 55:  *     (not part of this bundle, see note below).
>>> 56:  *     </ul>
>> 
>> I wonder if we should keep the first part of the note - without the link. Something like:
>> 
>> 
>>  *
>>  *       <p><u>Note</u>: The historical JMX Remote API specification
>>  *         also defined an optional part; optional packages implementing
>>  *         the optional part of the <em>JMX Remote API</em>
>>  *         are not part of the <em>Java SE Platform</em>.</p>
>>  *
>>  ```
>>  
>>  @AlanBateman do you think that would be helpful to keep?
>
> What would you think about dropping the sentence "The JMX Remote API allows the use of different type of connectors" and drop "User-defined" from the last list item?  Doing that makes it much easier to say that the RMI Connector is standard and that other Connectors are possible using using the JMXConnectorFactory. It removes any discussion as to whether there are two or three "difference types".
> 
> I think we want "RMI Connector" to link to either RMIConnector or to the java.management.rmi module description.
> 
> My concern with having a historical note is that it invites readers to search for these other "interesting" optional parts, and they will be disappointed. If you do have a historical note then I think it need to say more than "are not part of the Java Platform", it will also need to say that they are not included in the JDK.

OK - let's drop the historical note then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131770654

From kevinw at openjdk.org  Fri Jun  6 08:42:49 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 08:42:49 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <LB-kO58ZC2ptOCKyJumghyxmUnb_mj99YAkh74jwlOE=.50174c92-2b92-4c33-af69-4b49ea1c0826@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
 <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>
 <LB-kO58ZC2ptOCKyJumghyxmUnb_mj99YAkh74jwlOE=.50174c92-2b92-4c33-af69-4b49ea1c0826@github.com>
Message-ID: <VFTw0_VbtxEosMvLH-7W-qraLpPq3pkCRAMWW17i7wg=.afe05a11-4530-4549-bb18-d2a4fa9712df@github.com>

On Fri, 6 Jun 2025 08:35:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> What would you think about dropping the sentence "The JMX Remote API allows the use of different type of connectors" and drop "User-defined" from the last list item?  Doing that makes it much easier to say that the RMI Connector is standard and that other Connectors are possible using using the JMXConnectorFactory. It removes any discussion as to whether there are two or three "difference types".
>> 
>> I think we want "RMI Connector" to link to either RMIConnector or to the java.management.rmi module description.
>> 
>> My concern with having a historical note is that it invites readers to search for these other "interesting" optional parts, and they will be disappointed. If you do have a historical note then I think it need to say more than "are not part of the Java Platform", it will also need to say that they are not included in the JDK.
>
> OK - let's drop the historical note then.

> What would you think about dropping the sentence "The JMX Remote API allows the use of different type of connectors" and drop "User-defined" from the last list item

Yes that's fine.  As is "User-defined connector protocols..." -> "Other connector protocols..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131778600

From alanb at openjdk.org  Fri Jun  6 08:44:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 08:44:56 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
 <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
Message-ID: <MeUY0lF1UvMsAVvCp7gKWxmnogJbG3rl3uykiPpTyR0=.5bd36cbb-daf7-4512-859d-50adc33a4c53@github.com>

On Fri, 6 Jun 2025 07:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated. ?
>
>> @AlanBateman @plummercj @sspitsyn Thanks so much for taking time to review the changes, much appreciated.
> 
> Okay, but I'm still puzzled as to why the tests were changed as they don't ready from the console.

> @AlanBateman, I only skipped the practice of passing `stdin.encoding` to `InputStreamReader`/`Scanner` ctors whenever it is obvious that the `System.in` referred there is not the console. Do you imply I was mistaken while assessing `BindServer` and `attach010Agent00`? If so, which ones, and [to learn what I missed] why? I can create a follow-up ticket+PR to amend them.

Tests are automated and very rare to have tests read from an interactive console. A small number of test uses "expect" for testing interactive input. There might be tests that have stdin redirected from a file or something else.

For multi VM tests (very common in the test suite) then you typically see the parent process using Process/ProcessBuilder and starting a child VM with its standard streams connected to the parent, meaning reading from System.in will read from a pipe connected to the parent. Some tests do inherit but I doubt we have any tests that inherit and also read from an interactive console.

So my point is that we probably don't need to jump on all tests that use System.in. The tests that do read from System.in probably need closer examination to see if they are reading from a pipe or something else.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948526535

From alanb at openjdk.org  Fri Jun  6 08:48:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 08:48:52 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <VFTw0_VbtxEosMvLH-7W-qraLpPq3pkCRAMWW17i7wg=.afe05a11-4530-4549-bb18-d2a4fa9712df@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
 <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>
 <LB-kO58ZC2ptOCKyJumghyxmUnb_mj99YAkh74jwlOE=.50174c92-2b92-4c33-af69-4b49ea1c0826@github.com>
 <VFTw0_VbtxEosMvLH-7W-qraLpPq3pkCRAMWW17i7wg=.afe05a11-4530-4549-bb18-d2a4fa9712df@github.com>
Message-ID: <7xL1aaW6tYbUktBIv_AvWvM25e55Bx7_YVS84J0CfHE=.c7587385-8612-46ab-84df-39323e4351f4@github.com>

On Fri, 6 Jun 2025 08:40:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> As is "User-defined connector protocols..." -> "Other connector protocols..."

I think that would be okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131785164

From kevinw at openjdk.org  Fri Jun  6 08:48:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 08:48:53 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <7xL1aaW6tYbUktBIv_AvWvM25e55Bx7_YVS84J0CfHE=.c7587385-8612-46ab-84df-39323e4351f4@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
 <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>
 <LB-kO58ZC2ptOCKyJumghyxmUnb_mj99YAkh74jwlOE=.50174c92-2b92-4c33-af69-4b49ea1c0826@github.com>
 <VFTw0_VbtxEosMvLH-7W-qraLpPq3pkCRAMWW17i7wg=.afe05a11-4530-4549-bb18-d2a4fa9712df@github.com>
 <7xL1aaW6tYbUktBIv_AvWvM25e55Bx7_YVS84J0CfHE=.c7587385-8612-46ab-84df-39323e4351f4@github.com>
Message-ID: <8SS98VbauIAFE4-Bn2vTTAzQwmiJAK1tRcSHPUfR1h4=.45accc4c-1e75-4afd-baa3-2fe2dc6238ca@github.com>

On Fri, 6 Jun 2025 08:44:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> What would you think about dropping the sentence "The JMX Remote API allows the use of different type of connectors" and drop "User-defined" from the last list item
>> 
>> Yes that's fine.  As is "User-defined connector protocols..." -> "Other connector protocols..."
>
>> As is "User-defined connector protocols..." -> "Other connector protocols..."
> 
> I think that would be okay.

Also removing:
" and, optionally, the Generic Connector (not part of this bundle, see note below)."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131788355

From kevinw at openjdk.org  Fri Jun  6 09:10:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 09:10:06 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP [v2]
In-Reply-To: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
Message-ID: <KU_Ph4KQZlnJEnjczMbNerxB0swtRoII7Fj-Lz8dNPs=.87c22afc-0f21-4a18-881e-721686d3e564@github.com>

> Doc-only cleanup, not part of the API/spec.
> 
> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

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

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25670/files
  - new: https://git.openjdk.org/jdk/pull/25670/files/26ffc32e..25c90c77

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

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

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

From kevinw at openjdk.org  Fri Jun  6 09:10:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 09:10:06 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP
In-Reply-To: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
Message-ID: <P3mOOe0dBW8E_NKTlKK_NmNtb07XOHi7xRyVJUcgygo=.8eabd1d7-a88d-4de0-ab98-f8df2fbd620b@github.com>

On Fri, 6 Jun 2025 07:54:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Doc-only cleanup, not part of the API/spec.
> 
> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

While updating, I now see this as problematic:
"The specification of this functionality is completed by Part III of the [JMX Specification, version 1.4](https://jcp.org/aboutJava/communityprocess/mrel/jsr160/index2.html)"
..as it implies these docs are extended by the historical jmx remote spec.

Updating:

![image](https://github.com/user-attachments/assets/ea796b34-2416-4300-bad0-d2052f1da16c)

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

PR Comment: https://git.openjdk.org/jdk/pull/25670#issuecomment-2948587695

From kevinw at openjdk.org  Fri Jun  6 09:49:09 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 09:49:09 GMT
Subject: RFR: 8358701: Java API docs for javax.management.remote should not
 link to JMXMP [v3]
In-Reply-To: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
Message-ID: <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>

> Doc-only cleanup, not part of the API/spec.
> 
> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

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

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25670/files
  - new: https://git.openjdk.org/jdk/pull/25670/files/25c90c77..e3b46cc6

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

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

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

From dfuchs at openjdk.org  Fri Jun  6 10:12:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 10:12:50 GMT
Subject: RFR: Remove misleading javax.management.remote API doc wording
 about JMX spec, and historic link to JMXMP [v3]
In-Reply-To: <8SS98VbauIAFE4-Bn2vTTAzQwmiJAK1tRcSHPUfR1h4=.45accc4c-1e75-4afd-baa3-2fe2dc6238ca@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <enbLDKLIgOelKeH0Rzl_YGo5JEt0xJJDJDhsQ_fY6HI=.11f6476c-7604-45f3-9b62-59d76fece9f2@github.com>
 <uVxihe1tLxW23w8AQCn6sn_UQZDf16JBghbYgcSj3sA=.817862c7-d460-4e05-a01e-1383c20851e8@github.com>
 <LB-kO58ZC2ptOCKyJumghyxmUnb_mj99YAkh74jwlOE=.50174c92-2b92-4c33-af69-4b49ea1c0826@github.com>
 <VFTw0_VbtxEosMvLH-7W-qraLpPq3pkCRAMWW17i7wg=.afe05a11-4530-4549-bb18-d2a4fa9712df@github.com>
 <7xL1aaW6tYbUktBIv_AvWvM25e55Bx7_YVS84J0CfHE=.c7587385-8612-46ab-84df-39323e4351f4@github.com>
 <8SS98VbauIAFE4-Bn2vTTAzQwmiJAK1tRcSHPUfR1h4=.45accc4c-1e75-4afd-baa3-2fe2dc6238ca@github.com>
Message-ID: <HJjuwSBi6uMPptK2sRUnrY2Z8p51Vvq5nqqJoLnu9x4=.ccae83db-4cd4-494f-9196-ddcf3ce00096@github.com>

On Fri, 6 Jun 2025 08:45:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> As is "User-defined connector protocols..." -> "Other connector protocols..."
>> 
>> I think that would be okay.
>
> Also removing:
> " and, optionally, the Generic Connector (not part of this bundle, see note below)."

LGTM

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2131922115

From alanb at openjdk.org  Fri Jun  6 10:48:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Jun 2025 10:48:49 GMT
Subject: RFR: 8358701: Remove misleading javax.management.remote API doc
 wording about JMX spec, and historic link to JMXMP [v3]
In-Reply-To: <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
Message-ID: <al_dXP-hekLj3lg8ZGxz6FB65oNUqK_Lh-SZ26lhw6k=.54e25f10-b87e-42e4-ab98-e33a24e298dc@github.com>

On Fri, 6 Jun 2025 09:49:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Doc-only cleanup, not part of the API/spec.
>> 
>> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Good

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25670#pullrequestreview-2904549175

From kevinw at openjdk.org  Fri Jun  6 10:48:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 10:48:50 GMT
Subject: RFR: 8358701: Remove misleading javax.management.remote API doc
 wording about JMX spec, and historic link to JMXMP [v3]
In-Reply-To: <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
Message-ID: <8DhgwdEJPEhsWfzSjKRCJ11wLEMHYAVJm7x2wKxa3YQ=.79567a8d-3f5e-4e68-a72b-8bc9580b9da3@github.com>

On Fri, 6 Jun 2025 09:49:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Doc-only cleanup, not part of the API/spec.
>> 
>> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Thanks Daniel and Alan - I have created the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25670#issuecomment-2948855451

From coleenp at openjdk.org  Fri Jun  6 11:03:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 11:03:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

To integrate hotspot changes, you need two reviewers and people 'requesting changes' to withdraw their requests.  Thank goodness the bots prevented this from being integrated.  You need to wait for all the comments to be resolved.
This is a P3 bug so you have more time to get this integrated for JDK 25.  I posted the schedule in the issue.  The process is that this change would be integrated into the main repository (destined for JDK 26 and then slash-backported to JDK 25 a couple days later if testing is clean).
My tier 1-7 testing passes with the dynamic CDS patch above.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2948894141

From rvansa at openjdk.org  Fri Jun  6 11:15:59 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Jun 2025 11:15:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <GHuPh9-8LpkZZH1IOJt7HdnCDz-ltuO1U3QxP1J87_c=.6958705e-fa66-41dd-a997-f287f6e40f73@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

I am not a committer, so I didn't expect any action to be taken until this gets all the approvals and someone sponsors this.
(and I've misremembered the date, thinking it's today).

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2948915602

From rvansa at openjdk.org  Fri Jun  6 11:16:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 6 Jun 2025 11:16:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v7]
In-Reply-To: <oL0OKtZ9-6QOePFYXH_LgnRgWu4dp93oIl-35g_NvzE=.5f8d347a-8432-409a-ae23-4e69f7233d1c@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <0ukRXRaojw8KZXGYN_IpikqnA1kNsMoCWFE-0fOBHjk=.bda5ca70-ed55-4a27-a018-c89331415080@github.com>
 <oL0OKtZ9-6QOePFYXH_LgnRgWu4dp93oIl-35g_NvzE=.5f8d347a-8432-409a-ae23-4e69f7233d1c@github.com>
Message-ID: <GO-1NKRZZqXEvn-rdsEh6QfOt3dcmZhBKL4u7DFEJTo=.015479be-eeee-4a1c-a4b6-0e82153b4e4b@github.com>

On Wed, 21 May 2025 15:00:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> It looks like you removed the SA changes, so I'm not so sure you still need a review from me. I just ask that you make sure the tests in serviceability/sa and sun/tools/jhsdb all pass. I'm about to be OOO for a week, so I won't be able to responds again until then.

@plummercj @rose00 Could I ask you to withdraw the request for changes / clarify further ?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2948919121

From mbaesken at openjdk.org  Fri Jun  6 11:27:31 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Jun 2025 11:27:31 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v4]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <04ztddbwMOlo-dq6TQ4_jPWfj-wNhsyDNWQSsohFo-E=.98d51cab-3302-41fd-b214-dbb73f4f6e0d@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  remove the asan disabling from 2 sa tests; they work with asan too on some machines at least

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/8b9e3dde..7ce447b3

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

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

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

From mbaesken at openjdk.org  Fri Jun  6 11:34:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Jun 2025 11:34:04 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v5]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  exclude AbsPathInImage test from asan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/7ce447b3..f8458f10

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

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

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

From mbaesken at openjdk.org  Fri Jun  6 11:34:04 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Jun 2025 11:34:04 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v4]
In-Reply-To: <04ztddbwMOlo-dq6TQ4_jPWfj-wNhsyDNWQSsohFo-E=.98d51cab-3302-41fd-b214-dbb73f4f6e0d@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <04ztddbwMOlo-dq6TQ4_jPWfj-wNhsyDNWQSsohFo-E=.98d51cab-3302-41fd-b214-dbb73f4f6e0d@github.com>
Message-ID: <wCZlJlV-lVOxigRE3RbTx0xt2mcQmSa1s3IxFMoy6Ro=.72bbc4f7-d49f-45a5-b5eb-026b95e4e674@github.com>

On Fri, 6 Jun 2025 11:27:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove the asan disabling from 2 sa tests; they work with asan too on some machines at least

For the now remaining tests, are you okay with the explanation? Should I add it as comment to the test files, or let's simply keep it here?

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2948963076

From vyazici at openjdk.org  Fri Jun  6 11:48:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:48:54 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <MeUY0lF1UvMsAVvCp7gKWxmnogJbG3rl3uykiPpTyR0=.5bd36cbb-daf7-4512-859d-50adc33a4c53@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <RyDew8RDnutWo7nk8qDdYffDlxRmYOuXqJH-_G2XXjc=.721786e6-162b-4f8a-b1f0-1620a014c4e0@github.com>
 <vS_12hVfddE3MPi1XaBS82YeHJfPGHKSJxXK6SmsVQE=.d0466cb8-51b8-4fc9-b435-050691b3d9cc@github.com>
 <MeUY0lF1UvMsAVvCp7gKWxmnogJbG3rl3uykiPpTyR0=.5bd36cbb-daf7-4512-859d-50adc33a4c53@github.com>
Message-ID: <kSazC1jCUEQekQsZ9BqVIRqve39JATAtmDEi5vmz6Yc=.6dbf3b21-a921-434d-b4fc-336afce483af@github.com>

On Fri, 6 Jun 2025 08:42:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For multi VM tests (very common in the test suite) then you typically see the parent process using Process/ProcessBuilder and starting a child VM with its standard streams connected to the parent, meaning reading from System.in will read from a pipe connected to the parent. Some tests do inherit but I doubt we have any tests that inherit and also read from an interactive console.
> 
> So my point is that we probably don't need to jump on all tests that use System.in.

_I think_ ? I see your point, and I agree with it. I've dropped several of my earlier changes from the abandoned parent #25368 ? this applies to all subsequent tickets: #25544 (core), #25541 (tools), and this one. When the subject code is called in a `Process`, or the stream is obtained from a `URL` or a `ClassLoader`, ..., when it is _"obvious"_ that the stream doesn't refer to the console, I've skipped the `stdin.encoding` refactoring. That said, _"obvious"_ is very subjective and I might have misjudged certain usages.

> The tests that do read from System.in probably need closer examination to see if they are reading from a pipe or something else.

In all `stdin.encoding` PRs ? #25544 (core), #25541 (tools), and this one ? I've examined usages before introducing the changes. I did my best, but I cannot claim it was exhaustive. That said, if it requires a significant effort to deduce that the console is not involved in a `System.in` usage, I'd prefer to include the `stdin.encoding` best-practice. There is a considerable likelihood that a later change could inadvertently violate that subtle assumption.

@AlanBateman, if you think a particular change needs closer examination or needs to be reverted, please say so. I'd be more than happy to carry out that task.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2948996963

From kevinw at openjdk.org  Fri Jun  6 15:29:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 6 Jun 2025 15:29:28 GMT
Subject: RFR: 8347114: JMXServiceURL with null protocol defaults to jmxmp
Message-ID: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>

Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.

This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")

A missing (null) protocol should throw a MalformedURLException for all constructors.

JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.

While we are here, remove the last remaining JMXMP references in the source:

src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>


These doc references are just examples of Connectors that support generation of cliennt stubs.  There is no need for JMXMP to be mentioned here.

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

Commit messages:
 - typo
 - 8347114: JMXServiceURL with null protocol defaults to jmxmp

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

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

From iklam at openjdk.org  Fri Jun  6 16:17:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Jun 2025 16:17:01 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <E9tupzxSycquP3xJGGJS0giT6QHZ7YKF241lobO8EfI=.79ce36fd-2be1-421c-b0a1-369ed0be6474@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

I don't think there's a rush to get this into JDK 25, especially this PR adds a lot of complexity into the field lookup code. I have to say honestly that I can't understand how it works without tracing in gdb. While the benefit can be seen in a synthetic benchmark, do we have any data that shows a benefit in real world applications?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2949768200

From cjplummer at openjdk.org  Fri Jun  6 16:21:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Jun 2025 16:21:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v7]
In-Reply-To: <oL0OKtZ9-6QOePFYXH_LgnRgWu4dp93oIl-35g_NvzE=.5f8d347a-8432-409a-ae23-4e69f7233d1c@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <0ukRXRaojw8KZXGYN_IpikqnA1kNsMoCWFE-0fOBHjk=.bda5ca70-ed55-4a27-a018-c89331415080@github.com>
 <oL0OKtZ9-6QOePFYXH_LgnRgWu4dp93oIl-35g_NvzE=.5f8d347a-8432-409a-ae23-4e69f7233d1c@github.com>
Message-ID: <WExx_4BZcuAOxhacxUUZHruJZo40Isv5-surAdbHask=.f41697cb-aa12-4765-aa3d-ec57cdfe316f@github.com>

On Wed, 21 May 2025 15:00:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> It looks like you removed the SA changes, so I'm not so sure you still need a review from me. I just ask that you make sure the tests in serviceability/sa and sun/tools/jhsdb all pass. I'm about to be OOO for a week, so I won't be able to responds again until then.

> @plummercj Could I ask you to withdraw the request for changes / clarify further ?

As I mentioned earlier:

> It looks like you removed the SA changes, so I'm not so sure you still need a review from me. I just ask that you make sure the tests in serviceability/sa and sun/tools/jhsdb all pass.

This still seems to be the case. Also, I don't think there is any formal way to withdraw a request for changes. Maybe I could mark it as reviewed, but that would be misleading since after you removed the SA changes there would not actually be any code in this PR that I would be reviewing, so I wouldn't want to be listed as a reviewer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2949783839

From iklam at openjdk.org  Fri Jun  6 16:31:55 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Jun 2025 16:31:55 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <HLlfowWiEfXYBXjZcsl_r3ujihQEvumy7Iclm4mrOqw=.8989c36e-dbb8-4f62-81ae-be65a4e12d39@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

To aid debugging, please add the FieldInfoStream::print_search_table() code (called from InstanceKlass::print_on()) that I included in https://github.com/iklam/jdk/commit/dcd53ebaeab7b38be02aa5b896ce9e449a45418f

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2905429817

From coleenp at openjdk.org  Fri Jun  6 16:45:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 16:45:02 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

I have a few more comments and questions.

src/hotspot/share/oops/fieldInfo.inline.hpp line 126:

> 124:   fi._offset = _r.next_uint();
> 125:   fi._access_flags = AccessFlags(checked_cast<u2>(_r.next_uint()));
> 126:   fi._field_flags = FieldInfo::FieldFlags(_r.next_uint());

These callers don't need to know about _r even though they're in FieldInfoStream.  And then you don't need to make these changes.

test/hotspot/jtreg/runtime/FieldStream/LocalFieldLookupTest.java line 30:

> 28: import static org.objectweb.asm.ClassWriter.COMPUTE_FRAMES;
> 29: import static org.objectweb.asm.ClassWriter.COMPUTE_MAXS;
> 30: import static org.objectweb.asm.Opcodes.*;

Sorry I just noticed this.  Is it possible to write this using the Classfile API?  I think the Classfile API is available in JDK 21 (checking) https://bugs.openjdk.org/browse/JDK-8294982

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2905191098
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132434505
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132519889

From coleenp at openjdk.org  Fri Jun  6 16:45:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 16:45:03 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v21]
In-Reply-To: <4YvUnJZ6lk5sJbTScP2_oX43fcbMKWatEkfiXSFEhsM=.f8a3afd9-c896-49db-9f13-6f651cf7795c@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
 <4YvUnJZ6lk5sJbTScP2_oX43fcbMKWatEkfiXSFEhsM=.f8a3afd9-c896-49db-9f13-6f651cf7795c@github.com>
Message-ID: <Sm5vhfBldIGGs4rFOOreAVD530L1SIo62qlOLuH4mNk=.cd9d5a70-495b-47a0-af60-dd83a616aad4@github.com>

On Thu, 5 Jun 2025 20:52:10 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.cpp line 164:
>> 
>>> 162:   r.read_field_counts(&java_fields, &injected_fields);
>>> 163:   assert(java_fields >= 0, "must be");
>>> 164:   if (java_fields == 0 || fis->length() == 0 || static_cast<uint>(java_fields) < BinarySearchThreshold) {
>> 
>> I don't know why you only sort Java fields and ignore the injected fields.  JavaClasses::compute_offsets calls find_local_field, so might not find an injected field, I assume in the java.lang.Class (mirror).  Should this sorted cache exclude classes with injected fields? ie if injected_fields > 0?
>> If you exclude classes with injected fields, you could remove the javaClasses code (and maybe not have to re-sort any fields during dynamic dumping (?))
>
> I don't build a search table for injected fields because I am trying to fix performance of `InstanceKlass::find_local_field` and this uses `JavaFieldStream` - that is/was ignoring injected fields in the iteration as well.
> Classes with injected fields are not excluded, we just don't build the table for them. There's not lookup by name+signature, just `InstanceKlass::field(int index)` which uses iteration through `AllFieldStream`.

Okay the code I looked at in JavaClasses calls AllFieldStream for injected fields.

>> src/hotspot/share/oops/fieldInfo.cpp line 285:
>> 
>>> 283:     FieldInfo fi;
>>> 284:     reader.read_field_info(fi);
>>> 285:     if (fi.field_flags().is_injected()) {
>> 
>> I thought that above, you only process java fields and not the injected fields?
>
> `FieldInfoReader` is limited by the full stream, and after iterating through java fields it would start returning injected fields. For java fields we call the lookup below; we know that injected fields don't have a record in the table, and we know that there won't be any more java fields after we encounter the first injected field; that's why we `break` the cycle here.

Okay, this does have a comment about this assumption.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132355744
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132361474

From coleenp at openjdk.org  Fri Jun  6 16:45:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 16:45:04 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <YQM_PWRF3JSOetjFaZz-EEkQ-BRoi1yKA54BrMO1Zng=.0ebbbcf6-3190-49c5-a4f7-5ae2883e1f53@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <EgQG3SUyud91u8pED_MeDSG7E2VFvHMtLREMljcJTos=.65089891-cd59-4325-b28f-c84469994ecf@github.com>
 <UDlOOfWnMB5OXw5vK4cd6bEs4xhGeZbbMq6qI33DwrY=.0651d5cc-67ba-423d-8e63-edebfe52e7e5@github.com>
 <YQM_PWRF3JSOetjFaZz-EEkQ-BRoi1yKA54BrMO1Zng=.0ebbbcf6-3190-49c5-a4f7-5ae2883e1f53@github.com>
Message-ID: <zqYqWe9XJIaieqatcbvj56ZDWz9sbKsuK5gvef-XIG0=.030bdec7-09b9-45a7-a436-42fa7372dc4c@github.com>

On Thu, 5 Jun 2025 21:06:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.hpp line 238:
>> 
>>> 236: 
>>> 237:   private:
>>> 238:   uint32_t next_uint() { return _r.next_uint(); }
>> 
>> Why did you make this change and have the callers expose _r ?
>
> AFAIU `_r` is not exposed, it's private. My change removes `next_uint()` because it's at wrong level of abstraction: `FieldInfoReader` should expose things java/injected fields counts (and field info itself), not just some 'uint's.
> The encapsulation is imperfect as the methods have to be called anyway only in the correct order but to me it seemed as a way forward.

Okay I see why you made this change.  Removing the friends was good because it removes other callers that shouldn't call next_uint(), but the callers within FieldInfoStream now have to call _r.next_uint() which is extra exposure to the name _r, that could be a lot more descriptive. I don't see what's wrong with FieldInfoStream calling next_uint() a private method that has access to the Unsigned5 stream.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132424315

From coleenp at openjdk.org  Fri Jun  6 16:45:05 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 16:45:05 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>
Message-ID: <yp8rSJXft_xkUlk8gwtvVpPi3suryv_e3hJZQwtF1Nw=.12c8e73f-690e-4b76-b100-5c30bdc68f4d@github.com>

On Fri, 6 Jun 2025 15:44:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add more comments
>>  - Disable search table with dynamic CDS
>
> src/hotspot/share/oops/fieldInfo.inline.hpp line 126:
> 
>> 124:   fi._offset = _r.next_uint();
>> 125:   fi._access_flags = AccessFlags(checked_cast<u2>(_r.next_uint()));
>> 126:   fi._field_flags = FieldInfo::FieldFlags(_r.next_uint());
> 
> These callers don't need to know about _r even though they're in FieldInfoStream.  And then you don't need to make these changes.

The addition of read_name_and_signature() is a good level of abstraction.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132437537

From coleenp at openjdk.org  Fri Jun  6 16:45:05 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 16:45:05 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v20]
In-Reply-To: <P4WXscvgdWvboAlQMuQUeVgh_CDHc9teNXyQAhn3rqs=.8dccbcb7-f9f8-4a7d-aabc-454f1a851790@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <Qma6iUlNliAok7HsI2GfyJi87VAWW0A47neMOi6Hubc=.d363acc6-ad9e-474c-a119-1c046eccbb44@github.com>
 <f7QBWD5FyOM_VNGVrOnJHvF014lpehRQteTsah8GTPg=.dbb085c8-dbfb-4611-a9f5-332b7ed5aabd@github.com>
 <sQsU-pujWZmu5HX-UDABwPI5ZW_bjMycXPwkUGicKxk=.3935e052-920f-4e94-8921-cfb6037bf9b0@github.com>
 <chn4VYP2pY1Exufkwbg7Syf5hsJkEL02DKqBjGNdNxw=.23e67ff9-02a1-4baf-8915-0ed7c3f76ca0@github.com>
 <P4WXscvgdWvboAlQMuQUeVgh_CDHc9teNXyQAhn3rqs=.8dccbcb7-f9f8-4a7d-aabc-454f1a851790@github.com>
Message-ID: <rQnj2yjeldkRqas_bCIZXXvlEQm45yVVvqW2Ewra7Lg=.f9eeb301-8e93-4d40-980f-069c25904be5@github.com>

On Thu, 5 Jun 2025 20:37:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, in practice these all are of the same size, but in case of the masks (as well as in case of arguments in API) I want to stress out that these are 32 bit numbers. The `unsigned int`s are just 'some not too big number'.
>> Is there any general guidance on deciding between `unsigned int` (I suppose just `unsigned` is not recommended), `uint32_t` and `u4`?
>> 
>> I was hoping that the comment on line 68 explains the intended use, but I can be more verbose and document each method. When the packed table is used for fieldinfo, it's { offset-in-fieldstream, index-in-fieldstream }. The Comparator implementation can translate offset-in-fieldstream -> { name, signature } and then do the comparison. The `index-in-fieldstream` is kind of second-class citizen; we need to fill it into `FieldInfo` and it is not encoded in the stream, therefore we need to encode it in the packed table.
>
> Reading further, I see what this mapping is and intentionally generalized.  I guess a comment like, the key and value are sized to represent the maximum value for each and then compacted, or something like that.  But maybe I haven't figured out the packing.  Are they increments of u1, u2 or u4 or something in between?

Yes this is helpful, but could you move this to the implementation in the cpp file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132440496

From coleenp at openjdk.org  Fri Jun  6 17:27:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 17:27:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>
Message-ID: <p64SRaQXKA-Q5SJ0uKE2hsmh5txAtEaNKTtrxekIDGw=.ca2c57aa-27fb-4a02-8cff-82ccf1495dec@github.com>

On Fri, 6 Jun 2025 16:41:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add more comments
>>  - Disable search table with dynamic CDS
>
> test/hotspot/jtreg/runtime/FieldStream/LocalFieldLookupTest.java line 30:
> 
>> 28: import static org.objectweb.asm.ClassWriter.COMPUTE_FRAMES;
>> 29: import static org.objectweb.asm.ClassWriter.COMPUTE_MAXS;
>> 30: import static org.objectweb.asm.Opcodes.*;
> 
> Sorry I just noticed this.  Is it possible to write this using the Classfile API?  I think the Classfile API is available in JDK 21 (checking) https://bugs.openjdk.org/browse/JDK-8294982

No, never mind this.  The Classfile API won't be backportable to JDK 21.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132585135

From cjplummer at openjdk.org  Fri Jun  6 18:51:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Jun 2025 18:51:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v4]
In-Reply-To: <wCZlJlV-lVOxigRE3RbTx0xt2mcQmSa1s3IxFMoy6Ro=.72bbc4f7-d49f-45a5-b5eb-026b95e4e674@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <04ztddbwMOlo-dq6TQ4_jPWfj-wNhsyDNWQSsohFo-E=.98d51cab-3302-41fd-b214-dbb73f4f6e0d@github.com>
 <wCZlJlV-lVOxigRE3RbTx0xt2mcQmSa1s3IxFMoy6Ro=.72bbc4f7-d49f-45a5-b5eb-026b95e4e674@github.com>
Message-ID: <Z92MOvw1sLWcRDxPv6NDiuof9L0iGs7xgW4o1dkRrvc=.45d3d778-a519-4437-84de-c7b4504fa2a0@github.com>

On Fri, 6 Jun 2025 11:31:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> For the now remaining tests, are you okay with the explanation? Should I add it as comment to the test files, or let's simply keep it here?

I like @dholmes-ora idea of adding an `@comment`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2950180918

From iklam at openjdk.org  Fri Jun  6 18:54:05 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Jun 2025 18:54:05 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <LGd35UpKrNtv7SXfjgB0fUfMjbcTJNZQoo6_FpgJvGI=.670dcb0f-8598-41c1-b1b9-c0af19ec3403@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

src/hotspot/share/oops/fieldInfo.cpp line 137:

> 135:   int index;
> 136:   int position;
> 137: } field_pos_t;

The naming of the type and fields is not consistent with HotSpot conventions. Suggestion:


struct FieldPosition {
  Symbol* _name;
  Symbol* _signature;
  int _index;
  int _position;
};

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132711029

From sspitsyn at openjdk.org  Fri Jun  6 19:06:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 6 Jun 2025 19:06:54 GMT
Subject: RFR: 8358701: Remove misleading javax.management.remote API doc
 wording about JMX spec, and historic link to JMXMP [v3]
In-Reply-To: <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
Message-ID: <DBWt5p3MzI9Lz6Wsv5bOIVvSTL3F9LB9yOlgPJAIMZY=.c4cab5db-6e34-4d83-bcce-c026a845ce6a@github.com>

On Fri, 6 Jun 2025 09:49:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Doc-only cleanup, not part of the API/spec.
>> 
>> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

src/java.management/share/classes/javax/management/remote/package-info.java line 41:

> 39:  *
> 40:  * <p>A connector makes an MBean server remotely accessible through
> 41:  * a given protocol.

Nit: Before, this line was ended with semicolon sign `:` as there is the list following it.
Now: The list follows the dot `.`. Should the dot be replaced with a semicolon?
(It impacts the CSR if you decide to change it.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2132746386

From mbaesken at openjdk.org  Fri Jun  6 19:23:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 6 Jun 2025 19:23:55 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <W6YZr5HhYbegTTT6P11bS1OJAX4-ixxPJ7ZYv1oxTII=.341483bf-59a1-4095-a0f2-014e4d5f8c7c@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <W6YZr5HhYbegTTT6P11bS1OJAX4-ixxPJ7ZYv1oxTII=.341483bf-59a1-4095-a0f2-014e4d5f8c7c@github.com>
Message-ID: <AZD1t3SambmaD6KsEbStXyOY8QV1vfnavWtEjIH7HtE=.1b13ca5b-7668-46b3-9fd6-fc035ecb2afc@github.com>

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

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBreakSignalThreadDump has issues with asan
>
> Changes look fine but I agree with Chris that we need to document why these tests don't work with ASAN, though I think I'd prefer to see an `@comment` before the `@requires !vm.asan` in the actual test files - assuming the reason can be stated clearly and succinctly.

> I like @dholmes-ora idea of adding an @comment.

Why not, I am fine with this !
Do you think the current comment suggestions are okay ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2950403319

From coleenp at openjdk.org  Fri Jun  6 19:25:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Jun 2025 19:25:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

I have a couple more comments for today.

src/hotspot/share/utilities/packedTable.cpp line 49:

> 47:     assert((key & ~_key_mask) == 0, "key out of bounds");
> 48:     assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x (%x)", value, _value_mask, ~_value_mask);
> 49:     *reinterpret_cast<uint64_t*>(data + offset) = static_cast<uint64_t>(key) | (static_cast<uint64_t>(value) << _value_shift);

How does this line not get a signal for unaligned write?

src/hotspot/share/utilities/packedTable.cpp line 83:

> 81:     assert(mid >= low && mid < high, "integer overflow?");
> 82:     uint64_t element = read_element(data, length, _element_bytes * mid);
> 83:     uint32_t key = element & _key_mask;

All this casting is hard to follow so I added this at the beginning of the file:

#ifndef _WIN32
#pragma GCC diagnostic warning "-Wconversion"
#endif

and this line, 102, and 87 complain:


warning: conversion from 'uint64_t' {aka 'long unsigned int'} to 'uint32_t' {aka 'unsigned int'} may change value [-Wconversion]
   87 |     uint32_t key = element & _key_mask;
      |                    ~~~~~~~~^~~~~~~~~~~


If the value is okay to cast to uint32_t, which I believe it is, use checked_cast<uint32_t> from checkedCast.hpp.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2905861595
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132749485
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2132790669

From cjplummer at openjdk.org  Fri Jun  6 19:28:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Jun 2025 19:28:55 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

BindServer.java is not used. It can be removed.

The changes in attach010Agent00.java are unnecessary because System.in has been set to read from a file:

35     private static final String inStreamFileName = "AttachOnDemand.attach010.in";
60         FileInputStream newInputStream = new FileInputStream(inStreamFileName);
61         System.setIn(newInputStream);

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2950447745

From stuefe at openjdk.org  Fri Jun  6 19:54:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 6 Jun 2025 19:54:53 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v5]
In-Reply-To: <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
Message-ID: <MDDbVjF3uqW9j7JJVRbiiGfLo9jWjba5fVJg9sQWilU=.74372607-ff5a-4754-9778-a5f3edd35db6@github.com>

On Fri, 6 Jun 2025 11:34:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude AbsPathInImage test from asan

Like @dholmes-ora , I would appreciate a short comment explaining the reasons for these exclusions. If those are bugs that can be fixed, its better to have a JBS issue describing the problem in order to evenutally fix it, and possibly problemlist the test (for asan) in the meantime. 

Note that even if you don't know the exact reasons why e.g. libjsig + asan fails, and have no time to investigate it, its okay to make that a JBS task as in "Investigate whether libjsig tests can work with asan". Those are good starter issues for folks with a bit of time at their hands.

test/hotspot/jtreg/runtime/XCheckJniJsig/XCheckJSig.java line 32:

> 30:  *          java.management
> 31:  * @requires os.family == "linux" | os.family == "mac"
> 32:  * @requires !vm.asan

I would like to understand this. What part of asan interferes with the libjsig? Asan interposes memory APIs, libjsig interposes signal functions, both should be able to coexist.

 If its a bug, we should have a JBS issue to (eventually) fix it, and problemlist the test for asan in the meantime. Otherwise, a short comment explaining the issue would be good.

test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java line 39:

> 37:  * @library /test/lib
> 38:  * @requires (os.family == "linux" | os.family == "windows" | os.family == "mac")
> 39:  * @requires !vm.asan

If this is easy to fix, e.g. like Jiangli did for the static build, I would rather have a fix inside the test than to completely disable it. Otherwise, a short comment would be good explaining why the test cannot run with asan.

Preexisting: I have no clue why this is excluded for riscv quemu, but SystemMapTest is not, both tests are functionally almost identical.

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2905989713
PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2132815020
PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2132822857

From iklam at openjdk.org  Fri Jun  6 20:57:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 6 Jun 2025 20:57:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
Message-ID: <dg48KDh94mhtIQP20JjzzmvSyy0E2sugGTSy4Fg41Hw=.e81dedd8-428e-4f7f-aad1-a68c3f1cf49b@github.com>

On Fri, 6 Jun 2025 07:14:21 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add more comments
>  - Disable search table with dynamic CDS

I found the `PackedTableLookup` needing too many type casts. Also, there's inconsistent naming for `table` and `data`, `table_length` vs `length`. We should use `table` and `table_table`.

There's no need to pass the table around in the APIs. It should be set once in the constructor.

Suggested fix: https://github.com/iklam/jdk/commit/4e51ce86f296c5bd3b50ec4636db0dea991ca869

BTW, I concur with Coleen that this will trigger unaligned access traps (on some platforms, SPARC for sure), so it should be removed).


uint64_t PackedTableLookup::read_element(size_t offset) const {Add commentMore actions
  if (offset + sizeof(uint64_t) <= _table_length) {
    return *reinterpret_cast<const uint64_t*>(_table + offset);

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2950773472

From cjplummer at openjdk.org  Fri Jun  6 21:12:53 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Jun 2025 21:12:53 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v2]
In-Reply-To: <W6YZr5HhYbegTTT6P11bS1OJAX4-ixxPJ7ZYv1oxTII=.341483bf-59a1-4095-a0f2-014e4d5f8c7c@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <ifO8dSadOFShDJ8omk_P2CLp1cLwCJ5PgzBpjlqqJQ4=.36e43467-ea8f-4517-a317-c9b7d4352080@github.com>
 <W6YZr5HhYbegTTT6P11bS1OJAX4-ixxPJ7ZYv1oxTII=.341483bf-59a1-4095-a0f2-014e4d5f8c7c@github.com>
Message-ID: <ET-hdXuGFG5v3QTWOnZj15m7pADJlTbRsuwl-La5nmo=.28193ecb-b8cf-47c0-8331-ce5ed97e635a@github.com>

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

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBreakSignalThreadDump has issues with asan
>
> Changes look fine but I agree with Chris that we need to document why these tests don't work with ASAN, though I think I'd prefer to see an `@comment` before the `@requires !vm.asan` in the actual test files - assuming the reason can be stated clearly and succinctly.

> > I like @dholmes-ora idea of adding an @comment.
> 
> Why not, I am fine with this ! Do you think the current comment suggestions are okay ?

If you are talking about the 1-line reasons given in the comment above, I'm fine with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2950805942

From amenkov at openjdk.org  Fri Jun  6 23:45:41 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 6 Jun 2025 23:45:41 GMT
Subject: RFR: 8358577: Test
 serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java
 failed: unexpexcted monitor object
Message-ID: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>

The change fixes race in the test.
Tested thread is expected to have no contended monitor when main thread checks it, but System.out.println() can cause waiting on a monitor when concurrent printing is performed, so printing should not be performed after signalling main thread to continue.

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

Commit messages:
 - fix

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

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

From cjplummer at openjdk.org  Sat Jun  7 00:35:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 7 Jun 2025 00:35:51 GMT
Subject: RFR: 8358577: Test
 serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java
 failed: unexpexcted monitor object
In-Reply-To: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
References: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
Message-ID: <hsMlno43U4uJreCqzAsV_YKycKu8EOI5gz9shhsd9tQ=.8d6eabc3-622f-4e34-b1d6-293c7bc7ba5e@github.com>

On Fri, 6 Jun 2025 23:41:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes race in the test.
> Tested thread is expected to have no contended monitor when main thread checks it, but System.out.println() can cause waiting on a monitor when concurrent printing is performed, so printing should not be performed after signalling main thread to continue.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25683#pullrequestreview-2906476152

From amenkov at openjdk.org  Sat Jun  7 01:16:44 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 7 Jun 2025 01:16:44 GMT
Subject: RFR: 8358094: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java still times
 out after JDK-8357282
Message-ID: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>

The test intermittently times out due to deadlock between 2 monitors: one monitor is JVMTI raw monitor used by agents, another is in Java (`nsk_jvmti_aod_disableEventAndFinish` does upcall) See JBS issue for details.
The fix updates agents to exit raw monitors before upcall.

Testing: no failures in 1000 runs

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

Commit messages:
 - fix

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

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

From kevinw at openjdk.org  Sat Jun  7 16:59:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 7 Jun 2025 16:59:52 GMT
Subject: RFR: 8358701: Remove misleading javax.management.remote API doc
 wording about JMX spec, and historic link to JMXMP [v3]
In-Reply-To: <DBWt5p3MzI9Lz6Wsv5bOIVvSTL3F9LB9yOlgPJAIMZY=.c4cab5db-6e34-4d83-bcce-c026a845ce6a@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
 <DBWt5p3MzI9Lz6Wsv5bOIVvSTL3F9LB9yOlgPJAIMZY=.c4cab5db-6e34-4d83-bcce-c026a845ce6a@github.com>
Message-ID: <FRe8XJM8zwerG352DmJYgKAJNI3Xw5U09bp7c4HE6zA=.10881f88-5677-4b24-903d-493ff3e6b3dd@github.com>

On Fri, 6 Jun 2025 19:02:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.management/share/classes/javax/management/remote/package-info.java line 41:
> 
>> 39:  *
>> 40:  * <p>A connector makes an MBean server remotely accessible through
>> 41:  * a given protocol.
> 
> Nit: Before, this line was ended with semicolon sign `:` as there is the list following it.
> Now: The list follows the dot `.`. Should the dot be replaced with a semicolon?
> (It impacts the CSR if you decide to change it.)

Thanks Serguei.  The colon made sense before, the text was clearly introducing a list of facts.
With the change, I think it looks good with or without.  Happy to leave as is, or update if there is any objection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25670#discussion_r2133997955

From lucy at openjdk.org  Sat Jun  7 19:13:54 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Sat, 7 Jun 2025 19:13:54 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v5]
In-Reply-To: <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
Message-ID: <UlRavuC6hyrkkHCxqTb77LyZTDanIk9tmdBl0td6H2A=.35dc93d9-a620-431a-9896-123c8b720cd0@github.com>

On Fri, 6 Jun 2025 11:34:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude AbsPathInImage test from asan

Changes look good technically. No add'l requirements from my side. 

As already discussed, some reasoning why a particular test does not work with asan is more than desirable - it's required. As @plummercj said, @comments are ok if the reason can be condensed into a one-liner.

I'll approve once the requests from others are honored.

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

Changes requested by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2907694852

From vyazici at openjdk.org  Sun Jun  8 21:12:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Sun, 8 Jun 2025 21:12:59 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
Message-ID: <aqslvw1rOZF6ZNxjjm_XCrn7xhOYhc-ia-z957pV9B8=.9c9eb7c8-f491-4052-8a94-c5287a06b330@github.com>

On Fri, 6 Jun 2025 19:26:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Provide fallback for `stdin.encoding`
>
> BindServer.java is not used. It can be removed.
> 
> The changes in attach010Agent00.java are unnecessary because System.in has been set to read from a file:
> 
> 35     private static final String inStreamFileName = "AttachOnDemand.attach010.in";
> 60         FileInputStream newInputStream = new FileInputStream(inStreamFileName);
> 61         System.setIn(newInputStream);

@plummercj, shall I create a ticket+PR to

1. remove `BindServer.java`, and
2. revert changes to `attach010Agent00.java`?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2954277726

From rvansa at openjdk.org  Mon Jun  9 06:43:59 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 06:43:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <yp8rSJXft_xkUlk8gwtvVpPi3suryv_e3hJZQwtF1Nw=.12c8e73f-690e-4b76-b100-5c30bdc68f4d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>
 <yp8rSJXft_xkUlk8gwtvVpPi3suryv_e3hJZQwtF1Nw=.12c8e73f-690e-4b76-b100-5c30bdc68f4d@github.com>
Message-ID: <O8WakGBJyBqrTn5WzTFQZj20gfxPFPWKwDkkkPVs0AA=.1eeff921-c362-4846-9b15-c11cf7024e40@github.com>

On Fri, 6 Jun 2025 15:46:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.inline.hpp line 126:
>> 
>>> 124:   fi._offset = _r.next_uint();
>>> 125:   fi._access_flags = AccessFlags(checked_cast<u2>(_r.next_uint()));
>>> 126:   fi._field_flags = FieldInfo::FieldFlags(_r.next_uint());
>> 
>> These callers don't need to know about _r even though they're in FieldInfoStream.  And then you don't need to make these changes.
>
> The addition of read_name_and_signature() is a good level of abstraction.

We must have some misunderstanding. This is not `FieldInfoStream`, this is `FieldInfoReader::read_field_info`, therefore I don't see any issue accessing private `FieldInfoReader::_r`. I've removed all friend classes from `FieldInfoReader` - noone outside `FieldInfoReader` can see `_r`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135129495

From rvansa at openjdk.org  Mon Jun  9 06:55:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 06:55:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
Message-ID: <UJUhrb_pOyVQfDUeuPjSw84scO1B_kJFLPNhbw3frMM=.975ad7fb-2ed5-46c9-98a8-7d7e859ca378@github.com>

On Fri, 6 Jun 2025 19:04:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add more comments
>>  - Disable search table with dynamic CDS
>
> src/hotspot/share/utilities/packedTable.cpp line 49:
> 
>> 47:     assert((key & ~_key_mask) == 0, "key out of bounds");
>> 48:     assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x (%x)", value, _value_mask, ~_value_mask);
>> 49:     *reinterpret_cast<uint64_t*>(data + offset) = static_cast<uint64_t>(key) | (static_cast<uint64_t>(value) << _value_shift);
> 
> How does this line not get a signal for unaligned write?

>From what I could find, strict alignment checking must be explicitly enabled an aarch64. x86_64 does not require alignment either. In both cases, there might be a performance penalty.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135145604

From rvansa at openjdk.org  Mon Jun  9 09:08:59 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 09:08:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
Message-ID: <onvNq1LxPbRxjLDw8PP0omST4ts_iJpfU3NXpBd__FE=.ab96b4a2-915f-4a11-bbea-7b07c5ce1560@github.com>

On Fri, 6 Jun 2025 19:22:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add more comments
>>  - Disable search table with dynamic CDS
>
> src/hotspot/share/utilities/packedTable.cpp line 83:
> 
>> 81:     assert(mid >= low && mid < high, "integer overflow?");
>> 82:     uint64_t element = read_element(data, length, _element_bytes * mid);
>> 83:     uint32_t key = element & _key_mask;
> 
> All this casting is hard to follow so I added this at the beginning of the file:
> 
> #ifndef _WIN32
> #pragma GCC diagnostic warning "-Wconversion"
> #endif
> 
> and this line, 102, and 87 complain:
> 
> 
> warning: conversion from 'uint64_t' {aka 'long unsigned int'} to 'uint32_t' {aka 'unsigned int'} may change value [-Wconversion]
>    87 |     uint32_t key = element & _key_mask;
>       |                    ~~~~~~~~^~~~~~~~~~~
> 
> 
> If the value is okay to cast to uint32_t, which I believe it is, use checked_cast<uint32_t> from checkedCast.hpp.

We cannot use `checked_cast`, because `element` can contain higher-order bits; but we want to ignore those. I can do an explicit `static_cast` and add a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135343070

From syan at openjdk.org  Mon Jun  9 09:38:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Jun 2025 09:38:49 GMT
Subject: RFR: 8358577: Test
 serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java
 failed: unexpexcted monitor object
In-Reply-To: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
References: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
Message-ID: <141JRUtwDNU8Uyg7AnEmAgFtFAS4PPxKjv-90g9mfSM=.b95bbba7-7ee1-46d7-8615-e0abfbfeb536@github.com>

On Fri, 6 Jun 2025 23:41:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes race in the test.
> Tested thread is expected to have no contended monitor when main thread checks it, but System.out.println() can cause waiting on a monitor when concurrent printing is performed, so printing should not be performed after signalling main thread to continue.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25683#pullrequestreview-2909522802

From syan at openjdk.org  Mon Jun  9 09:48:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Jun 2025 09:48:49 GMT
Subject: RFR: 8358577: Test
 serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java
 failed: unexpexcted monitor object
In-Reply-To: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
References: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
Message-ID: <6iRzRCIXpDEA0Z-XF4qRkfRWohmbcGTu7DzFGHOJdIo=.a4ad6ee2-1109-4c1f-996a-860987b7d4d7@github.com>

On Fri, 6 Jun 2025 23:41:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes race in the test.
> Tested thread is expected to have no contended monitor when main thread checks it, but System.out.println() can cause waiting on a monitor when concurrent printing is performed, so printing should not be performed after signalling main thread to continue.

LGTM

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25683#pullrequestreview-2909549228

From rvansa at openjdk.org  Mon Jun  9 10:13:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 10:13:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v24]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <qC-j4gTUtPx7y6ZaS8VprQ0Ox3MZVkK5GdKK-FukzI0=.f640ace5-f8f0-4ac7-a8b5-27a0bf104ee7@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with five additional commits since the last revision:

 - Add debugging aids
 - Move comments to the implementation
 - Replace unaligned access with __builtin_memcpy
 - Add table to PackedTableLookup ctor
 - Helper struct naming conventions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/d75d6240..0226f470

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=22-23

  Stats: 119 lines in 5 files changed: 59 ins; 19 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

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

From rvansa at openjdk.org  Mon Jun  9 10:19:58 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 10:19:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <E9tupzxSycquP3xJGGJS0giT6QHZ7YKF241lobO8EfI=.79ce36fd-2be1-421c-b0a1-369ed0be6474@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <E9tupzxSycquP3xJGGJS0giT6QHZ7YKF241lobO8EfI=.79ce36fd-2be1-421c-b0a1-369ed0be6474@github.com>
Message-ID: <Sz3IX8XGyNBXiSOrpSYYJoqd4sjjOBEJCnYbJMQiVk0=.7533460b-b053-43a6-8a69-c4150dcaaab6@github.com>

On Fri, 6 Jun 2025 16:13:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>  While the benefit can be seen in a synthetic benchmark, do we have any data that shows a benefit in real world applications?

@iklam Regrettably I cannot disclose the reproducer that came from a customer, but it is not synthetic - it caused problems when migrating to 21.

I admit that I was not looking on the unaligned behaviour of platforms besides x86_64 and aarch64, where this was supposed to be OK (with perf penalty at worst). I've replaced this with `__builtin_memcpy` as I haven't found a different platform-agnostic way to convince GCC handle an unaligned read/write. I don't see any difference in performance on the reproducer, so it's probably good enough.

Added the debugging print method as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2955355271

From rvansa at openjdk.org  Mon Jun  9 11:15:21 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 11:15:21 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v25]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <HnJNF6YUJYkjqupTQclYDrgLgJYH3sGo6OX3KxIzGkk=.e06a3998-c9b8-4528-af6a-d8ca22c6a21a@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Fallback to memcpy on MSVC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/0226f470..909fe85e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=23-24

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

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

From rvansa at openjdk.org  Mon Jun  9 11:33:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 11:33:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Print debugging info for InstanceKlass

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/909fe85e..c3730b6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=24-25

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

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

From jsjolen at openjdk.org  Mon Jun  9 12:02:54 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 12:02:54 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v2]
In-Reply-To: <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <emR-kfrOUG-iz_PySeHY7tirIF45T7U4i6y1z7s-zHw=.56f6b025-11e3-412a-abf7-c388886b9420@github.com>
Message-ID: <LP3FFDSUIiKgn_3KCsKVJwlkNOOTPR8j_yquXL0L8Is=.8c5ca72a-929b-4b22-829b-3f827ce0b3b8@github.com>

On Thu, 22 May 2025 17:55:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lois's comments

Hi,

> I think this looks like a nice improvement but I thought operands was going to turn into two arrays? Also there's probably a better name than 'operands' maybe bsm_operands?

Yeah, I hope to do that in a future PR.

Re: SA mirror constants. OK, I can do that, that makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/25298#issuecomment-2955581389

From jsjolen at openjdk.org  Mon Jun  9 12:09:38 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 12:09:38 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v3]
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <ZBuJA6NLzS5h9p8t1kcOdo0n_A6C0IwNuGFf2dwLIrw=.623e9117-5aec-44fa-b227-80097d8a7015@github.com>

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Coleen's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25298/files
  - new: https://git.openjdk.org/jdk/pull/25298/files/13e27259..2a5c820c

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

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

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

From coleenp at openjdk.org  Mon Jun  9 12:19:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 12:19:04 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <UJUhrb_pOyVQfDUeuPjSw84scO1B_kJFLPNhbw3frMM=.975ad7fb-2ed5-46c9-98a8-7d7e859ca378@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
 <UJUhrb_pOyVQfDUeuPjSw84scO1B_kJFLPNhbw3frMM=.975ad7fb-2ed5-46c9-98a8-7d7e859ca378@github.com>
Message-ID: <onBzYjVUTo1P5tZC1HdjdlDAYpi7OUmPbCNZ2BzzM5g=.3028eeb8-b86c-45af-907e-2271e412e766@github.com>

On Mon, 9 Jun 2025 06:52:41 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/utilities/packedTable.cpp line 49:
>> 
>>> 47:     assert((key & ~_key_mask) == 0, "key out of bounds");
>>> 48:     assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x (%x)", value, _value_mask, ~_value_mask);
>>> 49:     *reinterpret_cast<uint64_t*>(data + offset) = static_cast<uint64_t>(key) | (static_cast<uint64_t>(value) << _value_shift);
>> 
>> How does this line not get a signal for unaligned write?
>
> From what I could find, strict alignment checking must be explicitly enabled an aarch64. x86_64 does not require alignment either. In both cases, there might be a performance penalty.

Once I turned on hard signals for these unaligned accesses to find some performance problems (and I think I was debugging something on sparc).  The OS handles these signals silently but it does/can cause performance loss.  There must be a way to write this without all this C style casting with C++ syntax or a special memcpy.  It would still be performant for field access even if the array was copied as a byte stream.  There must be a more readable way to do this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135613762

From kevinw at openjdk.org  Mon Jun  9 13:20:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Jun 2025 13:20:06 GMT
Subject: RFR: 8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp() JavaDoc
 incorrectly documents null
Message-ID: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>

Simple correction where API docs state a return value may be "null", but in fact this is a lresult of type long, and may be zero.

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

Commit messages:
 - 8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp() JavaDoc incorrectly documents null

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

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

From jsjolen at openjdk.org  Mon Jun  9 13:32:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 13:32:01 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
Message-ID: <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>

On Mon, 9 Jun 2025 11:33:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print debugging info for InstanceKlass

There are more instances of these style errors that I've noted, please fix the other instances as well.

src/hotspot/share/oops/fieldInfo.cpp line 132:

> 130: // We use both name and signature during the comparison; while JLS require unique
> 131: // names for fields, JVMS requires only unique name + signature combination.
> 132: typedef struct {

Style: Use C++ struct def (no typedef), don't use trailing _t in the name and write it as FieldPos. The fields are public, so no underscore as name prefix for them.

src/hotspot/share/oops/fieldInfo.cpp line 140:

> 138: 
> 139: class FieldInfoSupplier: public PackedTableBuilder::Supplier {
> 140: private:

Unnecessary private

src/hotspot/share/oops/fieldInfo.cpp line 143:

> 141:   const field_pos_t* _positions;
> 142:   size_t _elements;
> 143: public:

Insert newline between public: and _elements

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2910061487
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135716601
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135716801
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135717226

From ihse at openjdk.org  Mon Jun  9 13:33:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:33:39 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v2]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zxrLICCCcLyUhUi55p4ZTPn1ioJOVims3WQ6cImbTzA=.3ebe3fc0-c8c7-4156-b563-e14f04bac137@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into utf8-sequences-in-src
 - 8356978: Convert unicode sequences in Java source code to UTF-8

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

Changes: https://git.openjdk.org/jdk/pull/25229/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25229&range=01
  Stats: 6776 lines in 79 files changed: 0 ins; 0 del; 6776 mod
  Patch: https://git.openjdk.org/jdk/pull/25229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25229/head:pull/25229

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

From jsjolen at openjdk.org  Mon Jun  9 13:39:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 13:39:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
Message-ID: <3bF8Ui8lil4ndeHVS6jIWhT1qi2TzJKgsIg7xPPrL4Y=.47570e4b-8d3f-4308-aab3-e0a712f3dae6@github.com>

On Mon, 9 Jun 2025 11:33:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Print debugging info for InstanceKlass

src/hotspot/share/oops/fieldStreams.hpp line 177:

> 175: 
> 176:   // Performs either a linear search or binary search through the stream
> 177:   // looking for a matchin name/signature combo

matchin -> matching

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135735115

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v3]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Reverting fixes in java.xml and jdk.jdi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25229/files
  - new: https://git.openjdk.org/jdk/pull/25229/files/37bf474c..5a5d7b7b

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

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

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

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
 <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>
Message-ID: <MlaNiiD6KyfBbrM7Rfs6jeWHg9ZGE-MKa4i2p2Ya4sU=.63399b3c-2270-4916-8055-47e0dac8a29c@github.com>

On Tue, 27 May 2025 16:31:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> @justin-curtis-lu Are these files handled by the translation team?
>
> @magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

I have now reverted the changes in java.xml and jdk.jdi. I still think these changes should be made, but it should apparently go through the translation team. @justin-curtis-lu Can you help me file a bug report so this gets done? I'm not sure how to do that. Basically, they will need to revert 5a5d7b7b13158c3b35ed9c433e6fdc34aa20b73d.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955820392

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>
Message-ID: <Cpl6dRjtnj-m3gtvHqeiIIVcCdpGWvNoqOUJtoVm7eM=.4a0bfc91-6c1a-4bd0-b8f5-bb89e2a7d732@github.com>

On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

@naotoj You okay with this?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955822435

From rvansa at openjdk.org  Mon Jun  9 13:43:59 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 13:43:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
 <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>
Message-ID: <_L71mAfYE529CQldfa4pHtuU3bETQ3_2LmJTrH64zfg=.5d68285f-107d-41a3-bbd5-10bd99699b5f@github.com>

On Mon, 9 Jun 2025 13:23:40 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Print debugging info for InstanceKlass
>
> src/hotspot/share/oops/fieldInfo.cpp line 132:
> 
>> 130: // We use both name and signature during the comparison; while JLS require unique
>> 131: // names for fields, JVMS requires only unique name + signature combination.
>> 132: typedef struct {
> 
> Style: Use C++ struct def (no typedef), don't use trailing _t in the name and write it as FieldPos. The fields are public, so no underscore as name prefix for them.

Now I am confused; @iklam just requested to use the underscores.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135747029

From rvansa at openjdk.org  Mon Jun  9 13:56:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 13:56:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <_L71mAfYE529CQldfa4pHtuU3bETQ3_2LmJTrH64zfg=.5d68285f-107d-41a3-bbd5-10bd99699b5f@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
 <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>
 <_L71mAfYE529CQldfa4pHtuU3bETQ3_2LmJTrH64zfg=.5d68285f-107d-41a3-bbd5-10bd99699b5f@github.com>
Message-ID: <GPqy9rxaaGnhxYCuEQQVEV1CDHH-JuEmT2ljWRcn10g=.449eb109-6aa4-4b16-83a7-222fe55d5e54@github.com>

On Mon, 9 Jun 2025 13:41:01 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> src/hotspot/share/oops/fieldInfo.cpp line 132:
>> 
>>> 130: // We use both name and signature during the comparison; while JLS require unique
>>> 131: // names for fields, JVMS requires only unique name + signature combination.
>>> 132: typedef struct {
>> 
>> Style: Use C++ struct def (no typedef), don't use trailing _t in the name and write it as FieldPos. The fields are public, so no underscore as name prefix for them.
>
> Now I am confused; @iklam just requested to use the underscores.

>From https://wiki.openjdk.org/display/HotSpot/StyleGuide :
> [#Names](https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names) Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.

No mention of distinction based on public/private

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135769155

From rvansa at openjdk.org  Mon Jun  9 13:56:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 13:56:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <onBzYjVUTo1P5tZC1HdjdlDAYpi7OUmPbCNZ2BzzM5g=.3028eeb8-b86c-45af-907e-2271e412e766@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
 <UJUhrb_pOyVQfDUeuPjSw84scO1B_kJFLPNhbw3frMM=.975ad7fb-2ed5-46c9-98a8-7d7e859ca378@github.com>
 <onBzYjVUTo1P5tZC1HdjdlDAYpi7OUmPbCNZ2BzzM5g=.3028eeb8-b86c-45af-907e-2271e412e766@github.com>
Message-ID: <nytcdlpZIiU72836w4ZuIkaj-VnxdzMJgXSQr7pX3Mk=.a65ca288-1b8c-4fb2-9e99-b55b9ef20e40@github.com>

On Mon, 9 Jun 2025 12:16:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> From what I could find, strict alignment checking must be explicitly enabled an aarch64. x86_64 does not require alignment either. In both cases, there might be a performance penalty.
>
> Once I turned on hard signals for these unaligned accesses to find some performance problems (and I think I was debugging something on sparc).  The OS handles these signals silently but it does/can cause performance loss.  There must be a way to write this without all this C style casting with C++ syntax or a special memcpy.  It would still be performant for field access even if the array was copied as a byte stream.  There must be a more readable way to do this.

What's wrong about `memcpy`, or rather the builtin version? Naturally I could write a for cycle copying the bytes, and rely on the compiler to optimize that out anyway, but I think that this makes the intention clear.

If the handling was done through OS, I guess that the penalty would be actually quite severe. I could have tested the previous version on aarch64 e.g. in AWS, though now there's no casting of pointers anymore.

When we have a final version, I could set up a build in AWS and report performance data from there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135764757

From jsjolen at openjdk.org  Mon Jun  9 13:58:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 13:58:09 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Move it to public

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25298/files
  - new: https://git.openjdk.org/jdk/pull/25298/files/2a5c820c..1c7484d7

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

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

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

From rvansa at openjdk.org  Mon Jun  9 14:14:00 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 14:14:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v27]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <pmrQLJvbmQuZ8u-BnOprjepvDvEvUZLma4vRxxW25E4=.4b905744-ec68-45c6-985a-c7c3edd29ddf@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Fix coding style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/c3730b6e..bd186c4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24847&range=25-26

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

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

From coleenp at openjdk.org  Mon Jun  9 14:24:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 14:24:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <O8WakGBJyBqrTn5WzTFQZj20gfxPFPWKwDkkkPVs0AA=.1eeff921-c362-4846-9b15-c11cf7024e40@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <nrES5niqAKbVbkm9BeypB0yYUvroUQqATW5gDPr_Vl0=.8bc6bdca-7502-44e6-a9e6-e69dc3d796b5@github.com>
 <yp8rSJXft_xkUlk8gwtvVpPi3suryv_e3hJZQwtF1Nw=.12c8e73f-690e-4b76-b100-5c30bdc68f4d@github.com>
 <O8WakGBJyBqrTn5WzTFQZj20gfxPFPWKwDkkkPVs0AA=.1eeff921-c362-4846-9b15-c11cf7024e40@github.com>
Message-ID: <szSqmjrrBa5NrELtX4mOEF0wWwNTXxjHAiY7twlrlWA=.6b179019-1c84-4e4a-908b-ea9092dca90d@github.com>

On Mon, 9 Jun 2025 06:40:48 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> The addition of read_name_and_signature() is a good level of abstraction.
>
> We must have some misunderstanding. This is not `FieldInfoStream`, this is `FieldInfoReader::read_field_info`, therefore I don't see any issue accessing private `FieldInfoReader::_r`. I've removed all friend classes from `FieldInfoReader` - noone outside `FieldInfoReader` can see `_r`.

Sorry, it's FieldInfoReader.  I think the next_uint() is a helpful function in that class to keep the _r.thing() pattern to a minimum. I don't think the changes here are an improvement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135820196

From aivanov at openjdk.org  Mon Jun  9 14:25:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jun 2025 14:25:55 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v3]
In-Reply-To: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
Message-ID: <cClJUYWcy9oZ_a3qLky54b_n8y4KXr1z9435NpmUoEg=.d03699aa-68c9-49e5-841c-729e8dc4a533@github.com>

On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting fixes in java.xml and jdk.jdi

src/demo/share/jfc/Stylepad/HelloWorld.java line 196:

> 194:             + "???????"
> 195:             + "??? ???"
> 196:             + "?!")

Maybe we can merge the string now:
Suggestion:

            new Run("none", "?????? ?????????? ????!") // Greek

At least two words seem to be split between the wrapped lines.

src/demo/share/jfc/Stylepad/HelloWorld.java line 203:

> 201:         new Paragraph("title", new Run[] {
> 202:             new Run("none", "???? ????"
> 203:             + "????")

Suggestion:

            new Run("none", "???? ????????")

src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java line 90:

> 88:             { "japanese.FirstYear",
> 89:                 new String[] {  // first year name
> 90:                     "?",   // "Gan"-nen

Suggestion:

                    "?",       // "Gan"-nen

Preserve comment alignment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135817539
PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135819248
PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135821435

From jsjolen at openjdk.org  Mon Jun  9 14:35:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 9 Jun 2025 14:35:57 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <GPqy9rxaaGnhxYCuEQQVEV1CDHH-JuEmT2ljWRcn10g=.449eb109-6aa4-4b16-83a7-222fe55d5e54@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
 <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>
 <_L71mAfYE529CQldfa4pHtuU3bETQ3_2LmJTrH64zfg=.5d68285f-107d-41a3-bbd5-10bd99699b5f@github.com>
 <GPqy9rxaaGnhxYCuEQQVEV1CDHH-JuEmT2ljWRcn10g=.449eb109-6aa4-4b16-83a7-222fe55d5e54@github.com>
Message-ID: <V3mUscCB9fHExNSZ9mJ9cJnOgbXA4U0h5cDXxnBK3aw=.d4ddce4d-1409-4d84-a3db-485005f60882@github.com>

On Mon, 9 Jun 2025 13:53:26 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Now I am confused; @iklam just requested to use the underscores.
>
> From https://wiki.openjdk.org/display/HotSpot/StyleGuide :
>> [#Names](https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names) Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.
> 
> No mention of distinction based on public/private

Well, now I am surprised :-). Thank you for looking that up, I've probably misunderstood the style and applied my own advice incorrectly. Sorry about the conflicting review comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135839913

From coleenp at openjdk.org  Mon Jun  9 14:41:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 14:41:59 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v27]
In-Reply-To: <pmrQLJvbmQuZ8u-BnOprjepvDvEvUZLma4vRxxW25E4=.4b905744-ec68-45c6-985a-c7c3edd29ddf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <pmrQLJvbmQuZ8u-BnOprjepvDvEvUZLma4vRxxW25E4=.4b905744-ec68-45c6-985a-c7c3edd29ddf@github.com>
Message-ID: <836kML8ZJKP4kPwN6OX9Z4Nuq8Iz39-2GYLdmcx5xbY=.ba8459e8-811c-4dbd-9f8e-49d633b2cd4f@github.com>

On Mon, 9 Jun 2025 14:14:00 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix coding style

src/hotspot/share/utilities/packedTable.cpp line 64:

> 62:     assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x (%x)", value, _value_mask, ~_value_mask);
> 63:     uint64_t element = static_cast<uint64_t>(key) | (static_cast<uint64_t>(value) << _value_shift);
> 64:     __builtin_memcpy(table + offset, &element, _element_bytes);

Looking at this is context makes more sense.  We don't have __builtin_memcpy in the sources, just memcpy.  Assuming the platform will do the right thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135850157

From coleenp at openjdk.org  Mon Jun  9 14:48:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 14:48:58 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <V3mUscCB9fHExNSZ9mJ9cJnOgbXA4U0h5cDXxnBK3aw=.d4ddce4d-1409-4d84-a3db-485005f60882@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
 <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>
 <_L71mAfYE529CQldfa4pHtuU3bETQ3_2LmJTrH64zfg=.5d68285f-107d-41a3-bbd5-10bd99699b5f@github.com>
 <GPqy9rxaaGnhxYCuEQQVEV1CDHH-JuEmT2ljWRcn10g=.449eb109-6aa4-4b16-83a7-222fe55d5e54@github.com>
 <V3mUscCB9fHExNSZ9mJ9cJnOgbXA4U0h5cDXxnBK3aw=.d4ddce4d-1409-4d84-a3db-485005f60882@github.com>
Message-ID: <V_Svw4xwfnBW_CGHK38vYuthXALpss5L6QITBVwsJLA=.f2104e22-4741-4930-a52f-22baf2306ee9@github.com>

On Mon, 9 Jun 2025 14:32:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> From https://wiki.openjdk.org/display/HotSpot/StyleGuide :
>>> [#Names](https://wiki.openjdk.org/display/HotSpot/StyleGuide#StyleGuide-Names) Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.
>> 
>> No mention of distinction based on public/private
>
> Well, now I am surprised :-). Thank you for looking that up, I've probably misunderstood the style and applied my own advice incorrectly. Sorry about the conflicting review comments.

This typedef didn't really bother me because it's a local internal class.  The coding style might be that it has to declared with camel case though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135862604

From coleenp at openjdk.org  Mon Jun  9 14:49:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 14:49:00 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v27]
In-Reply-To: <836kML8ZJKP4kPwN6OX9Z4Nuq8Iz39-2GYLdmcx5xbY=.ba8459e8-811c-4dbd-9f8e-49d633b2cd4f@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <pmrQLJvbmQuZ8u-BnOprjepvDvEvUZLma4vRxxW25E4=.4b905744-ec68-45c6-985a-c7c3edd29ddf@github.com>
 <836kML8ZJKP4kPwN6OX9Z4Nuq8Iz39-2GYLdmcx5xbY=.ba8459e8-811c-4dbd-9f8e-49d633b2cd4f@github.com>
Message-ID: <3Ncrgi9_PdaKzWTf5bgop2DFVKWLNgk7VjiL0tRgjMw=.09fffa29-3471-49fa-8a4e-5ff84176de41@github.com>

On Mon, 9 Jun 2025 14:38:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix coding style
>
> src/hotspot/share/utilities/packedTable.cpp line 64:
> 
>> 62:     assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x (%x)", value, _value_mask, ~_value_mask);
>> 63:     uint64_t element = static_cast<uint64_t>(key) | (static_cast<uint64_t>(value) << _value_shift);
>> 64:     __builtin_memcpy(table + offset, &element, _element_bytes);
> 
> Looking at this is context makes more sense.  We don't have __builtin_memcpy in the sources, just memcpy.  Assuming the platform will do the right thing.

The memcpy is better than what was there before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135863534

From kevinw at openjdk.org  Mon Jun  9 15:22:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Jun 2025 15:22:17 GMT
Subject: RFR: 8347114: JMXServiceURL with null protocol defaults to jmxmp
 [v2]
In-Reply-To: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
Message-ID: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>

> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
> 
> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
> 
> A missing (null) protocol should throw a MalformedURLException for all constructors.
> 
> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
> 
> While we are here, remove the last remaining JMXMP references in the source:
> 
> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
> 
> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25674/files
  - new: https://git.openjdk.org/jdk/pull/25674/files/6ab3203c..83c153e5

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

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

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

From kevinw at openjdk.org  Mon Jun  9 15:22:18 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Jun 2025 15:22:18 GMT
Subject: RFR: 8347114: JMXServiceURL with null protocol defaults to jmxmp
In-Reply-To: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
Message-ID: <JGRxe-UZUcXdzbINNIhXpcCwITN_oZCvlOsMG2td5Ao=.63c025c8-c76e-4243-8d1f-5afb78248d22@github.com>

On Fri, 6 Jun 2025 15:20:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
> 
> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
> 
> A missing (null) protocol should throw a MalformedURLException for all constructors.
> 
> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
> 
> While we are here, remove the last remaining JMXMP references in the source:
> 
> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
> 
> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.

(Test was missing from original commit.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2956106847

From rvansa at openjdk.org  Mon Jun  9 15:34:44 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 15:34:44 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Revert removing FieldInfoReader::next_uint()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/bd186c4b..5d646376

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

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

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

From rvansa at openjdk.org  Mon Jun  9 15:39:09 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Mon, 9 Jun 2025 15:39:09 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>
Message-ID: <9REPDxd-Ua3sLPfTKU-ASHNGupdvzV5Jo5Ji1yGi5rE=.35c11385-5fd4-4763-a68d-283199f9e145@github.com>

On Fri, 6 Jun 2025 11:01:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add more comments
>>  - Disable search table with dynamic CDS
>
> To integrate hotspot changes, you need two reviewers and people 'requesting changes' to withdraw their requests.  Thank goodness the bots prevented this from being integrated.  You need to wait for all the comments to be resolved.
> This is a P3 bug so you have more time to get this integrated for JDK 25.  I posted the schedule in the issue.  The process is that this change would be integrated into the main repository (destined for JDK 26 and then slash-backported to JDK 25 a couple days later if testing is clean).
> My tier 1-7 testing passes with the dynamic CDS patch above.

@coleenp Can't find the comment to reply... I've replaced all `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2956157579

From cjplummer at openjdk.org  Mon Jun  9 15:48:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Jun 2025 15:48:08 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
 <uFhSP7dGG44BliKRPz2CpAPuv7H_BBC6g6-zGDnaK2s=.705e3ba8-9831-470f-9227-d65830b0b0e6@github.com>
Message-ID: <oGvae3hPJsYSkm5JkdIKqxmac3hoe-V-QA1JEjZ95-g=.b48821db-4e45-4b99-aa16-d0aba006e2b6@github.com>

On Fri, 6 Jun 2025 19:26:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Provide fallback for `stdin.encoding`
>
> BindServer.java is not used. It can be removed.
> 
> The changes in attach010Agent00.java are unnecessary because System.in has been set to read from a file:
> 
> 35     private static final String inStreamFileName = "AttachOnDemand.attach010.in";
> 60         FileInputStream newInputStream = new FileInputStream(inStreamFileName);
> 61         System.setIn(newInputStream);

> @plummercj, shall I create a ticket+PR to
> 
>     1. remove `BindServer.java`, and
> 
>     2. revert changes to `attach010Agent00.java`?

Yes. It might be better to make them 2 PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2956182139

From ihse at openjdk.org  Mon Jun  9 15:52:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 15:52:24 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v4]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:

 - Fix comment indentation
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Concatenate string literals
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Concatenate string literals
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25229/files
  - new: https://git.openjdk.org/jdk/pull/25229/files/5a5d7b7b..a9f7acc6

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

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

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

From ihse at openjdk.org  Mon Jun  9 15:52:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 15:52:24 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v3]
In-Reply-To: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
Message-ID: <800l9jY8WcERDH6cBd9Jiw-TXxDWjjsn2kJhxK32HYA=.9eae1609-b9f8-4485-af6c-1808a5735cd0@github.com>

On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting fixes in java.xml and jdk.jdi

Thanks @aivanov-jdk!

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2956185963

From coleenp at openjdk.org  Mon Jun  9 15:53:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Jun 2025 15:53:06 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
Message-ID: <VmhmSPjaqtGhTb8HKHw5fr6NrIdKU_2O4N_vQP6QFpM=.b0d115fd-db2d-4bd6-976d-cdb43994dfdd@github.com>

On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removing FieldInfoReader::next_uint()

It's somewhat of a bikeshed argument but thank you for making it since there are many of us that work on these sources.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2956195206

From naoto at openjdk.org  Mon Jun  9 16:09:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 16:09:53 GMT
Subject: RFR: 8356978: Convert unicode sequences in Java source code to
 UTF-8 [v4]
In-Reply-To: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>
Message-ID: <f86k18YSqMNnLFfAES-56FVmEwDL3qBo2JfZnATOR88=.631be620-509d-459a-8d85-f18e0e8e6af5@github.com>

On Mon, 9 Jun 2025 15:52:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix comment indentation
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Concatenate string literals
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Concatenate string literals
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2910543905

From kbarrett at openjdk.org  Mon Jun  9 16:20:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 9 Jun 2025 16:20:07 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
Message-ID: <ugqBeHJjjyNHboVqSerEp1KLN6IFCUfqiNvz6XxuOtc=.0938fcab-9b4c-464e-8f3a-d2cbf163607f@github.com>

On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removing FieldInfoReader::next_uint()

Not really reviewing, just a couple of drive-by comments because I was asked to
take a quick look.

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2910515862

From kbarrett at openjdk.org  Mon Jun  9 16:20:08 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 9 Jun 2025 16:20:08 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v26]
In-Reply-To: <V_Svw4xwfnBW_CGHK38vYuthXALpss5L6QITBVwsJLA=.f2104e22-4741-4930-a52f-22baf2306ee9@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <O_xw7gr4-AUWmvqB1oQlIW_Mq487cyJ8u8NyoUlCGc4=.96791012-caf2-49bb-9d6b-f5095df6cc1d@github.com>
 <5ukCvH91tRfknvYy4d_8mLHGULPYSG71oZrWKNG4BhE=.034e2efe-9a11-4192-8cd6-fba1c7f0a0e4@github.com>
 <_L71mAfYE529CQldfa4pHtuU3bETQ3_2LmJTrH64zfg=.5d68285f-107d-41a3-bbd5-10bd99699b5f@github.com>
 <GPqy9rxaaGnhxYCuEQQVEV1CDHH-JuEmT2ljWRcn10g=.449eb109-6aa4-4b16-83a7-222fe55d5e54@github.com>
 <V3mUscCB9fHExNSZ9mJ9cJnOgbXA4U0h5cDXxnBK3aw=.d4ddce4d-1409-4d84-a3db-485005f60882@github.com>
 <V_Svw4xwfnBW_CGHK38vYuthXALpss5L6QITBVwsJLA=.f2104e22-4741-4930-a52f-22baf2306ee9@github.com>
Message-ID: <Pztso-GaQoCK-O0ZnAlBcEiGHB2FHQetVCP3nHADkX0=.bb11e6bd-cd11-4b8f-90c0-21f965dfa936@github.com>

On Mon, 9 Jun 2025 14:45:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Well, now I am surprised :-). Thank you for looking that up, I've probably misunderstood the style and applied my own advice incorrectly. Sorry about the conflicting review comments.
>
> This typedef didn't really bother me because it's a local internal class.  The coding style might be that it has to declared with camel case though.

This is C++, not C. There's no good reason to use a typedef of an anonymous struct.
And yes to the underscores on even public members of PODs.

There are lots of violations of both of those, but that's the current style after various discussions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135990161

From kbarrett at openjdk.org  Mon Jun  9 16:20:09 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 9 Jun 2025 16:20:09 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v27]
In-Reply-To: <3Ncrgi9_PdaKzWTf5bgop2DFVKWLNgk7VjiL0tRgjMw=.09fffa29-3471-49fa-8a4e-5ff84176de41@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <pmrQLJvbmQuZ8u-BnOprjepvDvEvUZLma4vRxxW25E4=.4b905744-ec68-45c6-985a-c7c3edd29ddf@github.com>
 <836kML8ZJKP4kPwN6OX9Z4Nuq8Iz39-2GYLdmcx5xbY=.ba8459e8-811c-4dbd-9f8e-49d633b2cd4f@github.com>
 <3Ncrgi9_PdaKzWTf5bgop2DFVKWLNgk7VjiL0tRgjMw=.09fffa29-3471-49fa-8a4e-5ff84176de41@github.com>
Message-ID: <rAFEqHKwqLen5bdsEhJFDN6lZ23kKd7vuFgrEdP46Go=.ec761e34-effd-41e6-822d-bcfbbe357f6f@github.com>

On Mon, 9 Jun 2025 14:45:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/packedTable.cpp line 64:
>> 
>>> 62:     assert((value & ~_value_mask) == 0, "value out of bounds: %x vs. %x (%x)", value, _value_mask, ~_value_mask);
>>> 63:     uint64_t element = static_cast<uint64_t>(key) | (static_cast<uint64_t>(value) << _value_shift);
>>> 64:     __builtin_memcpy(table + offset, &element, _element_bytes);
>> 
>> Looking at this is context makes more sense.  We don't have __builtin_memcpy in the sources, just memcpy.  Assuming the platform will do the right thing.
>
> The memcpy is better than what was there before.

I wouldn't expect using __builtin_memcpy to even compile in Windows.  Use memcpy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2135997724

From ihse at openjdk.org  Mon Jun  9 18:01:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 18:01:56 GMT
Subject: Integrated: 8356978: Convert unicode sequences in Java source code to
 UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <IBsqcOHT6G9vQO7_iXKeYsFa4SuRwl-93HvWt9xyFZA=.6550ebd6-354f-42ae-9733-ece720f75da2@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

This pull request has now been integrated.

Changeset: 156187ac
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/156187accc1c3e2a897ced011727a5c8d8e1b0cf
Stats:     17 lines in 3 files changed: 0 ins; 4 del; 13 mod

8356978: Convert unicode sequences in Java source code to UTF-8

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: naoto, prr, joehw

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

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

From iklam at openjdk.org  Mon Jun  9 21:44:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 9 Jun 2025 21:44:41 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
Message-ID: <N1A_HRvc7RmvM-QixdBpmnN9Z1NLrALoc7ZOcJOKRqQ=.95bf3d26-a209-4889-9bdb-94de2f09d325@github.com>

On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removing FieldInfoReader::next_uint()

src/hotspot/share/utilities/packedTable.cpp line 83:

> 81:   assert((element & ~((uint64_t) _key_mask | ((uint64_t) _value_mask << _value_shift))) == 0, "read too much");
> 82:   return element;
> 83: }

Since `_element_bytes` can be smaller than 8, memcpy will not work on big endian.

Why are you trying to optimize this? This PR already cuts down the iterations from O(n) to O(log(n)). You are already doing a lot at each iteration -- decoding the name_index and signature_index from the unsigned5 stream, looking up the symbols from the constant pool, etc.  So a few bit operations in read_element isn't going to make any substantial difference:


uint64_t element = 0;
for (int i = 0; i < _elements_bytes; i++) {
   element <<= 8;
   element |= _table[offset++]; // Need to rewrite fill() accordingly.
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2136554610

From mbaesken at openjdk.org  Tue Jun 10 06:42:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Jun 2025 06:42:46 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v6]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <muABInNSOI0fId-YMlJYHAbG7uI01ZSKdkLBOIHF5kw=.edb02602-fe8f-467a-a82b-514b8a04cbb7@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  Add comments to tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/f8458f10..3f64dffe

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

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

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

From mbaesken at openjdk.org  Tue Jun 10 06:42:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Jun 2025 06:42:46 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v5]
In-Reply-To: <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
Message-ID: <RitQ6bjB4SKDRNupshAyQFNJFeU5bnukCc11lY8pzBg=.4d76d241-8a62-4feb-becc-1a45fc01eb74@github.com>

On Fri, 6 Jun 2025 11:34:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude AbsPathInImage test from asan

Hi David/Chris/Lucy - I added the comments to the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2957857105

From mbaesken at openjdk.org  Tue Jun 10 06:58:28 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 10 Jun 2025 06:58:28 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v6]
In-Reply-To: <muABInNSOI0fId-YMlJYHAbG7uI01ZSKdkLBOIHF5kw=.edb02602-fe8f-467a-a82b-514b8a04cbb7@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <muABInNSOI0fId-YMlJYHAbG7uI01ZSKdkLBOIHF5kw=.edb02602-fe8f-467a-a82b-514b8a04cbb7@github.com>
Message-ID: <WaeRz-IYasdC1Xj-0X4ONJEr2LP92OJyryvnKf7d-Tw=.f2fda4bb-2761-4ecd-97f1-68260030b467@github.com>

On Tue, 10 Jun 2025 06:42:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments to tests

I created
https://bugs.openjdk.org/browse/JDK-8359091
Tests using libjsig lib do not work when asan is enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2957893175

From sspitsyn at openjdk.org  Tue Jun 10 07:22:11 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 07:22:11 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to catch_klass
 parameter
Message-ID: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>

The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
I treat this as a bug and doubt we need a CSR for this issue.

Testing: N/A

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

Commit messages:
 - 8358815: Exception event spec has stale reference to catch_klass parameter

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

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

From rvansa at openjdk.org  Tue Jun 10 07:58:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 07:58:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <N1A_HRvc7RmvM-QixdBpmnN9Z1NLrALoc7ZOcJOKRqQ=.95bf3d26-a209-4889-9bdb-94de2f09d325@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <N1A_HRvc7RmvM-QixdBpmnN9Z1NLrALoc7ZOcJOKRqQ=.95bf3d26-a209-4889-9bdb-94de2f09d325@github.com>
Message-ID: <c_XTW9N--SQTuOvTCowOLct-FfKIWbQ_PF8H8hb8M24=.31a75e2f-4dd9-42ff-b5ed-a494509c6cfc@github.com>

On Mon, 9 Jun 2025 21:42:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert removing FieldInfoReader::next_uint()
>
> src/hotspot/share/utilities/packedTable.cpp line 83:
> 
>> 81:   assert((element & ~((uint64_t) _key_mask | ((uint64_t) _value_mask << _value_shift))) == 0, "read too much");
>> 82:   return element;
>> 83: }
> 
> Since `_element_bytes` can be smaller than 8, memcpy will not work on big endian.
> 
> Why are you trying to optimize this? This PR already cuts down the iterations from O(n) to O(log(n)). You are already doing a lot at each iteration -- decoding the name_index and signature_index from the unsigned5 stream, looking up the symbols from the constant pool, etc.  So a few bit operations in read_element isn't going to make any substantial difference:
> 
> 
> uint64_t element = 0;
> for (int i = 0; i < _elements_bytes; i++) {
>    element <<= 8;
>    element |= _table[offset++]; // Need to rewrite fill() accordingly.
> }

The idea comes from this comment: https://github.com/openjdk/jdk/pull/24847#discussion_r2106110163

> you can load 1..8 bytes in a single (misaligned) memory operation, loading garbage into unused bytes, and then using shift or mask to clear the garbage. That may be faster than asking C++ to do a bunch of branchy logic and byte assembly on every access.

I like that idea, though it appears that the plethora of platforms that JDK supports (but one cannot simply test) makes it difficult to express. Let's rely on the compiler to get the idea from for cycle and do the right thing on each platform, then...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137178186

From ayang at openjdk.org  Tue Jun 10 08:40:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 10 Jun 2025 08:40:14 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v11]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <jXLMPtHTtErCCKB-y3II7TaNFSiv-h7saOS2McZH54w=.9f5ca2c5-3ca5-4fc3-9b01-528efb33c5ad@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 6 more: https://git.openjdk.org/jdk/compare/7c9c8ba3...3a0502c3

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=10
  Stats: 4373 lines in 31 files changed: 522 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From sspitsyn at openjdk.org  Tue Jun 10 08:49:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 08:49:29 GMT
Subject: RFR: 8358577: Test
 serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java
 failed: unexpexcted monitor object
In-Reply-To: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
References: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
Message-ID: <OdY-__zsBO5kcI6uqr-2AiVwyw8RHMoKCTCRAMEWdpM=.01652069-d3fd-4f58-a524-78595d4401e4@github.com>

On Fri, 6 Jun 2025 23:41:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes race in the test.
> Tested thread is expected to have no contended monitor when main thread checks it, but System.out.println() can cause waiting on a monitor when concurrent printing is performed, so printing should not be performed after signalling main thread to continue.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25683#pullrequestreview-2912578375

From sspitsyn at openjdk.org  Tue Jun 10 09:02:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 09:02:27 GMT
Subject: RFR: 8358094: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java still times
 out after JDK-8357282
In-Reply-To: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
References: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
Message-ID: <3Nn5t55E9aiJU5yfTSWOMktBkBpdX1yi7jVoweLvXmI=.d251f29e-1da1-42e8-9906-5698a066f5c7@github.com>

On Sat, 7 Jun 2025 01:11:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test intermittently times out due to deadlock between 2 monitors: one monitor is JVMTI raw monitor used by agents, another is in Java (`nsk_jvmti_aod_disableEventAndFinish` does upcall) See JBS issue for details.
> The fix updates agents to exit raw monitors before upcall.
> 
> Testing: no failures in 1000 runs

Looks good.

Marked as reviewed by sspitsyn (Reviewer).

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25684#pullrequestreview-2912616757
PR Review: https://git.openjdk.org/jdk/pull/25684#pullrequestreview-2912620207

From sspitsyn at openjdk.org  Tue Jun 10 09:09:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 09:09:29 GMT
Subject: RFR: 8358701: Remove misleading javax.management.remote API doc
 wording about JMX spec, and historic link to JMXMP [v3]
In-Reply-To: <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
 <ZnbkxD4LoRPVh-GDFqwh9uPoFdJ2aNSMxuk0hLBuzxA=.68424b22-c68c-4519-a119-653d384d4e4d@github.com>
Message-ID: <AAKNX0C6BP8UuJdNKHutfWcQxWtpWlGQs-kXRHzO5Ns=.77ccca56-157a-43df-b142-09031bc4e55f@github.com>

On Fri, 6 Jun 2025 09:49:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Doc-only cleanup, not part of the API/spec.
>> 
>> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25670#pullrequestreview-2912641463

From sspitsyn at openjdk.org  Tue Jun 10 09:17:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 09:17:29 GMT
Subject: RFR: 8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp()
 JavaDoc incorrectly documents null
In-Reply-To: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
References: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
Message-ID: <vqzKuncpzOBPu3kmF9WnduTx_2O9SxVQw28tE0XX_bc=.7d8c1650-d5ea-4753-bb30-486d8a9d959b@github.com>

On Mon, 9 Jun 2025 13:15:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple correction where API docs state a return value may be "null", but in fact this is a result of type long, and may be zero.

Looks good and trivial.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25694#pullrequestreview-2912664548

From rvansa at openjdk.org  Tue Jun 10 09:30:31 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 09:30:31 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v29]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <-T7PM80uoFrT7wol7RWu6ufJefRPZ-cWuW-qi646dHM=.996db406-7246-49b2-951a-603512194e34@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:

 - Remove __builtin_memcpy
 - Fix coding style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/5d646376..14f9bdf7

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

  Stats: 127 lines in 5 files changed: 5 ins; 14 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/24847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24847/head:pull/24847

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

From jsjolen at openjdk.org  Tue Jun 10 10:17:38 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 10:17:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v29]
In-Reply-To: <-T7PM80uoFrT7wol7RWu6ufJefRPZ-cWuW-qi646dHM=.996db406-7246-49b2-951a-603512194e34@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <-T7PM80uoFrT7wol7RWu6ufJefRPZ-cWuW-qi646dHM=.996db406-7246-49b2-951a-603512194e34@github.com>
Message-ID: <wDX1thP5d6E3y6cCBqn5v73H1ehTuBBFAX9eQ7UcFG4=.436d9a8e-ef38-48a2-8365-acadba6df346@github.com>

On Tue, 10 Jun 2025 09:30:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove __builtin_memcpy
>  - Fix coding style

Some more comments.

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2912537540

From jsjolen at openjdk.org  Tue Jun 10 10:17:38 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 10:17:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <nytcdlpZIiU72836w4ZuIkaj-VnxdzMJgXSQr7pX3Mk=.a65ca288-1b8c-4fb2-9e99-b55b9ef20e40@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
 <UJUhrb_pOyVQfDUeuPjSw84scO1B_kJFLPNhbw3frMM=.975ad7fb-2ed5-46c9-98a8-7d7e859ca378@github.com>
 <onBzYjVUTo1P5tZC1HdjdlDAYpi7OUmPbCNZ2BzzM5g=.3028eeb8-b86c-45af-907e-2271e412e766@github.com>
 <nytcdlpZIiU72836w4ZuIkaj-VnxdzMJgXSQr7pX3Mk=.a65ca288-1b8c-4fb2-9e99-b55b9ef20e40@github.com>
Message-ID: <DoMkqzZ5PYzlkM6e3NRQ96Aw_QWUN5itz4_z_D9GlVI=.a53ef7ab-3292-4589-9b86-15a494f3efab@github.com>

On Mon, 9 Jun 2025 13:50:54 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>What's wrong about memcpy, or rather the builtin version?

Doesn't regular `memcpy` compile into the builtin anyway? Aren't there LE/BE concerns when you do this type of computation?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137475323

From jsjolen at openjdk.org  Tue Jun 10 10:17:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 10:17:40 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
Message-ID: <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>

On Mon, 9 Jun 2025 15:34:44 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert removing FieldInfoReader::next_uint()

src/hotspot/share/utilities/packedTable.hpp line 56:

> 54:     // Packed table does NOT support duplicate keys.
> 55:     virtual bool next(uint32_t* key, uint32_t* value) = 0;
> 56:   };

Does it make sense to take the cost of an indirect call for each kv pair? You can't inline it, so the stack frame needs to be popped and pushed, and you're taking 2 registers (16 bytes) to give 8 bytes and 1 bit of information.

 We can amortize the cost by implementing this signature instead:


virtual uint32_t next(Pair<uint32_t, uint32_t>* kvs, uint32_t kvs_size);

src/hotspot/share/utilities/packedTable.hpp line 69:

> 67:   // by the supplier (when Supplier::next() returns false the whole array should
> 68:   // be filled).
> 69:   void fill(u1* table, size_t table_length, Supplier &supplier) const;

Let the ampersand hug the type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137289775
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137269715

From jsjolen at openjdk.org  Tue Jun 10 10:17:41 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 10:17:41 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
Message-ID: <ayplmQ586WMZjWWzcmne7L7ZyVaOCgl3P-8yWpve2b8=.29741619-449d-4029-a5c9-dd5958824a7a@github.com>

On Tue, 10 Jun 2025 08:34:49 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert removing FieldInfoReader::next_uint()
>
> src/hotspot/share/utilities/packedTable.hpp line 69:
> 
>> 67:   // by the supplier (when Supplier::next() returns false the whole array should
>> 68:   // be filled).
>> 69:   void fill(u1* table, size_t table_length, Supplier &supplier) const;
> 
> Let the ampersand hug the type.

Also seems like this can be a static method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137331314

From rvansa at openjdk.org  Tue Jun 10 10:21:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 10:21:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <ayplmQ586WMZjWWzcmne7L7ZyVaOCgl3P-8yWpve2b8=.29741619-449d-4029-a5c9-dd5958824a7a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
 <ayplmQ586WMZjWWzcmne7L7ZyVaOCgl3P-8yWpve2b8=.29741619-449d-4029-a5c9-dd5958824a7a@github.com>
Message-ID: <lIYmRfB_Yao6zWHNxFUuvGMFv5LkhZqQx37GvYQuTOg=.8d70a494-454c-4d0c-9996-2246a5870523@github.com>

On Tue, 10 Jun 2025 09:05:00 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/utilities/packedTable.hpp line 69:
>> 
>>> 67:   // by the supplier (when Supplier::next() returns false the whole array should
>>> 68:   // be filled).
>>> 69:   void fill(u1* table, size_t table_length, Supplier &supplier) const;
>> 
>> Let the ampersand hug the type.
>
> Also seems like this can be a static method?

The class constructor calculates the sizes, masks and bitshift for the arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137482532

From rvansa at openjdk.org  Tue Jun 10 10:25:34 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 10:25:34 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <DoMkqzZ5PYzlkM6e3NRQ96Aw_QWUN5itz4_z_D9GlVI=.a53ef7ab-3292-4589-9b86-15a494f3efab@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <fg4ZC_uw7BKJubLRAaikzRtAEmwmysI9P2gNW-GeCsA=.6a6e6263-48dc-4931-be04-dd5ac971a88d@github.com>
 <UJUhrb_pOyVQfDUeuPjSw84scO1B_kJFLPNhbw3frMM=.975ad7fb-2ed5-46c9-98a8-7d7e859ca378@github.com>
 <onBzYjVUTo1P5tZC1HdjdlDAYpi7OUmPbCNZ2BzzM5g=.3028eeb8-b86c-45af-907e-2271e412e766@github.com>
 <nytcdlpZIiU72836w4ZuIkaj-VnxdzMJgXSQr7pX3Mk=.a65ca288-1b8c-4fb2-9e99-b55b9ef20e40@github.com>
 <DoMkqzZ5PYzlkM6e3NRQ96Aw_QWUN5itz4_z_D9GlVI=.a53ef7ab-3292-4589-9b86-15a494f3efab@github.com>
Message-ID: <wFa6ygKbTlWps0cHUhHzpgH3ba0PBxIqfYtCHw5Rlug=.425fafac-42a7-414e-b7d1-02fc08b9a4d3@github.com>

On Tue, 10 Jun 2025 10:14:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> What's wrong about `memcpy`, or rather the builtin version? Naturally I could write a for cycle copying the bytes, and rely on the compiler to optimize that out anyway, but I think that this makes the intention clear.
>> 
>> If the handling was done through OS, I guess that the penalty would be actually quite severe. I could have tested the previous version on aarch64 e.g. in AWS, though now there's no casting of pointers anymore.
>> 
>> When we have a final version, I could set up a build in AWS and report performance data from there.
>
>>What's wrong about memcpy, or rather the builtin version?
> 
> Doesn't regular `memcpy` compile into the builtin anyway? Aren't there LE/BE concerns when you do this type of computation?

>From what I read `memcpy` should be treated as builtin but in debugger I've seen deeper stacks.

Anyway, this code is gone, I didn't really think about big endian archs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137489958

From stuefe at openjdk.org  Tue Jun 10 10:45:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Jun 2025 10:45:45 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v6]
In-Reply-To: <WaeRz-IYasdC1Xj-0X4ONJEr2LP92OJyryvnKf7d-Tw=.f2fda4bb-2761-4ecd-97f1-68260030b467@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <muABInNSOI0fId-YMlJYHAbG7uI01ZSKdkLBOIHF5kw=.edb02602-fe8f-467a-a82b-514b8a04cbb7@github.com>
 <WaeRz-IYasdC1Xj-0X4ONJEr2LP92OJyryvnKf7d-Tw=.f2fda4bb-2761-4ecd-97f1-68260030b467@github.com>
Message-ID: <2hZyAjtrXS2E4mkwrWTI6j4_mnLWYTBBN97-hQpuUDw=.4347bb71-7681-414e-8076-63cec0fb3f60@github.com>

On Tue, 10 Jun 2025 06:56:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I created https://bugs.openjdk.org/browse/JDK-8359091 Tests using libjsig lib do not work when asan is enabled.

Danke!

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2958620216

From alanb at openjdk.org  Tue Jun 10 11:06:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Jun 2025 11:06:28 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter
In-Reply-To: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
Message-ID: <3e2U0lztN76iKtiYtQaDlsPTknjRuubBJCq1azuj1Lk=.0a5e463b-9012-4a03-9a69-b2b0b0c6c601@github.com>

On Tue, 10 Jun 2025 07:17:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
> I treat this as a bug and doubt we need a CSR for this issue.
> 
> Testing: N/A

src/hotspot/share/prims/jvmti.xml line 12874:

> 12872:       be reset by one of those native methods.
> 12873:       Similarly, exceptions that are reported as uncaught (<code>catch_method</code>
> 12874:       and <code>catch_location</code> set to 0) may in fact be caught by native code.

catch_method is a jmethodID so null if uncaught.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25710#discussion_r2137595271

From dfuchs at openjdk.org  Tue Jun 10 11:34:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 11:34:30 GMT
Subject: RFR: 8347114: JMXServiceURL with null protocol defaults to jmxmp
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <Fn_R_xmnDz7eoQXbrHp-YyH1KZsGkBN-M2f6AivKeI8=.4216d4a9-9db7-4c3b-aca0-a67b04fc0af5@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Marked as reviewed by dfuchs (Reviewer).

This change introduces a potential compatibility with application that may be using third-party implementations of the JMXMP protocol. I do not believe JMXMP is widely used, but I could be wrong. I agree that defaulting to the "jmxmp" protocol when `null` is supplied is odd, since the only standard (non optional) connector is the RMI Connector. Changing the specification and behaviour looks therefore a desirable cleanup. 
I see that you have planned a CSR, which is good. Make sure to also add a release note.

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

PR Review: https://git.openjdk.org/jdk/pull/25674#pullrequestreview-2913146449
PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2958810096

From kevinw at openjdk.org  Tue Jun 10 11:43:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 10 Jun 2025 11:43:30 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <MHWTESow-XALBqER59kSaerlioWGf2fFOQZLKJMVKa8=.4248458a-f6bf-4aff-967d-a835fad3ea47@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Thanks Daniel, yes there is a possibility of flushing out some niche dependencies on the odd behaviour, will go ahead with CSR and release note.

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

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2958849144

From jsjolen at openjdk.org  Tue Jun 10 12:52:45 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 12:52:45 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <9REPDxd-Ua3sLPfTKU-ASHNGupdvzV5Jo5Ji1yGi5rE=.35c11385-5fd4-4763-a68d-283199f9e145@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>
 <9REPDxd-Ua3sLPfTKU-ASHNGupdvzV5Jo5Ji1yGi5rE=.35c11385-5fd4-4763-a68d-283199f9e145@github.com>
Message-ID: <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>

On Mon, 9 Jun 2025 15:36:14 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> To integrate hotspot changes, you need two reviewers and people 'requesting changes' to withdraw their requests.  Thank goodness the bots prevented this from being integrated.  You need to wait for all the comments to be resolved.
>> This is a P3 bug so you have more time to get this integrated for JDK 25.  I posted the schedule in the issue.  The process is that this change would be integrated into the main repository (destined for JDK 26 and then slash-backported to JDK 25 a couple days later if testing is clean).
>> My tier 1-7 testing passes with the dynamic CDS patch above.
>
> @coleenp Can't find the comment to reply... I've replaced all `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.

Hi @rvansa ,

What about this type of API for dealing with the compressed table? We do the 8 byte accesses as unsigned chars (important so that they're 0-extended and not sign extended) and write the compressed KV down in little-endian. We use bitwise OR to not squash whatever was there before. Comparing GCC x64 and PPC (power), it looks good.

```c++
#include <cstdint>
#include <cstdio>
#include <cstdlib>
#include <cstring>


// For this hard-coded example we use 2 byte keys
// and 3 byte values -- for an element_bytes of 5
uint32_t key_mask = (1 << 16) - 1;
uint32_t value_mask = (1 << 24) - 1;
uint32_t value_shift = 16;

uint32_t element_bytes = 5;

uint64_t* kv_array;

uint32_t unpack_key(uint64_t kv) {
  return kv & key_mask;
}
uint32_t unpack_value(uint64_t kv) { return (kv >> value_shift) & value_mask; }

uint64_t pack_kv(uint64_t k, uint64_t v) {
  return k | (v << value_shift);
}


uint32_t align_down(uint32_t x, uint32_t align) { return x & -align; }
uint32_t align_up(uint32_t x, uint32_t align) {
  return (x + (align - 1)) & -align;
}

uint64_t u64s_required(int n) {
  uint32_t bytes_required = element_bytes * n;
  return align_up(bytes_required, 8) / 8;
}

uint64_t read_u8(uint8_t* p) {
  uint64_t result = 0;
  result |= ((uint64_t)*(p + 0)) << (0 * 8);
  result |= ((uint64_t)*(p + 1)) << (1 * 8);
  result |= ((uint64_t)*(p + 2)) << (2 * 8);
  result |= ((uint64_t)*(p + 3)) << (3 * 8);
  result |= ((uint64_t)*(p + 4)) << (4 * 8);
  result |= ((uint64_t)*(p + 5)) << (5 * 8);
  result |= ((uint64_t)*(p + 6)) << (6 * 8);
  result |= ((uint64_t)*(p + 7)) << (7 * 8);
  return result;
}

void write_u8(uint8_t* p, uint64_t u8) {
  p[0] |= u8             & 0xFF;
  p[1] |= (u8 >> 8*1) & 0xFF;
  p[2] |= (u8 >> 8*2) & 0xFF;
  p[3] |= (u8 >> 8*3) & 0xFF;
  p[4] |= (u8 >> 8*4) & 0xFF;
  p[5] |= (u8 >> 8*5) & 0xFF;
  p[6] |= (u8 >> 8*6) & 0xFF;
  p[7] |= (u8 >> 8*7) & 0xFF;
}

uint64_t read(int n) {
  uint32_t byte_index = element_bytes * n;
  return read_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index]);
}

void fill(int n, uint64_t kv) {
  uint32_t byte_index = element_bytes * n;
  write_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index], kv);
  return;
}

int main() {
  int num_elts = 65536;
  uint64_t sz = u64s_required(num_elts);
  kv_array = (uint64_t*)malloc(sz * 8);
  for (int i = 0; i < sz; i++) {
    kv_array[i] = 0;
  }

  for (int i = 0; i < num_elts; i++) {
    uint64_t kv = pack_kv(i, 2 * i);
    fill(i, kv);
  }
  for (int i = 0; i < num_elts; i++) {
    uint64_t kv = read(i);
    uint32_t k = unpack_key(kv);
    uint32_t v = unpack_value(kv);
    printf("K: %d, V: %d\n", k, v);
  }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2959079093

From coleenp at openjdk.org  Tue Jun 10 13:04:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Jun 2025 13:04:39 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>
 <9REPDxd-Ua3sLPfTKU-ASHNGupdvzV5Jo5Ji1yGi5rE=.35c11385-5fd4-4763-a68d-283199f9e145@github.com>
 <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>
Message-ID: <vVzCpGbMCD0l6ryn8L7p0iw547jy2J1Kwahfsb_uBqg=.873a5313-18f3-45a8-aa74-86d2a9ebd7c0@github.com>

On Tue, 10 Jun 2025 12:49:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> @coleenp Can't find the comment to reply... I've replaced all `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.
>
> Hi @rvansa ,
> 
> What about this type of API for dealing with the compressed table? We do the 8 byte accesses as unsigned chars (important so that they're 0-extended and not sign extended) and write the compressed KV down in little-endian. We use bitwise OR to not squash whatever was there before. Comparing GCC x64 and PPC (power), it looks good.
> 
> ```c++
> #include <cstdint>
> #include <cstdio>
> #include <cstdlib>
> #include <cstring>
> 
> 
> // For this hard-coded example we use 2 byte keys
> // and 3 byte values -- for an element_bytes of 5
> uint32_t key_mask = (1 << 16) - 1;
> uint32_t value_mask = (1 << 24) - 1;
> uint32_t value_shift = 16;
> 
> uint32_t element_bytes = 5;
> 
> uint64_t* kv_array;
> 
> uint32_t unpack_key(uint64_t kv) {
>   return kv & key_mask;
> }
> uint32_t unpack_value(uint64_t kv) { return (kv >> value_shift) & value_mask; }
> 
> uint64_t pack_kv(uint64_t k, uint64_t v) {
>   return k | (v << value_shift);
> }
> 
> 
> uint32_t align_down(uint32_t x, uint32_t align) { return x & -align; }
> uint32_t align_up(uint32_t x, uint32_t align) {
>   return (x + (align - 1)) & -align;
> }
> 
> uint64_t u64s_required(int n) {
>   uint32_t bytes_required = element_bytes * n;
>   return align_up(bytes_required, 8) / 8;
> }
> 
> uint64_t read_u8(uint8_t* p) {
>   uint64_t result = 0;
>   result |= ((uint64_t)*(p + 0)) << (0 * 8);
>   result |= ((uint64_t)*(p + 1)) << (1 * 8);
>   result |= ((uint64_t)*(p + 2)) << (2 * 8);
>   result |= ((uint64_t)*(p + 3)) << (3 * 8);
>   result |= ((uint64_t)*(p + 4)) << (4 * 8);
>   result |= ((uint64_t)*(p + 5)) << (5 * 8);
>   result |= ((uint64_t)*(p + 6)) << (6 * 8);
>   result |= ((uint64_t)*(p + 7)) << (7 * 8);
>   return result;
> }
> 
> void write_u8(uint8_t* p, uint64_t u8) {
>   p[0] |= u8             & 0xFF;
>   p[1] |= (u8 >> 8*1) & 0xFF;
>   p[2] |= (u8 >> 8*2) & 0xFF;
>   p[3] |= (u8 >> 8*3) & 0xFF;
>   p[4] |= (u8 >> 8*4) & 0xFF;
>   p[5] |= (u8 >> 8*5) & 0xFF;
>   p[6] |= (u8 >> 8*6) & 0xFF;
>   p[7] |= (u8 >> 8*7) & 0xFF;
> }
> 
> uint64_t read(int n) {
>   uint32_t byte_index = element_bytes * n;
>   return read_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index]);
> }
> 
> void fill(int n, uint64_t kv) {
>   uint32_t byte_index = element_bytes * n;
>   write_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index], kv);
>   return;
> }
> 
> int main() {
>   int num_elts = 65536;
>   uint64_t sz = u64s_required(num_elts);
>   kv_array = (uint64_t*)malloc(sz * 8);
>   for (int i = 0; i < sz; i++) {
>     kv_array[i] = 0;
>   }
> 
>   for (int i = 0; i < num_elts; i++) {
>     uint64_t kv = pack_kv(i, 2 * i);
>     fill(i, kv);
>   }
>   for (int i = 0; i < num_...

Shouldn't the Copy package or memcpy do all of this? @jdksjolen I don't think this should be in the packedTable code.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2959112151

From coleenp at openjdk.org  Tue Jun 10 13:04:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Jun 2025 13:04:40 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
Message-ID: <W3vc6NJ1QgYj8UwM8g2y-Zk1O3aics2QvONqclFOKqo=.b55f2c4e-7592-4621-8c5a-016eeec87e0c@github.com>

On Tue, 10 Jun 2025 08:44:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert removing FieldInfoReader::next_uint()
>
> src/hotspot/share/utilities/packedTable.hpp line 56:
> 
>> 54:     // Packed table does NOT support duplicate keys.
>> 55:     virtual bool next(uint32_t* key, uint32_t* value) = 0;
>> 56:   };
> 
> Does it make sense to take the cost of an indirect call for each kv pair? You can't inline it, so the stack frame needs to be popped and pushed, and you're taking 2 registers (16 bytes) to give 8 bytes and 1 bit of information.
> 
>  We can amortize the cost by implementing this signature instead:
> 
> 
> virtual uint32_t next(Pair<uint32_t, uint32_t>* kvs, uint32_t kvs_size);

This was done this way with a "Supplier" because this package would be useful for other Unsigned5 packed types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137846594

From rvansa at openjdk.org  Tue Jun 10 13:40:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 13:40:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>
 <9REPDxd-Ua3sLPfTKU-ASHNGupdvzV5Jo5Ji1yGi5rE=.35c11385-5fd4-4763-a68d-283199f9e145@github.com>
 <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>
Message-ID: <S4y905ayAr4N-26Dgx8zZy4hlYc8Ij3iyt46v7FNZNU=.bfd9cfcb-e3aa-4085-90f3-d1ffbfd21fea@github.com>

On Tue, 10 Jun 2025 12:49:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> @coleenp Can't find the comment to reply... I've replaced all `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.
>
> Hi @rvansa ,
> 
> What about this type of API for dealing with the compressed table? We do the 8 byte accesses as unsigned chars (important so that they're 0-extended and not sign extended) and write the compressed KV down in little-endian. We use bitwise OR to not squash whatever was there before. Comparing GCC x64 and PPC (power), it looks good.
> 
> ```c++
> #include <cstdint>
> #include <cstdio>
> #include <cstdlib>
> #include <cstring>
> 
> 
> // For this hard-coded example we use 2 byte keys
> // and 3 byte values -- for an element_bytes of 5
> uint32_t key_mask = (1 << 16) - 1;
> uint32_t value_mask = (1 << 24) - 1;
> uint32_t value_shift = 16;
> 
> uint32_t element_bytes = 5;
> 
> uint64_t* kv_array;
> 
> uint32_t unpack_key(uint64_t kv) {
>   return kv & key_mask;
> }
> uint32_t unpack_value(uint64_t kv) { return (kv >> value_shift) & value_mask; }
> 
> uint64_t pack_kv(uint64_t k, uint64_t v) {
>   return k | (v << value_shift);
> }
> 
> 
> uint32_t align_down(uint32_t x, uint32_t align) { return x & -align; }
> uint32_t align_up(uint32_t x, uint32_t align) {
>   return (x + (align - 1)) & -align;
> }
> 
> uint64_t u64s_required(int n) {
>   uint32_t bytes_required = element_bytes * n;
>   return align_up(bytes_required, 8) / 8;
> }
> 
> uint64_t read_u8(uint8_t* p) {
>   uint64_t result = 0;
>   result |= ((uint64_t)*(p + 0)) << (0 * 8);
>   result |= ((uint64_t)*(p + 1)) << (1 * 8);
>   result |= ((uint64_t)*(p + 2)) << (2 * 8);
>   result |= ((uint64_t)*(p + 3)) << (3 * 8);
>   result |= ((uint64_t)*(p + 4)) << (4 * 8);
>   result |= ((uint64_t)*(p + 5)) << (5 * 8);
>   result |= ((uint64_t)*(p + 6)) << (6 * 8);
>   result |= ((uint64_t)*(p + 7)) << (7 * 8);
>   return result;
> }
> 
> void write_u8(uint8_t* p, uint64_t u8) {
>   p[0] |= u8             & 0xFF;
>   p[1] |= (u8 >> 8*1) & 0xFF;
>   p[2] |= (u8 >> 8*2) & 0xFF;
>   p[3] |= (u8 >> 8*3) & 0xFF;
>   p[4] |= (u8 >> 8*4) & 0xFF;
>   p[5] |= (u8 >> 8*5) & 0xFF;
>   p[6] |= (u8 >> 8*6) & 0xFF;
>   p[7] |= (u8 >> 8*7) & 0xFF;
> }
> 
> uint64_t read(int n) {
>   uint32_t byte_index = element_bytes * n;
>   return read_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index]);
> }
> 
> void fill(int n, uint64_t kv) {
>   uint32_t byte_index = element_bytes * n;
>   write_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index], kv);
>   return;
> }
> 
> int main() {
>   int num_elts = 65536;
>   uint64_t sz = u64s_required(num_elts);
>   kv_array = (uint64_t*)malloc(sz * 8);
>   for (int i = 0; i < sz; i++) {
>     kv_array[i] = 0;
>   }
> 
>   for (int i = 0; i < num_elts; i++) {
>     uint64_t kv = pack_kv(i, 2 * i);
>     fill(i, kv);
>   }
>   for (int i = 0; i < num_...

@jdksjolen We'd need to solve the case without padding at the end of the table (or add the padding to ensure that we're not accessing past allocated area). However, I did not really get what problem are you trying to solve?

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2959298843

From rvansa at openjdk.org  Tue Jun 10 13:48:37 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 13:48:37 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <W3vc6NJ1QgYj8UwM8g2y-Zk1O3aics2QvONqclFOKqo=.b55f2c4e-7592-4621-8c5a-016eeec87e0c@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
 <W3vc6NJ1QgYj8UwM8g2y-Zk1O3aics2QvONqclFOKqo=.b55f2c4e-7592-4621-8c5a-016eeec87e0c@github.com>
Message-ID: <nFVdEId2-mLSvPwD20BV2vspdcKbM6boVsL_ocFapVE=.c6fcfa4e-214c-4e2e-9836-8b3a98db6f9d@github.com>

On Tue, 10 Jun 2025 13:02:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/utilities/packedTable.hpp line 56:
>> 
>>> 54:     // Packed table does NOT support duplicate keys.
>>> 55:     virtual bool next(uint32_t* key, uint32_t* value) = 0;
>>> 56:   };
>> 
>> Does it make sense to take the cost of an indirect call for each kv pair? You can't inline it, so the stack frame needs to be popped and pushed, and you're taking 2 registers (16 bytes) to give 8 bytes and 1 bit of information.
>> 
>>  We can amortize the cost by implementing this signature instead:
>> 
>> 
>> virtual uint32_t next(Pair<uint32_t, uint32_t>* kvs, uint32_t kvs_size);
>
> This was done this way with a "Supplier" because this package would be useful for other Unsigned5 packed types.

But then you'd need create an array of `Pair` in `create_search_table` and copy the data into that. You wouldn't need a Supplier at all, just pass the array and its length to the `fill` method. If you are worried about the virtual calls, I could do that.

Alternatively, we could replace virtual calls with templated `fill` method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2137952293

From jsjolen at openjdk.org  Tue Jun 10 14:22:39 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 14:22:39 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v23]
In-Reply-To: <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3rzU9-HHk_qfFkI8DRejJ-8RR4N9ys12NjQvYKQV8-s=.b1c9959e-86c7-4ed0-8d81-04ea943f6d7a@github.com>
 <AIAiy_G14OEDL51veYPRjelQGbl9pMGxEbV5oNIju-I=.9dfe1c18-c169-43fd-b56d-082b001ba8eb@github.com>
 <9REPDxd-Ua3sLPfTKU-ASHNGupdvzV5Jo5Ji1yGi5rE=.35c11385-5fd4-4763-a68d-283199f9e145@github.com>
 <pn8MlGUxzYj9uVQ4ZisAc2kdKr6EUtbKA1rQxzzoG4I=.22f8f88c-3e64-4b8d-9bd8-a49768ce6faf@github.com>
Message-ID: <2KPXTyX4hin3fF8MGa-7NgPkjYAG9UW11MVfPX8OAK0=.9dddca09-f542-42b0-9677-c73409fd52fb@github.com>

On Tue, 10 Jun 2025 12:49:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> @coleenp Can't find the comment to reply... I've replaced all `_r.next_uint()` with just `next_uint()`, it's a bikeshed argument.
>
> Hi @rvansa ,
> 
> What about this type of API for dealing with the compressed table? We do the 8 byte accesses as unsigned chars (important so that they're 0-extended and not sign extended) and write the compressed KV down in little-endian. We use bitwise OR to not squash whatever was there before. Comparing GCC x64 and PPC (power), it looks good.
> 
> ```c++
> #include <cstdint>
> #include <cstdio>
> #include <cstdlib>
> #include <cstring>
> 
> 
> // For this hard-coded example we use 2 byte keys
> // and 3 byte values -- for an element_bytes of 5
> uint32_t key_mask = (1 << 16) - 1;
> uint32_t value_mask = (1 << 24) - 1;
> uint32_t value_shift = 16;
> 
> uint32_t element_bytes = 5;
> 
> uint64_t* kv_array;
> 
> uint32_t unpack_key(uint64_t kv) {
>   return kv & key_mask;
> }
> uint32_t unpack_value(uint64_t kv) { return (kv >> value_shift) & value_mask; }
> 
> uint64_t pack_kv(uint64_t k, uint64_t v) {
>   return k | (v << value_shift);
> }
> 
> 
> uint32_t align_down(uint32_t x, uint32_t align) { return x & -align; }
> uint32_t align_up(uint32_t x, uint32_t align) {
>   return (x + (align - 1)) & -align;
> }
> 
> uint64_t u64s_required(int n) {
>   uint32_t bytes_required = element_bytes * n;
>   return align_up(bytes_required, 8) / 8;
> }
> 
> uint64_t read_u8(uint8_t* p) {
>   uint64_t result = 0;
>   result |= ((uint64_t)*(p + 0)) << (0 * 8);
>   result |= ((uint64_t)*(p + 1)) << (1 * 8);
>   result |= ((uint64_t)*(p + 2)) << (2 * 8);
>   result |= ((uint64_t)*(p + 3)) << (3 * 8);
>   result |= ((uint64_t)*(p + 4)) << (4 * 8);
>   result |= ((uint64_t)*(p + 5)) << (5 * 8);
>   result |= ((uint64_t)*(p + 6)) << (6 * 8);
>   result |= ((uint64_t)*(p + 7)) << (7 * 8);
>   return result;
> }
> 
> void write_u8(uint8_t* p, uint64_t u8) {
>   p[0] |= u8             & 0xFF;
>   p[1] |= (u8 >> 8*1) & 0xFF;
>   p[2] |= (u8 >> 8*2) & 0xFF;
>   p[3] |= (u8 >> 8*3) & 0xFF;
>   p[4] |= (u8 >> 8*4) & 0xFF;
>   p[5] |= (u8 >> 8*5) & 0xFF;
>   p[6] |= (u8 >> 8*6) & 0xFF;
>   p[7] |= (u8 >> 8*7) & 0xFF;
> }
> 
> uint64_t read(int n) {
>   uint32_t byte_index = element_bytes * n;
>   return read_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index]);
> }
> 
> void fill(int n, uint64_t kv) {
>   uint32_t byte_index = element_bytes * n;
>   write_u8(&reinterpret_cast<uint8_t*>(kv_array)[byte_index], kv);
>   return;
> }
> 
> int main() {
>   int num_elts = 65536;
>   uint64_t sz = u64s_required(num_elts);
>   kv_array = (uint64_t*)malloc(sz * 8);
>   for (int i = 0; i < sz; i++) {
>     kv_array[i] = 0;
>   }
> 
>   for (int i = 0; i < num_elts; i++) {
>     uint64_t kv = pack_kv(i, 2 * i);
>     fill(i, kv);
>   }
>   for (int i = 0; i < num_...

> Shouldn't the Copy package or memcpy do all of this? @jdksjolen I don't think this should be in the packedTable code.



> @jdksjolen We'd need to solve the case without padding at the end of the table (or add the padding to ensure that we're not accessing past allocated area). However, I did not really get what problem are you trying to solve?

My worry was that `memcpy` would have incorrect semantics when on a BE system. As the code no longer uses memcpy, we're fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2959448541

From jsjolen at openjdk.org  Tue Jun 10 14:32:37 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 14:32:37 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <nFVdEId2-mLSvPwD20BV2vspdcKbM6boVsL_ocFapVE=.c6fcfa4e-214c-4e2e-9836-8b3a98db6f9d@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
 <W3vc6NJ1QgYj8UwM8g2y-Zk1O3aics2QvONqclFOKqo=.b55f2c4e-7592-4621-8c5a-016eeec87e0c@github.com>
 <nFVdEId2-mLSvPwD20BV2vspdcKbM6boVsL_ocFapVE=.c6fcfa4e-214c-4e2e-9836-8b3a98db6f9d@github.com>
Message-ID: <CdzK1qK5yohj3xmeMyst8dc1HBpY_VucQE0FzyRn1Ss=.86ab0e12-1c5b-4b52-9816-77b1d300c0bf@github.com>

On Tue, 10 Jun 2025 13:45:52 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This was done this way with a "Supplier" because this package would be useful for other Unsigned5 packed types.
>
> But then you'd need create an array of `Pair` in `create_search_table` and copy the data into that. You wouldn't need a Supplier at all, just pass the array and its length to the `fill` method. If you are worried about the virtual calls, I could do that.
> 
> Alternatively, we could replace virtual calls with templated `fill` method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?

I think you misunderstand me, as what I'm proposing wouldn't requre creating an array in `create_search_table`.

I'm saying that you do this:

```c++
// Note: we require the supplier to provide the elements in the final order as we can't easily sort
// within this method - qsort() accepts only pure function as comparator.
void PackedTableBuilder::fill(u1* table, size_t table_length, Supplier &supplier) const {
  Pair<uint32_t, uint32_t> kvs[4];

  size_t offset = 0;
  size_t len_read = 0;
  while (len = supplier.next(kvs, 4)) {
    // len tells you how many of the full capacity of kvs was used.
  }
}


Now each call of  `Supplier::next` gives you up to 4 elements, quartering the amount of virtual calls necessary.

>Alternatively, we could replace virtual calls with templated fill method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?

Sure, you can try that out.

To be clear, I am only asking: Are virtual calls expensive enough here that not having them, or amortizing their cost, something that makes the performance better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2138061151

From kevinw at openjdk.org  Tue Jun 10 15:12:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 10 Jun 2025 15:12:32 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <0l1WUaM-GyqC2ZV9kkdH4XoKVC6q7Lw0ns_wAFR7QY0=.70622ad6-aac8-49e4-9bd4-39846fd4fec6@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

CSR detail added.

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

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2959635619

From rvansa at openjdk.org  Tue Jun 10 15:18:38 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 15:18:38 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <CdzK1qK5yohj3xmeMyst8dc1HBpY_VucQE0FzyRn1Ss=.86ab0e12-1c5b-4b52-9816-77b1d300c0bf@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
 <W3vc6NJ1QgYj8UwM8g2y-Zk1O3aics2QvONqclFOKqo=.b55f2c4e-7592-4621-8c5a-016eeec87e0c@github.com>
 <nFVdEId2-mLSvPwD20BV2vspdcKbM6boVsL_ocFapVE=.c6fcfa4e-214c-4e2e-9836-8b3a98db6f9d@github.com>
 <CdzK1qK5yohj3xmeMyst8dc1HBpY_VucQE0FzyRn1Ss=.86ab0e12-1c5b-4b52-9816-77b1d300c0bf@github.com>
Message-ID: <hIgmtj2xldr-bNLjX6jrPE3L3ZVWlkrRvThxZZQR1mQ=.de9dde26-3054-4ecb-bdbf-1bb388e5c367@github.com>

On Tue, 10 Jun 2025 14:30:06 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> But then you'd need create an array of `Pair` in `create_search_table` and copy the data into that. You wouldn't need a Supplier at all, just pass the array and its length to the `fill` method. If you are worried about the virtual calls, I could do that.
>> 
>> Alternatively, we could replace virtual calls with templated `fill` method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?
>
> I think you misunderstand me, as what I'm proposing wouldn't requre creating an array in `create_search_table`.
> 
> I'm saying that you do this:
> 
> ```c++
> // Note: we require the supplier to provide the elements in the final order as we can't easily sort
> // within this method - qsort() accepts only pure function as comparator.
> void PackedTableBuilder::fill(u1* table, size_t table_length, Supplier &supplier) const {
>   Pair<uint32_t, uint32_t> kvs[4];
> 
>   size_t offset = 0;
>   size_t len_read = 0;
>   while (len = supplier.next(kvs, 4)) {
>     // len tells you how many of the full capacity of kvs was used.
>   }
> }
> 
> 
> Now each call of  `Supplier::next` gives you up to 4 elements, quartering the amount of virtual calls necessary.
> 
>>Alternatively, we could replace virtual calls with templated fill method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?
> 
> Sure, you can try that out.
> 
> To be clear, I am only asking: Are virtual calls expensive enough here that not having them, or amortizing their cost, something that makes the performance better?

The earlier version of this PR was not abstracting out PackedTable* so there were no virtual calls. In both the CCC.java and undisclosed customer reproducer I don't see a significant difference in performance - these involve whole JVM startup, so the efficiency of code with linear complexity is probably under the radar. If we want to optimize the hack out of it - yes, there would be space for that, maybe at the cost of maintainability and/or reusability.
TLDR: I don't have a (micro)benchmark that would prove one thing is better than the other.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2138174164

From jsjolen at openjdk.org  Tue Jun 10 15:47:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Jun 2025 15:47:44 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v28]
In-Reply-To: <hIgmtj2xldr-bNLjX6jrPE3L3ZVWlkrRvThxZZQR1mQ=.de9dde26-3054-4ecb-bdbf-1bb388e5c367@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <8c1fQTBShvspmR9rxAag6KBqGfLScIAM_fnxObToXpw=.e9e29682-581d-4aeb-bf9f-0bb4538cccea@github.com>
 <OFuKcDIoOrgC_gTBlbnDeafQGidfZmwRJxn0zcJx9dg=.a4784111-d428-4012-be02-f213b931dfcb@github.com>
 <W3vc6NJ1QgYj8UwM8g2y-Zk1O3aics2QvONqclFOKqo=.b55f2c4e-7592-4621-8c5a-016eeec87e0c@github.com>
 <nFVdEId2-mLSvPwD20BV2vspdcKbM6boVsL_ocFapVE=.c6fcfa4e-214c-4e2e-9836-8b3a98db6f9d@github.com>
 <CdzK1qK5yohj3xmeMyst8dc1HBpY_VucQE0FzyRn1Ss=.86ab0e12-1c5b-4b52-9816-77b1d300c0bf@github.com>
 <hIgmtj2xldr-bNLjX6jrPE3L3ZVWlkrRvThxZZQR1mQ=.de9dde26-3054-4ecb-bdbf-1bb388e5c367@github.com>
Message-ID: <PM9RKorjn38J7wHl5yfvgzcNtLBESa1u83MKnuxBgPA=.ae10cb4f-9435-411c-b444-00eeb6f24d54@github.com>

On Tue, 10 Jun 2025 15:15:34 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> I think you misunderstand me, as what I'm proposing wouldn't requre creating an array in `create_search_table`.
>> 
>> I'm saying that you do this:
>> 
>> ```c++
>> // Note: we require the supplier to provide the elements in the final order as we can't easily sort
>> // within this method - qsort() accepts only pure function as comparator.
>> void PackedTableBuilder::fill(u1* table, size_t table_length, Supplier &supplier) const {
>>   Pair<uint32_t, uint32_t> kvs[4];
>> 
>>   size_t offset = 0;
>>   size_t len_read = 0;
>>   while (len = supplier.next(kvs, 4)) {
>>     // len tells you how many of the full capacity of kvs was used.
>>   }
>> }
>> 
>> 
>> Now each call of  `Supplier::next` gives you up to 4 elements, quartering the amount of virtual calls necessary.
>> 
>>>Alternatively, we could replace virtual calls with templated fill method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?
>> 
>> Sure, you can try that out.
>> 
>> To be clear, I am only asking: Are virtual calls expensive enough here that not having them, or amortizing their cost, something that makes the performance better?
>
> The earlier version of this PR was not abstracting out PackedTable* so there were no virtual calls. In both the CCC.java and undisclosed customer reproducer I don't see a significant difference in performance - these involve whole JVM startup, so the efficiency of code with linear complexity is probably under the radar. If we want to optimize the hack out of it - yes, there would be space for that, maybe at the cost of maintainability and/or reusability.
> TLDR: I don't have a (micro)benchmark that would prove one thing is better than the other.

Alright, if you can't observe a difference then don't change a thing :-).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2138248072

From amenkov at openjdk.org  Tue Jun 10 19:07:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 10 Jun 2025 19:07:33 GMT
Subject: Integrated: 8358577: Test
 serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java
 failed: unexpexcted monitor object
In-Reply-To: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
References: <0ZmVmwYDhoFyu0yTNK1QS5JkDKPOpnLoq8FtAxlDgTw=.f6eecd7f-91c0-47fc-b17d-1fb3127fe61c@github.com>
Message-ID: <jEyglvX9qk5jMz65QeCRFCj2tqfLd3Vk_i57_K0PIQs=.3158b99a-bb2a-47a6-94ec-f04c48b047e5@github.com>

On Fri, 6 Jun 2025 23:41:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes race in the test.
> Tested thread is expected to have no contended monitor when main thread checks it, but System.out.println() can cause waiting on a monitor when concurrent printing is performed, so printing should not be performed after signalling main thread to continue.

This pull request has now been integrated.

Changeset: 8f487d26
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f487d26c0f219d4df32be48ff1790e6f98d74a0
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8358577: Test serviceability/jvmti/thread/GetCurrentContendedMonitor/contmon01/contmon01.java failed: unexpexcted monitor object

Reviewed-by: cjplummer, syan, sspitsyn

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

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

From coleenp at openjdk.org  Tue Jun 10 19:11:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Jun 2025 19:11:44 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v29]
In-Reply-To: <-T7PM80uoFrT7wol7RWu6ufJefRPZ-cWuW-qi646dHM=.996db406-7246-49b2-951a-603512194e34@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <-T7PM80uoFrT7wol7RWu6ufJefRPZ-cWuW-qi646dHM=.996db406-7246-49b2-951a-603512194e34@github.com>
Message-ID: <WHoJF1nanBtMswNmCbEejS6chqcnwkDnQtJOhox4BXw=.ad663279-64a9-4d34-b3a1-be71f5d683d2@github.com>

On Tue, 10 Jun 2025 09:30:31 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove __builtin_memcpy
>  - Fix coding style

These files: classFileParser.hpp, fieldStreams.hpp, fieldStreams.inline.hpp and unsigned5.hpp need a copyright update.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2960325865

From cjplummer at openjdk.org  Tue Jun 10 19:23:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Jun 2025 19:23:29 GMT
Subject: RFR: 8358094: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java still times
 out after JDK-8357282
In-Reply-To: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
References: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
Message-ID: <B8HEW2KCtqzkjafjZwiNi5d6kzaVqpHO3VxTtpk2Woo=.f8efad4e-e3a7-4489-9482-6445f3c64887@github.com>

On Sat, 7 Jun 2025 01:11:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test intermittently times out due to deadlock between 2 monitors: one monitor is JVMTI raw monitor used by agents, another is in Java (`nsk_jvmti_aod_disableEventAndFinish` does upcall) See JBS issue for details.
> The fix updates agents to exit raw monitors before upcall.
> 
> Testing: no failures in 1000 runs

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25684#pullrequestreview-2914804285

From cjplummer at openjdk.org  Tue Jun 10 19:37:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Jun 2025 19:37:29 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter
In-Reply-To: <3e2U0lztN76iKtiYtQaDlsPTknjRuubBJCq1azuj1Lk=.0a5e463b-9012-4a03-9a69-b2b0b0c6c601@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <3e2U0lztN76iKtiYtQaDlsPTknjRuubBJCq1azuj1Lk=.0a5e463b-9012-4a03-9a69-b2b0b0c6c601@github.com>
Message-ID: <LXP1LsBVTwpiyDY9p3ZV0gdmaiP7wKMG51DHvQTNB1U=.b3ab1c2d-4a83-464a-a4eb-2c9cf822b297@github.com>

On Tue, 10 Jun 2025 11:03:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
>> I treat this as a bug and doubt we need a CSR for this issue.
>> 
>> Testing: N/A
>
> src/hotspot/share/prims/jvmti.xml line 12874:
> 
>> 12872:       be reset by one of those native methods.
>> 12873:       Similarly, exceptions that are reported as uncaught (<code>catch_method</code>
>> 12874:       and <code>catch_location</code> set to 0) may in fact be caught by native code.
> 
> catch_method is a jmethodID so null if uncaught.

Then you also need to fix:

"If there is no such catch clause, each field is set to 0."

Also, technically speaking, can't `catch_location` be 0 even if caught (caught first the bytecode of the method)? Although I doubt  javac would ever generate such code, it seems it is allowed. If so, then `catch_method == null` is the only check  a user should make.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25710#discussion_r2138638748

From cjplummer at openjdk.org  Tue Jun 10 19:42:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Jun 2025 19:42:29 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v5]
In-Reply-To: <RitQ6bjB4SKDRNupshAyQFNJFeU5bnukCc11lY8pzBg=.4d76d241-8a62-4feb-becc-1a45fc01eb74@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
 <RitQ6bjB4SKDRNupshAyQFNJFeU5bnukCc11lY8pzBg=.4d76d241-8a62-4feb-becc-1a45fc01eb74@github.com>
Message-ID: <MZpJUgOCc-egtKav6DxhC_kwFfuKeCFfg61Lac3upuk=.58e29530-af20-4ba3-8fdf-64987d653bd1@github.com>

On Tue, 10 Jun 2025 06:39:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi David/Chris/Lucy - I added the comments to the tests.

I think the `@comment` should be before the `@requires`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2960393458

From rvansa at openjdk.org  Tue Jun 10 19:44:03 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Tue, 10 Jun 2025 19:44:03 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

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

  Copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24847/files
  - new: https://git.openjdk.org/jdk/pull/24847/files/14f9bdf7..36510e22

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

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

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

From vyazici at openjdk.org  Tue Jun 10 20:34:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 10 Jun 2025 20:34:35 GMT
Subject: RFR: 8357993: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [hotspot] [v2]
In-Reply-To: <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
References: <o30CyAzVmpMbcQ4XPqRwXUGMsmz1Z7PrUFsb6LJ5BQY=.934382b3-9243-4249-9b95-1b3624254c22@github.com>
 <hN-CMuQNNIK2jaO29_Mdls4lJAcwplfjICza0UAcTVg=.1d5227fd-699e-4a49-8a7a-8bca41cab072@github.com>
Message-ID: <2q9j9ODae3SFNCHdS9fpasGuXrm3wWGXip_Fk1NNvIk=.ba677f20-2660-4d93-91e7-6debc0ad4cfd@github.com>

On Mon, 2 Jun 2025 18:39:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357993 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to Hotspot.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding`

I've created

- [8359167](https://bugs.openjdk.org/browse/JDK-8359167): Remove unused test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
- [8359168](https://bugs.openjdk.org/browse/JDK-8359168): Revert stdin.encoding usage in test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java

Used `hotspot` and `test` as `Component/s` and `Subcomponent`, respectively ? hope that is okay. Feel free to update the tickets as you see fit. I will try to pick them up sometime this week.

@plummercj, @AlanBateman, thank you for your assistance and patience. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25542#issuecomment-2960509836

From sspitsyn at openjdk.org  Tue Jun 10 21:15:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 21:15:28 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter
In-Reply-To: <LXP1LsBVTwpiyDY9p3ZV0gdmaiP7wKMG51DHvQTNB1U=.b3ab1c2d-4a83-464a-a4eb-2c9cf822b297@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <3e2U0lztN76iKtiYtQaDlsPTknjRuubBJCq1azuj1Lk=.0a5e463b-9012-4a03-9a69-b2b0b0c6c601@github.com>
 <LXP1LsBVTwpiyDY9p3ZV0gdmaiP7wKMG51DHvQTNB1U=.b3ab1c2d-4a83-464a-a4eb-2c9cf822b297@github.com>
Message-ID: <1_ZzX5NOC8YIn_oKpPBpI62WMNVdVI8JZLMwqpif0Vs=.d4840bcd-80ae-4b70-8b04-ab2424eb7ba5@github.com>

On Tue, 10 Jun 2025 19:35:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmti.xml line 12874:
>> 
>>> 12872:       be reset by one of those native methods.
>>> 12873:       Similarly, exceptions that are reported as uncaught (<code>catch_method</code>
>>> 12874:       and <code>catch_location</code> set to 0) may in fact be caught by native code.
>> 
>> catch_method is a jmethodID so null if uncaught.
>
> Then you also need to fix:
> 
> "If there is no such catch clause, each field is set to 0."
> 
> Also, technically speaking, can't `catch_location` be 0 even if caught (caught first the bytecode of the method)? Although I doubt  javac would ever generate such code, it seems it is allowed. If so, then `catch_method == null` is the only check  a user should make.

Thank you for the comments!
Yes, I've also come to the same conclusion about the only `catch_method == null` check.

> Then you also need to fix:
> "If there is no such catch clause, each field is set to 0."

Good catch, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25710#discussion_r2138777360

From sspitsyn at openjdk.org  Tue Jun 10 21:28:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 10 Jun 2025 21:28:07 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v2]
In-Reply-To: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
Message-ID: <jOvTOSc0lZJnKyn0L74U5-0v1J0nP4AGOLsJUjYo-5Q=.708584fb-afe9-4bfa-9119-e96256569e41@github.com>

> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
> I treat this as a bug and doubt we need a CSR for this issue.
> 
> Testing: N/A

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

  review: 1) only check for catch_method != null 2) replace field with parameter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25710/files
  - new: https://git.openjdk.org/jdk/pull/25710/files/ba775955..021756c5

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

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

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

From cjplummer at openjdk.org  Tue Jun 10 21:39:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 10 Jun 2025 21:39:27 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v2]
In-Reply-To: <jOvTOSc0lZJnKyn0L74U5-0v1J0nP4AGOLsJUjYo-5Q=.708584fb-afe9-4bfa-9119-e96256569e41@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <jOvTOSc0lZJnKyn0L74U5-0v1J0nP4AGOLsJUjYo-5Q=.708584fb-afe9-4bfa-9119-e96256569e41@github.com>
Message-ID: <7lNHdHcyFSaz7pzv_DK7Et_OCv7UrNptxBI3UsvmIkA=.c89d8e57-9de1-4360-9e8e-2d7616125c88@github.com>

On Tue, 10 Jun 2025 21:28:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
>> I treat this as a bug and doubt we need a CSR for this issue.
>> 
>> Testing: N/A
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: 1) only check for catch_method != null 2) replace field with parameter

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25710#pullrequestreview-2915094367

From lmesnik at openjdk.org  Tue Jun 10 22:00:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 10 Jun 2025 22:00:29 GMT
Subject: RFR: 8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp()
 JavaDoc incorrectly documents null
In-Reply-To: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
References: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
Message-ID: <smjtnbTvewG9n56OiCy9KIgFPFKpFWole6lwChJc8mQ=.a93b03b6-4d3a-4823-b266-3d6789268622@github.com>

On Mon, 9 Jun 2025 13:15:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple correction where API docs state a return value may be "null", but in fact this is a result of type long, and may be zero.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25694#pullrequestreview-2915132759

From lmesnik at openjdk.org  Tue Jun 10 22:03:27 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 10 Jun 2025 22:03:27 GMT
Subject: RFR: 8358094: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java still times
 out after JDK-8357282
In-Reply-To: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
References: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
Message-ID: <Bdi0YCpbZMWfsbPh4mgTi6oNuYenqYGLP-Igc0CXsDA=.985f4b9f-49ac-4443-83c7-07fd69e2ced5@github.com>

On Sat, 7 Jun 2025 01:11:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test intermittently times out due to deadlock between 2 monitors: one monitor is JVMTI raw monitor used by agents, another is in Java (`nsk_jvmti_aod_disableEventAndFinish` does upcall) See JBS issue for details.
> The fix updates agents to exit raw monitors before upcall.
> 
> Testing: no failures in 1000 runs

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25684#pullrequestreview-2915134513

From alanb at openjdk.org  Wed Jun 11 06:03:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 06:03:46 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v2]
In-Reply-To: <1_ZzX5NOC8YIn_oKpPBpI62WMNVdVI8JZLMwqpif0Vs=.d4840bcd-80ae-4b70-8b04-ab2424eb7ba5@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <3e2U0lztN76iKtiYtQaDlsPTknjRuubBJCq1azuj1Lk=.0a5e463b-9012-4a03-9a69-b2b0b0c6c601@github.com>
 <LXP1LsBVTwpiyDY9p3ZV0gdmaiP7wKMG51DHvQTNB1U=.b3ab1c2d-4a83-464a-a4eb-2c9cf822b297@github.com>
 <1_ZzX5NOC8YIn_oKpPBpI62WMNVdVI8JZLMwqpif0Vs=.d4840bcd-80ae-4b70-8b04-ab2424eb7ba5@github.com>
Message-ID: <1WQwUmMEMQNcadwD_-27loMxuOwCppkF7-tWKqoSbkw=.59d255ad-9dc1-4a7a-83d6-bf972064e69a@github.com>

On Tue, 10 Jun 2025 21:13:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Then you also need to fix:
>> 
>> "If there is no such catch clause, each field is set to 0."
>> 
>> Also, technically speaking, can't `catch_location` be 0 even if caught (caught first the bytecode of the method)? Although I doubt  javac would ever generate such code, it seems it is allowed. If so, then `catch_method == null` is the only check  a user should make.
>
> Thank you for the comments!
> Yes, I've also come to the same conclusion about the only `catch_method == null` check.
> 
>> Then you also need to fix:
>> "If there is no such catch clause, each field is set to 0."
> 
> Good catch, thanks.
> 
> The suggestions above have addressed now.
> Also, I've replaced the term `field` with `parameter` for consistency in two spots.

I think what you have looks okay now. I'm just wondering about the description for the catch_location parameter has "zero if no known catch". So if catch_method is null then catch_location must be 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25710#discussion_r2139275112

From mbaesken at openjdk.org  Wed Jun 11 06:31:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Jun 2025 06:31:20 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v7]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <OTmOAlgoCWNujhKPavmeKi3bY3mEYBOkvmOsC95nV4c=.1ee1051f-870a-4b02-b913-5edbcea28beb@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  Move test comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/3f64dffe..ea831d95

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

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

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

From mbaesken at openjdk.org  Wed Jun 11 06:31:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Jun 2025 06:31:20 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v5]
In-Reply-To: <MZpJUgOCc-egtKav6DxhC_kwFfuKeCFfg61Lac3upuk=.58e29530-af20-4ba3-8fdf-64987d653bd1@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <YWVeYib_DZpNslIEmxNXYRt8Xa3kzIMKhK1SM8lVLi4=.a4b92bcf-f7ab-43d6-8231-41777d571f2a@github.com>
 <RitQ6bjB4SKDRNupshAyQFNJFeU5bnukCc11lY8pzBg=.4d76d241-8a62-4feb-becc-1a45fc01eb74@github.com>
 <MZpJUgOCc-egtKav6DxhC_kwFfuKeCFfg61Lac3upuk=.58e29530-af20-4ba3-8fdf-64987d653bd1@github.com>
Message-ID: <_tH2_EGdEhvKQ_kpUR5VmamiHrB3Kz7BJJ1bn-1RGRw=.b82617f8-7fb0-4736-922f-ff807982d32f@github.com>

On Tue, 10 Jun 2025 19:39:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> 
> I think the `@comment` should be before the `@requires`.

Yes it seems at most places the comment is in front. I moved the comments .

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2961406162

From vyazici at openjdk.org  Wed Jun 11 10:32:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:32:32 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
Message-ID: <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>

On Thu, 5 Jun 2025 10:13:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve code style
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/javax/script/MyContext.java line 52:

> 50:         engineScope = new SimpleBindings();
> 51:         globalScope = null;
> 52:         reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));

I will revert this change, since

1. AFAICT, this file is not used anymore
2. Neither `std{out,err}.encoding` were used while creating `PrintWriter`s below

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139786341

From vyazici at openjdk.org  Wed Jun 11 10:37:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:37:30 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
Message-ID: <v97kiJfbm4kka6qtgVKr30XtA_BIPRQ26QVLuGdwzJY=.040aee98-63fc-469a-ab1b-d82daf9ecd46@github.com>

On Thu, 5 Jun 2025 10:13:24 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve code style
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/javax/security/auth/login/LoginContext/DefaultHandlerImpl.java line 80:

> 78:                 System.err.flush();
> 79:                 Reader stdinReader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 80:                 nc.setName(new BufferedReader(stdinReader).readLine());

Will revert this change, it is superfluous. As a matter of fact, there is a `readPassword(System.in)` down below that could have also been addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139795483

From vyazici at openjdk.org  Wed Jun 11 10:43:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:43:47 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v6]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

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

  Revert superfluous test changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25544/files
  - new: https://git.openjdk.org/jdk/pull/25544/files/92248bb3..ca96e12b

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

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

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

From vyazici at openjdk.org  Wed Jun 11 10:43:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:43:48 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v5]
In-Reply-To: <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <dBiIbECZisx6iRJ2P0MchwLNY-4Rg9m3VRbBUTTIZ4A=.56ff5fc6-e30f-4ff7-b3f1-c20f401972d2@github.com>
 <E2xTeHEtEObgciaqOrdjj-xGRdq1ZugtdzM7XQFvMvA=.f5defb51-2610-473d-89e7-1f6f178d7b9c@github.com>
Message-ID: <jOged_3bL5xjITokxOe5yzZ-gIUw1VeLnjiyqQrgSn4=.961fb018-8482-45a7-8f67-dad86cb59b23@github.com>

On Wed, 11 Jun 2025 10:29:52 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve code style
>>   
>>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>
> test/jdk/javax/script/MyContext.java line 52:
> 
>> 50:         engineScope = new SimpleBindings();
>> 51:         globalScope = null;
>> 52:         reader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
> 
> I will revert this change, since
> 
> 1. AFAICT, this file is not used anymore
> 2. Neither `std{out,err}.encoding` were used while creating `PrintWriter`s below

Reverted in ca96e12be8e.

> test/jdk/javax/security/auth/login/LoginContext/DefaultHandlerImpl.java line 80:
> 
>> 78:                 System.err.flush();
>> 79:                 Reader stdinReader = new InputStreamReader(System.in, System.getProperty("stdin.encoding"));
>> 80:                 nc.setName(new BufferedReader(stdinReader).readLine());
> 
> Will revert this change, it is superfluous. As a matter of fact, there is a `readPassword(System.in)` down below that could have also been addressed.

Reverted in ca96e12be8e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139804910
PR Review Comment: https://git.openjdk.org/jdk/pull/25544#discussion_r2139804751

From ayang at openjdk.org  Wed Jun 11 11:01:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 11 Jun 2025 11:01:23 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v12]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <8ydE-ymScXytYj65qVxSOmFikkvS90bH5NcvLsfAa7c=.b410d110-0db6-4750-8603-d2de21436263@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - ... and 7 more: https://git.openjdk.org/jdk/compare/56ce70c5...8689b54c

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=11
  Stats: 4373 lines in 31 files changed: 522 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From cjplummer at openjdk.org  Wed Jun 11 11:24:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Jun 2025 11:24:29 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v6]
In-Reply-To: <muABInNSOI0fId-YMlJYHAbG7uI01ZSKdkLBOIHF5kw=.edb02602-fe8f-467a-a82b-514b8a04cbb7@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <muABInNSOI0fId-YMlJYHAbG7uI01ZSKdkLBOIHF5kw=.edb02602-fe8f-467a-a82b-514b8a04cbb7@github.com>
Message-ID: <LntUffjUnvfYfr-uQmimNUUj5xlPwRmG_aKeIoP1ZJo=.138bcff2-55e9-4854-aafb-d24341b9d612@github.com>

On Tue, 10 Jun 2025 06:42:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments to tests

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

> 50:  * @library /test/lib
> 51:  * @requires vm.gc.Z & (os.family == "linux" | os.family == "windows" | os.family == "mac")
> 52:  * @requires !vm.asan

You should duplicate the comment here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2138641241

From coleenp at openjdk.org  Wed Jun 11 11:32:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Jun 2025 11:32:36 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <5nq6TlYli8aYrxOrwRWy5LFM2vvoc21L1PxjS24x4dw=.25030547-4def-4afe-9630-1d7e11fe687c@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

I do not have any further comments.  This change looks good and I believe this is needed to resolve the performance problem.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2916760401

From mbaesken at openjdk.org  Wed Jun 11 11:42:13 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Jun 2025 11:42:13 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v8]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/ea831d95..9aa58582

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

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

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

From vyazici at openjdk.org  Wed Jun 11 12:52:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 12:52:05 GMT
Subject: RFR: 8359168: Revert stdin.encoding usage in
 test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java
Message-ID: <AkboRBqRq-y_DjL7iTDZIDPRUbN5e1fhF28u99s9v9E=.a1c1d43d-5f92-4ca5-b7d2-2ae8c99548c5@github.com>

Revert `stdin.encoding` changes to `test/hotspot/.../attach010Agent00.java` introduced in [JDK-8357993](https://bugs.openjdk.org/browse/JDK-8357993) ? @plummercj [reported](https://github.com/openjdk/jdk/pull/25542#issuecomment-2950447745) that they are unnecessary.

Note that I've reset the copyright year back to 2018.

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

Commit messages:
 - Revert `stdin.encoding` changes to `test/hotspot/.../attach010Agent00.java`

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

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

From lucy at openjdk.org  Wed Jun 11 13:28:31 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 11 Jun 2025 13:28:31 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v8]
In-Reply-To: <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
Message-ID: <9hnk0aeI-KGmzzxAAjkgjuuZT44nOxT73X3rK_86sso=.3b030902-1113-4d26-b9d5-6656732e15fb@github.com>

On Wed, 11 Jun 2025 11:42:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Looks good with the nicely placed @comments.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2917152613

From kevinw at openjdk.org  Wed Jun 11 15:22:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Jun 2025 15:22:42 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode contract
 after deserialization
Message-ID: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>

Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.

The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, they change a class named "immutable).

Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

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

Commit messages:
 - spelling
 - Exception name
 - whitespace
 - whitespace
 - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

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

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

From rvansa at openjdk.org  Wed Jun 11 16:37:37 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 11 Jun 2025 16:37:37 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <-XuFmpo5Oj6x-mKlpgSseo5jJUZdY9GXo2Hm17pue0I=.4da01a2c-2c37-4bb3-a038-467746ad1582@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Thank you! I'll mark this for integration and I would appreciate if I can get your sponsorship.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2963485542

From duke at openjdk.org  Wed Jun 11 16:37:37 2025
From: duke at openjdk.org (duke)
Date: Wed, 11 Jun 2025 16:37:37 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <3dgCL2a6SXMjBzUYCWSPQefrzOKsmWWUZU1A61vLLJA=.5f044d95-02c7-4faa-9dcb-9d075ce33586@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

@rvansa 
Your change (at version 36510e22b25f1792bc53f867c62b1f0f58a2c8fd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2963487411

From iklam at openjdk.org  Wed Jun 11 16:40:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Jun 2025 16:40:39 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <SvZnxQP-guPkCBIFgaDZaR6x6TM7cwAjLuVxespWgHY=.297ec67a-6a85-44cd-b1c9-37cb5f1797bd@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2917965617

From iklam at openjdk.org  Wed Jun 11 17:09:42 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Jun 2025 17:09:42 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <-XuFmpo5Oj6x-mKlpgSseo5jJUZdY9GXo2Hm17pue0I=.4da01a2c-2c37-4bb3-a038-467746ad1582@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
 <-XuFmpo5Oj6x-mKlpgSseo5jJUZdY9GXo2Hm17pue0I=.4da01a2c-2c37-4bb3-a038-467746ad1582@github.com>
Message-ID: <b3GitWhdAITHTuZuRMTq6Xuo9uPsHaM71RGUkgxcWFw=.2256722a-5105-445c-8cc8-c25fd2c977dc@github.com>

On Wed, 11 Jun 2025 16:35:01 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright update
>
> Thank you! I'll mark this for integration and I would appreciate if I can get your sponsorship.

@rvansa the base version of this PR is quite old. Please merge with the latest JDK repo before we integrate it into the mainline.

How much testing have you done on your side? On what platforms?

After you merge, someone at Oracle will run it on our testing pipeline and will sponsor it after all tests are clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2963573573

From cjplummer at openjdk.org  Wed Jun 11 17:11:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Jun 2025 17:11:31 GMT
Subject: RFR: 8359168: Revert stdin.encoding usage in
 test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java
In-Reply-To: <AkboRBqRq-y_DjL7iTDZIDPRUbN5e1fhF28u99s9v9E=.a1c1d43d-5f92-4ca5-b7d2-2ae8c99548c5@github.com>
References: <AkboRBqRq-y_DjL7iTDZIDPRUbN5e1fhF28u99s9v9E=.a1c1d43d-5f92-4ca5-b7d2-2ae8c99548c5@github.com>
Message-ID: <BUA1dlkMp2appDvre_V-RYvadglMMw6lJ_V14zOcih4=.d822a0da-3e90-474b-84f8-0778c4ee4cef@github.com>

On Wed, 11 Jun 2025 12:47:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Revert `stdin.encoding` changes to `test/hotspot/.../attach010Agent00.java` introduced in [JDK-8357993](https://bugs.openjdk.org/browse/JDK-8357993) ? @plummercj [reported](https://github.com/openjdk/jdk/pull/25542#issuecomment-2950447745) that they are unnecessary.
> 
> Note that I've reset the copyright year back to 2018.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25753#pullrequestreview-2918057295

From coleenp at openjdk.org  Wed Jun 11 17:18:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Jun 2025 17:18:40 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <JSk3wcNuM_RFm2kBuL9RDtFYsDRVJKcZbC1Utksebsk=.ae4c1aca-c927-474f-9519-6442b9b31e41@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

I've been testing this against mainline source base -with just this change patched in and it seems fine.  I don't know if it's worth merging.  Also if you do merge it do 'git merge' not 'git rebase'  I'm rerunning tier1-7 now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2963594231

From cjplummer at openjdk.org  Wed Jun 11 17:45:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Jun 2025 17:45:33 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v8]
In-Reply-To: <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
Message-ID: <vQVsbAFEsAZAAfcqPSfMxyRZZIHlUDs7voEqiSaX-NA=.08c98655-3e87-4fee-86d3-782836b47688@github.com>

On Wed, 11 Jun 2025 11:42:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

I'm just giving my approval for how the comments are being handled. I haven't looked at the implementation details, nor for the correctness of the comments. With the updates svc tests are no longer part of this PR.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2918156391

From iklam at openjdk.org  Wed Jun 11 17:46:37 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Jun 2025 17:46:37 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <JSk3wcNuM_RFm2kBuL9RDtFYsDRVJKcZbC1Utksebsk=.ae4c1aca-c927-474f-9519-6442b9b31e41@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
 <JSk3wcNuM_RFm2kBuL9RDtFYsDRVJKcZbC1Utksebsk=.ae4c1aca-c927-474f-9519-6442b9b31e41@github.com>
Message-ID: <FAX6ohc3MFwqwd2vH-Jf4j0ekqaOyAAwvMV-8KIZVD4=.bfc2b64a-19f3-4502-9a2f-749d606dddd6@github.com>

On Wed, 11 Jun 2025 17:15:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I've been testing this against mainline source base -with just this change patched in and it seems fine. I don't know if it's worth merging. Also if you do merge it do 'git merge' not 'git rebase' I'm rerunning tier1-7 now.

@rvansa since Coleen is already testing against the mainline, there's no need for you to merge now. We will sponsor once the tests come out clean.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2963670758

From serb at openjdk.org  Wed Jun 11 18:05:44 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 18:05:44 GMT
Subject: RFR: 8359180: Apply java.io.Serial annotations in java.instrument
Message-ID: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>

Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.instrument module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.

This annotation can be applied to these methods in the module:

private void writeObject(java.io.ObjectOutputStream stream) throws IOException
private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
private void readObjectNoData() throws ObjectStreamException
ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
private static final ObjectStreamField[] serialPersistentFields
private static final long serialVersionUID


Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module.

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

Commit messages:
 - 8359180: Apply java.io.Serial annotations in java.instrument

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

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

From sspitsyn at openjdk.org  Wed Jun 11 18:12:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Jun 2025 18:12:49 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v3]
In-Reply-To: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
Message-ID: <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>

> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
> I treat this as a bug and doubt we need a CSR for this issue.
> 
> Testing: N/A

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

  review: add clarification for catch_location == 0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25710/files
  - new: https://git.openjdk.org/jdk/pull/25710/files/021756c5..ad760f49

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

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

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

From sspitsyn at openjdk.org  Wed Jun 11 18:12:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Jun 2025 18:12:50 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v3]
In-Reply-To: <1WQwUmMEMQNcadwD_-27loMxuOwCppkF7-tWKqoSbkw=.59d255ad-9dc1-4a7a-83d6-bf972064e69a@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <3e2U0lztN76iKtiYtQaDlsPTknjRuubBJCq1azuj1Lk=.0a5e463b-9012-4a03-9a69-b2b0b0c6c601@github.com>
 <LXP1LsBVTwpiyDY9p3ZV0gdmaiP7wKMG51DHvQTNB1U=.b3ab1c2d-4a83-464a-a4eb-2c9cf822b297@github.com>
 <1_ZzX5NOC8YIn_oKpPBpI62WMNVdVI8JZLMwqpif0Vs=.d4840bcd-80ae-4b70-8b04-ab2424eb7ba5@github.com>
 <1WQwUmMEMQNcadwD_-27loMxuOwCppkF7-tWKqoSbkw=.59d255ad-9dc1-4a7a-83d6-bf972064e69a@github.com>
Message-ID: <NbuiilwryjT9OuelGfcgGfKbaTvUcYITlLG2fC7GEWA=.55d81d1c-3401-41a0-b9f7-6287fb1aef75@github.com>

On Wed, 11 Jun 2025 06:00:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you for the comments!
>> Yes, I've also come to the same conclusion about the only `catch_method == null` check.
>> 
>>> Then you also need to fix:
>>> "If there is no such catch clause, each field is set to 0."
>> 
>> Good catch, thanks.
>> 
>> The suggestions above have addressed now.
>> Also, I've replaced the term `field` with `parameter` for consistency in two spots.
>
> I think what you have looks okay now. I'm just wondering about the description for the catch_location parameter has "zero if no known catch". So if catch_method is null then catch_location must be 0.

Thank you, Alan. I've updated the event description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25710#discussion_r2140791431

From alanb at openjdk.org  Wed Jun 11 18:39:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 18:39:32 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v3]
In-Reply-To: <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>
Message-ID: <7LgMMgIW-mm0MIJ5kcr6xLwqooO4qI1zDNRptlhvdhE=.b17d1ec0-721b-47c3-af91-924d632c1877@github.com>

On Wed, 11 Jun 2025 18:12:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
>> I treat this as a bug and doubt we need a CSR for this issue.
>> 
>> Testing: N/A
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add clarification for catch_location == 0

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25710#pullrequestreview-2918308260

From cjplummer at openjdk.org  Wed Jun 11 18:45:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Jun 2025 18:45:27 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v3]
In-Reply-To: <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>
Message-ID: <2UEDtJBtuJ73dOL46-iH8fA1L9ay1UXHTVnmW3prHM4=.6cad3a30-2d07-485b-96bc-a5df047d6171@github.com>

On Wed, 11 Jun 2025 18:12:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
>> I treat this as a bug and doubt we need a CSR for this issue.
>> 
>> Testing: N/A
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add clarification for catch_location == 0

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25710#pullrequestreview-2918324098

From sspitsyn at openjdk.org  Wed Jun 11 18:54:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Jun 2025 18:54:33 GMT
Subject: RFR: 8358815: Exception event spec has stale reference to
 catch_klass parameter [v3]
In-Reply-To: <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
 <l6UX1pInWk-T1tAjqL5tNVneDYiZqOrsxLIOq0qDm6M=.50cf1696-096f-4e39-a869-6c135e8bc090@github.com>
Message-ID: <BRcfnUcO1wD6ckRLp2M_EWHFQmvyu9Y6eaBJONPHzYo=.cdf5b5af-25b3-4935-a371-206fcbc2c031@github.com>

On Wed, 11 Jun 2025 18:12:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
>> I treat this as a bug and doubt we need a CSR for this issue.
>> 
>> Testing: N/A
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add clarification for catch_location == 0

Alan and Chris, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25710#issuecomment-2963840971

From sspitsyn at openjdk.org  Wed Jun 11 18:54:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Jun 2025 18:54:33 GMT
Subject: Integrated: 8358815: Exception event spec has stale reference to
 catch_klass parameter
In-Reply-To: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
References: <vLwG-xUo7AuKHDFAGTEoJrU4Z-2Ed4_DVSnr9BKAIu4=.92ae02bc-0db2-4ce9-a794-3811f33e5ab4@github.com>
Message-ID: <Iz4vC08hJ9VCotxZLvAU3kA_Hf3epWsW9zqaeqcHmdY=.39cf7947-8351-4b0e-a44c-3f17f2d0e179@github.com>

On Tue, 10 Jun 2025 07:17:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI Exception event callback spec refers to the `catch_klass` parameter which does not exist anymore. Instead the Exception event callback spec should refer to the `catch_method` and `catch_location` parameters.
> I treat this as a bug and doubt we need a CSR for this issue.
> 
> Testing: N/A

This pull request has now been integrated.

Changeset: 8f733570
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f733570040a7d7a24775e72244f47e946af191b
Stats:     6 lines in 1 file changed: 1 ins; 0 del; 5 mod

8358815: Exception event spec has stale reference to catch_klass parameter

Reviewed-by: cjplummer, alanb

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

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

From lmesnik at openjdk.org  Wed Jun 11 20:33:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 11 Jun 2025 20:33:29 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v8]
In-Reply-To: <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
Message-ID: <l_4DxeXe7L6bIypaWWojOuIQc3o9sRW4jA2jHKbwcjU=.e2420c90-65ce-4e1d-8d87-5bb9204a3182@github.com>

On Wed, 11 Jun 2025 11:42:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2918587183

From sspitsyn at openjdk.org  Wed Jun 11 21:14:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Jun 2025 21:14:30 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v8]
In-Reply-To: <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
Message-ID: <96XsVjWh2yOjtHrdPEzBDmiTe0t3TdrNq288WZ4Dyg8=.6ba138e9-e616-4fda-b012-14c2d9c7805c@github.com>

On Wed, 11 Jun 2025 11:42:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

This looks good. I've posted one nit though.

src/hotspot/share/prims/whitebox.hpp line 77:

> 75:   static bool is_asan_enabled();
> 76:   static bool is_ubsan_enabled();
> 77: };

Nit: I'd suggest to add a short comments explaining what `asan` and `ubsan` mean.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2918761842
PR Review Comment: https://git.openjdk.org/jdk/pull/25575#discussion_r2141125695

From syan at openjdk.org  Thu Jun 12 02:29:30 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 12 Jun 2025 02:29:30 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v8]
In-Reply-To: <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <5V3KDrOL5tc0ay5zbkGeGhY59491l5USEZjCG1kjjWA=.1e124b44-da11-4af4-a5b6-94c53e7860a8@github.com>
Message-ID: <tXlQat6dBkrmod54oA0uXMCLDNbub6HbWAWmNnzFGyU=.88bbafa1-b5f4-444d-ba58-cb3e628ce18f@github.com>

On Wed, 11 Jun 2025 11:42:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Thanks for fixing this.

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2919282949

From mbaesken at openjdk.org  Thu Jun 12 05:44:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Jun 2025 05:44:45 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v9]
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25575/files
  - new: https://git.openjdk.org/jdk/pull/25575/files/9aa58582..62a389d7

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

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

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

From mbaesken at openjdk.org  Thu Jun 12 06:51:35 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Jun 2025 06:51:35 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v9]
In-Reply-To: <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>
Message-ID: <cdci_xBh3mWVtHOdVCsnIeYQdRANFiQFVTvZ1Sx2HMM=.415e0325-dc15-4afb-8b6b-b622a73ab382@github.com>

On Thu, 12 Jun 2025 05:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Thanks for the reviews !
Need a re - review now because of the comment change .

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

PR Comment: https://git.openjdk.org/jdk/pull/25575#issuecomment-2965331120

From amitkumar at openjdk.org  Thu Jun 12 06:59:32 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 12 Jun 2025 06:59:32 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v9]
In-Reply-To: <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>
Message-ID: <xz7UnymuuPdTsDocoLymhRUsk6dPllcpWBcjrkAvaKU=.806846c1-05b3-42d7-9a35-f7a0166a114a@github.com>

On Thu, 12 Jun 2025 05:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by amitkumar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2919765059

From sspitsyn at openjdk.org  Thu Jun 12 07:08:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 12 Jun 2025 07:08:34 GMT
Subject: RFR: 8357826: Avoid running some jtreg tests when asan is
 configured [v9]
In-Reply-To: <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
 <FHMTrPkyGsGi8_i_iJMsdtiptPdeyXUtdH0N3mmgiII=.9b87bf69-95ce-414f-b616-16b7e0b7eef9@github.com>
Message-ID: <j8WGctpyNSRDuHiktBHqTi5ibr1OZ3WmQ2evdJ2f9QA=.8d1c24b7-6571-465d-8b0b-e0a255540f4a@github.com>

On Thu, 12 Jun 2025 05:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
>> Those fail when the address sanitizer is configured ( --enable-asan ).
>> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
>> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
>> While at it, also same is also added for ubsan .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25575#pullrequestreview-2919792257

From mbaesken at openjdk.org  Thu Jun 12 07:11:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Jun 2025 07:11:37 GMT
Subject: Integrated: 8357826: Avoid running some jtreg tests when asan is
 configured
In-Reply-To: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
References: <2VOsPdnaamydEfe2I-79af90nn9xlaRXULKEzrDHkGk=.7b237cd6-0a12-4ec2-8467-4177084b4468@github.com>
Message-ID: <dNstiBwB__7TKV5tKLkNP_IIEHyQw3ORLOb6ZcRjsy8=.8ebbe5b6-c51a-4df2-b10f-f64ad5b902e9@github.com>

On Mon, 2 Jun 2025 07:25:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of jtreg tests, especially in the HS area, with very special assumptions about memory layout/sizes .
> Those fail when the address sanitizer is configured ( --enable-asan ).
> The change adds a way to tag those tests with 'requires' so that they can be avoided easily when running jtreg tests with ASAN enabled.
> Adjusting the tests for "pleasing" the sanitizer is not always desired (if possible for some tests it can be done later) .
> While at it, also same is also added for ubsan .

This pull request has now been integrated.

Changeset: d7aa3498
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7aa34982053bad37b3b726539f1245d054258f4
Stats:     64 lines in 12 files changed: 62 ins; 0 del; 2 mod

8357826: Avoid running some jtreg tests when asan is configured

Reviewed-by: sspitsyn, amitkumar, lmesnik, syan, lucy, cjplummer

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

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

From kevinw at openjdk.org  Thu Jun 12 08:09:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Jun 2025 08:09:04 GMT
Subject: RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
Message-ID: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>

Removal of an obscure historical feature, following on from its deprecation for removal in:

8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

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

Commit messages:
 - 8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport

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

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

From jsjolen at openjdk.org  Thu Jun 12 12:25:43 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 12 Jun 2025 12:25:43 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <8QrMgCDug6daTsW-P_4wDGKMHHoXxsgs1LHmxX44J5s=.01069d54-cac2-47d2-bfc6-480b295285fd@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Thanks for the good and patient work.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24847#pullrequestreview-2920919102

From coleenp at openjdk.org  Thu Jun 12 12:25:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Jun 2025 12:25:44 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <9xa9l6ZpE8Pshkn0zMrS9G849EpAiWHqi1A5rSS2g7g=.8abd3caa-ef62-4397-a83a-df0011563647@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Tier1 on oracle platforms passsed, and tier1-7 have passed with yesterdays OpenJDK code and this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2966487473

From coleenp at openjdk.org  Thu Jun 12 12:31:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Jun 2025 12:31:54 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <-XuFmpo5Oj6x-mKlpgSseo5jJUZdY9GXo2Hm17pue0I=.4da01a2c-2c37-4bb3-a038-467746ad1582@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
 <-XuFmpo5Oj6x-mKlpgSseo5jJUZdY9GXo2Hm17pue0I=.4da01a2c-2c37-4bb3-a038-467746ad1582@github.com>
Message-ID: <q1ThSPyAw7pHQ_km-IIt4FVL1oUJBQ0c4wFr1kO388g=.3f5b0955-6c94-4942-a3c2-f9130af2543b@github.com>

On Wed, 11 Jun 2025 16:35:01 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright update
>
> Thank you! I'll mark this for integration and I would appreciate if I can get your sponsorship.

@rvansa  thank you for your work on this change, fixing the performance regression in an understandable way and answering all comments and questions. I think it's ready to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2966506671

From rvansa at openjdk.org  Thu Jun 12 12:31:55 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Thu, 12 Jun 2025 12:31:55 GMT
Subject: Integrated: 8352075: Perf regression accessing fields
In-Reply-To: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
Message-ID: <zyolHo4iEssNzKIi8EuzOP8872ebRuRoHbsB61_dkfc=.21d0d406-2e09-45c0-8914-0136d69a1292@github.com>

On Thu, 24 Apr 2025 10:37:56 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
> 
> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
> 
> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
> 
> My measurements on the attached reproducer
> 
> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
> 
> (the jdk25-master above already contains JDK-8353175)
> 
> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
> 
> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
> 
> JDK 17: 1.6 s
> JDK 21 (no patches): 22 s
> JDK25-master: 12.3 s
> JDK25-this-pr: 0.5 s

This pull request has now been integrated.

Changeset: e18277b4
Author:    Radim Vansa <rvansa at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604
Stats:     924 lines in 18 files changed: 854 ins; 20 del; 50 mod

8352075: Perf regression accessing fields

Reviewed-by: coleenp, iklam, jsjolen

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

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

From coleenp at openjdk.org  Thu Jun 12 12:45:16 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Jun 2025 12:45:16 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
Message-ID: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>

This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.

The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.

Tested with tier1-4, 5-7.

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

Commit messages:
 - 8305626: Kitchensink7D.java failing because of native memory exhausting with ZGC

Changes: https://git.openjdk.org/jdk/pull/25267/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8268406
  Stats: 596 lines in 14 files changed: 315 ins; 223 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

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

From adinn at openjdk.org  Thu Jun 12 13:03:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 12 Jun 2025 13:03:47 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <dzcmhbedt7VeBc5HaAj8kpfTkFa_1KElBN6cDwoP2bc=.3082944a-a49e-401d-8db3-6f9bf92adc92@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Nice work, Radim! Thanks for persevering with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2966624330

From sspitsyn at openjdk.org  Thu Jun 12 15:45:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 12 Jun 2025 15:45:31 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <DZQixaLUSUELzuaGnrZrS5EjQq-dspkXwUygx871vgY=.8fca68cf-d8d1-4ac3-b78d-a34f0bd4ecdf@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25674#pullrequestreview-2921744730

From kevinw at openjdk.org  Thu Jun 12 15:54:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Jun 2025 15:54:33 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <hWcMsosaKNLfstoj8OX_SLnIGagbiRsxWq085E-yDoU=.0fc63f09-785d-460c-9983-95a1524e43bb@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2967379446

From coleenp at openjdk.org  Thu Jun 12 15:57:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Jun 2025 15:57:34 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <BU0NUZ6s76vZDuwxHKRAu5kUe28UybkF4qScFeC_T9U=.c2cc673c-1cdb-4747-9989-ad86f4e5b521@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Also, this was @fisk 's idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2967389860

From sroy at openjdk.org  Thu Jun 12 16:07:09 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 12 Jun 2025 16:07:09 GMT
Subject: RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
Message-ID: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>

JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)

c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)

This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.

Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.

Similarly for c2_globals.hpp &etc.

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

Commit messages:
 - Update c2_globals.hpp
 - c1 header
 - global headers

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

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

From mhaessig at openjdk.org  Thu Jun 12 16:53:30 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 12 Jun 2025 16:53:30 GMT
Subject: RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <SlD-5xgjDNawUTjiEnA3hum1jq3bXCdrOLCVfXFuNwk=.e0bd6eec-5f49-43c7-b152-fd4e9a1cfd6d@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

Thank you for working on this, @suchismith1993! Good to see the includes cleaned up.

This looks good to me, but I nevertheless kicked off some testing on our side. I will let you know how it went when the results are in.

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

PR Review: https://git.openjdk.org/jdk/pull/25773#pullrequestreview-2921960450

From vyazici at openjdk.org  Thu Jun 12 17:15:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 17:15:34 GMT
Subject: RFR: 8359168: Revert stdin.encoding usage in
 test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java
In-Reply-To: <BUA1dlkMp2appDvre_V-RYvadglMMw6lJ_V14zOcih4=.d822a0da-3e90-474b-84f8-0778c4ee4cef@github.com>
References: <AkboRBqRq-y_DjL7iTDZIDPRUbN5e1fhF28u99s9v9E=.a1c1d43d-5f92-4ca5-b7d2-2ae8c99548c5@github.com>
 <BUA1dlkMp2appDvre_V-RYvadglMMw6lJ_V14zOcih4=.d822a0da-3e90-474b-84f8-0778c4ee4cef@github.com>
Message-ID: <OH6D2AdAkU47vD4OWmtHzDS7lkwmgT_DiJrt-Egqwzw=.2beca4c5-cd45-4b72-a7c2-0517df356762@github.com>

On Wed, 11 Jun 2025 17:09:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Revert `stdin.encoding` changes to `test/hotspot/.../attach010Agent00.java` introduced in [JDK-8357993](https://bugs.openjdk.org/browse/JDK-8357993) ? @plummercj [reported](https://github.com/openjdk/jdk/pull/25542#issuecomment-2950447745) that they are unnecessary.
>> 
>> Note that I've reset the copyright year back to 2018.
>
> Looks good.

@plummercj, thanks so much for the prompt review. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25753#issuecomment-2967619396

From vyazici at openjdk.org  Thu Jun 12 17:15:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 17:15:34 GMT
Subject: Integrated: 8359168: Revert stdin.encoding usage in
 test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java
In-Reply-To: <AkboRBqRq-y_DjL7iTDZIDPRUbN5e1fhF28u99s9v9E=.a1c1d43d-5f92-4ca5-b7d2-2ae8c99548c5@github.com>
References: <AkboRBqRq-y_DjL7iTDZIDPRUbN5e1fhF28u99s9v9E=.a1c1d43d-5f92-4ca5-b7d2-2ae8c99548c5@github.com>
Message-ID: <nxdH2wICDqixqmzPQmUhxuvUA-GBujwNcuGQ91eGVcA=.9f33e74e-ec24-4078-80e6-d1733aaeddb6@github.com>

On Wed, 11 Jun 2025 12:47:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Revert `stdin.encoding` changes to `test/hotspot/.../attach010Agent00.java` introduced in [JDK-8357993](https://bugs.openjdk.org/browse/JDK-8357993) ? @plummercj [reported](https://github.com/openjdk/jdk/pull/25542#issuecomment-2950447745) that they are unnecessary.
> 
> Note that I've reset the copyright year back to 2018.

This pull request has now been integrated.

Changeset: 0ef09867
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ef0986731c23b00510e9501e1627b7712a45b65
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8359168: Revert stdin.encoding usage in test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java

Reviewed-by: cjplummer

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

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

From cjplummer at openjdk.org  Thu Jun 12 18:06:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 12 Jun 2025 18:06:39 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
Message-ID: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>

The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:

[JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers

There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".

Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.

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

Commit messages:
 - Remove unused BindServer and update comments related to remote and manually started debugees

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

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

From naoto at openjdk.org  Thu Jun 12 20:08:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 20:08:31 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v6]
In-Reply-To: <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <7XLzfBmB2raJzcZP4NtaaWxQX2gYDrdd8Z1FzhTRmTg=.cfe1fb59-e062-45c4-9410-f5164c2cf479@github.com>
Message-ID: <Z13w_jQPyUsasMyTRcXDJDwdlCNZImVLdJz9xUjY_rg=.5b78eb62-0344-4ebf-9c34-98e4b471dea7@github.com>

On Wed, 11 Jun 2025 10:43:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert superfluous test changes

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25544#pullrequestreview-2922513387

From kevinw at openjdk.org  Thu Jun 12 20:09:37 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Jun 2025 20:09:37 GMT
Subject: Integrated: 8358701: Remove misleading javax.management.remote API doc
 wording about JMX spec, and historic link to JMXMP
In-Reply-To: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
References: <tZ17uqVPNaudkcA0ywfOWwnzN4bNEDqsU3tzMw6yOpo=.7a2269a0-ab31-497d-b7f6-2778ace034d1@github.com>
Message-ID: <lxoJ73CfeZToTOpsYu9E0PGz58Dxt0XevRFqrqjXVys=.5ecf7e81-ecad-4964-8fa4-af72f435605b@github.com>

On Fri, 6 Jun 2025 07:54:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Doc-only cleanup, not part of the API/spec.
> 
> Remove link to the very old reference implementation of JMXMP in the Javadoc.  This may misleadingly imply it is a supported part of the JDK.

This pull request has now been integrated.

Changeset: 66535fe2
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/66535fe26da27dfaf0940bd70deb30942f7d0cdc
Stats:     27 lines in 1 file changed: 0 ins; 18 del; 9 mod

8358701: Remove misleading javax.management.remote API doc wording about JMX spec, and historic link to JMXMP

Reviewed-by: alanb, sspitsyn

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

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

From kevinw at openjdk.org  Thu Jun 12 20:26:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Jun 2025 20:26:33 GMT
Subject: RFR: 8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp()
 JavaDoc incorrectly documents null
In-Reply-To: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
References: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
Message-ID: <i2L0kC57C1SWamm_6EQ4gk5KjR-VqodVVg6HagnkQMs=.699a861e-cd41-44c2-937d-f74fbbe6b6f0@github.com>

On Mon, 9 Jun 2025 13:15:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple correction where API docs state a return value may be "null", but in fact this is a result of type long, and may be zero.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25694#issuecomment-2968061130

From kevinw at openjdk.org  Thu Jun 12 20:26:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Jun 2025 20:26:34 GMT
Subject: Integrated: 8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp()
 JavaDoc incorrectly documents null
In-Reply-To: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
References: <q9fDtLETrM1NIOG3_UP3oNEa3wDTJaZHFbDY32QHUhY=.e00054e8-b1f7-495f-b8a8-24535840f1f3@github.com>
Message-ID: <tTjUEQ8IaCyEImn4fWgqkXTZYveNelA0xAILiNhTm8E=.5eb21724-5491-4c52-b49e-ab98138dce31@github.com>

On Mon, 9 Jun 2025 13:15:27 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple correction where API docs state a return value may be "null", but in fact this is a result of type long, and may be zero.

This pull request has now been integrated.

Changeset: 523a4efe
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/523a4efe1ce2231edd7019043a49f7bf0a0f6aef
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8358970: CounterMonitorMBean.getDerivedGaugeTimeStamp() JavaDoc incorrectly documents null

Reviewed-by: sspitsyn, lmesnik

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

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

From wkemper at openjdk.org  Thu Jun 12 23:46:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Jun 2025 23:46:36 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
Message-ID: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>

We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

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

Commit messages:
 - Fix typo
 - Clean up/fix gc causes for Shenandoah

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

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

From wkemper at openjdk.org  Fri Jun 13 00:15:29 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Jun 2025 00:15:29 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <p9BzwURqdvou-U1L4pPs5O-kir0JqOJcpWEoKMsOF9g=.e3e7f924-60bd-456a-99ac-cae5c9226e6f@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

src/hotspot/share/gc/shared/gcCause.cpp line 92:

> 90:       return "Diagnostic Command";
> 91: 
> 92:     case _shenandoah_stop_vm:

Just reordered this case to match enum's declaration order.

src/hotspot/share/gc/shared/gcCause.hpp line 118:

> 116:   inline static bool is_allocation_failure_gc(GCCause::Cause cause) {
> 117:     // _allocation_failure is the generic cause a collection for allocation failure
> 118:     return cause == GCCause::_allocation_failure;

Shenandoah does not use this method. Nobody else needs to know about this Shenandoah specific value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2143900441
PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2143904488

From kbarrett at openjdk.org  Fri Jun 13 06:29:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Jun 2025 06:29:28 GMT
Subject: RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <wb2jgX5PIpkRu7SJGj4noJpsgWqtWE80L1binY_S4Yw=.ad836c4d-48f0-4f04-966e-138ab2d2418b@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25773#pullrequestreview-2923554527

From vyazici at openjdk.org  Fri Jun 13 08:15:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 08:15:44 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v7]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <8Cr08eX4jZi0YBrIUAWJqV8q3xZxdSCvm7t6_4ch-Jw=.299b1af4-e363-4669-9f3c-8f37d27bc068@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge remote-tracking branch 'upstream/master' into stdinEnc-core
 - Revert superfluous test changes
 - Improve code style
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Fix missing `java.io.Reader` import in `Ktab`
 - Clean-up `MultiBreakpointsTarg`
 - Provide fallback for `stdin.encoding`
 - Revert changes to `Application` and `JavaChild`
   
   There stdin is connected to the parent process rather than the console.
 - Revert more superfluous changes
 - Fix code typo
 - Discard changes unrelated with core libraries
 - ... and 4 more: https://git.openjdk.org/jdk/compare/9aeacf2d...d36e0bd5

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

Changes: https://git.openjdk.org/jdk/pull/25544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25544&range=06
  Stats: 130 lines in 11 files changed: 33 ins; 28 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/25544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25544/head:pull/25544

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

From mhaessig at openjdk.org  Fri Jun 13 09:01:36 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 13 Jun 2025 09:01:36 GMT
Subject: RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <7iAduRwCTEhdlLrawIwYXAM4k5l5PRY7090XOYJeheE=.c279c29b-8316-4551-852c-d44bb8fe058a@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

Testing passed. Ship it!

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

Marked as reviewed by mhaessig (Author).

PR Review: https://git.openjdk.org/jdk/pull/25773#pullrequestreview-2923939477

From duke at openjdk.org  Fri Jun 13 09:17:30 2025
From: duke at openjdk.org (duke)
Date: Fri, 13 Jun 2025 09:17:30 GMT
Subject: RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <mMw3eJ099udlNfLFQP0jUmY1BUy2GYsVmXGmTYX1mDc=.ea38f68e-fcc0-48d2-850d-2ad81db0ecc2@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

@suchismith1993 
Your change (at version 993ee2632f0e7be6a6eb40d22a98c4e8d5da29e2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25773#issuecomment-2969667508

From kevinw at openjdk.org  Fri Jun 13 09:44:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Jun 2025 09:44:13 GMT
Subject: [jdk25] RFR: 8358701: Remove misleading javax.management.remote API
 doc wording about JMX spec, and historic link to JMXMP
Message-ID: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>

8358701: Remove misleading javax.management.remote API doc wording about JMX spec, and historic link to JMXMP

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

Commit messages:
 - Backport 66535fe26da27dfaf0940bd70deb30942f7d0cdc

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

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

From shade at openjdk.org  Fri Jun 13 09:45:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 09:45:29 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <yX3ItHkBc8Rt7jI6Iu8bQMODtI-SrtMZ4ZbA4MGqvpc=.1bb654f5-cadb-4447-8769-0b459ed1ef91@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

Shenandoah parts look good, but we should avoid changing shared code unnecessarily.

Changes requested by shade (Reviewer).

src/hotspot/share/gc/shared/gcCause.hpp line 58:

> 56:     /* implementation independent, but reserved for GC use */
> 57:     _no_gc,
> 58:     _no_cause_specified,

Code history shows this enum was there since the beginning of OpenJDK. So it is better to leave it alone. It is also less confusing to have only Shenandoah-specific changes in RFE that starts with "Shenandoah: ..."

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

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2924090662
PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2924091681
PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2144632935

From rvansa at openjdk.org  Fri Jun 13 10:28:46 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Fri, 13 Jun 2025 10:28:46 GMT
Subject: RFR: 8352075: Perf regression accessing fields [v30]
In-Reply-To: <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
References: <0FXlc_4Zi2WDj-f3MVkUT4farzZJqvCP1CIgRVjbkK8=.3acf7aab-8cd8-494d-962a-340447efe39a@github.com>
 <3vrqqpyldDrHFM_usZFBAnRMq00ftXuPaPRqjONzDMc=.f850ebdf-c4e5-44a0-a160-5b52505b05d4@github.com>
Message-ID: <tN6x_vM9s0AnyHPAtAfFZKYFcJNOX7S4CCyxHTnP8r4=.ca055922-0b1e-447d-85cf-ac657b83cb44@github.com>

On Tue, 10 Jun 2025 19:44:03 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This optimization is a followup to https://github.com/openjdk/jdk/pull/24290 trying to reduce the performance regression in some scenarios introduced in https://bugs.openjdk.org/browse/JDK-8292818 . Based both on performance and memory consumption it is a (better) alternative to https://github.com/openjdk/jdk/pull/24713 .
>> 
>> This PR optimizes local field lookup in classes with more than 16 fields; rather than sequentially iterating through all fields during lookup we sort the fields based on the field name. The stream includes extra table after the field information: for field at position 16, 32 ... we record the (variable-length-encoded) offset of the field info in this stream. On field lookup, rather than iterating through all fields, we iterate through this table, resolve names for given fields and continue field-by-field iteration only after the last record (hence at most 16 fields).
>> 
>> In classes with <= 16 fields this PR reduces the memory consumption by 1 byte that was left with value 0 at the end of stream. In classes with > 16 fields we add extra 4 bytes with offset of the table, and the table contains one varint for each 16 fields. The terminal byte is not used either.
>> 
>> My measurements on the attached reproducer
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk-17/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk-17/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      51.3 ms ?   2.8 ms    [User: 44.7 ms, System: 13.7 ms]
>>   Range (min ? max):    45.1 ms ?  53.9 ms    100 runs
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-master/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-master/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      78.2 ms ?   1.0 ms    [User: 74.6 ms, System: 17.3 ms]
>>   Range (min ? max):    73.8 ms ?  79.7 ms    100 runs
>> 
>> (the jdk25-master above already contains JDK-8353175)
>> 
>> hyperfine -w 50 -r 100 '/path/to/jdk25-this-pr/bin/java -cp /tmp CCC'
>> Benchmark 1: /path/to/jdk25-this-pr/jdk/bin/java -cp /tmp CCC
>>   Time (mean ? ?):      38.5 ms ?   0.5 ms    [User: 34.4 ms, System: 17.3 ms]
>>   Range (min ? max):    37.7 ms ?  42.1 ms    100 runs
>> 
>> While https://github.com/openjdk/jdk/pull/24713 returned the performance to previous levels, this PR improves it by 25% compared to JDK 17 (which does not contain the regression)! This time, the undisclosed production-grade reproducer shows even higher improvement:
>> 
>> JDK 17: 1.6 s
>> JDK 21 (no patches): 22 s
>> JDK25-master: 12.3 s
>> JDK25-this-pr: 0.5 s
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Thanks to everyone involved!

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

PR Comment: https://git.openjdk.org/jdk/pull/24847#issuecomment-2969876715

From alanb at openjdk.org  Fri Jun 13 14:09:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 14:09:34 GMT
Subject: [jdk25] RFR: 8358701: Remove misleading javax.management.remote
 API doc wording about JMX spec, and historic link to JMXMP
In-Reply-To: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>
References: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>
Message-ID: <Na-a7bHi0G1qR08yEGzaMs218mfNADmRqjIMR-A1PT0=.ab9b3713-e451-4168-8093-c6a232ec026e@github.com>

On Fri, 13 Jun 2025 09:14:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to jdk25 of this doc-only change.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25795#pullrequestreview-2924968150

From kevinw at openjdk.org  Fri Jun 13 14:30:14 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Jun 2025 14:30:14 GMT
Subject: RFR: 8346982: Remove JMX javadoc duplication that was in place due to
 JDK-6369229
Message-ID: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>

Remove unnecessary javadoc duplication.

Both of these files:
src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java
src/java.management/share/classes/javax/management/ImmutableDescriptor.java

..have two instances of this comment:
     // Note: this Javadoc is copied from javax.management.Descriptor
     //       due to 6369229.
	 	 
JDK-6369229 is long since resolved, the Javadoc duplication can be removed.

In the new doc build, we still have javadoc for equals() hashCode(), with e.g.:
"Description copied from interface: Descriptor"

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

Commit messages:
 - 8346982: Remove JMX javadoc duplication that was in place due to JDK-6369229

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

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

From kevinw at openjdk.org  Fri Jun 13 14:31:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Jun 2025 14:31:35 GMT
Subject: [jdk25] RFR: 8358701: Remove misleading javax.management.remote
 API doc wording about JMX spec, and historic link to JMXMP
In-Reply-To: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>
References: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>
Message-ID: <Mjn-R0WyH-byYLY886IwwbF-_j-Oa6xfsIHhkcNtBCE=.aa95fe30-1534-4049-8298-5e35b46ebd0b@github.com>

On Fri, 13 Jun 2025 09:14:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to jdk25 of this doc-only change.

Thanks Alan!

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

PR Comment: https://git.openjdk.org/jdk/pull/25795#issuecomment-2970579787

From kevinw at openjdk.org  Fri Jun 13 14:31:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Jun 2025 14:31:35 GMT
Subject: [jdk25] Integrated: 8358701: Remove misleading javax.management.remote
 API doc wording about JMX spec, and historic link to JMXMP
In-Reply-To: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>
References: <lsf5vU0q0RwPHTwvgYN-g0wa0eLToeTi-5-7MRTgq4g=.a58b0200-b17b-41fc-986b-a7dfd7ba6819@github.com>
Message-ID: <SzmqrVGPjHDv8iUuN3mKWhj56Gq2G0eBVvkS_ZFu7KY=.b74ac2d9-7c49-46da-887a-407e546ac0b5@github.com>

On Fri, 13 Jun 2025 09:14:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport to jdk25 of this doc-only change.

This pull request has now been integrated.

Changeset: 74ea38e4
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74ea38e406058ae2e0b6e47e5d0bff5e77f74809
Stats:     27 lines in 1 file changed: 0 ins; 18 del; 9 mod

8358701: Remove misleading javax.management.remote API doc wording about JMX spec, and historic link to JMXMP

Reviewed-by: alanb
Backport-of: 66535fe26da27dfaf0940bd70deb30942f7d0cdc

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

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

From dcubed at openjdk.org  Fri Jun 13 16:14:46 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jun 2025 16:14:46 GMT
Subject: RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <xVR85dKJNzZ2BtnAYUVBRJNf51OPHxgcGDkIz4Bbw0g=.4cd70809-f018-4524-b31e-0ad4f53741c1@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

(Gotta love it when you typo a lable^H^H^H^H^H label).

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

PR Comment: https://git.openjdk.org/jdk/pull/25773#issuecomment-2970862022

From phh at openjdk.org  Fri Jun 13 17:09:33 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 13 Jun 2025 17:09:33 GMT
Subject: RFR: 8359180: Apply java.io.Serial annotations in java.instrument
In-Reply-To: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>
References: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>
Message-ID: <omeSG9jjjqlZMD_Rj90MjDkGhi9Yq7jwJFaBr1qi2e4=.7c704775-7262-4392-9360-894d6d37cbbd@github.com>

On Tue, 10 Jun 2025 23:19:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.instrument module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
> 
> This annotation can be applied to these methods in the module:
> 
> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
> private void readObjectNoData() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
> private static final ObjectStreamField[] serialPersistentFields
> private static final long serialVersionUID
> 
> 
> Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module.

I'm not an expert in this area, but this PR just adds @Serial to 3 instances of serialVersionUID, which is one of the fields mentioned in [JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385), so lgtm.

It would be worth doing a scan for the instances of serialVersionUID that need @Serial added.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25738#pullrequestreview-2925554810

From amenkov at openjdk.org  Fri Jun 13 17:18:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Jun 2025 17:18:39 GMT
Subject: Integrated: 8358094: Test
 vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java still times
 out after JDK-8357282
In-Reply-To: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
References: <uaqXmopn8_2_4B5j71304pgtoAzUQ1wy9GBY7UX1kgc=.7402e6cd-9ef1-481e-bfc5-7f0383a5abac@github.com>
Message-ID: <has8Am45m_mY7mzR05O3EYGBWtEUvHeexBX2ATvxoJ4=.df7bc244-9c36-4b3d-a872-c3b96acc4e5b@github.com>

On Sat, 7 Jun 2025 01:11:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test intermittently times out due to deadlock between 2 monitors: one monitor is JVMTI raw monitor used by agents, another is in Java (`nsk_jvmti_aod_disableEventAndFinish` does upcall) See JBS issue for details.
> The fix updates agents to exit raw monitors before upcall.
> 
> Testing: no failures in 1000 runs

This pull request has now been integrated.

Changeset: b3f56086
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3f56086c99023a30b91f90c2acbed51b3b17ec0
Stats:     24 lines in 5 files changed: 4 ins; 4 del; 16 mod

8358094: Test vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java still times out after JDK-8357282

Reviewed-by: sspitsyn, cjplummer, lmesnik

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

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

From dcubed at openjdk.org  Fri Jun 13 19:33:38 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jun 2025 19:33:38 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <PQmHuUHZZh8LfhmnircioaQ9pjm94JyGyMi0TeqMoGE=.7f4b616d-bf87-4350-897e-176e44f4a814@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about performance going forward.

s/concerned about performance/concerned about JNI performance/

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2971428640

From dcubed at openjdk.org  Fri Jun 13 19:39:56 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jun 2025 19:39:56 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <iGA2Zc00GHGUVXdylKPyfhdVV0VLQxUmo9JB_IlrTns=.37e67bfe-5580-4966-b7ce-0a675b9316e9@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code. But that's not in this change.

Hmmm... I'm rusty with redefinition, but I think there are legitimate scenarios where is "okay"
to call an obsolete method. I believe it has to do with an in-progress call to a method being
redefined and you might get the obsolete method or the new method depending on timing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2971451618

From coleenp at openjdk.org  Fri Jun 13 20:39:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 13 Jun 2025 20:39:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <8hFd0ec-RQ2ZmA1hvUg6Oa7XBQtUL6SCcfvVQEFeQLo=.7aded867-efa5-4818-aed1-f6f1c0daa455@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

There is a way to create a jmethodID from an obsolete method and I thought we had tests that did this. I'm not finding them right now. The old and obsolete methods can still be running after a redefinition if they were running during the redefinition.  The JIT deoptimizes them but they will be run in the interpreter.  New invocations of the method will choose the new version of the method always.  Always unless there's a bug that we don't know about.  We have fixed a few old method invocations in the past coming from various places in the JVM but we fixed the "last" one fairly recently.
But technically, one could create a jmethodID to an obsolete method although it's not easy to do.  I was musing above but not committed to breaking compatibility if there is code that requires this.

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2971620203

From dcubed at openjdk.org  Fri Jun 13 20:44:43 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jun 2025 20:44:43 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Changes requested by dcubed (Reviewer).

src/hotspot/share/classfile/classLoaderData.cpp line 585:

> 583:   MutexLocker m1(metaspace_lock(), Mutex::_no_safepoint_check_flag);
> 584:   if (_jmethod_ids == nullptr) {
> 585:     _jmethod_ids = new (mtClass) GrowableArray<jmethodID>(32, mtClass);

Do you want the literal `32` to be a tunable value?

src/hotspot/share/classfile/classLoaderData.cpp line 590:

> 588: }
> 589: 
> 590: // Method::clear_jmethod_ids removes jmethodID entries from the table which

Perhaps the name changed during your development?
    s/clear_jmethod_ids/remove_jmethod_ids/

src/hotspot/share/classfile/classLoaderData.cpp line 592:

> 590: // Method::clear_jmethod_ids removes jmethodID entries from the table which
> 591: // releases memory.
> 592: // Because native code (e.g. JVMTI agent) holding jmethod_ids may access them

grammar: s/e.g./e.g.,/

src/hotspot/share/classfile/classLoaderData.cpp line 594:

> 592: // Because native code (e.g. JVMTI agent) holding jmethod_ids may access them
> 593: // after the associated classes and class loader are unloaded, subsequent lookups
> 594: // for these ids will return null since they are no longer found in the table.

Perhaps: s/null/nullptr/

src/hotspot/share/classfile/classLoaderData.hpp line 319:

> 317:   void add_jmethod_id(jmethodID id);
> 318:   void remove_jmethod_ids();
> 319:   GrowableArray<jmethodID>* jmethod_ids() { return _jmethod_ids; }

Should `jmethod_ids` still be `const`?

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

> 2392: }
> 2393: 
> 2394: // Lookup or create a jmethodID.

The comment on L2394 appears wrong for `create_jmethod_id_cache`.
Perhaps move it to L2404 (above get_jmethod_id() function).

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

> 2395: static jmethodID* create_jmethod_id_cache(size_t size) {
> 2396:   jmethodID* jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
> 2397:   memset(jmeths, 0, (size+1)*sizeof(jmethodID));

nit spacing: s/size+1/size + 1/
on two lines.

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

> 2400:   return jmeths;
> 2401: }
> 2402: 

nit spacing: delete extra blank line?

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

> 2402: 
> 2403: 
> 2404: jmethodID InstanceKlass::get_jmethod_id(Method* method) {

Should `method` be `const`?

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

> 2458:     size_t size = idnum_allocated_count();
> 2459:     size_t old_size = (size_t)cache[0];
> 2460:     if (old_size < size+1) {

nit spacing: s/size+1/size + 1/

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

> 2459:     size_t old_size = (size_t)cache[0];
> 2460:     if (old_size < size+1) {
> 2461:       // allocate a larger one and copy entries to the new one.

nit typo: s/allocate/Allocate/

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

> 2460:     if (old_size < size+1) {
> 2461:       // allocate a larger one and copy entries to the new one.
> 2462:       // They've already been updated to point to new methods where applicable (ie. not obsolete)

nit typo: s/(ie. not obsolete)/(i.e., not obsolete)./

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

> 2493:         id == nullptr) {
> 2494:       id = Method::make_jmethod_id(class_loader_data(), m);
> 2495:       Atomic::release_store(&jmeths[idnum+1], id);

nit spacing: s/size+1/size + 1/

src/hotspot/share/oops/instanceKlass.hpp line 1057:

> 1055:   inline jmethodID* methods_jmethod_ids_acquire() const;
> 1056:   inline void release_set_methods_jmethod_ids(jmethodID* jmeths);
> 1057:   // This nulls out obsolete jmethodIDs for all methods in 'klass'

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.cpp line 29:

> 27: #include "memory/resourceArea.hpp"
> 28: #include "oops/method.hpp"
> 29: #include "oops/jmethodIDTable.hpp"

Please swap these two #includes into sort order.

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

> 33: #include "utilities/macros.hpp"
> 34: 
> 35: // Save (jmethod, Method*) in a hashtable to lookup Method

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.cpp line 36:

> 34: 
> 35: // Save (jmethod, Method*) in a hashtable to lookup Method
> 36: // The CHT is for performance because it is has lock free lookup.

typo: s/because it is has lock free/because it has lock free/

src/hotspot/share/oops/jmethodIDTable.cpp line 73:

> 71:   // 2^24 is max size
> 72:   const size_t end_size = 24;
> 73:   // If a chain gets to 32 something might be wrong

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.cpp line 98:

> 96: 
> 97: static JmethodEntry* get_jmethod_entry(jmethodID mid) {
> 98:   assert(mid != nullptr, "JNI method id should not be null");

Perhaps: s/null/nullptr/
I can't remember if assert failure text output is okay to be `null`.

src/hotspot/share/oops/jmethodIDTable.cpp line 104:

> 102:   JmethodEntry* result = nullptr;
> 103:   auto get = [&] (JmethodEntry* value) {
> 104:     // function called if value is found so is never null

Perhaps: s/null/nullptr/

src/hotspot/share/oops/jmethodIDTable.cpp line 109:

> 107:   bool needs_rehashing = false;
> 108:   _jmethod_id_table->get(current, lookup, get, &needs_rehashing);
> 109:   assert (!needs_rehashing, "should never need rehashing");

nit spacing: s/assert (/assert(/

src/hotspot/share/oops/jmethodIDTable.cpp line 129:

> 127: }
> 128: 
> 129: // Add a method id to the jmethod_ids

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.cpp line 131:

> 129: // Add a method id to the jmethod_ids
> 130: jmethodID JmethodIDTable::make_jmethod_id(Method* m) {
> 131:   bool grow_hint, clean_hint, created;

nit: sort local variables?

src/hotspot/share/oops/jmethodIDTable.cpp line 144:

> 142:   log_debug(jmethod)("Inserted jmethod id " UINT64_FORMAT_X, _jmethodID_counter);
> 143: 
> 144:   // Resize table if it needs to grow.  The _jmethod_id_table has a good distribution

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.cpp line 158:

> 156:   JmethodEntry* result;
> 157:   auto get = [&] (JmethodEntry* value) {
> 158:     // function called if value is found so is never null

Perhaps: s/null/nullptr/

src/hotspot/share/oops/jmethodIDTable.cpp line 162:

> 160:   };
> 161:   bool removed = _jmethod_id_table->remove(current, lookup, get);
> 162:   assert(removed, "should be");

"should be" or "must be"?

src/hotspot/share/oops/jmethodIDTable.cpp line 169:

> 167:   assert_locked_or_safepoint(JmethodIdCreation_lock);
> 168:   JmethodEntry* result = get_jmethod_entry(jmid);
> 169:   // change to table to point to the new method

Perhaps: // Change to table entry to point to the new method.

src/hotspot/share/oops/jmethodIDTable.cpp line 180:

> 178:   // We need to make sure that jmethodID actually resolves to this method
> 179:   // - multiple redefined versions may share jmethodID slots and if a method
> 180:   //   has already been rewired to a newer version we could be removing reference

typo?: s/could be removing reference/could be clearing a reference/

src/hotspot/share/oops/jmethodIDTable.hpp line 31:

> 29: #include "memory/allocation.hpp"
> 30: 
> 31: // Class for associating Method with jmethodID

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.hpp line 38:

> 36:   static void initialize();
> 37: 
> 38:   // Given a Method return a jmethodID

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.hpp line 41:

> 39:   static jmethodID make_jmethod_id(Method* m);
> 40: 
> 41:   // Given a jmethodID, return a Method

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/jmethodIDTable.hpp line 45:

> 43: 
> 44:   // Class unloading support, remove the associations from the tables.  Stale jmethodID will
> 45:   // not be found and return null

nit typo: please add an ending period to the comment.

Perhaps: s/null/nullptr/

src/hotspot/share/oops/method.cpp line 2063:

> 2061: 
> 2062: // jmethodID handling
> 2063: // jmethodIDs are 64-bit integers that will never run out and are mapped in a table

Should we have a `guarantee` or `assert` somewhere that the counter never wraps?

src/hotspot/share/oops/method.cpp line 2065:

> 2063: // jmethodIDs are 64-bit integers that will never run out and are mapped in a table
> 2064: // to their Method and vice versa.  If JNI code has access to stale jmethodID, this
> 2065: // wastes no memory but the Method* returned is null

Perhaps: s/null/nullptr/

src/hotspot/share/oops/method.cpp line 2076:

> 2074:   assert(jmid != nullptr, "must be created");
> 2075: 
> 2076:   // Add to growable array in CLD

nit typo: please add an ending period to the comment.

src/hotspot/share/oops/method.cpp line 2088:

> 2086: // Get the Method out of the table given the method id.
> 2087: Method* Method::resolve_jmethod_id(jmethodID mid) {
> 2088:   assert(mid != nullptr, "JNI method id should not be null");

Perhaps: s/null/nullptr/

src/hotspot/share/oops/method.hpp line 709:

> 707:   // Use resolve_jmethod_id() in situations where the caller is expected
> 708:   // to provide a valid jmethodID; the only sanity checks are in asserts;
> 709:   // result guaranteed not to be null.

Perhaps: s/null/nullptr/

src/hotspot/share/oops/method.hpp line 713:

> 711: 
> 712:   // Use checked_resolve_jmethod_id() in situations where the caller
> 713:   // should provide a valid jmethodID, but might not. Null is returned

Perhaps: s/Null/Nullptr/

src/hotspot/share/prims/jvmtiEnv.cpp line 2773:

> 2771:   int skipped = 0;  // skip overpass methods
> 2772: 
> 2773:   // Make jmethodIDs for all non-overpass methods

nit typo: please add an ending period to the comment.

src/hotspot/share/prims/jvmtiEnv.cpp line 2789:

> 2787:     }
> 2788:     jmethodID id = m->find_jmethod_id_or_null();
> 2789:     assert (id != nullptr, "should be created above");

nit spacing: s/assert (/assert(/

src/hotspot/share/runtime/mutexLocker.cpp line 236:

> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
> 235: 
> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1); // used for creating jmethodIDs.

Interesting. Why change from `nosafepoint-2` to `nosafepoint-1`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2926153300
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145955175
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145963559
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145960811
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145967055
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145984911
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145989746
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145993097
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145994055
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146005043
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145996873
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145997702
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2145998880
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146002943
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146006426
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146007219
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146007725
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146008289
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146011312
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146013418
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146029756
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146014609
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146018654
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146016370
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146017327
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146029142
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146019950
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146022181
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146024577
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146025893
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146026406
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146026860
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146029258
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146037800
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146031309
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146039166
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146040503
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146045442
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146047075
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146049138
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146050371
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2146052800

From ysr at openjdk.org  Fri Jun 13 20:52:28 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Jun 2025 20:52:28 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <d2iYDGY5VtLvwbwWaz2klBw7uRgMaf829WpdFFqweDc=.bd1c05f3-7ac3-4fe0-9ac8-a336abaefe34@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

Reviewed -- would be good to go from my standpoint after separating into a separate ticket as suggested by Aleksey the collapse of `no_cause_specified` into its putative synonym `_no_gc`.

Approving in advance, subject to that change, and re-review by Aleksey.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java line 42:

> 40: 
> 41:   _no_gc ("No GC"),
> 42:   _no_cause_specified ("Unknown GCCause"),

I agree that "no cause specified" and "no gc" almost sound like synonyms, and any uses of one could be replaced with the other. However, with @shipilev , I agree that may be you split the changes to this kind of shared code into a separate ticket, in keeping with hotspot dev practices.

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2926250505
PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2146013368

From amenkov at openjdk.org  Fri Jun 13 23:41:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Jun 2025 23:41:28 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
In-Reply-To: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
Message-ID: <dNUtkt8mFuNytgw8hWq_NGQLAnGrc3bQklMbe2EPG0s=.0b5e2500-fc96-4146-9992-3aa2c9271afc@github.com>

On Thu, 12 Jun 2025 18:01:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
> 
> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
> 
> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
> 
> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.

test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 35:

> 33: /**
> 34:  * This class provides launching of <code>jdb</code> and debuggee in local
> 35:  * mode according to test command line options.

As now there is only local mode, I think there is no sense to mention it at all:

 * This class provides launching of <code>jdb</code> and debuggee
 * according to test command line options.

test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 97:

> 95: 
> 96:     /**
> 97:      * Defines mode (local) and type of connector (default, launching,

Suggestion:

     * Defines type of connector (default, launching,

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 44:

> 42:  * debugee VM process.
> 43:  * Derived classes should implement these methods corresponding to the mode
> 44:  * that the process should be started in (locally).

I think this can be dropped

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java line 32:

> 30:  * This class implements communicational channel between
> 31:  * debugger and debugee used for synchronization and data exchange.
> 32:  * This channel is based on TCP/IP socketss.

Suggestion:

 * This channel is based on TCP/IP sockets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2146271592
PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2146272505
PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2146275444
PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2146276315

From amenkov at openjdk.org  Fri Jun 13 23:46:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Jun 2025 23:46:28 GMT
Subject: RFR: 8346982: Remove JMX javadoc duplication that was in place due
 to JDK-6369229
In-Reply-To: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>
References: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>
Message-ID: <IAsPF3Tn6HHLt5pGkAXvUWT4VC9-tZNvr9JevwdXTYY=.8f826163-5e67-4679-a5e2-9ed7b4810fdb@github.com>

On Fri, 13 Jun 2025 14:21:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove unnecessary javadoc duplication.
> 
> Both of these files:
> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java
> src/java.management/share/classes/javax/management/ImmutableDescriptor.java
> 
> ..have two instances of this comment:
>      // Note: this Javadoc is copied from javax.management.Descriptor
>      //       due to 6369229.
> 	 	 
> JDK-6369229 is long since resolved, the Javadoc duplication can be removed.
> 
> In the new doc build, we still have javadoc for equals() hashCode(), with e.g.:
> "Description copied from interface: Descriptor"

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25803#pullrequestreview-2926789452

From lmesnik at openjdk.org  Sun Jun 15 06:06:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 15 Jun 2025 06:06:33 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
In-Reply-To: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
Message-ID: <VPeDP6Gs4yrMhjY1ymZG4MoL97Q22p60qV-rUkLg1TQ=.0d9d25ae-5b7d-4455-8b07-0414a4e81fa4@github.com>

On Thu, 12 Jun 2025 18:01:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
> 
> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
> 
> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
> 
> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25785#pullrequestreview-2928994647

From kustos at gmx.net  Sun Jun 15 15:43:55 2025
From: kustos at gmx.net (Philippe Marschall)
Date: Sun, 15 Jun 2025 17:43:55 +0200
Subject: Interest in Java based attach provider implementation?
In-Reply-To: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
References: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
Message-ID: <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>

Hello

I further pursued the approach

- Rebased the Linux implementation [1], implemented the permission check 
using JSR 203 and the Unix domain sockets using JEP 380.
- Applied the same changes to the AIX implementation [2].
- Switched Linux to an FFM based kill implementation [3], completely 
getting rid of JNI.
-  Updated the macOS implementation [4], implemented the permission 
check using JSR 203 and the Unix domain sockets using JEP 380.
- Switched macOS to an FFM based kill and sysctl implementation [5], 
completely getting rid of JNI.

I ran the serviceability test suite on Linux and macOS and it passes. I 
manually verified that I can attach to JVMs using local builds.

I could not test on AIX.

  [1] 
https://github.com/marschall/jdk/commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
  [2] 
https://github.com/marschall/jdk/commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
  [3] 
https://github.com/marschall/jdk/commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559
  [4] 
https://github.com/marschall/jdk/commit/93372a124eca6078fde5597c2498b381a4ef5dfa
  [5] 
https://github.com/marschall/jdk/commit/c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b

Cheers
Philippe

On 20.04.22 22:13, Philippe Marschall wrote:
> Hello
> 
> I hope this is the right mailing list. I recently had a look at the
> Linux attach provider implementation and could not help but noticing
> that a large part, if not all of it, could be replaced with Java.
> Besides getting rid of the C code this should allow us to unify the AIX,
> Linux and macOS implementations under a single Unix implementation.
> 
> The permission check can be implemented using JSR 203 [1] to access uid,
> gid and file mode and using jdk.internal.misc.VM to get the euid and egid.
> 
> Reading and writing to Unix domain sockets can be done through JEP 380 [2].
> 
> Sending SIGQUIT to a process could in theory done through JEP 102 [3]
> however sending SIGQUIT to self is currently blocked. This is required
> for the self attach mechanism. There a very small C function is still
> needed for now, this is hopefully portable.
> 
> I did a small prototype [4]. The tier1 suite runs and I can attach to a
> local JVM.
> 
> The overhead will likely be a bit higher as we go through more JDK
> abstractions.
> 
>  ?[1] https://jcp.org/en/jsr/detail?id=203
>  ?[2] https://openjdk.java.net/jeps/380
>  ?[3] https://openjdk.java.net/jeps/102
>  ?[4]
> https://github.com/marschall/jdk/ 
> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc
> 
> Cheers
> Philippe


From vyazici at openjdk.org  Mon Jun 16 07:29:43 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 07:29:43 GMT
Subject: RFR: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core] [v4]
In-Reply-To: <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
 <Un_X1YsBiRbeiyDuH-t-U8hxuRfkm5Pn-aqNvLiju1I=.45e12922-aec3-454d-9f71-9ed7d42f22c9@github.com>
 <0r4lN4voPGXnF1IPlmMGgdyZd54Y4a5GdOsngNbSGlY=.03c9a53f-b044-44d3-affa-4542a7711d8c@github.com>
Message-ID: <hZ604vk0v1SI0nglx9lAGDH4A0ljfgAZBBxD0fVFfPE=.fd2e67cc-8454-4b00-86ed-7dbc2c18851c@github.com>

On Tue, 3 Jun 2025 20:09:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix missing `java.io.Reader` import in `Ktab`
>
> I was thinking if someone made a typo for "stdin.encoding" and then it unknowingly defaults to the fallback. Turned out it immediately fails with "java.lang.IllegalArgumentException: Null charset name" so I think it should be OK.

@naotoj, @turbanoff, @wangweij, @plummercj, @AlanBateman, thanks so much for the reviews.

`tier1,2,3` pass ? results are attached to the ticket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25544#issuecomment-2969879685

From vyazici at openjdk.org  Mon Jun 16 07:29:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 07:29:44 GMT
Subject: Integrated: 8357995: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [core]
In-Reply-To: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
References: <mBxYfRtPoq7fOtY9BftPfNDRTKLteL6DS_NkrRnUJ-M=.ee1a9f6f-ba9a-41dd-abf7-7236c0186f4b@github.com>
Message-ID: <2bZxFXAIgff0dW80SQs1nnYNEarkBmhThnJ4pkmHre4=.de088625-d9ef-442d-9be5-70725a6000f6@github.com>

On Fri, 30 May 2025 11:07:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357995 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to core libraries.

This pull request has now been integrated.

Changeset: eacfcd86
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eacfcd86d38f4acf0165275a42d246ba6c5fae56
Stats:     130 lines in 11 files changed: 33 ins; 28 del; 69 mod

8357995: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [core]

Reviewed-by: naoto, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/25544

From kevinw at openjdk.org  Mon Jun 16 07:32:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Jun 2025 07:32:33 GMT
Subject: RFR: 8346982: Remove JMX javadoc duplication that was in place due
 to JDK-6369229
In-Reply-To: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>
References: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>
Message-ID: <kR_8_4iUNdnp_NfdmbTl6zvaFi0Y-MfQpguWrSYUNKc=.b22b1042-fa7d-4ce3-8b0f-fca69abda394@github.com>

On Fri, 13 Jun 2025 14:21:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove unnecessary javadoc duplication.
> 
> Both of these files:
> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java
> src/java.management/share/classes/javax/management/ImmutableDescriptor.java
> 
> ..have two instances of this comment:
>      // Note: this Javadoc is copied from javax.management.Descriptor
>      //       due to 6369229.
> 	 	 
> JDK-6369229 is long since resolved, the Javadoc duplication can be removed.
> 
> In the new doc build, we still have javadoc for equals() hashCode(), with e.g.:
> "Description copied from interface: Descriptor"

Thanks Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25803#issuecomment-2975399613

From kevinw at openjdk.org  Mon Jun 16 07:32:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Jun 2025 07:32:33 GMT
Subject: Integrated: 8346982: Remove JMX javadoc duplication that was in place
 due to JDK-6369229
In-Reply-To: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>
References: <qHmEtqfjmsbSfXAL2Zj8GUTOWTW5tPI04ZlfZYXJN6A=.20a1f6c4-23d1-4d7f-9a77-e31e8ffb610c@github.com>
Message-ID: <iR_Rr53u0UChuLeeotX4thxZpVq6Hrj9sN1KTH_1KN4=.2c88a48a-77ad-4349-8549-3eebf0bbde5f@github.com>

On Fri, 13 Jun 2025 14:21:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove unnecessary javadoc duplication.
> 
> Both of these files:
> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java
> src/java.management/share/classes/javax/management/ImmutableDescriptor.java
> 
> ..have two instances of this comment:
>      // Note: this Javadoc is copied from javax.management.Descriptor
>      //       due to 6369229.
> 	 	 
> JDK-6369229 is long since resolved, the Javadoc duplication can be removed.
> 
> In the new doc build, we still have javadoc for equals() hashCode(), with e.g.:
> "Description copied from interface: Descriptor"

This pull request has now been integrated.

Changeset: 8416ca31
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8416ca3104d98edad89ed20bdb203a36974f410a
Stats:     93 lines in 2 files changed: 0 ins; 93 del; 0 mod

8346982: Remove JMX javadoc duplication that was in place due to JDK-6369229

Reviewed-by: amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/25803

From stefank at openjdk.org  Mon Jun 16 07:54:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Jun 2025 07:54:30 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <JsnkRZTMVaOtyBbLr1Nb9dlXmaChJVpKxBvatGtb7mg=.1543b4bd-d6bf-458b-bea3-f8dda0031a1e@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

I'm OK with the shared GC changes if you change the title of JBS issue or split it out the shared parts into a separate issue.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2930994011

From sroy at openjdk.org  Mon Jun 16 08:33:36 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 16 Jun 2025 08:33:36 GMT
Subject: Integrated: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <TqLcquWtZAoKyLQJ23EaSz9Sr6EbH4rayHoAHT_82Po=.333b1007-7d58-4de3-b6bf-88656ed9db40@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

This pull request has now been integrated.

Changeset: 79497ef7
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79497ef7f55ef445b31348ae9d3d6dff6d3b6a54
Stats:     366 lines in 13 files changed: 2 ins; 360 del; 4 mod

8348574: Simplify c1/c2_globals inclusions

Reviewed-by: mhaessig, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/25773

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 kevinw at openjdk.org  Mon Jun 16 15:28:37 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Jun 2025 15:28:37 GMT
Subject: Integrated: 8347114: JMXServiceURL should require an explicit protocol
In-Reply-To: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
Message-ID: <NKSTPmjwHjR6LfbZ-lILQL0YxAKNAvxHUA_DrXT87rI=.4e0c86f0-c9e4-4f9a-9415-767a642c825d@github.com>

On Fri, 6 Jun 2025 15:20:45 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
> 
> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
> 
> A missing (null) protocol should throw a MalformedURLException for all constructors.
> 
> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
> 
> While we are here, remove the last remaining JMXMP references in the source:
> 
> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
> 
> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.

This pull request has now been integrated.

Changeset: 9652ae9a
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9652ae9a8d48924a90d25e9daffcdb7f582ff503
Stats:     71 lines in 4 files changed: 58 ins; 2 del; 11 mod

8347114: JMXServiceURL should require an explicit protocol

Reviewed-by: dfuchs, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25674

From kevinw at openjdk.org  Mon Jun 16 15:48:36 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Jun 2025 15:48:36 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <c6YMPUnsEiLMVY6wVHLRlQROxob_qa0h6rPf2Y2v2XE=.25f049d3-41fc-4836-83b4-90905a6d8fd5@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Release note updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2977145963

From cjplummer at openjdk.org  Mon Jun 16 16:12:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Jun 2025 16:12:31 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
In-Reply-To: <dNUtkt8mFuNytgw8hWq_NGQLAnGrc3bQklMbe2EPG0s=.0b5e2500-fc96-4146-9992-3aa2c9271afc@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
 <dNUtkt8mFuNytgw8hWq_NGQLAnGrc3bQklMbe2EPG0s=.0b5e2500-fc96-4146-9992-3aa2c9271afc@github.com>
Message-ID: <_zJZC52NDqJzJj47y7d8D__cvoS9UQkE3Feavy9SkVk=.d0bf8255-99b3-4568-86dd-d74033cd3a7c@github.com>

On Fri, 13 Jun 2025 23:37:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
>> 
>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
>> 
>> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
>> 
>> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 44:
> 
>> 42:  * debugee VM process.
>> 43:  * Derived classes should implement these methods corresponding to the mode
>> 44:  * that the process should be started in (locally).
> 
> I think this can be dropped

Which part?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2150376249

From ysr at openjdk.org  Mon Jun 16 17:15:30 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 16 Jun 2025 17:15:30 GMT
Subject: RFR: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <yafhgRUcOsermOyGoRk3A1cklCmJrjOtBUuhRDBSVbg=.3aa7f942-000d-4fc4-b00f-e0245db73509@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

Thanks for changing the title/summary to broaden scope.

Re-approved; ?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2932895948

From coleenp at openjdk.org  Mon Jun 16 17:37:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Jun 2025 17:37:17 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix formatting errors.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/57321e75..c2f2f42c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=00-01

  Stats: 36 lines in 8 files changed: 2 ins; 1 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Mon Jun 16 17:37:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Jun 2025 17:37:18 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <gpwsCAq3520Nz23NNKOUeLkRcnY6jvYoXYvgy-DIr7k=.d4ea90c6-0ee7-43d0-9637-1d36432d6dab@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Dan, thank you for your first pass.  I've tried to address the things you pointed out.  I think I've used 'null' correctly in comments and strings though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2977460666

From coleenp at openjdk.org  Mon Jun 16 17:37:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Jun 2025 17:37:19 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
Message-ID: <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>

On Fri, 13 Jun 2025 19:39:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix formatting errors.
>
> src/hotspot/share/classfile/classLoaderData.cpp line 585:
> 
>> 583:   MutexLocker m1(metaspace_lock(), Mutex::_no_safepoint_check_flag);
>> 584:   if (_jmethod_ids == nullptr) {
>> 585:     _jmethod_ids = new (mtClass) GrowableArray<jmethodID>(32, mtClass);
> 
> Do you want the literal `32` to be a tunable value?

I don't want it tunable.   I think it's fairly unlikely to grow.  Even if it does, I don't think it would cause a performance problem.  I could name 32 as a constant globally in classLoaderData.cpp in case we ever find we need to change the initial value.

> src/hotspot/share/classfile/classLoaderData.cpp line 590:
> 
>> 588: }
>> 589: 
>> 590: // Method::clear_jmethod_ids removes jmethodID entries from the table which
> 
> Perhaps the name changed during your development?
>     s/clear_jmethod_ids/remove_jmethod_ids/

It did change.  Thank you for noticing it.

> src/hotspot/share/classfile/classLoaderData.cpp line 592:
> 
>> 590: // Method::clear_jmethod_ids removes jmethodID entries from the table which
>> 591: // releases memory.
>> 592: // Because native code (e.g. JVMTI agent) holding jmethod_ids may access them
> 
> grammar: s/e.g./e.g.,/

ok.

> src/hotspot/share/classfile/classLoaderData.cpp line 594:
> 
>> 592: // Because native code (e.g. JVMTI agent) holding jmethod_ids may access them
>> 593: // after the associated classes and class loader are unloaded, subsequent lookups
>> 594: // for these ids will return null since they are no longer found in the table.
> 
> Perhaps: s/null/nullptr/

I thought the convention was that we were supposed to call it `null` in the comments and `nullptr` in the code.

> src/hotspot/share/classfile/classLoaderData.hpp line 319:
> 
>> 317:   void add_jmethod_id(jmethodID id);
>> 318:   void remove_jmethod_ids();
>> 319:   GrowableArray<jmethodID>* jmethod_ids() { return _jmethod_ids; }
> 
> Should `jmethod_ids` still be `const`?

yes.

> src/hotspot/share/oops/instanceKlass.cpp line 2394:
> 
>> 2392: }
>> 2393: 
>> 2394: // Lookup or create a jmethodID.
> 
> The comment on L2394 appears wrong for `create_jmethod_id_cache`.
> Perhaps move it to L2404 (above get_jmethod_id() function).

yes moved.

> src/hotspot/share/oops/instanceKlass.cpp line 2397:
> 
>> 2395: static jmethodID* create_jmethod_id_cache(size_t size) {
>> 2396:   jmethodID* jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
>> 2397:   memset(jmeths, 0, (size+1)*sizeof(jmethodID));
> 
> nit spacing: s/size+1/size + 1/
> on two lines.

fixed.  The spaces match the coding style. I fixed the others that you pointed out below.

> src/hotspot/share/oops/instanceKlass.cpp line 2402:
> 
>> 2400:   return jmeths;
>> 2401: }
>> 2402: 
> 
> nit spacing: delete extra blank line?

fixed.

> src/hotspot/share/oops/instanceKlass.cpp line 2404:
> 
>> 2402: 
>> 2403: 
>> 2404: jmethodID InstanceKlass::get_jmethod_id(Method* method) {
> 
> Should `method` be `const`?

It's really unusual in our source code to pass const Metadata pointers because of the history of the code.  We should probably start doing that.  I'll change this to const and see if there's a fall out.

> src/hotspot/share/oops/instanceKlass.cpp line 2495:
> 
>> 2493:         id == nullptr) {
>> 2494:       id = Method::make_jmethod_id(class_loader_data(), m);
>> 2495:       Atomic::release_store(&jmeths[idnum+1], id);
> 
> nit spacing: s/size+1/size + 1/

I fixed the idnum+1 => idnum + 1 in this function.

> src/hotspot/share/oops/jmethodIDTable.cpp line 29:
> 
>> 27: #include "memory/resourceArea.hpp"
>> 28: #include "oops/method.hpp"
>> 29: #include "oops/jmethodIDTable.hpp"
> 
> Please swap these two #includes into sort order.

I thought the build checked this. thanks for noticing.

> src/hotspot/share/oops/jmethodIDTable.cpp line 98:
> 
>> 96: 
>> 97: static JmethodEntry* get_jmethod_entry(jmethodID mid) {
>> 98:   assert(mid != nullptr, "JNI method id should not be null");
> 
> Perhaps: s/null/nullptr/
> I can't remember if assert failure text output is okay to be `null`.

I think the rules are comments and strings say `null` and code is `nullptr`.

> src/hotspot/share/oops/jmethodIDTable.cpp line 131:
> 
>> 129: // Add a method id to the jmethod_ids
>> 130: jmethodID JmethodIDTable::make_jmethod_id(Method* m) {
>> 131:   bool grow_hint, clean_hint, created;
> 
> nit: sort local variables?

I moved 'created' to where it's used but grow_hint and clean_hint are in the order of the parameter list.

> src/hotspot/share/oops/jmethodIDTable.cpp line 169:
> 
>> 167:   assert_locked_or_safepoint(JmethodIdCreation_lock);
>> 168:   JmethodEntry* result = get_jmethod_entry(jmid);
>> 169:   // change to table to point to the new method
> 
> Perhaps: // Change to table entry to point to the new method.

much better

> src/hotspot/share/oops/jmethodIDTable.cpp line 180:
> 
>> 178:   // We need to make sure that jmethodID actually resolves to this method
>> 179:   // - multiple redefined versions may share jmethodID slots and if a method
>> 180:   //   has already been rewired to a newer version we could be removing reference
> 
> typo?: s/could be removing reference/could be clearing a reference/

clearing is better.

> src/hotspot/share/oops/method.cpp line 2063:
> 
>> 2061: 
>> 2062: // jmethodID handling
>> 2063: // jmethodIDs are 64-bit integers that will never run out and are mapped in a table
> 
> Should we have a `guarantee` or `assert` somewhere that the counter never wraps?

Okay, I added one when we increment the jmethod_id_counter.

  // Update jmethodID global counter.
  _jmethodID_counter++;
  guarantee(_jmethodID_counter != 0, "must never go back to zero");

I think this will detect wraparound.

> src/hotspot/share/runtime/mutexLocker.cpp line 236:
> 
>> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
>> 235: 
>> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1); // used for creating jmethodIDs.
> 
> Interesting. Why change from `nosafepoint-2` to `nosafepoint-1`?

I can't remember.  There may have been another lock held while this one was (which is why we added MUTEX_DEFL to help with that).  I'll check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150302295
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150302945
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150308058
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150309308
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150312028
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150319536
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150320490
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150321823
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150326543
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150338172
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150340203
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150344720
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150354189
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150356106
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150358453
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150366952
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150372817

From coleenp at openjdk.org  Mon Jun 16 17:37:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Jun 2025 17:37:20 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
Message-ID: <xd3Mt52Wv0xZojNRSlvNkjh_yOOveHToJKufo5m5EIg=.91875057-0cba-4432-a055-4b64b88e2c74@github.com>

On Mon, 16 Jun 2025 15:43:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 2404:
>> 
>>> 2402: 
>>> 2403: 
>>> 2404: jmethodID InstanceKlass::get_jmethod_id(Method* method) {
>> 
>> Should `method` be `const`?
>
> It's really unusual in our source code to pass const Metadata pointers because of the history of the code.  We should probably start doing that.  I'll change this to const and see if there's a fall out.

Much of the metadata parameter declarations aren't const-safe.  Adding this one const has a big fall-out leading to some jni calls.  This would be is a good project and we should have it for new code, which some of this is.  I'll see if can add any consts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150511587

From stefank at openjdk.org  Mon Jun 16 18:12:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Jun 2025 18:12:34 GMT
Subject: RFR: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <nylY2hgZL81KmVnTDF-HBBGPRRfHd_Y5JLYda6PFZh0=.b4a48507-7378-40dd-a6e3-30311379aca9@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

I've reviewed the non-shenandoah parts of this patch.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2933048021

From coleenp at openjdk.org  Mon Jun 16 20:36:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Jun 2025 20:36:29 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
Message-ID: <ZCnaXO9d0IcTxOx-zPxObRWnG3v2reaWlMCt8lHXYnE=.04b48006-d3f1-45a3-992a-817df0a637cd@github.com>

On Mon, 16 Jun 2025 16:07:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 236:
>> 
>>> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
>>> 235: 
>>> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1); // used for creating jmethodIDs.
>> 
>> Interesting. Why change from `nosafepoint-2` to `nosafepoint-1`?
>
> I can't remember.  There may have been another lock held while this one was (which is why we added MUTEX_DEFL to help with that).  I'll check.

This has to be nosafepoint-1 (actually can be nosafepoint) is that it must be above the rank for the ConcurrentHashTable which is nosafepoint-2.  I don't know why it was nosafepoint-2 before this though, I can't find any lock ordering that requires this.

In general we should use the highest lock ordering within the category (no-safepoint, safepoint) possible to leave room for further locks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2150826433

From dcubed at openjdk.org  Mon Jun 16 23:23:29 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 16 Jun 2025 23:23:29 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
Message-ID: <89TBi0eCodG4d6T1wDUXGpYGwCKRAFIVblVH-D28xsY=.77887e94-3825-4707-8055-9202cdfa0b81@github.com>

On Mon, 16 Jun 2025 17:37:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting errors.

Thumbs up with the latest version!

Thanks for fixing all the nits.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2933747031

From dcubed at openjdk.org  Mon Jun 16 23:23:30 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 16 Jun 2025 23:23:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <xd3Mt52Wv0xZojNRSlvNkjh_yOOveHToJKufo5m5EIg=.91875057-0cba-4432-a055-4b64b88e2c74@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
 <xd3Mt52Wv0xZojNRSlvNkjh_yOOveHToJKufo5m5EIg=.91875057-0cba-4432-a055-4b64b88e2c74@github.com>
Message-ID: <M_HxLuxx2Ku5qwgeq5K6AmIbqS1AFd9WRUCPerfWXtg=.e6b49443-46f0-43d9-89c9-5babe61f8446@github.com>

On Mon, 16 Jun 2025 17:32:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> It's really unusual in our source code to pass const Metadata pointers because of the history of the code.  We should probably start doing that.  I'll change this to const and see if there's a fall out.
>
> Much of the metadata parameter declarations aren't const-safe.  Adding this one const has a big fall-out leading to some jni calls.  This would be is a good project and we should have it for new code, which some of this is.  I'll see if can add any consts.

Thanks for investigating!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151047748

From dcubed at openjdk.org  Mon Jun 16 23:23:30 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 16 Jun 2025 23:23:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
Message-ID: <QyDVFbx5X1nKCsiScE9Wdqhe1M-4NZQm6vVBosh_C4c=.58bc0cff-abf9-41bb-8993-8f69f38ed15e@github.com>

On Mon, 16 Jun 2025 15:34:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classLoaderData.cpp line 594:
>> 
>>> 592: // Because native code (e.g. JVMTI agent) holding jmethod_ids may access them
>>> 593: // after the associated classes and class loader are unloaded, subsequent lookups
>>> 594: // for these ids will return null since they are no longer found in the table.
>> 
>> Perhaps: s/null/nullptr/
>
> I thought the convention was that we were supposed to call it `null` in the comments and `nullptr` in the code.

I'm not sure, but your reasoning sounds good to me!

>> src/hotspot/share/oops/method.cpp line 2063:
>> 
>>> 2061: 
>>> 2062: // jmethodID handling
>>> 2063: // jmethodIDs are 64-bit integers that will never run out and are mapped in a table
>> 
>> Should we have a `guarantee` or `assert` somewhere that the counter never wraps?
>
> Okay, I added one when we increment the jmethod_id_counter.
> 
>   // Update jmethodID global counter.
>   _jmethodID_counter++;
>   guarantee(_jmethodID_counter != 0, "must never go back to zero");
> 
> I think this will detect wraparound.

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151046551
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151049919

From sspitsyn at openjdk.org  Tue Jun 17 00:35:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 00:35:38 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <c6YMPUnsEiLMVY6wVHLRlQROxob_qa0h6rPf2Y2v2XE=.25f049d3-41fc-4836-83b4-90905a6d8fd5@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
 <c6YMPUnsEiLMVY6wVHLRlQROxob_qa0h6rPf2Y2v2XE=.25f049d3-41fc-4836-83b4-90905a6d8fd5@github.com>
Message-ID: <nwo_G20SoMxSmsdbf_Ik9clWwtm7CLdbCdWhn9gA3NI=.bf9e664f-a39b-4f52-90a9-7609c94f89a5@github.com>

On Mon, 16 Jun 2025 15:45:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Release note updated.

Somehow I do not see a release note associated with this bug.
Do you mean this sub-task: https://bugs.openjdk.org/browse/JDK-8359700 ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2978553366

From sspitsyn at openjdk.org  Tue Jun 17 00:52:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 00:52:28 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
In-Reply-To: <_zJZC52NDqJzJj47y7d8D__cvoS9UQkE3Feavy9SkVk=.d0bf8255-99b3-4568-86dd-d74033cd3a7c@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
 <dNUtkt8mFuNytgw8hWq_NGQLAnGrc3bQklMbe2EPG0s=.0b5e2500-fc96-4146-9992-3aa2c9271afc@github.com>
 <_zJZC52NDqJzJj47y7d8D__cvoS9UQkE3Feavy9SkVk=.d0bf8255-99b3-4568-86dd-d74033cd3a7c@github.com>
Message-ID: <vD-9AWWtrNQWlW_V8dUgCKccFM27izUliRAtuOcG2zw=.fc8a0a30-4a3a-4d71-9a4c-b13fbba39dab@github.com>

On Mon, 16 Jun 2025 16:09:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 44:
>> 
>>> 42:  * debugee VM process.
>>> 43:  * Derived classes should implement these methods corresponding to the mode
>>> 44:  * that the process should be started in (locally).
>> 
>> I think this can be dropped
>
> Which part?

I guess, Alex suggested to simplify this statement, or maybe to remove it.
This part looks a little bit strange when there is only one (local) mode:
 `these methods corresponding to the mode`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2151119585

From dholmes at openjdk.org  Tue Jun 17 03:22:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 03:22:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
Message-ID: <210dnKnGx2ztDlrfGgi1TTu5UmwSuaK86cLk2iTb9eg=.377f2324-a42d-437f-921d-25679704274e@github.com>

On Mon, 16 Jun 2025 17:37:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting errors.

This looks good. I'm still digesting it.

Thanks

src/hotspot/share/oops/instanceKlass.cpp line 2480:

> 2478: void InstanceKlass::make_methods_jmethod_ids() {
> 2479:   MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
> 2480:   jmethodID* jmeths = methods_jmethod_ids_acquire();

Technically you don't need acquire semantics here as this value is not used to then access other data. But I see this is the only getter API available.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2933991535
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151221096

From dholmes at openjdk.org  Tue Jun 17 03:22:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 03:22:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
Message-ID: <RqoZecEAlBrXZiz-phdgfB5qDOlaCGPNTvFpqlV0P0E=.15063dfa-f7cc-4668-95ac-c3befda6804f@github.com>

On Mon, 16 Jun 2025 15:51:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/jmethodIDTable.cpp line 98:
>> 
>>> 96: 
>>> 97: static JmethodEntry* get_jmethod_entry(jmethodID mid) {
>>> 98:   assert(mid != nullptr, "JNI method id should not be null");
>> 
>> Perhaps: s/null/nullptr/
>> I can't remember if assert failure text output is okay to be `null`.
>
> I think the rules are comments and strings say `null` and code is `nullptr`.

Yes that is the general rule. We can talk about null-ness as a concept, e..g "x must not be null", whereas `nullptr` is a C++ artifact used to check null-ness.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151225664

From dholmes at openjdk.org  Tue Jun 17 03:22:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 03:22:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <QyDVFbx5X1nKCsiScE9Wdqhe1M-4NZQm6vVBosh_C4c=.58bc0cff-abf9-41bb-8993-8f69f38ed15e@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
 <QyDVFbx5X1nKCsiScE9Wdqhe1M-4NZQm6vVBosh_C4c=.58bc0cff-abf9-41bb-8993-8f69f38ed15e@github.com>
Message-ID: <7xxqpdg2SI6cJkzx8BJArFT9T7aHT1yR1tqskFP0dc8=.998f269d-1fc6-4ea8-806f-78efcb3c2d73@github.com>

On Mon, 16 Jun 2025 23:19:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Okay, I added one when we increment the jmethod_id_counter.
>> 
>>   // Update jmethodID global counter.
>>   _jmethodID_counter++;
>>   guarantee(_jmethodID_counter != 0, "must never go back to zero");
>> 
>> I think this will detect wraparound.
>
> Thanks!

Given it will take 584 years to wrap-around at a generation rate of 1 per nanosecond, I think we can just use an assertion here, as the only way this could fire is if we initialize the counter incorrectly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151233626

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 aboldtch at openjdk.org  Tue Jun 17 05:28:29 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 17 Jun 2025 05:28:29 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
Message-ID: <rIDKSrj2LJT49uWyiNWP8dbOw-5D6lnQWaOOkWRyz1w=.0dc38fc2-31d3-4ad5-8757-844c3183197a@github.com>

On Mon, 16 Jun 2025 17:37:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting errors.

src/hotspot/share/oops/jmethodIDTable.cpp line 126:

> 124: static bool needs_resize(Thread* current) {
> 125:   return ((_jmethodID_counter > (_resize_load_trigger * table_size(current))) &&
> 126:          !_jmethod_id_table->is_max_size_reached());

Should we not just have a separate jmethodID entry count variable we use here instead, that is incremented and decremented on insert and remove. Rather than using the next jmethodID counter which just grows monotonically regardless of any removals.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2151348302

From syan at openjdk.org  Tue Jun 17 06:18:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 06:18:39 GMT
Subject: RFR: 8359733: UnProblemList
 serviceability/jvmti/vthread/SuspendWithInterruptLock
In-Reply-To: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
References: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
Message-ID: <7HDTuwHcVnuYTbWCnp0agsoHr_TYojFQ-fGVf4uTZMI=.2f98b09c-1886-40d6-a4da-6e5b5bfe85c2@github.com>

On Mon, 16 Jun 2025 21:34:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The bug [JDK-8312064](https://bugs.openjdk.org/browse/JDK-8312064) is not reproducible anymore and will be closed as a dup of [JDK-8316682](https://bugs.openjdk.org/browse/JDK-8316682).
> The test SuspendWithInterruptLock needs to be unproblem-listed.

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25837#pullrequestreview-2934245396

From sspitsyn at openjdk.org  Tue Jun 17 06:18:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 06:18:38 GMT
Subject: RFR: 8359733: UnProblemList
 serviceability/jvmti/vthread/SuspendWithInterruptLock
Message-ID: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>

The bug [JDK-8312064](https://bugs.openjdk.org/browse/JDK-8312064) is not reproducible anymore and will be closed as a dup of [JDK-8316682](https://bugs.openjdk.org/browse/JDK-8316682).
The test SuspendWithInterruptLock needs to be unproblem-listed.

-------------

Commit messages:
 - update copyright comment
 - 8359733: UnProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock

Changes: https://git.openjdk.org/jdk/pull/25837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359733
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25837/head:pull/25837

PR: https://git.openjdk.org/jdk/pull/25837

From dholmes at openjdk.org  Tue Jun 17 06:24:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 06:24:27 GMT
Subject: RFR: 8359733: UnProblemList
 serviceability/jvmti/vthread/SuspendWithInterruptLock
In-Reply-To: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
References: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
Message-ID: <vgyDhL7QVeZVTLjfnZ7uq2WYHkfF5kbxJJ1zUybUYPw=.dea18a40-8578-4b9e-93be-ff2f1a723da2@github.com>

On Mon, 16 Jun 2025 21:34:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The bug [JDK-8312064](https://bugs.openjdk.org/browse/JDK-8312064) is not reproducible anymore and will be closed as a dup of [JDK-8316682](https://bugs.openjdk.org/browse/JDK-8316682).
> The test SuspendWithInterruptLock needs to be unproblem-listed.

Okay.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25837#pullrequestreview-2934277878

From kevinw at openjdk.org  Tue Jun 17 07:53:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 17 Jun 2025 07:53:38 GMT
Subject: RFR: 8347114: JMXServiceURL should require an explicit protocol
 [v2]
In-Reply-To: <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
References: <FZB4CGdMYCTJ--K6KO5M-ddg3wD0wqacSCv3sfRDZrQ=.2e63ded9-1c69-4b44-860b-3b86375eede0@github.com>
 <fgA_5s8NT3BugBxx4WUuP_3akXOwBWlbOLe_p7nvUy4=.c01e516b-8617-4f19-ad4e-ca41d0cdd154@github.com>
Message-ID: <EXzePSII58cp2v_cakXXpdWwDKa8KC_4AcMfZy1fCrQ=.497c92f6-5214-465e-8607-d81ad4ca5188@github.com>

On Mon, 9 Jun 2025 15:22:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the historic oddity that JMXServiceURL defaults to jmxmp if a null protocol is specified.
>> 
>> This has been the case for JMXServiceURL constructors that take individual parameters, but not for JMXServiceURL(String serviceURL), which enforces that there must be a protocol (If empty in the String, it throws: java.net.MalformedURLException: Missing or invalid protocol name: "")
>> 
>> A missing (null) protocol should throw a MalformedURLException for all constructors.
>> 
>> JMXMP was never part of the JDK, but a separate component in the historic JMX Remote reference implementation.
>> 
>> While we are here, remove the last remaining JMXMP references in the source:
>> 
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java:     * (JMXMP Connector and RMI Connector).</p>
>> src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java:     * (JMXMP Connector and RMI Connector).</p>
>> 
>> These doc references are just examples of Connectors that support generation of client stubs.  There is no need for JMXMP to be mentioned here.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Yes that's right, the release note text in the subtask.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25674#issuecomment-2979312052

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 coleenp at openjdk.org  Tue Jun 17 12:31:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 12:31:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <210dnKnGx2ztDlrfGgi1TTu5UmwSuaK86cLk2iTb9eg=.377f2324-a42d-437f-921d-25679704274e@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
 <210dnKnGx2ztDlrfGgi1TTu5UmwSuaK86cLk2iTb9eg=.377f2324-a42d-437f-921d-25679704274e@github.com>
Message-ID: <O75TTWY7226NSPOJjL_WN-y7AKm_XYnr1U7rSIzDgCo=.ae353906-456d-49b4-813b-8718c0af70a9@github.com>

On Tue, 17 Jun 2025 02:53:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix formatting errors.
>
> src/hotspot/share/oops/instanceKlass.cpp line 2480:
> 
>> 2478: void InstanceKlass::make_methods_jmethod_ids() {
>> 2479:   MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
>> 2480:   jmethodID* jmeths = methods_jmethod_ids_acquire();
> 
> Technically you don't need acquire semantics here as this value is not used to then access other data. But I see this is the only getter API available.

Yes, this does need an acquire getter outside the lock.  It's better to not have a non-acquire version to be possibly used by accident.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2152140447

From coleenp at openjdk.org  Tue Jun 17 12:31:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 12:31:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <rIDKSrj2LJT49uWyiNWP8dbOw-5D6lnQWaOOkWRyz1w=.0dc38fc2-31d3-4ad5-8757-844c3183197a@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
 <rIDKSrj2LJT49uWyiNWP8dbOw-5D6lnQWaOOkWRyz1w=.0dc38fc2-31d3-4ad5-8757-844c3183197a@github.com>
Message-ID: <YInTSGozt5BJ86MuUurTxiw9zfiQ3n6Mt9ltU012Atk=.22534677-0e8c-4f0c-96a6-1f08d25a5e66@github.com>

On Tue, 17 Jun 2025 05:24:57 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix formatting errors.
>
> src/hotspot/share/oops/jmethodIDTable.cpp line 126:
> 
>> 124: static bool needs_resize(Thread* current) {
>> 125:   return ((_jmethodID_counter > (_resize_load_trigger * table_size(current))) &&
>> 126:          !_jmethod_id_table->is_max_size_reached());
> 
> Should we not just have a separate jmethodID entry count variable we use here instead, that is incremented and decremented on insert and remove. Rather than using the next jmethodID counter which just grows monotonically regardless of any removals.

If we remove a jmethodID, we need to keep the number for it in case some JVMTI code still thinks that number is valid.  So we can't decrement the entry count.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2152136500

From coleenp at openjdk.org  Tue Jun 17 12:49:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 12:49:34 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
Message-ID: <JPWf6lt40JTJMMb_n5IZKYfbTtrNHvwyEghrdDaRljI=.530595d2-d168-496d-92f7-101d3874f198@github.com>

On Mon, 9 Jun 2025 13:58:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move it to public

This looks good.  Looking forward to future improvements in this code.  Thank you!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2935521048

From dholmes at openjdk.org  Tue Jun 17 12:51:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 12:51:29 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <O75TTWY7226NSPOJjL_WN-y7AKm_XYnr1U7rSIzDgCo=.ae353906-456d-49b4-813b-8718c0af70a9@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
 <210dnKnGx2ztDlrfGgi1TTu5UmwSuaK86cLk2iTb9eg=.377f2324-a42d-437f-921d-25679704274e@github.com>
 <O75TTWY7226NSPOJjL_WN-y7AKm_XYnr1U7rSIzDgCo=.ae353906-456d-49b4-813b-8718c0af70a9@github.com>
Message-ID: <B1i6JbBHQUEmgvgTov8Ff6LqG9QDETZi8YMHSCVfgA0=.b1e8d8a8-b423-4e73-8791-33990bc62df9@github.com>

On Tue, 17 Jun 2025 12:29:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 2480:
>> 
>>> 2478: void InstanceKlass::make_methods_jmethod_ids() {
>>> 2479:   MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
>>> 2480:   jmethodID* jmeths = methods_jmethod_ids_acquire();
>> 
>> Technically you don't need acquire semantics here as this value is not used to then access other data. But I see this is the only getter API available.
>
> Yes, this does need an acquire getter outside the lock.  It's better to not have a non-acquire version to be possibly used by accident.

Acquire is only ever needed outside the lock. I don't like there only being acquire/release available generally speaking because it just confuses what memory operations are being synchronized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2152188477

From coleenp at openjdk.org  Tue Jun 17 12:59:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 12:59:54 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v3]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <5RiyOu1SrdvAOEmpnPYQjcvu-faSm7wiDQpq1HJKXzo=.2b66a579-3cc2-4d90-93a0-b33c14496aba@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - I meant HandshakeState_lock.
 - Add comment for JmethodIdCreation_lock about why it's rank safepoint-1.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/c2f2f42c..067046bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Tue Jun 17 12:59:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 12:59:54 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v3]
In-Reply-To: <ZCnaXO9d0IcTxOx-zPxObRWnG3v2reaWlMCt8lHXYnE=.04b48006-d3f1-45a3-992a-817df0a637cd@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <SAuCidR9RZ3Mi7wS-dwyG9gyi_MQFRMEnyNFGbwnBjQ=.1f2f4f58-1cd1-4853-951c-27b502d65190@github.com>
 <ZCnaXO9d0IcTxOx-zPxObRWnG3v2reaWlMCt8lHXYnE=.04b48006-d3f1-45a3-992a-817df0a637cd@github.com>
Message-ID: <GVqD5mkUMRvJrZw6COEloZ8ub4pfmV6LtZYG9lkYRhQ=.bcfb4bc2-0288-48f9-98c8-19f25b88d885@github.com>

On Mon, 16 Jun 2025 20:33:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I can't remember.  There may have been another lock held while this one was (which is why we added MUTEX_DEFL to help with that).  I'll check.
>
> This has to be nosafepoint-1 (actually can be nosafepoint) is that it must be above the rank for the ConcurrentHashTable which is nosafepoint-2.  I don't know why it was nosafepoint-2 before this though, I can't find any lock ordering that requires this.
> 
> In general we should use the highest lock ordering within the category (no-safepoint, safepoint) possible to leave room for further locks.

Found why it needed to be nosafepoint-1.  The DEFL macro is good for the global locks but HandshakeState_lock is not global since there's one per handshake operation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2152204429

From coleenp at openjdk.org  Tue Jun 17 13:59:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Jun 2025 13:59:54 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v4]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <xcTZkJrd2AkPcOgB81ARBgfXL28PJgvihlmn8LNZMF8=.a5e62ac3-02f8-41a7-8b8b-5c4d4d3c29db@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use load_acquire only in the places that need it.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/067046bf..41d49607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=02-03

  Stats: 23 lines in 3 files changed: 9 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From aboldtch at openjdk.org  Tue Jun 17 13:59:54 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 17 Jun 2025 13:59:54 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <YInTSGozt5BJ86MuUurTxiw9zfiQ3n6Mt9ltU012Atk=.22534677-0e8c-4f0c-96a6-1f08d25a5e66@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
 <rIDKSrj2LJT49uWyiNWP8dbOw-5D6lnQWaOOkWRyz1w=.0dc38fc2-31d3-4ad5-8757-844c3183197a@github.com>
 <YInTSGozt5BJ86MuUurTxiw9zfiQ3n6Mt9ltU012Atk=.22534677-0e8c-4f0c-96a6-1f08d25a5e66@github.com>
Message-ID: <h_bjdDDEoupPDN26neFUTzd_zNUC0jYsXc-9Epk5-tQ=.deabe63e-872b-4609-8757-58d11aee79c8@github.com>

On Tue, 17 Jun 2025 12:27:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/jmethodIDTable.cpp line 126:
>> 
>>> 124: static bool needs_resize(Thread* current) {
>>> 125:   return ((_jmethodID_counter > (_resize_load_trigger * table_size(current))) &&
>>> 126:          !_jmethod_id_table->is_max_size_reached());
>> 
>> Should we not just have a separate jmethodID entry count variable we use here instead, that is incremented and decremented on insert and remove. Rather than using the next jmethodID counter which just grows monotonically regardless of any removals.
>
> If we remove a jmethodID, we need to keep the number for it in case some JVMTI code still thinks that number is valid.  So we can't decrement the entry count.

That is not was I was trying to propose. What I tried to describe was this:

```c++
// The value of the next jmethodID. This only increments (always unique IDs)
static uint64_t _jmethodID_counter = 0; 
// Tracks the number of jmethodID entries in the _jmethod_id_table. 
// Incremented on insert, decremented on remove. Use to track if we need to resize the table.
static uint64_t _jmethodID_entry_count = 0;


The problem with using `_jmethodID_counter` as a proxy for how many entries there are in the table is that it will diverge over time as we keep calling remove due to class unloading.

Using a separate variable lets us resize based on what is actual in the table.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2152350643

From matsaave at openjdk.org  Tue Jun 17 16:32:33 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 17 Jun 2025 16:32:33 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
Message-ID: <jrllxuKNtrAPbm14qwoDRDVqkM4muJEdr83mdq6AlrQ=.9d007c93-e8f1-492c-a7bd-7a153f652e5a@github.com>

On Mon, 9 Jun 2025 13:58:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move it to public

Changes look good, thanks for doing this!

src/hotspot/share/oops/constantPool.hpp line 85:

> 83:   u2 _argument_count;
> 84: 
> 85:   const u2* argument_indexes() const {

I agree with Lois that some comments here would be useful. I think the original comment can stay where it is and you can add some extra details here.

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2936238823
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2152626054

From lmesnik at openjdk.org  Tue Jun 17 17:09:30 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 17 Jun 2025 17:09:30 GMT
Subject: RFR: 8359733: UnProblemList
 serviceability/jvmti/vthread/SuspendWithInterruptLock
In-Reply-To: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
References: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
Message-ID: <-6o2CAwKwYuhDcBTV1dqnt_iTEeIqiGf0nHCgyIgd8c=.5dd45e75-1a38-4d33-a0ec-631ed9dbf4f4@github.com>

On Mon, 16 Jun 2025 21:34:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The bug [JDK-8312064](https://bugs.openjdk.org/browse/JDK-8312064) is not reproducible anymore and will be closed as a dup of [JDK-8316682](https://bugs.openjdk.org/browse/JDK-8316682).
> The test SuspendWithInterruptLock needs to be unproblem-listed.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25837#pullrequestreview-2936458865

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 cjplummer at openjdk.org  Tue Jun 17 17:53:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Jun 2025 17:53:45 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java [v2]
In-Reply-To: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
Message-ID: <X1a-NGsHa-cXXinroSmkNB9VPUg5Cb7HkpWoXeYqKjo=.ae1520a3-ba51-4e96-960a-8cd60503839d@github.com>

> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
> 
> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
> 
> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
> 
> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java
  
  Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25785/files
  - new: https://git.openjdk.org/jdk/pull/25785/files/21dc4e5d..ed0999c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25785&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25785&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25785.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25785/head:pull/25785

PR: https://git.openjdk.org/jdk/pull/25785

From cjplummer at openjdk.org  Tue Jun 17 17:53:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Jun 2025 17:53:45 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java [v2]
In-Reply-To: <vD-9AWWtrNQWlW_V8dUgCKccFM27izUliRAtuOcG2zw=.fc8a0a30-4a3a-4d71-9a4c-b13fbba39dab@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
 <dNUtkt8mFuNytgw8hWq_NGQLAnGrc3bQklMbe2EPG0s=.0b5e2500-fc96-4146-9992-3aa2c9271afc@github.com>
 <_zJZC52NDqJzJj47y7d8D__cvoS9UQkE3Feavy9SkVk=.d0bf8255-99b3-4568-86dd-d74033cd3a7c@github.com>
 <vD-9AWWtrNQWlW_V8dUgCKccFM27izUliRAtuOcG2zw=.fc8a0a30-4a3a-4d71-9a4c-b13fbba39dab@github.com>
Message-ID: <ycjS0Na8cLutyPQdlaDDhRwJ2cknIMMYYvayKVGVPY4=.d60318a4-4333-44dd-9c15-3bc8726666af@github.com>

On Tue, 17 Jun 2025 00:49:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Which part?
>
> I guess, Alex suggested to simplify this statement, or maybe to remove it.
> This part looks a little bit strange when there is only one (local) mode:
>  `these methods corresponding to the mode`.

There are a lot of references to "local" in comments and API names (in most of the files changed, not just DebugeeProcessl.java). I started down the path of cleaning these all up, but there ended up being a lot, and it distracts from the main purpose of this CR, which is removing BindServer.java. I'd rather do the other "local" cleanups in another PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2152837710

From sspitsyn at openjdk.org  Tue Jun 17 19:25:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 19:25:34 GMT
Subject: RFR: 8359733: UnProblemList
 serviceability/jvmti/vthread/SuspendWithInterruptLock
In-Reply-To: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
References: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
Message-ID: <VX9K3BDAux8YZemBHo-Ic5vZ1rYS4G4Vgl9zvB1iswM=.bb3864a6-f607-4772-b6dd-342a36e3474f@github.com>

On Mon, 16 Jun 2025 21:34:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The bug [JDK-8312064](https://bugs.openjdk.org/browse/JDK-8312064) is not reproducible anymore and will be closed as a dup of [JDK-8316682](https://bugs.openjdk.org/browse/JDK-8316682).
> The test SuspendWithInterruptLock needs to be unproblem-listed.

SendaoYan, David and Leonid, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25837#issuecomment-2981581304

From sspitsyn at openjdk.org  Tue Jun 17 19:25:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 19:25:34 GMT
Subject: Integrated: 8359733: UnProblemList
 serviceability/jvmti/vthread/SuspendWithInterruptLock
In-Reply-To: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
References: <djzHwJdTHhPLZ_nHHjx4vaZzOKfpVfyGNoOj5xbqVYM=.96234c67-2aa7-428d-8907-a12d97f73993@github.com>
Message-ID: <YXS-A0vJNvZq6i_7kQnGvmiUyz6ToJ-I4-fRIdsdgGQ=.3ea0ae95-6bc0-4409-8002-48825ede2dd8@github.com>

On Mon, 16 Jun 2025 21:34:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The bug [JDK-8312064](https://bugs.openjdk.org/browse/JDK-8312064) is not reproducible anymore and will be closed as a dup of [JDK-8316682](https://bugs.openjdk.org/browse/JDK-8316682).
> The test SuspendWithInterruptLock needs to be unproblem-listed.

This pull request has now been integrated.

Changeset: 164cae46
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/164cae469ca0b97b01ce36402a248be308419af6
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8359733: UnProblemList serviceability/jvmti/vthread/SuspendWithInterruptLock

Reviewed-by: syan, dholmes, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/25837

From naoto at openjdk.org  Tue Jun 17 20:37:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jun 2025 20:37:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
Message-ID: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>

Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

-------------

Commit messages:
 - Several more locations
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359732
  Stats: 69 lines in 13 files changed: 50 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25860/head:pull/25860

PR: https://git.openjdk.org/jdk/pull/25860

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 sspitsyn at openjdk.org  Tue Jun 17 22:36:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 22:36:28 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java [v2]
In-Reply-To: <X1a-NGsHa-cXXinroSmkNB9VPUg5Cb7HkpWoXeYqKjo=.ae1520a3-ba51-4e96-960a-8cd60503839d@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
 <X1a-NGsHa-cXXinroSmkNB9VPUg5Cb7HkpWoXeYqKjo=.ae1520a3-ba51-4e96-960a-8cd60503839d@github.com>
Message-ID: <2gyrz9_V-j1apl_w3DtZPhkK0i5pfU8-ajnIXKO79Xg=.86fe2626-48f5-4dbe-9c7b-a90048ae90ca@github.com>

On Tue, 17 Jun 2025 17:53:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
>> 
>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
>> 
>> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
>> 
>> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java
>   
>   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

This looks good.

I was not able to post any comment or approve for a couple of hours. It was some kind of `github` failure.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25785#pullrequestreview-2936868210
PR Comment: https://git.openjdk.org/jdk/pull/25785#issuecomment-2982020892

From sspitsyn at openjdk.org  Tue Jun 17 22:36:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 22:36:29 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java [v2]
In-Reply-To: <ycjS0Na8cLutyPQdlaDDhRwJ2cknIMMYYvayKVGVPY4=.d60318a4-4333-44dd-9c15-3bc8726666af@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
 <dNUtkt8mFuNytgw8hWq_NGQLAnGrc3bQklMbe2EPG0s=.0b5e2500-fc96-4146-9992-3aa2c9271afc@github.com>
 <_zJZC52NDqJzJj47y7d8D__cvoS9UQkE3Feavy9SkVk=.d0bf8255-99b3-4568-86dd-d74033cd3a7c@github.com>
 <vD-9AWWtrNQWlW_V8dUgCKccFM27izUliRAtuOcG2zw=.fc8a0a30-4a3a-4d71-9a4c-b13fbba39dab@github.com>
 <ycjS0Na8cLutyPQdlaDDhRwJ2cknIMMYYvayKVGVPY4=.d60318a4-4333-44dd-9c15-3bc8726666af@github.com>
Message-ID: <uV6c2rNFMsOxlsOXLqVy0HZcEq5MnyciUE05yh2n7f0=.7c2057fd-e7c9-4e7f-a7c4-1160272b1b0f@github.com>

On Tue, 17 Jun 2025 17:49:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I guess, Alex suggested to simplify this statement, or maybe to remove it.
>> This part looks a little bit strange when there is only one (local) mode:
>>  `these methods corresponding to the mode`.
>
> There are a lot of references to "local" in comments and API names (in most of the files changed, not just DebugeeProcessl.java). I started down the path of cleaning these all up, but there ended up being a lot, and it distracts from the main purpose of this CR, which is removing BindServer.java. I'd rather do the other "local" cleanups in another PR.

It sounds good to me, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25785#discussion_r2153034919

From achung at openjdk.org  Tue Jun 17 23:11:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:11:15 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

-------------

Commit messages:
 - empty commit
 - redo ws fixes, add manual changes

Changes: https://git.openjdk.org/jdk/pull/25839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1574 lines in 76 files changed: 810 ins; 93 del; 671 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From achung at openjdk.org  Tue Jun 17 23:18:27 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:18:27 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <-07gTVUiE_k1Kfc5m2OgDlX6fj1hUMYWZqsSK2YFlYc=.0fc07185-3be2-4f7c-b24f-fca061924170@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

whitespace changes are fixed, PR is ready for review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2982077742

From jlu at openjdk.org  Tue Jun 17 23:18:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:18:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 2:

> 1: #
> 2: # Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved.

Same as my comment in `src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java`

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] ''{dir|jar|class}'' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Extra quotes, applies to other localized versions as well. (Usual change we revert)

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.

Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314389
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153313105
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314152

From jlu at openjdk.org  Tue Jun 17 23:24:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:24:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <41BnI9ePFiQiYk_COU-Rrpz0qzr33GN0p9AfF38Fkmk=.0d9c1020-d538-41b2-a939-f7e296029ae0@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 30:

> 28: STARNN=*******************************************\n\n
> 29: # keytool: Help part
> 30: .OPTION.=\ [OPTION]...

We spoke about this offline. This is fine, property file values need to either start with a `\ `or `\u0020` to denote intentional leading white space. In this case, since we convert to UTF-8 native characters from escape sequences this gets included as well. Functionally, they are equivalent and the new form works well with the translation process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153321343

From achung at openjdk.org  Tue Jun 17 23:34:52 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:34:52 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  fix unicode escapes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/2dfac379..d8027691

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00-01

  Stats: 459 lines in 3 files changed: 0 ins; 0 del; 459 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From sspitsyn at openjdk.org  Tue Jun 17 23:40:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 23:40:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v4]
In-Reply-To: <xcTZkJrd2AkPcOgB81ARBgfXL28PJgvihlmn8LNZMF8=.a5e62ac3-02f8-41a7-8b8b-5c4d4d3c29db@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <xcTZkJrd2AkPcOgB81ARBgfXL28PJgvihlmn8LNZMF8=.a5e62ac3-02f8-41a7-8b8b-5c4d4d3c29db@github.com>
Message-ID: <Te7Cm0oWlnAjEjgWoNW9tCMQN-F4rzVYa05P-5HTmFE=.3703f059-647c-453b-a30f-648a8676f0bb@github.com>

On Tue, 17 Jun 2025 13:59:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use load_acquire only in the places that need it.

This is really great optimization and refactoring!
Looks pretty good to me but I'd like to make one more pass through the changes.

src/hotspot/share/oops/instanceKlass.cpp line 2412:

> 2410: }
> 2411: 
> 2412: // Lookup or create a jmethodID

Nit: Add dot at the end.

src/hotspot/share/oops/instanceKlass.cpp line 2472:

> 2470:       // Allocate a larger one and copy entries to the new one.
> 2471:       // They've already been updated to point to new methods where applicable (i.e., not obsolete).
> 2472:       jmethodID* new_cache = create_jmethod_id_cache(size);

Nice micro-refactoring!

src/hotspot/share/oops/jmethodIDTable.hpp line 48:

> 46:   static void remove(jmethodID mid);
> 47: 
> 48:   // RedefineClasses support

Nit: Add a dot at the end of the comment for consistency with other comments.

src/hotspot/share/oops/method.hpp line 718:

> 716: 
> 717:   static void change_method_associated_with_jmethod_id(jmethodID old_jmid_ptr, Method* new_method);
> 718:   static bool validate_method_id(jmethodID mid);

Nit: I'd suggest to name it `validate_jmethod_id` for consistency.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2937302206
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2153333668
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2153332839
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2153323790
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2153315538

From sspitsyn at openjdk.org  Tue Jun 17 23:40:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Jun 2025 23:40:32 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <h_bjdDDEoupPDN26neFUTzd_zNUC0jYsXc-9Epk5-tQ=.deabe63e-872b-4609-8757-58d11aee79c8@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
 <rIDKSrj2LJT49uWyiNWP8dbOw-5D6lnQWaOOkWRyz1w=.0dc38fc2-31d3-4ad5-8757-844c3183197a@github.com>
 <YInTSGozt5BJ86MuUurTxiw9zfiQ3n6Mt9ltU012Atk=.22534677-0e8c-4f0c-96a6-1f08d25a5e66@github.com>
 <h_bjdDDEoupPDN26neFUTzd_zNUC0jYsXc-9Epk5-tQ=.deabe63e-872b-4609-8757-58d11aee79c8@github.com>
Message-ID: <U-LXGE_z4FS4hlSY9jWNbJCMecVVEqMc5wRLdmauoeM=.4b8b829c-e53b-4c48-affc-1afa4d1c5d95@github.com>

On Tue, 17 Jun 2025 13:56:41 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> If we remove a jmethodID, we need to keep the number for it in case some JVMTI code still thinks that number is valid.  So we can't decrement the entry count.
>
> That is not was I was trying to propose. What I tried to describe was this:
> 
> ```c++
> // The value of the next jmethodID. This only increments (always unique IDs)
> static uint64_t _jmethodID_counter = 0; 
> // Tracks the number of jmethodID entries in the _jmethod_id_table. 
> // Incremented on insert, decremented on remove. Use to track if we need to resize the table.
> static uint64_t _jmethodID_entry_count = 0;
> 
> 
> The problem with using `_jmethodID_counter` as a proxy for how many entries there are in the table is that it will diverge over time as we keep calling remove due to class unloading.
> 
> Using a separate variable lets us resize based on what is actual in the table.

Interesting suggestion to consider. I'm not sure yet if it is really important.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2153327605

From almatvee at openjdk.org  Tue Jun 17 23:43:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 17 Jun 2025 23:43:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <uLYnpuvdWyGcO615myaP0lHZ9HMiX9Ag27OnViwh5Ik=.cb34bbec-542b-40a6-98ab-270e2b63bcae@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

jdk.jpackage changes looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2937331933

From naoto at openjdk.org  Wed Jun 18 01:56:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 01:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:

> 1: #

Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153463170

From sspitsyn at openjdk.org  Wed Jun 18 02:36:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Jun 2025 02:36:32 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
Message-ID: <dBVTpIEds4K_d_8seBWye9NV1B-EWga3CI3DmZFwUu8=.3b68a83b-a3a5-4808-8e33-e8b1938978b6@github.com>

On Mon, 9 Jun 2025 13:58:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move it to public

It is nice update and refactoring in general.

src/hotspot/share/oops/constantPool.cpp line 1953:

> 1951:       k1 = bsm_attribute_entry(idx1)->argument_index(j);
> 1952:       k2 = cp2->bsm_attribute_entry(idx2)->argument_index(j);
> 1953:       match = compare_entry_to(k1, cp2, k2);

Nit: I'd suggest to define two locals to simplify the code as below:

  BSMAttributeEntry* e1 = bsm_attribute_entry(idx1);
  BSMAttributeEntry& e2 = cp2->bsm_attribute_entry(idx12);
 
  int k1 = e1->bootstrap_method_index();
  int k2 = e2->bootstrap_method_index();
  bool match = compare_entry_to(k1, cp2, k2);

  if (!match) {
    return false;
  }
  int argc = e1->argument_count();
  if (argc == e2->argument_count()) {
    for (int j = 0; j < argc; j++) {
      k1 = e1->argument_index(j);
      k2 = e2->argument_index(j);
      match = compare_entry_to(k1, cp2, k2);

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 29:

> 27: #include "memory/universe.hpp"
> 28: #include "oops/constantPool.hpp"
> 29: #include "oops/constantPool.inline.hpp"

The line 28 is not needed as we already have line 29.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2937554075
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2153510993
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2153513749

From sspitsyn at openjdk.org  Wed Jun 18 02:50:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Jun 2025 02:50:36 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
Message-ID: <Q8e9MdhQLpgjInaD84GUZfHnJs7nNVEkOJbKjTJ_nFk=.d74d4d26-33e5-4065-8f4d-d34018ac2530@github.com>

On Mon, 9 Jun 2025 13:58:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move it to public

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 686:

> 684: 
> 685:   for (int i = 0; i < argc; i++) {
> 686:     u2 old_arg_ref_i = scratch_cp->bsm_attribute_entry(old_bs_i)->argument_index(i);

Nit: Could you, consider below for a code simplification? :

  BSMAttributeEntry* old_bsme = scratch_cp->bsm_attribute_entry(old_bs_i);
. . .
665  u2 old_ref_i = old_bsme->bootstrap_method_index();
. . .
679  u2 argc = old_bsme->argument_count();
. . .
686    u2 old_arg_ref_i = old_bsme->argument_index(i);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2153527548

From sspitsyn at openjdk.org  Wed Jun 18 04:26:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Jun 2025 04:26:27 GMT
Subject: RFR: 8359180: Apply java.io.Serial annotations in java.instrument
In-Reply-To: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>
References: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>
Message-ID: <BUp-mTmXAg2aNbVBgdKog6pqO6zZ_QGxnQu-o3FD1gc=.9622a8a8-2589-43e8-9525-a7c231687e0f@github.com>

On Tue, 10 Jun 2025 23:19:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.instrument module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
> 
> This annotation can be applied to these methods in the module:
> 
> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
> private void readObjectNoData() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
> private static final ObjectStreamField[] serialPersistentFields
> private static final long serialVersionUID
> 
> 
> Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module.

Looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25738#pullrequestreview-2937683909

From vyazici at openjdk.org  Wed Jun 18 07:10:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 18 Jun 2025 07:10:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2937989243

From alanb at openjdk.org  Wed Jun 18 07:55:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:55:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.base/share/classes/module-info.java line 287:

> 285:         jdk.jpackage,
> 286:         jdk.jshell,
> 287:         jdk.net;

At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110: 
> 111:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jhsdb tool, just wondering why it needs to be changed.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java line 802:

> 800:         }
> 801:         try {
> 802:             Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the example jdb debugger, I assume okay to let it read the stdin.encoding property.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153907749
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153910478
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153913162

From alanb at openjdk.org  Wed Jun 18 07:59:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:59:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <HS_moiW1ZXnwCePhJrtlJTtiwO37FEHMKxldVBPgDcw=.d649f3bf-3ce2-44d9-bc5c-9ed5f74b333d@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.scripting/share/classes/javax/script/SimpleScriptContext.java line 100:

> 98: 
> 99:     private static InputStreamReader stdinReader() {
> 100:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jrunscript command line tool. I suppose it's possible it could run a script that changes stdin.encoding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153921907

From ayang at openjdk.org  Wed Jun 18 09:00:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 09:00:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363

-------------

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=12
  Stats: 4371 lines in 31 files changed: 520 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Wed Jun 18 09:01:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 09:01:00 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
Message-ID: <spZuyO1XSapuWZgnkytsHbL1hsKUIWMPQLD4xbEHJz0=.3233c3a7-6b78-462f-9c3c-4909910ff768@github.com>

On Sun, 18 May 2025 15:36:03 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - pgc-size-policy
>
> src/hotspot/share/gc/parallel/psYoungGen.cpp line 268:
> 
>> 266:   size_t original_committed_size = virtual_space()->committed_size();
>> 267: 
>> 268:   while (true) {
> 
> The `while` statement only runs once. May we find a better way to refactor the code?

@lgxbslgx I did some restructuring based on some offline discussion -- hopefully, the new style is more readable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2154053199

From nbenalla at openjdk.org  Wed Jun 18 09:08:29 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 09:08:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <xcSAVqLxI2phW8UCEHcDpUMeFySiy0zigXx-MPkt5aU=.0c203d6f-60e1-41d1-82d5-a93bba898f5f@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

I'm unable to confirm the accuracy of the translations, since I don't speak the target languages. I've only reviewed the `jdk.javadoc` sources.

All keys in the English property files match one-to-one with those in the non-English files: there are no missing or extra entries. The only changes are to the `.properties` files, exactly as the PR title suggests.

>From the `jdk.javadoc` perspective, this looks good, so I'm happy to approve this PR.

-------------

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2938377311

From jsikstro at openjdk.org  Wed Jun 18 09:50:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 18 Jun 2025 09:50:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2983504760

From kevinw at openjdk.org  Wed Jun 18 11:39:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 18 Jun 2025 11:39:04 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
Message-ID: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>

javax.management classes AttributeList, RoleList and UnresolvedRoleList have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.

This feature should be removed, and these classes should never accept the wrong kind of Object.

-------------

Commit messages:
 - test/jdk/javax/management/generified/ListTypeCheckTest.java

Changes: https://git.openjdk.org/jdk/pull/25856/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359809
  Stats: 257 lines in 5 files changed: 42 ins; 164 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

PR: https://git.openjdk.org/jdk/pull/25856

From kevinw at openjdk.org  Wed Jun 18 11:39:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 18 Jun 2025 11:39:04 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <lM5XX4Je06UCEnDo84fxvJhq1-DIeOWjLuAnjvCgTeQ=.f645452c-7f2b-403a-a1cf-9acd1b659f8d@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> javax.management classes AttributeList, RoleList and UnresolvedRoleList have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

src/java.management/share/classes/javax/management/relation/RoleList.java line 195:

> 193: 
> 194:         if (role == null) {
> 195:             throw new IllegalArgumentException("Invalid parameter");

Removing the trailing dot from "parameter.", here and new line 247 below, to be in line with the rest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2154370578

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 coleenp at openjdk.org  Wed Jun 18 12:06:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:06:23 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v5]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <004wleJ3yHgoUNrbtM7k6dGPoQ3olVfohABbP_4OvdA=.99779359-8024-4fe0-8563-9172acb1d991@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Serguei's comments rename validate_jmethod_id

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/41d49607..333d344c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=03-04

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Wed Jun 18 12:06:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:06:26 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v4]
In-Reply-To: <Te7Cm0oWlnAjEjgWoNW9tCMQN-F4rzVYa05P-5HTmFE=.3703f059-647c-453b-a30f-648a8676f0bb@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <xcTZkJrd2AkPcOgB81ARBgfXL28PJgvihlmn8LNZMF8=.a5e62ac3-02f8-41a7-8b8b-5c4d4d3c29db@github.com>
 <Te7Cm0oWlnAjEjgWoNW9tCMQN-F4rzVYa05P-5HTmFE=.3703f059-647c-453b-a30f-648a8676f0bb@github.com>
Message-ID: <k2dFnCO8JxHxgU6SJS-9aDkyxS5KJX1hlO0vSSGDzjo=.d169749f-d853-4019-84a9-b2ef797fd748@github.com>

On Tue, 17 Jun 2025 23:34:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use load_acquire only in the places that need it.
>
> src/hotspot/share/oops/instanceKlass.cpp line 2412:
> 
>> 2410: }
>> 2411: 
>> 2412: // Lookup or create a jmethodID
> 
> Nit: Add dot at the end.

fixed.

> src/hotspot/share/oops/jmethodIDTable.hpp line 48:
> 
>> 46:   static void remove(jmethodID mid);
>> 47: 
>> 48:   // RedefineClasses support
> 
> Nit: Add a dot at the end of the comment for consistency with other comments.

This isn't a sentence and this pattern is in the sources in a lot of places, none of these places have a period at the end.

> src/hotspot/share/oops/method.hpp line 718:
> 
>> 716: 
>> 717:   static void change_method_associated_with_jmethod_id(jmethodID old_jmid_ptr, Method* new_method);
>> 718:   static bool validate_method_id(jmethodID mid);
> 
> Nit: I'd suggest to name it `validate_jmethod_id` for consistency.

Good suggestion - these names get confusing without the 'j'.  I tried to make them consistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2154417361
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2154420659
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2154422068

From coleenp at openjdk.org  Wed Jun 18 12:06:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:06:26 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v2]
In-Reply-To: <U-LXGE_z4FS4hlSY9jWNbJCMecVVEqMc5wRLdmauoeM=.4b8b829c-e53b-4c48-affc-1afa4d1c5d95@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <j3BI3P-_j8ro6tOJO6xvOwjt3uF2ea0no7nn5fSsgxQ=.4f7a9919-3106-4fe6-84c3-d1a61b981859@github.com>
 <rIDKSrj2LJT49uWyiNWP8dbOw-5D6lnQWaOOkWRyz1w=.0dc38fc2-31d3-4ad5-8757-844c3183197a@github.com>
 <YInTSGozt5BJ86MuUurTxiw9zfiQ3n6Mt9ltU012Atk=.22534677-0e8c-4f0c-96a6-1f08d25a5e66@github.com>
 <h_bjdDDEoupPDN26neFUTzd_zNUC0jYsXc-9Epk5-tQ=.deabe63e-872b-4609-8757-58d11aee79c8@github.com>
 <U-LXGE_z4FS4hlSY9jWNbJCMecVVEqMc5wRLdmauoeM=.4b8b829c-e53b-4c48-affc-1afa4d1c5d95@github.com>
Message-ID: <5Uzay5zSlbA4oXBvXrEFMymaxuHo6SFx6U55Pz3Tnoo=.bacb52e9-0913-4346-938c-d511e1b4b47b@github.com>

On Tue, 17 Jun 2025 23:28:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> That is not was I was trying to propose. What I tried to describe was this:
>> 
>> ```c++
>> // The value of the next jmethodID. This only increments (always unique IDs)
>> static uint64_t _jmethodID_counter = 0; 
>> // Tracks the number of jmethodID entries in the _jmethod_id_table. 
>> // Incremented on insert, decremented on remove. Use to track if we need to resize the table.
>> static uint64_t _jmethodID_entry_count = 0;
>> 
>> 
>> The problem with using `_jmethodID_counter` as a proxy for how many entries there are in the table is that it will diverge over time as we keep calling remove due to class unloading.
>> 
>> Using a separate variable lets us resize based on what is actual in the table.
>
> Interesting suggestion to consider. I'm not sure yet if it is really important.

This makes sense because we want to know how many items are in the table vs. how many items have been in the table.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2154424321

From coleenp at openjdk.org  Wed Jun 18 12:06:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:06:27 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v5]
In-Reply-To: <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
Message-ID: <F3hIv3kNRwezM0Vm_E4NfrCU-JlNMVldvMGhDHwvEhU=.15957c17-a97e-47de-a855-33cc97b675b3@github.com>

On Fri, 13 Jun 2025 20:18:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Serguei's comments rename validate_jmethod_id
>
> src/hotspot/share/oops/jmethodIDTable.hpp line 31:
> 
>> 29: #include "memory/allocation.hpp"
>> 30: 
>> 31: // Class for associating Method with jmethodID
> 
> nit typo: please add an ending period to the comment.

fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2154419139

From coleenp at openjdk.org  Wed Jun 18 12:13:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:13:54 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v6]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <0nLuoxUlhYAgg2cRGC1EpOp_HqWsg5SH11Uj1RmOMhE=.865999e3-c1a1-4369-8772-b430ee16cd59@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add entry count for jmethodID table.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/333d344c..fd9bf502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=04-05

  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Wed Jun 18 12:18:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:18:49 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps
Message-ID: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>

This uses names for frame types for stackmaps in the verifier and redefinition.
Tested with tier1-7.

-------------

Commit messages:
 - 8359920: Use names for frame types in stackmaps

Changes: https://git.openjdk.org/jdk/pull/25870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359920
  Stats: 23 lines in 3 files changed: 8 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/25870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25870/head:pull/25870

PR: https://git.openjdk.org/jdk/pull/25870

From jsjolen at openjdk.org  Wed Jun 18 12:24:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 18 Jun 2025 12:24:31 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <y_r-2Vk0AeyYDrr1vfCfnR_kkEEGenpZsiEzwNkPUT8=.5671f221-8656-4cfe-b676-c3d8d7d1161c@github.com>

On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

Marked as reviewed by jsjolen (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2938988022

From jsjolen at openjdk.org  Wed Jun 18 12:27:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 18 Jun 2025 12:27:31 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <dBVTpIEds4K_d_8seBWye9NV1B-EWga3CI3DmZFwUu8=.3b68a83b-a3a5-4808-8e33-e8b1938978b6@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
 <dBVTpIEds4K_d_8seBWye9NV1B-EWga3CI3DmZFwUu8=.3b68a83b-a3a5-4808-8e33-e8b1938978b6@github.com>
Message-ID: <glyYTlF0XbOiGKEysVcR4IYwglDJPXaqM0dtX2AF5r0=.098de0dc-f71d-4041-8019-af16cd340e76@github.com>

On Wed, 18 Jun 2025 02:28:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move it to public
>
> src/hotspot/share/oops/constantPool.cpp line 1953:
> 
>> 1951:       k1 = bsm_attribute_entry(idx1)->argument_index(j);
>> 1952:       k2 = cp2->bsm_attribute_entry(idx2)->argument_index(j);
>> 1953:       match = compare_entry_to(k1, cp2, k2);
> 
> Nit: I'd suggest to define two locals to simplify the code as below:
> 
>   BSMAttributeEntry* e1 = bsm_attribute_entry(idx1);
>   BSMAttributeEntry& e2 = cp2->bsm_attribute_entry(idx12);
>  
>   int k1 = e1->bootstrap_method_index();
>   int k2 = e2->bootstrap_method_index();
>   bool match = compare_entry_to(k1, cp2, k2);
> 
>   if (!match) {
>     return false;
>   }
>   int argc = e1->argument_count();
>   if (argc == e2->argument_count()) {
>     for (int j = 0; j < argc; j++) {
>       k1 = e1->argument_index(j);
>       k2 = e2->argument_index(j);
>       match = compare_entry_to(k1, cp2, k2);

Yeah, that's a good simplification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2154466594

From jsjolen at openjdk.org  Wed Jun 18 12:37:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 18 Jun 2025 12:37:07 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v5]
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <4uEo1C_csdAppvNYFqU1JtgADY-m4as2wBIq1kVq_GA=.6125ab99-8b92-410c-9257-852d8e7eb47e@github.com>

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Matias's comments
 - Apply Sergei's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25298/files
  - new: https://git.openjdk.org/jdk/pull/25298/files/1c7484d7..af3caa9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=03-04

  Stats: 17 lines in 4 files changed: 6 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25298/head:pull/25298

PR: https://git.openjdk.org/jdk/pull/25298

From jsjolen at openjdk.org  Wed Jun 18 12:37:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 18 Jun 2025 12:37:07 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v4]
In-Reply-To: <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <lyyd3U8iPFbjCfkhSVJxBl42WU8IhxV58M6ShZMT5PM=.16ce6f45-e5c7-43f4-b30a-d900b8848d4a@github.com>
Message-ID: <vV0fgHlK6qfvLqyKMhG5LaCuel9oPPo5101IObfgF6M=.1020603a-58a4-4698-874d-5af1287a72c6@github.com>

On Mon, 9 Jun 2025 13:58:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move it to public

Thank you for the reviews! I applied your comments, will await GHA before integration (also need a re-approval).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25298#issuecomment-2984018108

From coleenp at openjdk.org  Wed Jun 18 12:46:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 12:46:56 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add a basic gtest.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/fd9bf502..8339a6b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=05-06

  Stats: 63 lines in 3 files changed: 63 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Wed Jun 18 14:53:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Jun 2025 14:53:55 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
Message-ID: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>

Hi all,

This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.

This has been running cleanly in CI for a week now.

Thanks!

-------------

Commit messages:
 - Backport e18277b470a162b9668297e8e286c812c4b0b604

Changes: https://git.openjdk.org/jdk/pull/25877/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25877&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352075
  Stats: 924 lines in 18 files changed: 854 ins; 20 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/25877.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25877/head:pull/25877

PR: https://git.openjdk.org/jdk/pull/25877

From rriggs at openjdk.org  Wed Jun 18 15:08:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <LbRBF6gknL_SsjFh_wALuLuFGTOFzDNYTUikL7MbvA8=.f0b9e433-da69-4280-9a3d-9150dfaa1b80@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Static properties should not be used outside of java.base.
The "for internal use only" should have said "java.base internal use only"
Adding a comment to that effect would be a good idea.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2939624079

From rriggs at openjdk.org  Wed Jun 18 15:08:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:30 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
Message-ID: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>

On Wed, 18 Jun 2025 07:50:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> src/java.base/share/classes/module-info.java line 287:
> 
>> 285:         jdk.jpackage,
>> 286:         jdk.jshell,
>> 287:         jdk.net;
> 
> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

The original intent of StaticProperties was to limit it to the base module.
Other modules are free to read the property themselves.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2154852609

From rvansa at openjdk.org  Wed Jun 18 15:44:28 2025
From: rvansa at openjdk.org (Radim Vansa)
Date: Wed, 18 Jun 2025 15:44:28 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <EQkGA5KulUvKT_Md8-bNN93M0Y1uT1MVlerRe-GxbW0=.9f2b4393-9d8d-41c2-9950-e0908e37af46@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Thank you for the backport! @shipilev indicated that the backport to 21 should wait a bit, could you clarify when should I file that (e.g. end of July, ...)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-2984754129

From aivanov at openjdk.org  Wed Jun 18 16:15:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:15:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:

> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.

Shall the copyright year be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:

> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
> 459: SliderDemo.majorticks=Grobteilungen
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen

Should the translation of `SliderDemo.majorticks` also be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

The following description uses different words now:

Feinteilungen -> Teilstrichen
Teilungen -> Teilstrichen

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:

> 181: size.bit.alg=%1$d-Bit-%2$s
> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}

It feels as if there's something missing after _?einem?_.

src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46:

> 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben
> 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben
> 46: Subject.=Subject:\n

Is it correct? German usually uses `k`.

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:

> 54: 
> 55: # javax.security.auth.login.AppConfigurationEntry
> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020

Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:

> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:

Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:

> 227: doclet.search_in_documentation=In Dokumentation suchen
> 228: doclet.search_reset=Zur?cksetzen
> 229: doclet.Member=Member

Is `Member` translated? Should it be _?Mitglied?_?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154931256
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154807291
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154813672
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154907979
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154905960
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154915395
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154968902
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154985100

From jlu at openjdk.org  Wed Jun 18 16:24:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:24:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <epU16E3XQ7BNcECTdZbJJpdFw05jYxEZ8Kt1yRx34nY=.a5624636-51ea-4466-83c2-6e0f7aa6aca1@github.com>

On Wed, 18 Jun 2025 15:28:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
> 
>> 54: 
>> 55: # javax.security.auth.login.AppConfigurationEntry
>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
> 
> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155032074

From jlu at openjdk.org  Wed Jun 18 16:28:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:28:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>

On Wed, 18 Jun 2025 15:34:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
> 
>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Shall the copyright year be updated?

In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155038247

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 aivanov at openjdk.org  Wed Jun 18 16:45:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:45:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
Message-ID: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>

On Wed, 18 Jun 2025 16:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
>> 
>>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Shall the copyright year be updated?
>
> In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

This is weird? Usually, the copyright year is bumped up whenever the file is edited.

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
>> 
>>> 54: 
>>> 55: # javax.security.auth.login.AppConfigurationEntry
>>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
>> 
>> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.
>
> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

Thank you for clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071387
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071915

From naoto at openjdk.org  Wed Jun 18 16:58:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 16:58:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
Message-ID: <GMreFXOIVIHSDY6c8Vcze6uvKnnsOAaNIH6G5rBfkQA=.507f3521-b8a6-4024-a1ed-d41f71a9c1e1@github.com>

On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

Those languages (de/ja/zh-CN) are the ones we (Oracle) support. Other entities would be welcome to provide l10n for other languages (not a sporadic l10n, but commit to update/maintain).

> 
> Edit: I see that the other localizations haven't been updated for the last few releases, so maybe this is intentional. Still interested to know why we have the other localizations if they aren't updated.

Usuallly l10n resource updates are additions, so those old l10ns still have values for those languages. New additions will simply fall back to English.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2985038815

From larry.cable at oracle.com  Wed Jun 18 17:23:04 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 18 Jun 2025 10:23:04 -0700
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@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>
 <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@github.com>
Message-ID: <c6886778-6239-44b6-b8a7-2f0ffbd5cf2f@oracle.com>

I believe that somewhere in the bowels of MacOS libc there is a 
(hopefully public) function that will map a UID to the UUID used to 
construct
the per-user directory path from a base 36(?) encoded string thereof, 
the leading 2 characters of which form the "buckets" in /var/folders
and the remainder of the encoded string forms the per user directory 
with the appropriate bucket...

if might make sense to perform a serious investigation to locate this 
function and then simply make a native call to map the target JVM euid
to the uuid and encode it, from which the actual /var/folders/... path 
can be constructed avoiding a costly traversal of the /var/folders
structure in the search for hsperfdata_user files?

Rgds

- Larry

On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
> 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 matsaave at openjdk.org  Wed Jun 18 17:49:31 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 18 Jun 2025 17:49:31 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <oWbv-B6Qjg-w56mRbxroPgFmYKWN6YVgBYD1B4d-kvA=.b2989ea7-bd45-4e43-9e08-5cad5f3a28fb@github.com>

On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

LGTM, thanks!

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2940165788

From sspitsyn at openjdk.org  Wed Jun 18 17:55:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Jun 2025 17:55:34 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v5]
In-Reply-To: <4uEo1C_csdAppvNYFqU1JtgADY-m4as2wBIq1kVq_GA=.6125ab99-8b92-410c-9257-852d8e7eb47e@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <4uEo1C_csdAppvNYFqU1JtgADY-m4as2wBIq1kVq_GA=.6125ab99-8b92-410c-9257-852d8e7eb47e@github.com>
Message-ID: <kGzPpZkKta0JAczpumGuprQSiw57G4kTQdfOYZxyW8g=.0d77cae6-649d-4f04-b172-4e227c0b13d4@github.com>

On Wed, 18 Jun 2025 12:37:07 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Matias's comments
>  - Apply Sergei's comments

src/hotspot/share/oops/constantPool.cpp line 1944:

> 1942:   BSMAttributeEntry* e2 = bsm_attribute_entry(idx2);
> 1943:   int k1 = e1->bootstrap_method_index();
> 1944:   int k2 = cp2->e2->bootstrap_method_index();

I'm kind of confused, this does not look right. It is event not going to be compiled.
It is supposed to be as below:

BSMAttributeEntry* e2 = cp2->bsm_attribute_entry(idx2);
. . .
int k2 = e2->bootstrap_method_index();
. . .
    if (argc == e2->argument_count()) {
. . .
    k2 = e2->argument_index(j);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2155183220

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 achung at openjdk.org  Wed Jun 18 18:42:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 18 Jun 2025 18:42:54 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <3Sb_Nj53MtMZRoKypbBFn0yumsFtiGJzY5fv60CilwA=.4ee9201b-0657-484b-8e69-01306c131b39@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  remove double quotes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d8027691..66c34e7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From cjplummer at openjdk.org  Wed Jun 18 18:46:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Jun 2025 18:46:40 GMT
Subject: RFR: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java [v2]
In-Reply-To: <X1a-NGsHa-cXXinroSmkNB9VPUg5Cb7HkpWoXeYqKjo=.ae1520a3-ba51-4e96-960a-8cd60503839d@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
 <X1a-NGsHa-cXXinroSmkNB9VPUg5Cb7HkpWoXeYqKjo=.ae1520a3-ba51-4e96-960a-8cd60503839d@github.com>
Message-ID: <yOY-1iLxHau7MZEfqn-yFHojz-RN_Ts02Ve2t6JQJcs=.11f10e22-efba-4a1a-affe-27a25c2608fb@github.com>

On Tue, 17 Jun 2025 17:53:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
>> 
>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
>> 
>> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
>> 
>> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java
>   
>   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

Thanks for the reviews Alex, Serguei, and Leonid!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25785#issuecomment-2985346187

From cjplummer at openjdk.org  Wed Jun 18 18:46:40 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Jun 2025 18:46:40 GMT
Subject: Integrated: 8359167: Remove unused
 test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java
In-Reply-To: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
References: <GM0uWb4fbr0hkAckAmUsYrL1Pw0GKcEcNR_FY3eIsjI=.91af7c0c-8022-450e-9357-4bcb366dc68b@github.com>
Message-ID: <Zt0wCSvG2oDMNgxGTGCVZZx5S7O6E9Za65r-lUirBEI=.a2482649-d556-4e3b-84fe-ece9c93d1d7c@github.com>

On Thu, 12 Jun 2025 18:01:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The nsk BindServer class is no longer used so it can be removed. This appears to be a remnant left over after the following recent change:
> 
> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) Remove support of remote and manual debuggee launchers
> 
> There is also some additional cleanup of "manual" and "remote" debuggee launchers done by this PR and fixing some comments that have been wrong for a long time regarding "see also".
> 
> Tested by running nsk/jdi, nsk/jdb, and nsk/jdwp tests locally. I'll also run them with tier5 CI once reviews have been done.

This pull request has now been integrated.

Changeset: 982064e5
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/982064e50ca6bbcfb7d1d619307921adc6f4fdcd
Stats:     1906 lines in 6 files changed: 2 ins; 1895 del; 9 mod

8359167: Remove unused test/hotspot/jtreg/vmTestbase/nsk/share/jpda/BindServer.java

Reviewed-by: sspitsyn, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/25785

From dnguyen at openjdk.org  Wed Jun 18 18:50:29 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 18 Jun 2025 18:50:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
Message-ID: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>

On Tue, 17 Jun 2025 23:15:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155272483

From prr at openjdk.org  Wed Jun 18 20:40:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jun 2025 20:40:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>

On Wed, 18 Jun 2025 14:45:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
> 
>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>> 459: SliderDemo.majorticks=Grobteilungen
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 
> Should the translation of `SliderDemo.majorticks` also be updated?

I agree. I'd expect consistency here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155451453

From larry.cable at oracle.com  Wed Jun 18 21:46:07 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 18 Jun 2025 14:46:07 -0700
Subject: [External] : Re: RFR: 8319589: Attach from root to a user java
 process not supported in Mac [v2]
In-Reply-To: <b4da9552-1164-4974-8307-696a46160b6b@bell-sw.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>
 <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@github.com>
 <c6886778-6239-44b6-b8a7-2f0ffbd5cf2f@oracle.com>
 <b4da9552-1164-4974-8307-696a46160b6b@bell-sw.com>
Message-ID: <d8fa80f0-929a-4e5b-8beb-92d8046af486@oracle.com>



On 6/18/25 12:44 PM, Sergey Chernyshev wrote:
> Hi Larry,
>
> Thank you for your comments! Yes, it's probably more like base 32 / 5 
> bits per symbol. The function is actually __user_local_dirname, it's 
> exported by CoreServices (libsystem_coreservices.dylib). One can 
> dlopen() 
> /System/Library/Frameworks/CoreServices.framework/Versions/Current/CoreServices 
> and then lookup the __user_local_dirname (still works in 15.5 
> Sequoia). The problem is that the function is undocumented, it is not 
> exposed in any platform SDK headers and it is not reachable from any 
> documented api except for the confstr(), at least what i am aware of. 
> With the introduction of dyld shared cache in Big Sur the approach 
> became even less attractive. 

Its probably not worth it, I followed a similar (fruitless) trail to the 
same conclusion a couple of years ago ... :(

> I might need to look deeper into it.
>
> Thanks,
> Sergey
>
>
> Am 18.06.25 um 19:23 schrieb Laurence Cable:
>> I believe that somewhere in the bowels of MacOS libc there is a 
>> (hopefully public) function that will map a UID to the UUID used to 
>> construct
>> the per-user directory path from a base 36(?) encoded string thereof, 
>> the leading 2 characters of which form the "buckets" in /var/folders
>> and the remainder of the encoded string forms the per user directory 
>> with the appropriate bucket...
>>
>> if might make sense to perform a serious investigation to locate this 
>> function and then simply make a native call to map the target JVM euid
>> to the uuid and encode it, from which the actual /var/folders/... 
>> path can be constructed avoiding a costly traversal of the /var/folders
>> structure in the search for hsperfdata_user files?
>>
>> Rgds
>>
>> - Larry
>>
>> On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
>>> 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 larry.cable at oracle.com  Wed Jun 18 21:51:35 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 18 Jun 2025 14:51:35 -0700
Subject: [External] : Re: RFR: 8319589: Attach from root to a user java
 process not supported in Mac [v2]
In-Reply-To: <d8fa80f0-929a-4e5b-8beb-92d8046af486@oracle.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>
 <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@github.com>
 <c6886778-6239-44b6-b8a7-2f0ffbd5cf2f@oracle.com>
 <b4da9552-1164-4974-8307-696a46160b6b@bell-sw.com>
 <d8fa80f0-929a-4e5b-8beb-92d8046af486@oracle.com>
Message-ID: <9f2b0a55-4a12-4033-8a7c-48129352e330@oracle.com>

I believe you can ignore bucket "zz"

- Larry

On 6/18/25 2:46 PM, Laurence Cable wrote:
>
>
> On 6/18/25 12:44 PM, Sergey Chernyshev wrote:
>> Hi Larry,
>>
>> Thank you for your comments! Yes, it's probably more like base 32 / 5 
>> bits per symbol. The function is actually __user_local_dirname, it's 
>> exported by CoreServices (libsystem_coreservices.dylib). One can 
>> dlopen() 
>> /System/Library/Frameworks/CoreServices.framework/Versions/Current/CoreServices 
>> and then lookup the __user_local_dirname (still works in 15.5 
>> Sequoia). The problem is that the function is undocumented, it is not 
>> exposed in any platform SDK headers and it is not reachable from any 
>> documented api except for the confstr(), at least what i am aware of. 
>> With the introduction of dyld shared cache in Big Sur the approach 
>> became even less attractive. 
>
> Its probably not worth it, I followed a similar (fruitless) trail to 
> the same conclusion a couple of years ago ... :(
>
>> I might need to look deeper into it.
>>
>> Thanks,
>> Sergey
>>
>>
>> Am 18.06.25 um 19:23 schrieb Laurence Cable:
>>> I believe that somewhere in the bowels of MacOS libc there is a 
>>> (hopefully public) function that will map a UID to the UUID used to 
>>> construct
>>> the per-user directory path from a base 36(?) encoded string 
>>> thereof, the leading 2 characters of which form the "buckets" in 
>>> /var/folders
>>> and the remainder of the encoded string forms the per user directory 
>>> with the appropriate bucket...
>>>
>>> if might make sense to perform a serious investigation to locate 
>>> this function and then simply make a native call to map the target 
>>> JVM euid
>>> to the uuid and encode it, from which the actual /var/folders/... 
>>> path can be constructed avoiding a costly traversal of the /var/folders
>>> structure in the search for hsperfdata_user files?
>>>
>>> Rgds
>>>
>>> - Larry
>>>
>>> On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
>>>> 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 cjplummer at openjdk.org  Wed Jun 18 22:18:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Jun 2025 22:18:09 GMT
Subject: RFR: 8333117: Remove support of remote and manual debuggee launchers
Message-ID: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>

[JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.

Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.

Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.

-------------

Commit messages:
 - Get rid of references to "local" debuggee since it is alays local.

Changes: https://git.openjdk.org/jdk/pull/25887/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333117
  Stats: 103 lines in 18 files changed: 0 ins; 15 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/25887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25887/head:pull/25887

PR: https://git.openjdk.org/jdk/pull/25887

From sspitsyn at openjdk.org  Wed Jun 18 22:31:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Jun 2025 22:31:32 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
Message-ID: <GN_L-T-MtGNBXQQ0rDNvw92Kp7PwNeo75uPKzongu7I=.e9eb88bf-b724-4681-9544-d21f1677be27@github.com>

On Wed, 18 Jun 2025 12:46:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a basic gtest.

The update looks good. I've posted several nits though.

src/hotspot/share/classfile/classLoaderData.cpp line 605:

> 603:     JmethodIDTable::remove(mid);
> 604:   }
> 605:   delete _jmethod_ids;

Nit: I'd null out the `_jmethod_ids` field.

src/hotspot/share/memory/universe.cpp line 440:

> 438:     vmSymbols::initialize();
> 439: 
> 440:     // Initialize table for matching jmethodID, before SystemDictionary

Nit: Dot is missed.

src/hotspot/share/oops/instanceKlass.cpp line 4280:

> 4278: }
> 4279: 
> 4280: // This nulls out jmethodIDs for all obsolete methods in the previous version of the 'klass'

Nit: Dot is missed.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2940857934
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155610947
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155613281
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155617141

From sspitsyn at openjdk.org  Wed Jun 18 22:31:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Jun 2025 22:31:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v4]
In-Reply-To: <k2dFnCO8JxHxgU6SJS-9aDkyxS5KJX1hlO0vSSGDzjo=.d169749f-d853-4019-84a9-b2ef797fd748@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <xcTZkJrd2AkPcOgB81ARBgfXL28PJgvihlmn8LNZMF8=.a5e62ac3-02f8-41a7-8b8b-5c4d4d3c29db@github.com>
 <Te7Cm0oWlnAjEjgWoNW9tCMQN-F4rzVYa05P-5HTmFE=.3703f059-647c-453b-a30f-648a8676f0bb@github.com>
 <k2dFnCO8JxHxgU6SJS-9aDkyxS5KJX1hlO0vSSGDzjo=.d169749f-d853-4019-84a9-b2ef797fd748@github.com>
Message-ID: <BCZFc9t1KW8DAJ_z0z3FhTXCgXsV5G0eCF5-EBskLS8=.443acc34-b873-4014-9f9e-8c2ca1746c59@github.com>

On Wed, 18 Jun 2025 12:00:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/jmethodIDTable.hpp line 48:
>> 
>>> 46:   static void remove(jmethodID mid);
>>> 47: 
>>> 48:   // RedefineClasses support
>> 
>> Nit: Add a dot at the end of the comment for consistency with other comments.
>
> This isn't a sentence and this pattern is in the sources in a lot of places, none of these places have a period at the end.

Okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155619399

From serb at openjdk.org  Wed Jun 18 22:56:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Jun 2025 22:56:40 GMT
Subject: Integrated: 8359180: Apply java.io.Serial annotations in
 java.instrument
In-Reply-To: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>
References: <0b5MF7Qkn-m2feqUbRQMZgNajXgAAYbOW0tK2waSkow=.d0d83dd2-535d-4dc6-9a5b-98c4282baf58@github.com>
Message-ID: <0RM7_ls_0V-fknUFGuOsVmFwmrNr4iPUiP-LmSBzCmY=.9efb1ec7-8aa6-43e5-aedb-ee7808a1848c@github.com>

On Tue, 10 Jun 2025 23:19:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please review the application of `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the java.instrument module to enable stricter compile-time checking of serialization-related declarations. Just a few classes are covered.
> 
> This annotation can be applied to these methods in the module:
> 
> private void writeObject(java.io.ObjectOutputStream stream) throws IOException
> private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
> private void readObjectNoData() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
> ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
> private static final ObjectStreamField[] serialPersistentFields
> private static final long serialVersionUID
> 
> 
> Example of a similar change in the [java.compiler](https://github.com/openjdk/jdk/pull/24891) module.

This pull request has now been integrated.

Changeset: 23e1e2ff
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23e1e2ff4a4a75ec268c7925fb98d6b96a01bbcf
Stats:     16 lines in 3 files changed: 12 ins; 1 del; 3 mod

8359180: Apply java.io.Serial annotations in java.instrument

Reviewed-by: phh, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25738

From cjplummer at openjdk.org  Thu Jun 19 00:33:42 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 19 Jun 2025 00:33:42 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
Message-ID: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>

> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
> 
> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
> 
> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  startLocalDebugee renamed to startDebugee

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25887/files
  - new: https://git.openjdk.org/jdk/pull/25887/files/40624f6b..365cc930

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25887&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25887&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25887/head:pull/25887

PR: https://git.openjdk.org/jdk/pull/25887

From dholmes at openjdk.org  Thu Jun 19 00:44:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 00:44:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
Message-ID: <rQYh0fd0ROq22KTKS2Um1Si6M_ZSYlE_PPWDaGpeWHk=.8e0cc3ef-e9e3-4f0e-ac93-6b57d72b5c8a@github.com>

On Wed, 18 Jun 2025 12:46:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a basic gtest.

Still working my way through this ...

Just to be sure I have the correct mental picture of this, things work as follow:

- a `jMethodID` is just a unique integer index to represent a `Method` for use with JNI
- when we allocate a new `jMethodID` to a `Method` we 
  - add that mapping to the global table
  - add an entry to the `ClassLoaderData`'s `jMethodID` "list"
- each `instanceklass` also maintains a "cache" of its own `jMethodID` mappings (some of which need updating on method redefinition)
- when a class is unloaded we deallocate the cache, deallocate the CLD list, and remove the table entries
- when a JNI API is presented with a `jMethodID` by the caller, it validates it by looking it up in the table, to see if the mapping exists

The cache is created under a lock, and `jMethodID`s are created and added to the cache (and the table, and the CLD list) under the same lock. But access to the cache is lock-free using acquire/release.

The cache is also destroyed under the same lock, and the table entries removed under that same lock, and the CLD list deallocated.

Is the above correct? What details have I missed?

Thanks

src/hotspot/share/oops/instanceKlass.cpp line 2395:

> 2393: 
> 2394: // Allocate the jmethodID cache.
> 2395: static jmethodID* create_jmethod_id_cache(size_t size) {

Why isn't this used at line 2439 to create the (initial?) cache?

src/hotspot/share/oops/jmethodIDTable.cpp line 40:

> 38: static uint64_t _jmethodID_counter = 0;
> 39: // Tracks the number of jmethodID entries in the _jmethod_id_table.
> 40: // Incremented on insert, decremented on remove. Use to track if we need to resize the table.

Suggestion:

// Incremented on insert, decremented on remove. Used to track if we need to resize the table.

src/hotspot/share/oops/jmethodIDTable.cpp line 141:

> 139:   // Update jmethodID global counter.
> 140:   _jmethodID_counter++;
> 141:   guarantee(_jmethodID_counter != 0, "must never go back to zero");

Again a guarantee is not needed here as the only possible way this could trigger is if we initialize it incorrectly./

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2940758855
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155747747
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155550987
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2155763677

From dholmes at openjdk.org  Thu Jun 19 00:48:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 00:48:37 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
Message-ID: <HIetYWCEiQ8p260POJgHXL0O_ILN-hiIOLSelcXeOs0=.7ffa32b8-8503-48ee-8386-64083808c9fc@github.com>

On Wed, 18 Jun 2025 12:46:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a basic gtest.

I wrote above:

> when a JNI API is presented with a jMethodID by the caller, it validates it by looking it up in the table, to see if the mapping exists

This still seems racy though. What if the lookup succeeds but at the same time the class is to be unloaded?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2986150357

From dholmes at openjdk.org  Thu Jun 19 06:28:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 06:28:36 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <J_JFq9-OhvNPkeUWXiByTWcWIlRF7j2W4-d0RpURO38=.0acbcb61-172f-4a39-8095-93d162910b5b@github.com>

On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

src/hotspot/share/classfile/stackMapTable.hpp line 154:

> 152:     SAME_FRAME = 64,
> 153:     SAME_LOCALS_1_STACK_ITEM_FRAME = 128,
> 154:     SAME_LOCALS_1_STACK_ITEM_EXTENDED = 247,

I find these definitions a little confusing. SAME_FRAME is actually 0-63, with SAME_LOCALS_1_STACK_ITEM_FRAME being 64-127. Given many of these frame types imply tag ranges it may be clearer to define enum's for the start and end of ranges as applicable eg.

enum {
  SAME_FRAME_START = 0,
  SAME_FRAME_END = 63,
  SAME_LOCALS_1_STACK_ITEM_FRAME_START = 64,
  SAME_LOCALS_1_STACK_ITEM_FRAME_END = 127,
  RESERVED_START = 128,
  RESERVED_END = 246,
  SAME_LOCALS_1_STACK_ITEM_EXTENDED = 247,
  CHOP_FRAME_START = 248,
  CHOP_FRAME_END = 250,
  SAME_FRAME_EXTENDED = 251,
  APPEND_FRAME_START = 252,
  APPEND_FRAME_END = 254,
  FULL_FRAME = 255
}

and then adjust the code usage as appropriate e.g.

if (frame_type <= SAME_FRAME_END) {
...
if (frame_type <= SAME_LOCALS_1_STACK_ITEM_FRAME_END) {
  if (_first) {
    offset = frame_type - SAME_LOCALS_1_STACK_ITEM_FRAME_START;
...

What do you think?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 3321:

> 3319:     //   u1 frame_type = APPEND; /* 252-254 */
> 3320:     //   u2 offset_delta;
> 3321:     //   verification_type_info locals[frame_type - 251];

Suggestion:

    //   verification_type_info locals[frame_type - SAME_EXTENDED];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25870#discussion_r2156218466
PR Review Comment: https://git.openjdk.org/jdk/pull/25870#discussion_r2156184106

From stuefe at openjdk.org  Thu Jun 19 06:36:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 19 Jun 2025 06:36:40 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
Message-ID: <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>

On Wed, 18 Jun 2025 12:46:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a basic gtest.

I feel apprehensive about this; the solution feels pretty complex and I am not fully convinced this is the simplest solution for this problem. 

How much space to we lose in real life? Side note: I see the payload of the jmethodID block in NMT is allocated with mtInternal, so we don't see it in NMT. We should add jmethodIDs as an own category to NMT.

A pragmatic alternative solution could be to do delete them, but delayed: keep the last N methodblocks undeleted. It is rare that JNI accesses jmethodIDs long after they have been deleted. Typically, the bad access happens close after class unloading, e.g. because of concurrency problems in customer code.

We could then make the parameter N configurable, and thus give customers and supporters a tool to check for these kind of errors.

(I briefly wondered whether we could just mmap these blocks, and uncommit/mprotect them on release, so that we stop paying the memory costs but don't release the address space; but the coarser page size allocation granularity would make this probably forbidding in terms of mem cost per class)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2986801229

From dholmes at openjdk.org  Thu Jun 19 06:53:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 06:53:40 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
 <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>
Message-ID: <dEc5rLfVnoUSPlCiU_ywChgx-QTpfhJ2_Opok8fcOJM=.98a83ec1-282f-45b7-a48c-40d8cd7be531@github.com>

On Thu, 19 Jun 2025 06:33:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a basic gtest.
>
> I feel apprehensive about this; the solution feels pretty complex and I am not fully convinced this is the simplest solution for this problem. 
> 
> How much space to we lose in real life? Side note: I see the payload of the jmethodID block in NMT is allocated with mtInternal, so we don't see it in NMT. We should add jmethodIDs as an own category to NMT.
> 
> A pragmatic alternative solution could be to do delete them, but delayed: keep the last N methodblocks undeleted. It is rare that JNI accesses jmethodIDs long after they have been deleted. Typically, the bad access happens close after class unloading, e.g. because of concurrency problems in customer code.
> 
> We could then make the parameter N configurable, and thus give customers and supporters a tool to check for these kind of errors.
> 
> (I briefly wondered whether we could just mmap these blocks, and uncommit/mprotect them on release, so that we stop paying the memory costs but don't release the address space; but the coarser page size allocation granularity would make this probably forbidding in terms of mem cost per class)

@tstuefe, so at the moment we maintain safety for use-after-unload but at the expense of storage. Coleen's proposal maintains the same level of safety but reclaims the storage. You are suggesting a "simpler" technique to reclaim the storage by reducing the level of safety. I'd prefer to not re-open the door to unsafe usage, no matter how unlikely it may be.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2986841710

From jsjolen at openjdk.org  Thu Jun 19 07:12:16 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 19 Jun 2025 07:12:16 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v5]
In-Reply-To: <kGzPpZkKta0JAczpumGuprQSiw57G4kTQdfOYZxyW8g=.0d77cae6-649d-4f04-b172-4e227c0b13d4@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <4uEo1C_csdAppvNYFqU1JtgADY-m4as2wBIq1kVq_GA=.6125ab99-8b92-410c-9257-852d8e7eb47e@github.com>
 <kGzPpZkKta0JAczpumGuprQSiw57G4kTQdfOYZxyW8g=.0d77cae6-649d-4f04-b172-4e227c0b13d4@github.com>
Message-ID: <8Lvgf50diQvjHNgQSrZQowphu92FZM3M2Z7Fdi1DY5w=.8f7dca64-8cce-48ae-b739-fb609076b07f@github.com>

On Wed, 18 Jun 2025 17:51:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Matias's comments
>>  - Apply Sergei's comments
>
> src/hotspot/share/oops/constantPool.cpp line 1944:
> 
>> 1942:   BSMAttributeEntry* e2 = bsm_attribute_entry(idx2);
>> 1943:   int k1 = e1->bootstrap_method_index();
>> 1944:   int k2 = cp2->e2->bootstrap_method_index();
> 
> I'm kind of confused, this does not look right. It is event not going to be compiled.
> It is supposed to be as below:
> 
> BSMAttributeEntry* e2 = cp2->bsm_attribute_entry(idx2);
> . . .
> int k2 = e2->bootstrap_method_index();
> . . .
>     if (argc == e2->argument_count()) {
> . . .
>     k2 = e2->argument_index(j);

Gah, I accidentally made a mistake with the refactoring. Of course, when I pushed I thought "this change is so simple, no need to check it before pushing" :-). Let me fix that (and compile it myself this time)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2156295434

From jsjolen at openjdk.org  Thu Jun 19 07:35:33 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 19 Jun 2025 07:35:33 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v6]
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <GWLawKWpH9xtQzYE5H8ZXfzUPtFcCIfvw5LWDLNn0Ck=.3fbec1fa-8d63-42f8-b530-47fd918b8d1a@github.com>

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Double check your changes next time!

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25298/files
  - new: https://git.openjdk.org/jdk/pull/25298/files/af3caa9b..d891a3d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25298/head:pull/25298

PR: https://git.openjdk.org/jdk/pull/25298

From sspitsyn at openjdk.org  Thu Jun 19 07:35:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Jun 2025 07:35:34 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v5]
In-Reply-To: <8Lvgf50diQvjHNgQSrZQowphu92FZM3M2Z7Fdi1DY5w=.8f7dca64-8cce-48ae-b739-fb609076b07f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <4uEo1C_csdAppvNYFqU1JtgADY-m4as2wBIq1kVq_GA=.6125ab99-8b92-410c-9257-852d8e7eb47e@github.com>
 <kGzPpZkKta0JAczpumGuprQSiw57G4kTQdfOYZxyW8g=.0d77cae6-649d-4f04-b172-4e227c0b13d4@github.com>
 <8Lvgf50diQvjHNgQSrZQowphu92FZM3M2Z7Fdi1DY5w=.8f7dca64-8cce-48ae-b739-fb609076b07f@github.com>
Message-ID: <zN_u_mzBxrsdV-t-aNOZ3TLOc-v3BbiBC5ropWRvAcI=.8413484c-d175-4d65-bdf7-59953b9315dd@github.com>

On Thu, 19 Jun 2025 07:06:54 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.cpp line 1944:
>> 
>>> 1942:   BSMAttributeEntry* e2 = bsm_attribute_entry(idx2);
>>> 1943:   int k1 = e1->bootstrap_method_index();
>>> 1944:   int k2 = cp2->e2->bootstrap_method_index();
>> 
>> I'm kind of confused, this does not look right. It is event not going to be compiled.
>> It is supposed to be as below:
>> 
>> BSMAttributeEntry* e2 = cp2->bsm_attribute_entry(idx2);
>> . . .
>> int k2 = e2->bootstrap_method_index();
>> . . .
>>     if (argc == e2->argument_count()) {
>> . . .
>>     k2 = e2->argument_index(j);
>
> Gah, I accidentally made a mistake with the refactoring. Of course, when I pushed I thought "this change is so simple, no need to check it before pushing" :-). Let me fix that (and compile it myself this time)

It's okay unless you have not integrated the update. :)
Submitting at least 3 first mach5 tiers before integration will keep you out of potential trouble.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2156332326

From sspitsyn at openjdk.org  Thu Jun 19 07:38:23 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Jun 2025 07:38:23 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v6]
In-Reply-To: <GWLawKWpH9xtQzYE5H8ZXfzUPtFcCIfvw5LWDLNn0Ck=.3fbec1fa-8d63-42f8-b530-47fd918b8d1a@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <GWLawKWpH9xtQzYE5H8ZXfzUPtFcCIfvw5LWDLNn0Ck=.3fbec1fa-8d63-42f8-b530-47fd918b8d1a@github.com>
Message-ID: <uHwF0K87TV0kNkGG4eDZ2W12Teut32ld_ilRmqYF7Vc=.fa4810fa-b71f-41a2-93a6-2ac9734385de@github.com>

On Thu, 19 Jun 2025 07:35:33 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Double check your changes next time!

Thank you for the update. The fix looks good.
I've posted one more nit though.

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 414:

> 412:     write_u2(num_bootstrap_arguments);
> 413:     for (int arg = 0; arg < num_bootstrap_arguments; arg++) {
> 414:       u2 bootstrap_argument = cpool()->bsm_attribute_entry(n)->argument_index(arg);

Nit: This line can also use the `bsme` local: `u2 bootstrap_argument = bsme->argument_index(arg);`
Sorry, I missed this before.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2941919683
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2156344933

From sspitsyn at openjdk.org  Thu Jun 19 07:56:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Jun 2025 07:56:41 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <Ge09zEah-w89cSwmpCeZ7pJdx4hdg-2Xdf7SMmd6xHw=.678a7a55-6bc0-47d2-b41b-9f80e3ddada5@github.com>

On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

This looks good.
I was also thinking about `frame_type` ranges but no ideas on any improvements.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2941977212

From jsjolen at openjdk.org  Thu Jun 19 08:03:20 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 19 Jun 2025 08:03:20 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v7]
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <bdAaHV6lWPNJPAyfs_cbIBxonqZXNaDfcVmVaTwjdmg=.72e02c4f-6018-4b97-b1e4-4f19570bdb72@github.com>

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25298/files
  - new: https://git.openjdk.org/jdk/pull/25298/files/d891a3d3..5d7e46ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25298&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25298/head:pull/25298

PR: https://git.openjdk.org/jdk/pull/25298

From jsjolen at openjdk.org  Thu Jun 19 08:03:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 19 Jun 2025 08:03:22 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v6]
In-Reply-To: <uHwF0K87TV0kNkGG4eDZ2W12Teut32ld_ilRmqYF7Vc=.fa4810fa-b71f-41a2-93a6-2ac9734385de@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <GWLawKWpH9xtQzYE5H8ZXfzUPtFcCIfvw5LWDLNn0Ck=.3fbec1fa-8d63-42f8-b530-47fd918b8d1a@github.com>
 <uHwF0K87TV0kNkGG4eDZ2W12Teut32ld_ilRmqYF7Vc=.fa4810fa-b71f-41a2-93a6-2ac9734385de@github.com>
Message-ID: <f_J1-cFbg3_e_FVMfk4ONi6IIb0JZskryq7-Sh-SBeY=.b25afe80-c1df-4026-91fe-472b76e656c7@github.com>

On Thu, 19 Jun 2025 07:33:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Double check your changes next time!
>
> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 414:
> 
>> 412:     write_u2(num_bootstrap_arguments);
>> 413:     for (int arg = 0; arg < num_bootstrap_arguments; arg++) {
>> 414:       u2 bootstrap_argument = cpool()->bsm_attribute_entry(n)->argument_index(arg);
> 
> Nit: This line can also use the `bsme` local: `u2 bootstrap_argument = bsme->argument_index(arg);`
> Sorry, I missed this before.

Thanks, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2156382285

From sspitsyn at openjdk.org  Thu Jun 19 09:03:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Jun 2025 09:03:30 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v7]
In-Reply-To: <bdAaHV6lWPNJPAyfs_cbIBxonqZXNaDfcVmVaTwjdmg=.72e02c4f-6018-4b97-b1e4-4f19570bdb72@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <bdAaHV6lWPNJPAyfs_cbIBxonqZXNaDfcVmVaTwjdmg=.72e02c4f-6018-4b97-b1e4-4f19570bdb72@github.com>
Message-ID: <nCGwlt4lfHgW6p4gIHanNGE56fEWf9kzM0dVMoV1lpE=.804697a4-dad5-4b9e-abf5-c845ae3b4cf7@github.com>

On Thu, 19 Jun 2025 08:03:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Marked as reviewed by sspitsyn (Reviewer).

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 517:

> 515: 
> 516:     int bsms_attribute_index = cp->bootstrap_methods_attribute_index(cp_index);
> 517:     int arg_count = cp->bsm_attribute_entry(bsms_attribute_index)->argument_count();

Your fix made it possible to do a bit more simplifications.
For instance, each `bsms_attribute_index` parameter can be replaced with a `bsme` parameter.
But this does not look that important at the moment.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25298#pullrequestreview-2942179152
PR Review Comment: https://git.openjdk.org/jdk/pull/25298#discussion_r2156509715

From shade at openjdk.org  Thu Jun 19 10:06:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Jun 2025 10:06:45 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <EQkGA5KulUvKT_Md8-bNN93M0Y1uT1MVlerRe-GxbW0=.9f2b4393-9d8d-41c2-9950-e0908e37af46@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
 <EQkGA5KulUvKT_Md8-bNN93M0Y1uT1MVlerRe-GxbW0=.9f2b4393-9d8d-41c2-9950-e0908e37af46@github.com>
Message-ID: <4QtV9UGiRdP0LG6rIHH_4fwO2f5wm0evnHnut2nxvjM=.ecf61194-7201-4c7e-a496-3ddc821ea079@github.com>

On Wed, 18 Jun 2025 15:42:14 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

> @shipilev indicated that the backport to 21 should wait a bit, could you clarify when should I file that (e.g. end of July, ...)?

I would say for the fairly big change like this, we want to wait until JDK 25 GA (that would pass the all-tests-run). It would be too late for Oct 2025 release, though. So realistically, this would target January 2026 release. You can pull this patch to your downstream JDK 21 to see if there are any troubles ahead of this path, this will also soothe 21u maintainer concerns, I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-2987501194

From kevinw at openjdk.org  Thu Jun 19 11:17:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 19 Jun 2025 11:17:01 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v2]
In-Reply-To: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
Message-ID: <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>

> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
> 
> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
> 
> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
 - spelling
 - Exception name
 - whitespace
 - whitespace
 - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25758/files
  - new: https://git.openjdk.org/jdk/pull/25758/files/a94b49ef..6f28e857

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25758&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25758&range=00-01

  Stats: 14540 lines in 274 files changed: 10342 ins; 3094 del; 1104 mod
  Patch: https://git.openjdk.org/jdk/pull/25758.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25758/head:pull/25758

PR: https://git.openjdk.org/jdk/pull/25758

From magnus.ihse.bursie at oracle.com  Thu Jun 19 12:40:52 2025
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 19 Jun 2025 14:40:52 +0200
Subject: Interest in Java based attach provider implementation?
In-Reply-To: <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
References: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
 <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
Message-ID: <112cc394-b8a9-412a-9ca8-114a73994607@oracle.com>

Hi Philippe,

There is an ongoing effort about "Panamization" (that is, adapting it to 
use FFM instead of JNI) of native code in the JDK in general. This is 
discussed on the core-libs-dev mailing list. I've cc:ed them. I think it 
would be beneficial if you coordinate your efforts with the Panamization 
effort.

/Magnus


On 2025-06-15 17:43, Philippe Marschall wrote:
> Hello
>
> I further pursued the approach
>
> - Rebased the Linux implementation [1], implemented the permission 
> check using JSR 203 and the Unix domain sockets using JEP 380.
> - Applied the same changes to the AIX implementation [2].
> - Switched Linux to an FFM based kill implementation [3], completely 
> getting rid of JNI.
> -? Updated the macOS implementation [4], implemented the permission 
> check using JSR 203 and the Unix domain sockets using JEP 380.
> - Switched macOS to an FFM based kill and sysctl implementation [5], 
> completely getting rid of JNI.
>
> I ran the serviceability test suite on Linux and macOS and it passes. 
> I manually verified that I can attach to JVMs using local builds.
>
> I could not test on AIX.
>
> ?[1] 
> https://github.com/marschall/jdk/commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
> ?[2] 
> https://github.com/marschall/jdk/commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
> ?[3] 
> https://github.com/marschall/jdk/commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559
> ?[4] 
> https://github.com/marschall/jdk/commit/93372a124eca6078fde5597c2498b381a4ef5dfa
> ?[5] 
> https://github.com/marschall/jdk/commit/c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b
>
> Cheers
> Philippe
>
> On 20.04.22 22:13, Philippe Marschall wrote:
>> Hello
>>
>> I hope this is the right mailing list. I recently had a look at the
>> Linux attach provider implementation and could not help but noticing
>> that a large part, if not all of it, could be replaced with Java.
>> Besides getting rid of the C code this should allow us to unify the AIX,
>> Linux and macOS implementations under a single Unix implementation.
>>
>> The permission check can be implemented using JSR 203 [1] to access uid,
>> gid and file mode and using jdk.internal.misc.VM to get the euid and 
>> egid.
>>
>> Reading and writing to Unix domain sockets can be done through JEP 
>> 380 [2].
>>
>> Sending SIGQUIT to a process could in theory done through JEP 102 [3]
>> however sending SIGQUIT to self is currently blocked. This is required
>> for the self attach mechanism. There a very small C function is still
>> needed for now, this is hopefully portable.
>>
>> I did a small prototype [4]. The tier1 suite runs and I can attach to a
>> local JVM.
>>
>> The overhead will likely be a bit higher as we go through more JDK
>> abstractions.
>>
>> ??[1] https://jcp.org/en/jsr/detail?id=203
>> ??[2] https://openjdk.java.net/jeps/380
>> ??[3] https://openjdk.java.net/jeps/102
>> ??[4]
>> https://github.com/marschall/jdk/ 
>> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc
>>
>> Cheers
>> Philippe
>

From serge.chernyshev at bell-sw.com  Wed Jun 18 19:44:21 2025
From: serge.chernyshev at bell-sw.com (Sergey Chernyshev)
Date: Wed, 18 Jun 2025 21:44:21 +0200
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v2]
In-Reply-To: <c6886778-6239-44b6-b8a7-2f0ffbd5cf2f@oracle.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>
 <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@github.com>
 <c6886778-6239-44b6-b8a7-2f0ffbd5cf2f@oracle.com>
Message-ID: <b4da9552-1164-4974-8307-696a46160b6b@bell-sw.com>

Hi Larry,

Thank you for your comments! Yes, it's probably more like base 32 / 5 
bits per symbol. The function is actually __user_local_dirname, it's 
exported by CoreServices (libsystem_coreservices.dylib). One can 
dlopen() 
/System/Library/Frameworks/CoreServices.framework/Versions/Current/CoreServices 
and then lookup the __user_local_dirname (still works in 15.5 Sequoia). 
The problem is that the function is undocumented, it is not exposed in 
any platform SDK headers and it is not reachable from any documented api 
except for the confstr(), at least what i am aware of. With the 
introduction of dyld shared cache in Big Sur the approach became even 
less attractive. I might need to look deeper into it.

Thanks,
Sergey


Am 18.06.25 um 19:23 schrieb Laurence Cable:
> I believe that somewhere in the bowels of MacOS libc there is a 
> (hopefully public) function that will map a UID to the UUID used to 
> construct
> the per-user directory path from a base 36(?) encoded string thereof, 
> the leading 2 characters of which form the "buckets" in /var/folders
> and the remainder of the encoded string forms the per user directory 
> with the appropriate bucket...
>
> if might make sense to perform a serious investigation to locate this 
> function and then simply make a native call to map the target JVM euid
> to the uuid and encode it, from which the actual /var/folders/... path 
> can be constructed avoiding a costly traversal of the /var/folders
> structure in the search for hsperfdata_user files?
>
> Rgds
>
> - Larry
>
> On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
>> 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 duke at openjdk.org  Thu Jun 19 17:42:30 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 19 Jun 2025 17:42:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>

On Wed, 18 Jun 2025 15:25:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
> 
>> 181: size.bit.alg=%1$d-Bit-%2$s
>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
> 
> It feels as if there's something missing after _?einem?_.

seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2157444024

From shade at openjdk.org  Thu Jun 19 18:39:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Jun 2025 18:39:29 GMT
Subject: RFR: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <wSRFrJfHBRVvxn51Uckbi8fpOyX4AmTNMUw07r6HNls=.3d686422-fd26-4243-bf31-ee1713fa5e44@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2943805126

From wkemper at openjdk.org  Thu Jun 19 18:43:33 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Jun 2025 18:43:33 GMT
Subject: Integrated: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <tltsW_Y2YhEcfVzMCCvzzqxKhjtB9fLYBmbNf2eDvNk=.437cb104-0b1d-4050-b832-b1990708e81b@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

This pull request has now been integrated.

Changeset: dec42beb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dec42bebb836b2ea244dc19a5964dac828791135
Stats:     18 lines in 5 files changed: 5 ins; 6 del; 7 mod

8359394: GC cause cleanup

Reviewed-by: shade, ysr, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/25789

From coleenp at openjdk.org  Fri Jun 20 12:00:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 12:00:15 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v2]
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <XgV2_AmkKeaijSLT2Osss2XJ6LaadG8nOtbMyNpaxJ4=.a82ef7f7-8683-452b-a2ad-9f7925b820d4@github.com>

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25870/files
  - new: https://git.openjdk.org/jdk/pull/25870/files/37b5c7ee..c3d8d0fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25870/head:pull/25870

PR: https://git.openjdk.org/jdk/pull/25870

From coleenp at openjdk.org  Fri Jun 20 12:00:16 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 12:00:16 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v2]
In-Reply-To: <J_JFq9-OhvNPkeUWXiByTWcWIlRF7j2W4-d0RpURO38=.0acbcb61-172f-4a39-8095-93d162910b5b@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <J_JFq9-OhvNPkeUWXiByTWcWIlRF7j2W4-d0RpURO38=.0acbcb61-172f-4a39-8095-93d162910b5b@github.com>
Message-ID: <Ntcvg5ptxuBDgXN-fQckGLTIGu0CHQzXkoCnrI7-pHM=.f2e4eb5c-8185-4732-999f-70a63149e1b6@github.com>

On Thu, 19 Jun 2025 06:24:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
>>   
>>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/classfile/stackMapTable.hpp line 154:
> 
>> 152:     SAME_FRAME = 64,
>> 153:     SAME_LOCALS_1_STACK_ITEM_FRAME = 128,
>> 154:     SAME_LOCALS_1_STACK_ITEM_EXTENDED = 247,
> 
> I find these definitions a little confusing. SAME_FRAME is actually 0-63, with SAME_LOCALS_1_STACK_ITEM_FRAME being 64-127. Given many of these frame types imply tag ranges it may be clearer to define enum's for the start and end of ranges as applicable eg.
> 
> enum {
>   SAME_FRAME_START = 0,
>   SAME_FRAME_END = 63,
>   SAME_LOCALS_1_STACK_ITEM_FRAME_START = 64,
>   SAME_LOCALS_1_STACK_ITEM_FRAME_END = 127,
>   RESERVED_START = 128,
>   RESERVED_END = 246,
>   SAME_LOCALS_1_STACK_ITEM_EXTENDED = 247,
>   CHOP_FRAME_START = 248,
>   CHOP_FRAME_END = 250,
>   SAME_FRAME_EXTENDED = 251,
>   APPEND_FRAME_START = 252,
>   APPEND_FRAME_END = 254,
>   FULL_FRAME = 255
> }
> 
> and then adjust the code usage as appropriate e.g.
> 
> if (frame_type <= SAME_FRAME_END) {
> ...
> if (frame_type <= SAME_LOCALS_1_STACK_ITEM_FRAME_END) {
>   if (_first) {
>     offset = frame_type - SAME_LOCALS_1_STACK_ITEM_FRAME_START;
> ...
> 
> What do you think?

I wasn't really up for a big rewrite but having the complete set of names would be really good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25870#discussion_r2158789990

From coleenp at openjdk.org  Fri Jun 20 12:49:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 12:49:12 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v3]
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <cQOvlX1jxTQwkg-EXIwAAKW0XXlhUqU3UzNFAeBY7P4=.0efbac49-3e39-4800-9ac5-edee759412bf@github.com>

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Apply David's suggested more complete and accurate frame type names.  Being careful with >=s.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25870/files
  - new: https://git.openjdk.org/jdk/pull/25870/files/c3d8d0fc..107382e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=01-02

  Stats: 35 lines in 3 files changed: 10 ins; 0 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/25870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25870/head:pull/25870

PR: https://git.openjdk.org/jdk/pull/25870

From coleenp at openjdk.org  Fri Jun 20 15:05:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 15:05:03 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v4]
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix tags (running more tests)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25870/files
  - new: https://git.openjdk.org/jdk/pull/25870/files/107382e4..7d2e60c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25870/head:pull/25870

PR: https://git.openjdk.org/jdk/pull/25870

From coleenp at openjdk.org  Fri Jun 20 16:04:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 16:04:58 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v8]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <bzC1s2Yrjd4wReezltDmiB5eRBcVB6bCPlZSgZUuWL0=.5843fbbc-8661-4952-b879-b6e547a73738@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing periods and nullptr. thanks Serguei.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/8339a6b5..50c036f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=06-07

  Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From sspitsyn at openjdk.org  Fri Jun 20 16:47:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 16:47:30 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v8]
In-Reply-To: <bzC1s2Yrjd4wReezltDmiB5eRBcVB6bCPlZSgZUuWL0=.5843fbbc-8661-4952-b879-b6e547a73738@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <bzC1s2Yrjd4wReezltDmiB5eRBcVB6bCPlZSgZUuWL0=.5843fbbc-8661-4952-b879-b6e547a73738@github.com>
Message-ID: <dZUUxJgsM-H0YXBIZe2r_JhFRoaNdmbqz8oV1VdwhQ4=.072234fa-83a6-4d14-ad55-60fb69f258d6@github.com>

On Fri, 20 Jun 2025 16:04:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing periods and nullptr. thanks Serguei.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2946793683

From sspitsyn at openjdk.org  Fri Jun 20 17:08:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 17:08:33 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v2]
In-Reply-To: <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
Message-ID: <xiUjG--xMPf_APiSSqHujEr5Wji7UnaUhtwrbXmbj-Q=.05e40d15-324c-4589-b386-affa62c23786@github.com>

On Thu, 19 Jun 2025 11:17:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
>  - spelling
>  - Exception name
>  - whitespace
>  - whitespace
>  - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

src/java.management/share/classes/javax/management/ImmutableDescriptor.java line 141:

> 139:             bad = true;
> 140:         if (!bad) {
> 141:             hashCode = -1; // Force recalculation

Nit: Would it make sense to add same comment to the lines: 445, 452,473, 493?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25758#discussion_r2159391491

From sspitsyn at openjdk.org  Fri Jun 20 17:43:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 17:43:29 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

src/java.management/share/classes/javax/management/relation/RoleList.java line 265:

> 263:     @Override
> 264:     public boolean add(Object o) {
> 265:         checkTypeSafe(o);

Q: Is `null` allowed? The same question applies to the `addAll()` if these methods allow null to be present in the collection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2159436534

From kevinw at openjdk.org  Fri Jun 20 18:20:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 20 Jun 2025 18:20:28 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
Message-ID: <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>

On Fri, 20 Jun 2025 17:40:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
>> 
>> This feature should be removed, and these classes should never accept the wrong kind of Object.
>
> src/java.management/share/classes/javax/management/relation/RoleList.java line 265:
> 
>> 263:     @Override
>> 264:     public boolean add(Object o) {
>> 265:         checkTypeSafe(o);
> 
> Q: Is `null` allowed? The same question applies to the `addAll()` if these methods allow null to be present in the collection.

The intent here is not to change behaviour regarding nulls.
Nulls have been permitted, and should stay permitted.
Other object types (that don't cast to Role, in this file) should fail.

The Role related files are quite unusual to use, so expect they are mostly used only by the JDK.
MBean code might more commonly manipulate an AttributeList, and we can still permit nulls in case such code relies on nulls being accepted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2159481021

From coleenp at openjdk.org  Fri Jun 20 18:42:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 18:42:55 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v9]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <Y6xFLzHSv--UkshfoY575jwWa3F6Df6Ojx5432gryrU=.471c3506-d80b-4d55-a677-d8d89bfb8334@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  David's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/50c036f4..1c1924c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=07-08

  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Fri Jun 20 18:42:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 18:42:56 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <rQYh0fd0ROq22KTKS2Um1Si6M_ZSYlE_PPWDaGpeWHk=.8e0cc3ef-e9e3-4f0e-ac93-6b57d72b5c8a@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
 <rQYh0fd0ROq22KTKS2Um1Si6M_ZSYlE_PPWDaGpeWHk=.8e0cc3ef-e9e3-4f0e-ac93-6b57d72b5c8a@github.com>
Message-ID: <5m8EQOcI-LNXa8-gM_xxhwtg2vIW2sNnyJnJKuSRH18=.73adf555-921c-4ae3-b623-50de42252fce@github.com>

On Thu, 19 Jun 2025 00:07:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a basic gtest.
>
> src/hotspot/share/oops/instanceKlass.cpp line 2395:
> 
>> 2393: 
>> 2394: // Allocate the jmethodID cache.
>> 2395: static jmethodID* create_jmethod_id_cache(size_t size) {
> 
> Why isn't this used at line 2439 to create the (initial?) cache?

No reason. I should have done that.

> src/hotspot/share/oops/jmethodIDTable.cpp line 40:
> 
>> 38: static uint64_t _jmethodID_counter = 0;
>> 39: // Tracks the number of jmethodID entries in the _jmethod_id_table.
>> 40: // Incremented on insert, decremented on remove. Use to track if we need to resize the table.
> 
> Suggestion:
> 
> // Incremented on insert, decremented on remove. Used to track if we need to resize the table.

fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2159503221
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2159502540

From cjplummer at openjdk.org  Fri Jun 20 19:33:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 20 Jun 2025 19:33:29 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v2]
In-Reply-To: <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
Message-ID: <DG724DU9OBw81AooyU6fLDrTmn--evUG6FPA15YsJaI=.9da20c6c-0ee9-459b-9038-329b2130042a@github.com>

On Thu, 19 Jun 2025 11:17:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
>  - spelling
>  - Exception name
>  - whitespace
>  - whitespace
>  - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

I'm not much of a serialization expert, so just asking for some clarification here. I assume when de-serialized, the initial hashcode is always 0. Why it is 0 and not by default -1. Seems this would be an issue with any de-serialized type and all would need to explicitly set to -1 as you have done in this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-2992607168

From coleenp at openjdk.org  Fri Jun 20 19:44:27 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 19:44:27 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v4]
In-Reply-To: <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>
Message-ID: <__1QutaUqqg-7hN3eC1uYYnZQLU0GRg4gW9DLHDgas0=.0c915dc5-05af-4f66-8d62-cc3249f0ee8e@github.com>

On Fri, 20 Jun 2025 15:05:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This uses names for frame types for stackmaps in the verifier and redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tags (running more tests)

tiers 1-4 passed with changes suggested by @dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25870#issuecomment-2992624666

From matsaave at openjdk.org  Fri Jun 20 19:49:29 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 20 Jun 2025 19:49:29 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v4]
In-Reply-To: <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>
Message-ID: <0p-eoUP7uOmwzFwfUQseiJQGKisRaa4EQCHJXuVFvwA=.58c3a268-28a8-4c53-9281-bb54c24c7d9b@github.com>

On Fri, 20 Jun 2025 15:05:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This uses names for frame types for stackmaps in the verifier and redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tags (running more tests)

Updated change looks good!

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2947143580

From coleenp at openjdk.org  Fri Jun 20 20:41:21 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 20:41:21 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/1c1924c1..66eb4269

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Fri Jun 20 20:50:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 20:50:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <HIetYWCEiQ8p260POJgHXL0O_ILN-hiIOLSelcXeOs0=.7ffa32b8-8503-48ee-8386-64083808c9fc@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
 <HIetYWCEiQ8p260POJgHXL0O_ILN-hiIOLSelcXeOs0=.7ffa32b8-8503-48ee-8386-64083808c9fc@github.com>
Message-ID: <y-UVnZIx_PO2BKgBlcDexB6rYEUP2xMcuTbhsXO0-Mc=.993c4561-b0e6-4b85-a1ea-8211ea780e21@github.com>

On Thu, 19 Jun 2025 00:45:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This still seems racy though. What if the lookup succeeds but at the same time the class is to be unloaded?

Yes, It won't be at the same time, since lookup and remove_jmethod_ids hold the JmethodIdCreation_lock.  But this is a good question.  It could be still a race:


Method* Method::checked_resolve_jmethod_id(jmethodID mid) {
  if (mid == nullptr) return nullptr;
  Method* o = resolve_jmethod_id(mid);
  if (o == nullptr) {
    return nullptr;
  }
  // Method should otherwise be valid. Assert for testing.
  assert(is_valid_method(o), "should be valid jmethodid");
  // If the method's class holder object is unreferenced, but not yet marked as
  // unloaded, we need to return null here too because after a safepoint, its memory
  // will be reclaimed.
  return o->method_holder()->is_loader_alive() ? o : nullptr;
}


I think this should prevent this race but I'd have to think about it some more.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2992814813

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 coleenp at openjdk.org  Fri Jun 20 20:57:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 20:57:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
 <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>
Message-ID: <qyM4XTaWcOTpStpKVXekuFU3VseyFOA1icHNMbPHvK0=.531150c5-6f78-4f5a-a776-87c89cb49dcf@github.com>

On Thu, 19 Jun 2025 06:33:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a basic gtest.
>
> I feel apprehensive about this; the solution feels pretty complex and I am not fully convinced this is the simplest solution for this problem. 
> 
> How much space to we lose in real life? Side note: I see the payload of the jmethodID block in NMT is allocated with mtInternal, so we don't see it in NMT. We should add jmethodIDs as an own category to NMT.
> 
> A pragmatic alternative solution could be to do delete them, but delayed: keep the last N methodblocks undeleted. It is rare that JNI accesses jmethodIDs long after they have been deleted. Typically, the bad access happens close after class unloading, e.g. because of concurrency problems in customer code.
> 
> We could then make the parameter N configurable, and thus give customers and supporters a tool to check for these kind of errors.
> 
> (I briefly wondered whether we could just mmap these blocks, and uncommit/mprotect them on release, so that we stop paying the memory costs but don't release the address space; but the coarser page size allocation granularity would make this probably forbidding in terms of mem cost per class)

@tstuefe I think your method would still have a race and still allow a stale pointer crash, but just less likely, with more code to manage how to delete these pointers.

The memory leak for jmethodIDs has been observed in our testing, resulting in native OOMs.  We discussed a few things to solve this in the bugs, and this was the best idea we had at the time.  It is a big change though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2992826422

From sspitsyn at openjdk.org  Fri Jun 20 21:00:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 21:00:39 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
 <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
Message-ID: <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>

On Fri, 20 Jun 2025 18:18:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/relation/RoleList.java line 265:
>> 
>>> 263:     @Override
>>> 264:     public boolean add(Object o) {
>>> 265:         checkTypeSafe(o);
>> 
>> Q: Is `null` allowed? The same question applies to the `addAll()` if these methods allow null to be present in the collection.
>
> The intent here is not to change behaviour regarding nulls.
> Nulls have been permitted, and should stay permitted.
> Other object types (that don't cast to Role, in this file) should fail.
> 
> The Role related files are quite unusual to use, so expect they are mostly used only by the JDK.
> MBean code might more commonly manipulate an AttributeList, and we can still permit nulls in case such code relies on nulls being accepted.

My question was because there are checks for `null` in this class:

public void add(Role role)
        throws IllegalArgumentException {

        if (role == null) {
            throw new IllegalArgumentException("Invalid parameter");
        }
        checkTypeSafe(role);
        super.add(role);
    }

It is kind of confusing and not clear where `null` is allowed and where it is not.
Should it be more consistent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2159655977

From coleenp at openjdk.org  Fri Jun 20 21:19:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Jun 2025 21:19:28 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <4QtV9UGiRdP0LG6rIHH_4fwO2f5wm0evnHnut2nxvjM=.ecf61194-7201-4c7e-a496-3ddc821ea079@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
 <EQkGA5KulUvKT_Md8-bNN93M0Y1uT1MVlerRe-GxbW0=.9f2b4393-9d8d-41c2-9950-e0908e37af46@github.com>
 <4QtV9UGiRdP0LG6rIHH_4fwO2f5wm0evnHnut2nxvjM=.ecf61194-7201-4c7e-a496-3ddc821ea079@github.com>
Message-ID: <k8eDVwqr9Xh3t7IqzqeVjXEfNkAyqlBXRfRc-61Er-4=.25fb2312-c146-410f-85b6-5bd95741862b@github.com>

On Thu, 19 Jun 2025 10:02:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thank you for the backport! @shipilev indicated that the backport to 21 should wait a bit, could you clarify when should I file that (e.g. end of July, ...)?
>
>> @shipilev indicated that the backport to 21 should wait a bit, could you clarify when should I file that (e.g. end of July, ...)?
> 
> I would say for the fairly big change like this, we want to wait until JDK 25 GA (that would pass the all-tests-run). It would be too late for Oct 2025 release, though. So realistically, this would target January 2026 release. You can pull this patch to your downstream JDK 21 to see if there are any troubles ahead of this path, this will also soothe 21u maintainer concerns, I think.

So @shipilev, JDK 25 is in rampdown phase 1.  Rampdown phase 2 starts 7/17.  It's a big change for JDK 25.  My sense of the risk is that it's not high.  If it's checked in now, I think it'll get more testing than if it gets backported to a 25.01 release.  I'll discuss it with people here.  I think for JDK 21, we should wait for more testing to be run after 25 GA.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-2992962430

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

From dholmes at openjdk.org  Mon Jun 23 05:39:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jun 2025 05:39:35 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <y-UVnZIx_PO2BKgBlcDexB6rYEUP2xMcuTbhsXO0-Mc=.993c4561-b0e6-4b85-a1ea-8211ea780e21@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
 <HIetYWCEiQ8p260POJgHXL0O_ILN-hiIOLSelcXeOs0=.7ffa32b8-8503-48ee-8386-64083808c9fc@github.com>
 <y-UVnZIx_PO2BKgBlcDexB6rYEUP2xMcuTbhsXO0-Mc=.993c4561-b0e6-4b85-a1ea-8211ea780e21@github.com>
Message-ID: <ptf9Xx1n_SOp8W9RhEnEMZtQka9PrTWGlL6moAlGNMo=.e3fb4078-ea84-4e82-8708-fdc587dcea5b@github.com>

On Fri, 20 Jun 2025 20:47:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I think this should prevent this race but I'd have to think about it some more.

Aside from the fact the `checked` method is not used much, the problem is that if the caller does not have something keeping the class alive, then the resolution of the jMethodID can succeed and we will proceed with trying to call the method. In the meantime the fact the class is unreferenced could be noticed and the class then unloaded. Now that can only happen at safepoints, so it then depends on the details of the code that tries to invoke the method e.g. in jni.cpp

static void jni_invoke_static(JNIEnv *env, JavaValue* result, jobject receiver, JNICallType call_type, jmethodID method_id, JNI_ArgumentPusher *args, TRAPS) {
  methodHandle method(THREAD, Method::resolve_jmethod_id(method_id));

  // Create object to hold arguments for the JavaCall, and associate it with
  // the jni parser
  ResourceMark rm(THREAD);
  int number_of_parameters = method->size_of_parameters();
  JavaCallArguments java_args(number_of_parameters);

  assert(method->is_static(), "method should be static");

  // Fill out JavaCallArguments object
  args->push_arguments_on(&java_args);
  // Initialize result type
  result->set_type(args->return_type());

  // Invoke the method. Result is returned as oop.
  JavaCalls::call(result, method, &java_args, CHECK);

Can we hit safepoint checks anywhere on the path to the actual invocation of the method? If not, what is guaranteeing that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2994989682

From stuefe at openjdk.org  Mon Jun 23 06:14:31 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Jun 2025 06:14:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v7]
In-Reply-To: <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <LCDMHt8yqLId0rj8ywELMoItYzn4XJeG5wF01Q6t4co=.c9c35843-80f2-4e7f-b908-7aa71ab9f7a7@github.com>
 <ZJcVKM6Nv5M0_Lpr7572LXB9Z1drVmOmiDs-vGQ7wG0=.192058f8-1f4b-4e90-b910-132d077c9603@github.com>
Message-ID: <dvMaD3Dp_7MbBjuAMY310cE3Ot5pyiFSM7m5P1nXKgM=.301177a5-1faf-4751-a57e-b2ad8c0aa2ed@github.com>

On Thu, 19 Jun 2025 06:33:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a basic gtest.
>
> I feel apprehensive about this; the solution feels pretty complex and I am not fully convinced this is the simplest solution for this problem. 
> 
> How much space to we lose in real life? Side note: I see the payload of the jmethodID block in NMT is allocated with mtInternal, so we don't see it in NMT. We should add jmethodIDs as an own category to NMT.
> 
> A pragmatic alternative solution could be to do delete them, but delayed: keep the last N methodblocks undeleted. It is rare that JNI accesses jmethodIDs long after they have been deleted. Typically, the bad access happens close after class unloading, e.g. because of concurrency problems in customer code.
> 
> We could then make the parameter N configurable, and thus give customers and supporters a tool to check for these kind of errors.
> 
> (I briefly wondered whether we could just mmap these blocks, and uncommit/mprotect them on release, so that we stop paying the memory costs but don't release the address space; but the coarser page size allocation granularity would make this probably forbidding in terms of mem cost per class)

> @tstuefe I think your method would still have a race and still allow a stale pointer crash, but just less likely, with more code to manage how to delete these pointers.
> 
> The memory leak for jmethodIDs has been observed in our testing, resulting in native OOMs. We discussed a few things to solve this in the bugs, and this was the best idea we had at the time. It is a big change though.

Okay, fair enough. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2995060097

From dholmes at openjdk.org  Mon Jun 23 06:35:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jun 2025 06:35:31 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v4]
In-Reply-To: <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <yiV_4auwlXWkkh_9pHkiMtVAy9BylbzuRghLZsq7lkU=.afb10518-264f-4cf9-a41f-372c88bacdc6@github.com>
Message-ID: <RKE8IVsMUJHzjMQxBYX5MQxnwG9KFMuHyLc9EMw49gA=.363d4825-1770-4c0d-94f8-24a67219ee10@github.com>

On Fri, 20 Jun 2025 15:05:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This uses names for frame types for stackmaps in the verifier and redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tags (running more tests)

Thanks for applying this @coleenp !

I have a couple of suggested changes that to me make it more obvious what case(s) we are dealing with, but up to you whether to apply them or not. The more I look at this code the more it cries out to be restructured, to me.

Thanks

src/hotspot/share/classfile/stackMapTable.cpp line 384:

> 382:     _first = false;
> 383:     return frame;
> 384:   } else if (frame_type < SAME_FRAME_EXTENDED + 4) {

Suggestion:

  } else if (frame_type <= APPEND_FRAME_END) {

src/hotspot/share/classfile/stackMapTable.cpp line 387:

> 385:     // append_frame
> 386:     assert(frame_type >= APPEND_FRAME_START && frame_type <= APPEND_FRAME_END, "should be");
> 387:     int appends = frame_type - SAME_FRAME_EXTENDED;

Suggestion:

    int appends = frame_type - APPEND_FRAME_START + 1;

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 3328:

> 3326:         "no room for offset_delta");
> 3327:       stackmap_p += 2;
> 3328:       u1 len = frame_type - StackMapReader::SAME_FRAME_EXTENDED;

Suggestion:

      u1 len = frame_type - StackMapReader::APPEND_FRAME_START + 1;

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2948793293
PR Review Comment: https://git.openjdk.org/jdk/pull/25870#discussion_r2160802174
PR Review Comment: https://git.openjdk.org/jdk/pull/25870#discussion_r2160805107
PR Review Comment: https://git.openjdk.org/jdk/pull/25870#discussion_r2160809684

From jsjolen at openjdk.org  Mon Jun 23 07:08:37 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 23 Jun 2025 07:08:37 GMT
Subject: RFR: 8357220: Introduce a BSMAttributeEntry struct [v7]
In-Reply-To: <bdAaHV6lWPNJPAyfs_cbIBxonqZXNaDfcVmVaTwjdmg=.72e02c4f-6018-4b97-b1e4-4f19570bdb72@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
 <bdAaHV6lWPNJPAyfs_cbIBxonqZXNaDfcVmVaTwjdmg=.72e02c4f-6018-4b97-b1e4-4f19570bdb72@github.com>
Message-ID: <PAhJArr6EVhlRqjIdwWNOq-Fieio7Iu0_NtF7twi0Vc=.32f60bd5-d46f-4d5a-a4d6-ff814646037d@github.com>

On Thu, 19 Jun 2025 08:03:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
>> 
>> ```c++
>> struct BSMAE {
>>   u2 bootstrap_method_index;
>>   u2 argument_count;
>>   u2 arguments[argument_count];
>> }
>> 
>> 
>> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
>> 
>> Please consider!
>> 
>> Testing: Currently GHA, running tier1-tier3
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

Thank you all for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25298#issuecomment-2995192388

From jsjolen at openjdk.org  Mon Jun 23 07:08:37 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 23 Jun 2025 07:08:37 GMT
Subject: Integrated: 8357220: Introduce a BSMAttributeEntry struct
In-Reply-To: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
References: <4k7ezcDyFuiEKiYMour4OWsFhtwi6by6cuBFFozuc1c=.7a77f4b1-cd8d-4555-841e-f34612f0388f@github.com>
Message-ID: <warQ0SQjSAj9JcNPNXianjBnl3FM_xV61E08c7Qquk4=.4795d35d-d0bf-4674-8652-a494dd6aa04f@github.com>

On Mon, 19 May 2025 07:35:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
>  The constant pool currently has a lot of methods specific to extracting parts of the operands array. What this array actually is, is a sequence of bootstrap method attribute entries, where each entry has the following components:
> 
> ```c++
> struct BSMAE {
>   u2 bootstrap_method_index;
>   u2 argument_count;
>   u2 arguments[argument_count];
> }
> 
> 
> We can removes some of these operands array specific methods, and instead allows you to extract BSMAttributeEntrys which you can then use to extract its piece wise components. This makes for a nicer interface, and a bit easier to come into as a reader of the code, as it more closely mirrors the JVMS. 
> 
> Please consider!
> 
> Testing: Currently GHA, running tier1-tier3

This pull request has now been integrated.

Changeset: 3d35b408
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d35b408e1e69d7e3953af142c5bf606691fbeb8
Stats:     115 lines in 7 files changed: 42 ins; 31 del; 42 mod

8357220: Introduce a BSMAttributeEntry struct

Co-authored-by: John R Rose <jrose at openjdk.org>
Reviewed-by: sspitsyn, coleenp, matsaave

-------------

PR: https://git.openjdk.org/jdk/pull/25298

From henryjen at openjdk.org  Mon Jun 23 07:34:32 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Jun 2025 07:34:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
Message-ID: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>

On Wed, 18 Jun 2025 01:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
> 
>> 1: #
> 
> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
If that was intentionally left out, I don't see new reason to add them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2160914804

From iwalulya at openjdk.org  Mon Jun 23 07:40:33 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 23 Jun 2025 07:40:33 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
Message-ID: <l_021q2gZtUsDC4L53HMmK2uQ0o7Mqf-zANhJD8ezV0=.fe3a36de-b2b0-40cf-b51b-4758e72263b9@github.com>

On Wed, 18 Jun 2025 09:00:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - Merge branch 'master' into pgc-size-policy
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - merge
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363

Do we have other uses of `class AdaptiveSizePolicy` except for parallelGC?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-2995286022

From ayang at openjdk.org  Mon Jun 23 08:30:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:30:38 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <l_021q2gZtUsDC4L53HMmK2uQ0o7Mqf-zANhJD8ezV0=.fe3a36de-b2b0-40cf-b51b-4758e72263b9@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <l_021q2gZtUsDC4L53HMmK2uQ0o7Mqf-zANhJD8ezV0=.fe3a36de-b2b0-40cf-b51b-4758e72263b9@github.com>
Message-ID: <ccirFcIxHT8qELOWVeVYIu4E1FR2X0zDLn9DwPGl3yw=.5e32ad06-e2cd-4aa2-8338-c337ca887990@github.com>

On Mon, 23 Jun 2025 07:38:09 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Do we have other uses of class AdaptiveSizePolicy except for parallelGC?

No. A followup cleanup can be to merge this class into its sole subclass, used by Parallel.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-2995445820

From shade at openjdk.org  Mon Jun 23 08:32:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Jun 2025 08:32:34 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <4QtV9UGiRdP0LG6rIHH_4fwO2f5wm0evnHnut2nxvjM=.ecf61194-7201-4c7e-a496-3ddc821ea079@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
 <EQkGA5KulUvKT_Md8-bNN93M0Y1uT1MVlerRe-GxbW0=.9f2b4393-9d8d-41c2-9950-e0908e37af46@github.com>
 <4QtV9UGiRdP0LG6rIHH_4fwO2f5wm0evnHnut2nxvjM=.ecf61194-7201-4c7e-a496-3ddc821ea079@github.com>
Message-ID: <QvzcT0G6bVqHXj8tC6jRSSP0YwE3VTNFGygpf6v7KBk=.dd38d7c1-8c32-45cf-8b4e-4507013ce302@github.com>

On Thu, 19 Jun 2025 10:02:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thank you for the backport! @shipilev indicated that the backport to 21 should wait a bit, could you clarify when should I file that (e.g. end of July, ...)?
>
>> @shipilev indicated that the backport to 21 should wait a bit, could you clarify when should I file that (e.g. end of July, ...)?
> 
> I would say for the fairly big change like this, we want to wait until JDK 25 GA (that would pass the all-tests-run). It would be too late for Oct 2025 release, though. So realistically, this would target January 2026 release. You can pull this patch to your downstream JDK 21 to see if there are any troubles ahead of this path, this will also soothe 21u maintainer concerns, I think.

> So @shipilev, JDK 25 is in rampdown phase 1. Rampdown phase 2 starts 7/17. It's a big change for JDK 25. My sense of the risk is that it's not high. If it's checked in now, I think it'll get more testing than if it gets backported to a 25.01 release. I'll discuss it with people here. I think for JDK 21, we should wait for more testing to be run after 25 GA.

Yeah, I am on the fence for JDK 25, can take it both ways. If it is to land in JDK 25u anyway, there is some benefit for doing it in GA for more testing. At the same time, JDK 26 is already testing it, so there is no particular need to risk JDK 25 stability, and we can just capitalize on JDK 26 testing for JDK 25u backport.

For JDK 21u, it definitely needs to be released in JDK 25 first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-2995450240

From ayang at openjdk.org  Mon Jun 23 08:34:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:34:22 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v14]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang 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 pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - ... and 10 more: https://git.openjdk.org/jdk/compare/516197f5...41027bdf

-------------

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=13
  Stats: 4371 lines in 31 files changed: 520 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From kevinw at openjdk.org  Mon Jun 23 10:13:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 23 Jun 2025 10:13:34 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v2]
In-Reply-To: <DG724DU9OBw81AooyU6fLDrTmn--evUG6FPA15YsJaI=.9da20c6c-0ee9-459b-9038-329b2130042a@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
 <DG724DU9OBw81AooyU6fLDrTmn--evUG6FPA15YsJaI=.9da20c6c-0ee9-459b-9038-329b2130042a@github.com>
Message-ID: <jtK-icBxL9RMRGr0vKApJXSgR7hW9BRKj_kFiGrjlFw=.4fcb1531-f30b-468e-8c53-10e8e3334cce@github.com>

On Fri, 20 Jun 2025 19:30:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not much of a serialization expert, so just asking for some clarification here. I assume when de-serialized, the initial hashcode is always 0. Why it is 0 and not by default -1. Seems this would be an issue with any de-serialized type and all would need to explicitly set to -1 as you have done in this case.

As a transient field the hashCode int is not restored by serialization.  But why zero, and not -1 as per the field declaration?

The -1 is set by a constructor in ImmutableDescriptor.

ObjectInputStream:
"Reading an object is analogous to running the constructors of a new object. Memory is allocated for the object and initialized to zero (NULL). No-arg constructors are invoked for the non-serializable classes and then the fields of the serializable classes are restored from the stream starting with the serializable class closest to java.lang.object and finishing with the object's most specific class."

I think that is the explanation: it's all zero'd, and the constructor that would set the -1 doesn't get called.

I see another example (src/java.management/share/classes/javax/management/openmbean/ArrayType.java) where we implement a hashCode member as "private transient Integer  myHashCode = null; "  There we check if that is null, which causes re-calculating of the hashCode on demand after deserialization.  That gets default behaviour of recalculating, but uses a Java object.

This class used a primitive field, I didn't want to change much in this obscure old class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-2995805998

From coleenp at openjdk.org  Mon Jun 23 12:06:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 12:06:03 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v5]
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/classfile/stackMapTable.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/classfile/stackMapTable.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25870/files
  - new: https://git.openjdk.org/jdk/pull/25870/files/7d2e60c2..edec7b8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25870&range=03-04

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25870/head:pull/25870

PR: https://git.openjdk.org/jdk/pull/25870

From coleenp at openjdk.org  Mon Jun 23 12:06:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 12:06:03 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v5]
In-Reply-To: <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>
Message-ID: <R2bwpu3Wd0KPzjIlzMbN1ghf04GfpE61z9J7_pRpUys=.77108139-b069-4571-b8f9-ca1a6e40e150@github.com>

On Mon, 23 Jun 2025 12:02:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This uses names for frame types for stackmaps in the verifier and redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/classfile/stackMapTable.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/classfile/stackMapTable.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Yes, I like all of these changes.  One would have prevented me from a transient bug I had. @matias9927  and I chatted about restructuring this code in the future which seems like a good idea.  All in all, these tags and your suggestions are really helpful.

Also verified and am testing your suggested changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2949819071

From coleenp at openjdk.org  Mon Jun 23 12:19:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 12:19:32 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <pfYjl3ZpqaTm-qXaYFzfQCZEuAoxNt-OGPHcwxUd_dM=.e59e3b27-a08f-48b2-8162-50a28b4d9628@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

I'm not sure but I think in this instance, the native caller has the mirror for the class where it gets the jmethodID from, so can't unload the Method.


JNI_ENTRY(ResultType, \
          jni_CallStatic##Result##Method(JNIEnv *env, jclass cls, jmethodID methodID, ...)) \
\

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2996270175

From coleenp at openjdk.org  Mon Jun 23 12:46:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 12:46:33 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>
Message-ID: <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com>

On Fri, 20 Jun 2025 21:35:33 GMT, Leonid Mesnik <lmesnik 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 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");) {
> ...

getBytecodes propagates the exception from getResourceAsStream.  If I catch IOException (?), what should it do?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2161533545

From kevinw at openjdk.org  Mon Jun 23 14:40:27 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 23 Jun 2025 14:40:27 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
 <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
 <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>
Message-ID: <LWSmmcWfalhvkPLBhGLy9jSKTOpRJMCWY7bpm0Pr1Vw=.19a18ecc-18c0-4a6e-810e-2981d8c62f37@github.com>

On Fri, 20 Jun 2025 20:56:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The intent here is not to change behaviour regarding nulls.
>> Nulls have been permitted, and should stay permitted.
>> Other object types (that don't cast to Role, in this file) should fail.
>> 
>> The Role related files are quite unusual to use, so expect they are mostly used only by the JDK.
>> MBean code might more commonly manipulate an AttributeList, and we can still permit nulls in case such code relies on nulls being accepted.
>
> My question was because there are checks for `null` in this class:
> 
> public void add(Role role)
>         throws IllegalArgumentException {
> 
>         if (role == null) {
>             throw new IllegalArgumentException("Invalid parameter");
>         }
>         checkTypeSafe(role);
>         super.add(role);
>     }
> 
> It is kind of confusing and not clear where `null` is allowed and where it is not.
> Should it be more consistent?

Sorry, to be clearer:

javax/management/AttributeList does accept nulls being added, and should continue to do so because it might be a disruptive change.

RoleList and RoleUnresolvedList do not accept null Role/RoleUnresolved objects: they document that the add() method throws if given a null.

We don't have a need to change either behaviour about accepting nulls.
It should be clear when reading the api docs.  It might be unclear as I am grouping together somewhat unrelated classes here.   There is no reason for a user of AttributeList to expect it behaves the same way as a RoleList.

But we do want to stop accepting alien Objects!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2161794760

From jlu at openjdk.org  Mon Jun 23 14:45:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:45:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
 <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
Message-ID: <BVN8gdSxc54F_PWYYXyMoHt4FDCeFNtN_vMeMSxIGoI=.beedc45e-7447-4e77-9553-ad1420bc512e@github.com>

On Wed, 18 Jun 2025 18:48:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.
>
> Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

If this is committed, then the years will be synced and we won't have to change it back. This would be consistent with the way we receive l10n translations which sync the copyright years of localized files to the original. 

If we want to deviate from this then we could file a request asking them to not update copyright years and we could update them ourselves.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161805058

From duke at openjdk.org  Mon Jun 23 14:45:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 23 Jun 2025 14:45:44 GMT
Subject: RFR: 8359437: Make users and test suite not able to set LockingMode
 flag
Message-ID: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>

This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 

The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 

In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).

Lightweight locking is the default locking from now on.

Tested in tiers 1 - 7.

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into 8359437_locking_mode_obsoletion
 - Merge remote-tracking branch 'origin/master' into 8359437_locking_mode_obsoletion
 - 8359437: Addressed reviewers' comments
 - Merge remote-tracking branch 'origin/master' into 8359437_locking_mode_obsoletion
 - Merge remote-tracking branch 'origin/master' into 8359437_locking_mode_obsoletion
 - Merge branch 'master' into _remove_locking_mode_fix_tests
 - Update after pre-review
 - First try.

Changes: https://git.openjdk.org/jdk/pull/25847/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359437
  Stats: 1122 lines in 33 files changed: 40 ins; 992 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/25847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25847/head:pull/25847

PR: https://git.openjdk.org/jdk/pull/25847

From dholmes at openjdk.org  Mon Jun 23 14:45:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 23 Jun 2025 14:45:46 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <H7m8LZIIiWt_0DUuJA2INrgauGd-TnRwsv2T3ofrJ-U=.52faf027-2771-4a74-8319-79432027ad31@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

I've taken an initial pass through. Initially I misunderstood the strategy with heavy monitors - see comments below.

src/hotspot/share/runtime/arguments.cpp line 1839:

> 1837: #ifndef _LP64
> 1838:   if (LockingMode == LM_LEGACY) {
> 1839:     LockingMode = LM_LIGHTWEIGHT;

If we have prevented the locking mode from being set then surely we can never encounter this case?

src/hotspot/share/utilities/globalDefinitions.cpp line 59:

> 57: uint64_t OopEncodingHeapMax = 0;
> 58: 
> 59: int LockingMode = LM_LIGHTWEIGHT;

const ?

src/hotspot/share/utilities/globalDefinitions.hpp line 1012:

> 1010: };
> 1011: 
> 1012: extern int LockingMode;

const ?

test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 36:

> 34:  *     -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
> 35:  *     -Xint
> 36:  *     -XX:LockingMode=0

I was wondering why these LockingMode=0 test cases were not setting `VerifyHeavyMonitors` instead, but I'm assuming the intent now is that we will only test that mode when it is set externally by the user (or in our case a particular test task definition)?

I also realized we can only test heavy monitors in tests where we explicitly control the monitor creation places and hence can call the WB method to force inflation. That obviously reduces the test coverage for that mode quite significantly - but perhaps that will be handled if in the future we implicitly reenable forced inflation and do away with the WB usage.

test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java line 1:

> 1: /*

This seems to remove significant test coverage. can we not adapt the tests to not rely on logging warnings that will no longer be present?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2938076106
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2153873165
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2153924585
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2153924946
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2153884907
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2153911036

From coleenp at openjdk.org  Mon Jun 23 14:45:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 14:45:47 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <afknlhJzY1fsb-yWTuMfw3bWie1s-dwWRvhgoPegyUI=.b89b8965-1472-4569-9192-4bb65a460496@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

I have a request for some more deieting.

This looks great. Thank you!

test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 125:

> 123: public class TestRecursiveLocking {
> 124:     static final WhiteBox WB = WhiteBox.getWhiteBox();
> 125:     static final boolean flagHeavyMonitors = WB.getBooleanVMFlag("VerifyHeavyMonitors");

I think you should take out the VerifyHeavyMonitors cases.  @fbredber originally had that flag turn on a the reintroduced UseHeavyMonitors option but the UseHeavyMonitors option doesn't actually do that with this change.  I don't think this test will pass with -XX:+VerifyHeavyMonitors.
If we reintroduce UseHeavyMonitors, save this diff and fix this test then.  Right now it's not correct.

test/hotspot/jtreg/runtime/lockStack/TestLockStackCapacity.java line 42:

> 40: public class TestLockStackCapacity {
> 41:     static final WhiteBox WB = WhiteBox.getWhiteBox();
> 42:     static final boolean flagHeavyMonitors = WB.getBooleanVMFlag("VerifyHeavyMonitors");

I think this should also not have cases for VerifyHeavyMonitors. We can add back tests if we want UseHeavyMonitors.  As of now, removing the Legacy locking code will remove code that reaches the VerifyHeavyMonitors branches.

test/jtreg-ext/requires/VMProps.java line 424:

> 422:      * Note: Lightweight locking does not support RTM (for now).
> 423:      */
> 424:     protected String vmRTMCompiler() {

There's an issue to remove this function since it's now unused.

-------------

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2940262141
Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2949835857
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2155234150
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2155246651
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2155256340

From duke at openjdk.org  Mon Jun 23 14:45:47 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 23 Jun 2025 14:45:47 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <H7m8LZIIiWt_0DUuJA2INrgauGd-TnRwsv2T3ofrJ-U=.52faf027-2771-4a74-8319-79432027ad31@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <H7m8LZIIiWt_0DUuJA2INrgauGd-TnRwsv2T3ofrJ-U=.52faf027-2771-4a74-8319-79432027ad31@github.com>
Message-ID: <DFirdmmdb22q6TelkH75a1whmUaI4GMOQRt_2bpXLoY=.d97041df-04eb-47b0-9e42-d2b606f66f41@github.com>

On Wed, 18 Jun 2025 07:37:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> src/hotspot/share/runtime/arguments.cpp line 1839:
> 
>> 1837: #ifndef _LP64
>> 1838:   if (LockingMode == LM_LEGACY) {
>> 1839:     LockingMode = LM_LIGHTWEIGHT;
> 
> If we have prevented the locking mode from being set then surely we can never encounter this case?

Looks like yes, this whole check then can be removed. Addressed in the latest commit.

> src/hotspot/share/utilities/globalDefinitions.cpp line 59:
> 
>> 57: uint64_t OopEncodingHeapMax = 0;
>> 58: 
>> 59: int LockingMode = LM_LIGHTWEIGHT;
> 
> const ?

This can be done provided that one removes assignment on line 3763 in arguments.cpp. That assignment looks redundant as LockingMode is always LM_LIGHTWEIGHT from now on.

> src/hotspot/share/utilities/globalDefinitions.hpp line 1012:
> 
>> 1010: };
>> 1011: 
>> 1012: extern int LockingMode;
> 
> const ?

This can be done provided that one removes assignment on line 3763 in arguments.cpp. That assignment looks redundant as LockingMode is always LM_LIGHTWEIGHT from now on.

> test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 36:
> 
>> 34:  *     -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
>> 35:  *     -Xint
>> 36:  *     -XX:LockingMode=0
> 
> I was wondering why these LockingMode=0 test cases were not setting `VerifyHeavyMonitors` instead, but I'm assuming the intent now is that we will only test that mode when it is set externally by the user (or in our case a particular test task definition)?
> 
> I also realized we can only test heavy monitors in tests where we explicitly control the monitor creation places and hence can call the WB method to force inflation. That obviously reduces the test coverage for that mode quite significantly - but perhaps that will be handled if in the future we implicitly reenable forced inflation and do away with the WB usage.

My understanding is that VerifyHeavyMonitors requires LockingMode = 0, see line 1852 of arguments.cpp. So one has to set both at the same time, not one instead of another. Now locking mode is hardcoded to lightweight, and there is no way to use the incompatible `VerifyHeavyMonitors` option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161284370
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161120254
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161119703
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161284143

From duke at openjdk.org  Mon Jun 23 14:45:47 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 23 Jun 2025 14:45:47 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <afknlhJzY1fsb-yWTuMfw3bWie1s-dwWRvhgoPegyUI=.b89b8965-1472-4569-9192-4bb65a460496@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <afknlhJzY1fsb-yWTuMfw3bWie1s-dwWRvhgoPegyUI=.b89b8965-1472-4569-9192-4bb65a460496@github.com>
Message-ID: <OHWb5BT3tVAyveO56oI4fntpIvXScHaUwDIi1ki28zI=.5bda3b94-190b-4e87-bbee-a1c918f6cdbf@github.com>

On Wed, 18 Jun 2025 18:23:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 125:
> 
>> 123: public class TestRecursiveLocking {
>> 124:     static final WhiteBox WB = WhiteBox.getWhiteBox();
>> 125:     static final boolean flagHeavyMonitors = WB.getBooleanVMFlag("VerifyHeavyMonitors");
> 
> I think you should take out the VerifyHeavyMonitors cases.  @fbredber originally had that flag turn on a the reintroduced UseHeavyMonitors option but the UseHeavyMonitors option doesn't actually do that with this change.  I don't think this test will pass with -XX:+VerifyHeavyMonitors.
> If we reintroduce UseHeavyMonitors, save this diff and fix this test then.  Right now it's not correct.

Removed in the latest commit.

> test/hotspot/jtreg/runtime/lockStack/TestLockStackCapacity.java line 42:
> 
>> 40: public class TestLockStackCapacity {
>> 41:     static final WhiteBox WB = WhiteBox.getWhiteBox();
>> 42:     static final boolean flagHeavyMonitors = WB.getBooleanVMFlag("VerifyHeavyMonitors");
> 
> I think this should also not have cases for VerifyHeavyMonitors. We can add back tests if we want UseHeavyMonitors.  As of now, removing the Legacy locking code will remove code that reaches the VerifyHeavyMonitors branches.

Removed in the latest commit.

> test/jtreg-ext/requires/VMProps.java line 424:
> 
>> 422:      * Note: Lightweight locking does not support RTM (for now).
>> 423:      */
>> 424:     protected String vmRTMCompiler() {
> 
> There's an issue to remove this function since it's now unused.

Removed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161282585
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161282345
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161282101

From coleenp at openjdk.org  Mon Jun 23 14:45:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 14:45:47 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <H7m8LZIIiWt_0DUuJA2INrgauGd-TnRwsv2T3ofrJ-U=.52faf027-2771-4a74-8319-79432027ad31@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <H7m8LZIIiWt_0DUuJA2INrgauGd-TnRwsv2T3ofrJ-U=.52faf027-2771-4a74-8319-79432027ad31@github.com>
Message-ID: <fwtRVMpvE0tgZviZad5PZvgNpCi1hqBlG6xIfrijQEg=.4a2015ce-5acf-4add-9020-8424e7ebb1d0@github.com>

On Wed, 18 Jun 2025 07:52:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> test/hotspot/jtreg/runtime/vthread/JNIMonitor/JNIMonitor.java line 1:
> 
>> 1: /*
> 
> This seems to remove significant test coverage. can we not adapt the tests to not rely on logging warnings that will no longer be present?

The premise of this test is now invalid.  We could write a fresh new test if we'd like to see what happens with UseHeavyMonitors, and/or retrieve this from git history.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2155250065

From jlu at openjdk.org  Mon Jun 23 14:57:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:57:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>

On Wed, 18 Jun 2025 15:52:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
> 
>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
> 
> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161832785

From jlu at openjdk.org  Mon Jun 23 15:00:37 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 15:00:37 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <M5xHiXsy_RXNKRklp3u-Rc0JJiVmUyKDAdZgTmURWbo=.3c8874b7-ffda-4ffe-910f-381607b78e29@github.com>

On Wed, 18 Jun 2025 15:59:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:
> 
>> 227: doclet.search_in_documentation=In Dokumentation suchen
>> 228: doclet.search_reset=Zur?cksetzen
>> 229: doclet.Member=Member
> 
> Is `Member` translated? Should it be _?Mitglied?_?

Good catch. Usually, we file these issues with the translation team and make the appropriate updates in the second L10n drop. I think this one is fine to be updated now as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161839290

From lmesnik at openjdk.org  Mon Jun 23 15:51:31 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 23 Jun 2025 15:51:31 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: <D63o72gC23pD8MstyAjPkhKQhLIoYlAe7Q1iILrPTsE=.5f6d3cb6-9f90-419c-bae6-592a5d480415@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).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2950620500

From alanb at openjdk.org  Mon Jun 23 15:51:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Jun 2025 15:51:34 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <WgeME7_MyAgPVG4VpAwbHDb5XiBy4xmeJk1W7OgQItE=.ed6a57b6-b277-4cef-8f4f-e0d5d0768c65@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

test/jdk/java/lang/Thread/virtual/Parking.java line 388:

> 386:     @ParameterizedTest
> 387:     @ValueSource(booleans = { true, false })
> 388:     @DisabledIf("LockingMode#isLegacy")

Would you mind checking if the import DisabledIf can be removed from these tests? I think we only used it to conditionally run when not legacy mode.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2161946231

From lmesnik at openjdk.org  Mon Jun 23 15:51:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 23 Jun 2025 15:51:32 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>
 <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com>
Message-ID: <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com>

On Mon, 23 Jun 2025 12:43:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> 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");) {
>> ...
>
> getBytecodes propagates the exception from getResourceAsStream.  If I catch IOException (?), what should it do?

I didn't thought about this, but I think that's ok. I just propose to closed stream, not changing the exception handling.  The 

try(InputStream is = loader.getResourceAsStream(name + ".class");) {
    InputStream is = loader.getResourceAsStream(name + ".class");
    byte[] buf = is.readAllBytes();
    System.out.println("sizeof(" + name + ".class) == " + buf.length);
    return buf;
}

has completely the same workflow, just closing stream so we don't have any resource leak.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2161944047

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>

On Wed, 18 Jun 2025 14:48:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
> 
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>> 462: SliderDemo.minorticks=Feinteilungen
> 
> The following description uses different words now:
> 
> Feinteilungen -> Teilstrichen
> Teilungen -> Teilstrichen

Just to clarify, does this mean

SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
SliderDemo.minorticks=Teilstrichen

is correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162030543

From achung at openjdk.org  Mon Jun 23 16:38:29 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
Message-ID: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>

On Wed, 18 Jun 2025 20:37:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
>> 
>>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>>> 459: SliderDemo.majorticks=Grobteilungen
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 
>> Should the translation of `SliderDemo.majorticks` also be updated?
>
> I agree. I'd expect consistency here.

What would be the correct translation of majorticks here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162027420

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
Message-ID: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>

On Mon, 23 Jun 2025 07:31:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
>> 
>>> 1: #
>> 
>> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.
>
> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
> If that was intentionally left out, I don't see new reason to add them.

This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162024606

From achung at openjdk.org  Mon Jun 23 16:44:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:44:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  update to german translations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/66c34e7d..90bfd7bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From lmesnik at openjdk.org  Mon Jun 23 16:44:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 23 Jun 2025 16:44:29 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
Message-ID: <7HKgdR0w0qzSNE7CsPfobLYodrs8NO8O4oliOPgrEGc=.2f0b7216-138d-4363-a748-8e78a88af023@github.com>

On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
>> 
>> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
>> 
>> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   startLocalDebugee renamed to startDebugee

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 50:

> 48:  * @see nsk.share.jdwp.Debugee
> 49:  */
> 50: public class DebugeeProcess {

Are there any reason to make it non-abstract.. Even DebugeeProcess doesn't have abstract methods, only jid/jdwp subclasses might be used.Might be left it abstract?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25887#pullrequestreview-2950764480
PR Review Comment: https://git.openjdk.org/jdk/pull/25887#discussion_r2162039309

From naoto at openjdk.org  Mon Jun 23 16:44:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jun 2025 16:44:24 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
 <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
Message-ID: <i1GseMJyfCL5uo-smr3SLsDUVkvWzdQheIzvVr5PpKY=.1281d6d5-c07e-47cc-bacc-8ea1161a3df9@github.com>

On Mon, 23 Jun 2025 16:32:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
>> If that was intentionally left out, I don't see new reason to add them.
>
> This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

Thanks. I guess this was simply an overlook in the first place, as the process was manual back then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162038459

From lmesnik at openjdk.org  Mon Jun 23 17:09:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 23 Jun 2025 17:09:32 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <pllFKwg5aSsCkm1mUWTRKPc9c32k8EQdou4vVuasujo=.7384cd93-4b30-477a-93df-3701c956529c@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Marked as reviewed by lmesnik (Reviewer).

Sorry, I mistakenly approved the fix instead fo request changes. Please find my change requests in previous comments.

test/hotspot/jtreg/gtest/LockStackGtests.java line 26:

> 24: 
> 25: /* @test
> 26:  * @summary Run LockStack gtests with LockingMode=2

All gtests are executed with default vm flags in GTestWrapper.java so this while test should be just removed.

test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 37:

> 35:  * @bug 8318757
> 36:  * @summary Test concurrent monitor deflation by MonitorDeflationThread and thread dumping
> 37:  * @library /test/lib /

The '/' shouldn't be required for whitebox. Could you please remove it.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2950786910
Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2950827379
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2162077784
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2162055605

From cjplummer at openjdk.org  Mon Jun 23 17:18:30 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 23 Jun 2025 17:18:30 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <7HKgdR0w0qzSNE7CsPfobLYodrs8NO8O4oliOPgrEGc=.2f0b7216-138d-4363-a748-8e78a88af023@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
 <7HKgdR0w0qzSNE7CsPfobLYodrs8NO8O4oliOPgrEGc=.2f0b7216-138d-4363-a748-8e78a88af023@github.com>
Message-ID: <L232aowEugYz5O71Mw9ZWPFwIXeMGFpBBOJBjO4t07g=.879ead09-9011-44c5-a59a-ec3aae15bd28@github.com>

On Mon, 23 Jun 2025 16:41:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   startLocalDebugee renamed to startDebugee
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 50:
> 
>> 48:  * @see nsk.share.jdwp.Debugee
>> 49:  */
>> 50: public class DebugeeProcess {
> 
> Are there any reason to make it non-abstract.. Even DebugeeProcess doesn't have abstract methods, only jid/jdwp subclasses might be used.Might be left it abstract?

Currently it is only used via subclasses, but that doesn't necessarily mean it couldn't be used directly. Is there a reason you want to disallow that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25887#discussion_r2162093947

From duke at openjdk.org  Mon Jun 23 17:41:29 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 23 Jun 2025 17:41:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
Message-ID: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>

On Mon, 23 Jun 2025 16:34:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I agree. I'd expect consistency here.
>
> What would be the correct translation of majorticks here?

If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162131034

From aivanov at openjdk.org  Mon Jun 23 18:45:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 18:45:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
Message-ID: <9FQIYMoH-HEi7ktEzRGxRsoWXGPsDyWPWk3Ds0Edjy0=.5dcab616-2713-441b-b363-350ea62505e3@github.com>

On Mon, 23 Jun 2025 14:55:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
>> 
>>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
>> 
>> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.
>
> I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

I see the entries for


jar.signed.=jar signed.
jar.verified.=jar verified.

don't have the word *?file?*, whereas `?via.jarfile.and.jarinputstream` has it: ?This JAR *file*??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162318454

From aivanov at openjdk.org  Mon Jun 23 19:07:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:07:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
Message-ID: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>

On Mon, 23 Jun 2025 17:38:58 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> What would be the correct translation of majorticks here?
>
> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162350461

From aivanov at openjdk.org  Mon Jun 23 19:36:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
Message-ID: <O9Co_nchUBZcx7IsEWV3BulBeBx49f1DCSSfMncRP9Y=.01ec06db-951c-4466-b07e-4f49e34c41ad@github.com>

On Mon, 23 Jun 2025 16:36:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
>> 
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>>> 462: SliderDemo.minorticks=Feinteilungen
>> 
>> The following description uses different words now:
>> 
>> Feinteilungen -> Teilstrichen
>> Teilungen -> Teilstrichen
>
> Just to clarify, does this mean
> 
> SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
> SliderDemo.minorticks=Teilstrichen
> 
> is correct?

Hm? I don't know. You should clarify with the translation team. They've changed the translation for the major ticks from *Grobteilungen* to *Hauptteilstriche*. Yet minor ticks remain *Feinteilungen*, which doesn't look right because the main word is different. (*Teilung* doesn't seem to be the right word, at least dictionaries translate it as ?division?.)

*Teilstrich* means *scale line*, the marks on a ruler, so it fits.

Microsoft documentation for [MinorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.minortickmark?view=openxml-3.0.1) uses *Kleinere Teilstriche*, yet I don't understand why there's ?-e? ending (plural?).


SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels

This one looks particularly incorrect; ?einrasten? is a verb with a separable prefix that means ?to lock?, and I can't find a usage as if it's a noun.

The English phrase is ?Minor Ticks, Snap-to-ticks and Labels?, and I don't know how to correctly translate it to German.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162394521

From aivanov at openjdk.org  Mon Jun 23 19:36:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
Message-ID: <Cnn1pTxh334i_8vCnBa3c3FWvblGyzCjASOEGJQTsw8=.eb5e76f7-e83b-416c-9fe6-361d772780af@github.com>

On Thu, 19 Jun 2025 17:39:38 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
>> 
>>> 181: size.bit.alg=%1$d-Bit-%2$s
>>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
>> 
>> It feels as if there's something missing after _?einem?_.
>
> seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162395125

From coleenp at openjdk.org  Mon Jun 23 20:44:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 20:44:19 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v3]
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: <shfzjrQHP0fYYWpDHbzrhdmNv6i84XFwSFe6cKedFG8=.6b6a3a9d-f4ce-4de4-8d45-d952b552f4ae@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:

  Use try-with-resources

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/6bc1ca59..ed342127

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 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  Mon Jun 23 20:44:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 20:44:19 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>
 <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com>
 <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com>
Message-ID: <oPFFEqmtMvHSWRFKawRSj-8-xJDQhRdarCYwQAd3m3I=.7b2c8a28-c01d-4130-a059-f5428029164c@github.com>

On Mon, 23 Jun 2025 15:47:40 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> getBytecodes propagates the exception from getResourceAsStream.  If I catch IOException (?), what should it do?
>
> I didn't thought about this, but I think that's ok. I just propose to closed stream, not changing the exception handling.  The 
> 
> try(InputStream is = loader.getResourceAsStream(name + ".class");) {
>     InputStream is = loader.getResourceAsStream(name + ".class");
>     byte[] buf = is.readAllBytes();
>     System.out.println("sizeof(" + name + ".class) == " + buf.length);
>     return buf;
> }
> 
> has completely the same workflow, just closing stream so we don't have any resource leak.

Oh so this try is a try-with-resources and it'll close the stream?  It compiles without a catch clause.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162492123

From lmesnik at openjdk.org  Mon Jun 23 20:47:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 23 Jun 2025 20:47:28 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <oPFFEqmtMvHSWRFKawRSj-8-xJDQhRdarCYwQAd3m3I=.7b2c8a28-c01d-4130-a059-f5428029164c@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>
 <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com>
 <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com>
 <oPFFEqmtMvHSWRFKawRSj-8-xJDQhRdarCYwQAd3m3I=.7b2c8a28-c01d-4130-a059-f5428029164c@github.com>
Message-ID: <Sq0jai530f0XABScksiGJFSQLflRrnh2Qw2gVHBO3H8=.624cbc6f-95be-4f7f-a154-52e62cd4eaff@github.com>

On Mon, 23 Jun 2025 20:39:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I didn't thought about this, but I think that's ok. I just propose to closed stream, not changing the exception handling.  The 
>> 
>> try(InputStream is = loader.getResourceAsStream(name + ".class");) {
>>     InputStream is = loader.getResourceAsStream(name + ".class");
>>     byte[] buf = is.readAllBytes();
>>     System.out.println("sizeof(" + name + ".class) == " + buf.length);
>>     return buf;
>> }
>> 
>> has completely the same workflow, just closing stream so we don't have any resource leak.
>
> Oh so this try is a try-with-resources and it'll close the stream?  It compiles without a catch clause.

yes, only change is that stream is closed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162502439

From coleenp at openjdk.org  Mon Jun 23 20:57:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 23 Jun 2025 20:57:31 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <Sq0jai530f0XABScksiGJFSQLflRrnh2Qw2gVHBO3H8=.624cbc6f-95be-4f7f-a154-52e62cd4eaff@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <2i2Wc14_E7FCSPV8wxNrY-hvgl4VvQLzVV914QaGLmk=.16d4117b-328b-4dff-b4ba-b6309a8b619e@github.com>
 <90p2GWVgrs9a2Ja3QT-03Egiie2p2ay7W3dOD7lMijk=.2fa3991e-a5b7-40c4-a2da-914223b6af71@github.com>
 <44U0J9WMv5tgSGYYJwEYSgPKpBc1kn_qEuhwYdU1NNw=.7bc6f3a3-04e4-49cb-891d-550271d52566@github.com>
 <oPFFEqmtMvHSWRFKawRSj-8-xJDQhRdarCYwQAd3m3I=.7b2c8a28-c01d-4130-a059-f5428029164c@github.com>
 <Sq0jai530f0XABScksiGJFSQLflRrnh2Qw2gVHBO3H8=.624cbc6f-95be-4f7f-a154-52e62cd4eaff@github.com>
Message-ID: <nW58X23tUt-AAaUu6S-U4v6FcXuvxkY0v9CU2EZ_0xE=.ead2cba8-ddb2-4270-9c26-49bd42618924@github.com>

On Mon, 23 Jun 2025 20:45:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Oh so this try is a try-with-resources and it'll close the stream?  It compiles without a catch clause.
>
> yes, only change is that stream is closed.

That's really cool.  Thanks for the suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162515881

From amenkov at openjdk.org  Mon Jun 23 21:20:31 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 23 Jun 2025 21:20:31 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: <AKAlwoqY12rOJx2b6f6HHTHgsuPjDQ-88kFqjhFWujM=.afb244a8-3541-44e3-97c2-2f593ef28e19@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.

test/lib/RedefineClassHelper.java line 87:

> 85:         }
> 86:         return 0;
> 87:     }

I understand, that this is copy of the old code, but this method does not look good.
- it would be better to return -1 if the string not found (0 is valid offset)
- calculation of the buf's upper bound is incorrect when offset > 0
I'd suggest to update it to something like (not tested, also need to update callers to compare with -1)


private static int getStringIndex(String needle, byte[] buf, int offset) {
    byte[] needleArray = needle.getBytes(StandardCharsets.US_ASCII);
    for (int i = offset; i < buf.length - needleArray.length; i++) 
        if (Arrays.equals(buf, offset, offset + needleArray.length,
                          needleArray, 0, needleArray.length)) {
            return offset;
        }
    }
    return -1;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2162549862

From lmesnik at openjdk.org  Mon Jun 23 21:59:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 23 Jun 2025 21:59:29 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v3]
In-Reply-To: <shfzjrQHP0fYYWpDHbzrhdmNv6i84XFwSFe6cKedFG8=.6b6a3a9d-f4ce-4de4-8d45-d952b552f4ae@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <shfzjrQHP0fYYWpDHbzrhdmNv6i84XFwSFe6cKedFG8=.6b6a3a9d-f4ce-4de4-8d45-d952b552f4ae@github.com>
Message-ID: <0tYBhgIF7gWzR1G84utYNsG6iWE69rUc099IxNsXqcU=.dc36e9e0-e3d8-4507-8119-7308d1c02cf9@github.com>

On Mon, 23 Jun 2025 20:44:19 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:
> 
>   Use try-with-resources

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2951635049

From dcubed at openjdk.org  Tue Jun 24 00:19:29 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 24 Jun 2025 00:19:29 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <f6QkeHFO1amypmpJmqblz9WBnO-eFP_kKIvQfBDBmKA=.d5459c10-41cb-4d48-87a6-14e57bb8dde0@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Thumbs up. Reviewed the changes between v02 and v11
and the changed look good.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2951838637

From dcubed at openjdk.org  Tue Jun 24 00:29:29 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 24 Jun 2025 00:29:29 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <hjXT8bTyWChRW4S6QJTOLaD1KPuShjyTuf16FSbLcFY=.5f369fba-235f-4af7-b54f-7b3cc84f3b90@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

> > I think this should prevent this race but I'd have to think about it some more.
> 
> Aside from the fact the `checked` method is not used much, the problem is
> that if the caller does not have something keeping the class alive, then the
> esolution of the jMethodID can succeed and we will proceed with trying to
> call the method. In the meantime the fact the class is unreferenced could be
> noticed and the class then unloaded. Now that can only happen at safepoints,
> so it then depends on the details of the code that tries to invoke the method
>  e.g. in jni.cpp

Consider this code from above:
> static void jni_invoke_static(JNIEnv *env, JavaValue* result, jobject receiver, JNICallType call_type, jmethodID method_id, JNI_ArgumentPusher *args, TRAPS) {
>   methodHandle method(THREAD, Method::resolve_jmethod_id(method_id));

Once `Method::resolve_jmethod_id(method_id)` returns to the caller, how can
the class be unreferenced?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2998367651

From dholmes at openjdk.org  Tue Jun 24 02:38:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 02:38:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <pfYjl3ZpqaTm-qXaYFzfQCZEuAoxNt-OGPHcwxUd_dM=.e59e3b27-a08f-48b2-8162-50a28b4d9628@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <pfYjl3ZpqaTm-qXaYFzfQCZEuAoxNt-OGPHcwxUd_dM=.e59e3b27-a08f-48b2-8162-50a28b4d9628@github.com>
Message-ID: <xLVmjg1RjqCXLY0c4xFtg9NADyUakjs6pmuDywVrjhM=.50072f65-4ee4-46a4-b59a-99e3254e4d3b@github.com>

On Mon, 23 Jun 2025 12:17:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I'm not sure but I think in this instance, the native caller has the mirror for the class where it gets the jmethodID from, so can't unload the Method.
> 
> ```
> JNI_ENTRY(ResultType, \
>           jni_CallStatic##Result##Method(JNIEnv *env, jclass cls, jmethodID methodID, ...)) \
> \
> ```

@coleenp Take a look a the complete code:

JNI_ENTRY(ResultType, \
          jni_CallStatic##Result##Method(JNIEnv *env, jclass cls, jmethodID methodID, ...)) \
\
  EntryProbe; \
  ResultType ret{}; \
  DT_RETURN_MARK_FOR(Result, CallStatic##Result##Method, ResultType, \
                     (const ResultType&)ret);\
\
  va_list args; \
  va_start(args, methodID); \
  JavaValue jvalue(Tag); \
  JNI_ArgumentPusherVaArg ap(methodID, args); \
  jni_invoke_static(env, &jvalue, nullptr, JNI_STATIC, methodID, &ap, CHECK_(ResultType{})); \
  va_end(args); \
  ret = jvalue.get_##ResultType(); \
  return ret;\
JNI_END

the `cls` parameter is never actually used. So while it is supposed to refer to the class you have the static method jMethodID for, there is no requirement that it actually does, and could even be null.

> Once Method::resolve_jmethod_id(method_id) returns to the caller, how can the class be unreferenced?

@dcubed-ojdk  because the caller does not hold a reference to it initially, and resolving the jMethodID does not create a new reference to it. So once we have resolved, at the next safepoint the class could be seen as "not alive" and at the safepoint after that it can be unloaded. Hence we are relying on there being no safepoint checks in the upcall code, after the resolution,  to ensure this can't happen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2998571489

From dholmes at openjdk.org  Tue Jun 24 03:01:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 03:01:31 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <DFirdmmdb22q6TelkH75a1whmUaI4GMOQRt_2bpXLoY=.d97041df-04eb-47b0-9e42-d2b606f66f41@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <H7m8LZIIiWt_0DUuJA2INrgauGd-TnRwsv2T3ofrJ-U=.52faf027-2771-4a74-8319-79432027ad31@github.com>
 <DFirdmmdb22q6TelkH75a1whmUaI4GMOQRt_2bpXLoY=.d97041df-04eb-47b0-9e42-d2b606f66f41@github.com>
Message-ID: <YChWe2daepXDWyzMowM_o6ThXdXBLMDc6v_wV8poSKE=.43b5b1fc-14a3-4878-bebd-ebb6bbd6e91e@github.com>

On Mon, 23 Jun 2025 10:39:59 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 36:
>> 
>>> 34:  *     -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
>>> 35:  *     -Xint
>>> 36:  *     -XX:LockingMode=0
>> 
>> I was wondering why these LockingMode=0 test cases were not setting `VerifyHeavyMonitors` instead, but I'm assuming the intent now is that we will only test that mode when it is set externally by the user (or in our case a particular test task definition)?
>> 
>> I also realized we can only test heavy monitors in tests where we explicitly control the monitor creation places and hence can call the WB method to force inflation. That obviously reduces the test coverage for that mode quite significantly - but perhaps that will be handled if in the future we implicitly reenable forced inflation and do away with the WB usage.
>
> My understanding is that VerifyHeavyMonitors requires LockingMode = 0, see line 1852 of arguments.cpp. So one has to set both at the same time, not one instead of another. Now locking mode is hardcoded to lightweight, and there is no way to use the incompatible `VerifyHeavyMonitors` option.

My understanding was that `VerifyHeavyMonitors` was to be used as a replacement for `LockingMode=0` aka `UseHeavyMonitors`. But as Coleen has requested all `VerifyHeavyMonitors` testing be removed this is now a moot point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2162866307

From dholmes at openjdk.org  Tue Jun 24 03:12:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 03:12:32 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <8zcivFIhzh6QymXS119iTVwdzyufdXBaeOR4_dEjlig=.b1683573-13cb-4b40-baf3-8b609680e86f@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Changes are looking okay to me, but we have an issue with bug management that needs to be resolved - and probably need a new bug and PR.

test/jtreg-ext/requires/VMProps.java line 424:

> 422:      * Note: Lightweight locking does not support RTM (for now).
> 423:      */
> 424:     protected String vmRTMCompiler() {

[JDK-8358542](https://bugs.openjdk.org/browse/JDK-8358542) exists to remove this so you would need to add that bug id to this PR. However, it seems the bug management for this has gotten completely messed up so you may need to scrap this PR and file a new bug and PR for this part.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2952042310
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2162873188

From cstein at openjdk.org  Tue Jun 24 05:15:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:15:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
 <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
Message-ID: <bNn_SZAJQvbgRD39f2sJDCLItuz4Q-fJOjCQzc0URAo=.825ec4ad-31a1-4882-93ee-97f0eff02597@github.com>

On Mon, 23 Jun 2025 19:04:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").
>
> Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

Ja, "Hauptteilstrich" and "Hauptteilstriche" (pl) are correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162975420

From cstein at openjdk.org  Tue Jun 24 05:22:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:22:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <ws3HlD1kGmF5lUjtCE7SxWmnc4GEkdFi6FWo_Hnm7Tc=.c3dc65c9-7681-4145-afc2-a3af84857e78@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

For consistency with the "Hilfsteilstrich" (singular) and "Hilfsteilstriche" (plural) used below in `SliderDemo.minorticksdescription` and `SliderDemo.disableddescription`, I'd suggest to use:
Suggestion:

SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
SliderDemo.minorticks=Hilfsteilstriche


As "Labels" is not a German word.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162982972

From cstein at openjdk.org  Tue Jun 24 05:34:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:34:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <8Orj0J7-iUsSjTQEc7t-pSShM2wHGmfReMStzGByHGY=.41967017-0e70-4e2a-9133-f84fd263ff51@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 178:

> 176: javac.opt.Xlint.desc.restricted=Warnt vor der Verwendung eingeschr?nkter Methoden.
> 177: 
> 178: javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "Identit?t", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "Identit?t" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "Synchronisierung" zu verwenden.

"Identit?t" and "Synchronisierung" are literals that must not be translated.

The English base entry reads:


javac.opt.Xlint.desc.synchronization=\
    Warn about synchronization attempts on instances of value-based classes.\n\
\                         This key is a deprecated alias for ''identity'', which has the same uses and\n\
\                         effects. Users are encouraged to use the ''identity'' category for all future\n\
\                         and existing uses of ''synchronization''.


And `javac --help-lint` contains:


    strictfp             Warn about unnecessary use of the strictfp modifier.
    synchronization      Warn about synchronization attempts on instances of value-based classes.
    text-blocks          Warn about inconsistent white space characters in text block indentation.
    
    
    
Suggestion:

javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "identity", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "identity" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "synchronization" zu verwenden.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162995954

From cstein at openjdk.org  Tue Jun 24 05:44:30 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:44:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <AQix03HSJOPQl9dpzNexQJ-oAj3KLVWEt4zDGOxjmZM=.1efb1178-489f-478e-9534-f9b32e5b92de@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties line 103:

> 101: 
> 102: # 0: string
> 103: launcher.err.cant.find.main.method=main(String[])- oder main()-Methode nicht gefunden in Klasse: {0}

Suggestion:

launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2163006433

From sspitsyn at openjdk.org  Tue Jun 24 06:36:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 06:36:18 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
Message-ID: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>

The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. The fix is to wait for the first `THREAD_START` event at the `VM_INIT` event.

The update includes some other changes and minor refactoring:
 - the file `libMAAThreadStart.c` has been renamed to `libMAAThreadStart.cpp`
 - the test library `jvmti_common.hpp` is used where it is possible
 - static variable `printdump` has been removed
 - the static block with `loadLibrary` has been removed from the `MAAThreadStart.java`
 
 Testing:
  - ran the modified test locally
  - TBD: submit mach5 tiers 1-5

-------------

Commit messages:
 - 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart failed with Didn't get ThreadStart events in VM early start phase!

Changes: https://git.openjdk.org/jdk/pull/25948/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25948&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8225354
  Stats: 331 lines in 4 files changed: 141 ins; 189 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25948/head:pull/25948

PR: https://git.openjdk.org/jdk/pull/25948

From sspitsyn at openjdk.org  Tue Jun 24 06:54:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 06:54:19 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v2]
In-Reply-To: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
Message-ID: <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>

> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. The fix is to wait for the first `THREAD_START` event at the `VM_INIT` event.
> 
> The update includes some other changes and minor refactoring:
>  - the file `libMAAThreadStart.c` has been renamed to `libMAAThreadStart.cpp`
>  - the test library `jvmti_common.hpp` is used where it is possible
>  - static variable `printdump` has been removed
>  - the static block with `loadLibrary` has been removed from the `MAAThreadStart.java`
>  
>  Testing:
>   - ran the modified test locally
>   - TBD: submit mach5 tiers 1-5

Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:

 - corrected the Copyright line
 - small corrections and indentation fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25948/files
  - new: https://git.openjdk.org/jdk/pull/25948/files/360d911f..2d7840f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25948&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25948&range=00-01

  Stats: 66 lines in 1 file changed: 2 ins; 0 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/25948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25948/head:pull/25948

PR: https://git.openjdk.org/jdk/pull/25948

From dholmes at openjdk.org  Tue Jun 24 09:18:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 09:18:16 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v2]
In-Reply-To: <2evgySdW1pYxc1xd3rTGwfq0boMISr07cgPlzkFWTwo=.5d91ad21-c829-4080-ba57-20a92ab82bbf@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <2evgySdW1pYxc1xd3rTGwfq0boMISr07cgPlzkFWTwo=.5d91ad21-c829-4080-ba57-20a92ab82bbf@github.com>
Message-ID: <K13gNeQwfKA981EEa3a2PqvCmgGWFIDpe9CwWwhCWI0=.786037b5-5fa8-428f-928a-34abf40f33e7@github.com>

On Tue, 24 Jun 2025 09:14:42 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8359437: Addressed reviewers' comments
>  - 8359437: Addressed reviewers' comments

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 80:

> 78:             monitors[index] = new Object();
> 79:             synchronized (monitors[index]) {
> 80:                 WB.forceInflateMonitorLockedObject(monitors[index]);

This is now the only use of the new WB method and we can replace this with a simple:

monitors[index].wait(1);

as the `wait` forces inflation. Then we can deleted the new WB stuff.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2952909815
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163410222

From dholmes at openjdk.org  Tue Jun 24 09:18:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 09:18:16 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <EItoC6qfST6fGIbcCJWTOlmn5gCYALr5onlVTT2dxzY=.d30512eb-b6b3-497d-bdee-c46be7d671ce@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Bug management issue should be fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25847#issuecomment-2999459491

From duke at openjdk.org  Tue Jun 24 09:18:16 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 09:18:16 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v2]
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <2evgySdW1pYxc1xd3rTGwfq0boMISr07cgPlzkFWTwo=.5d91ad21-c829-4080-ba57-20a92ab82bbf@github.com>

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8359437: Addressed reviewers' comments
 - 8359437: Addressed reviewers' comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25847/files
  - new: https://git.openjdk.org/jdk/pull/25847/files/30de697d..215ee92d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=00-01

  Stats: 39 lines in 8 files changed: 0 ins; 38 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25847/head:pull/25847

PR: https://git.openjdk.org/jdk/pull/25847

From duke at openjdk.org  Tue Jun 24 09:18:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 09:18:17 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v2]
In-Reply-To: <WgeME7_MyAgPVG4VpAwbHDb5XiBy4xmeJk1W7OgQItE=.ed6a57b6-b277-4cef-8f4f-e0d5d0768c65@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <WgeME7_MyAgPVG4VpAwbHDb5XiBy4xmeJk1W7OgQItE=.ed6a57b6-b277-4cef-8f4f-e0d5d0768c65@github.com>
Message-ID: <rdfU-zhH_GpfdUNJbpQeNvzjdW4S1Q9egG5XUs9eRfQ=.a385a054-2a4c-4edb-af92-05b645641a0e@github.com>

On Mon, 23 Jun 2025 15:48:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8359437: Addressed reviewers' comments
>>  - 8359437: Addressed reviewers' comments
>
> test/jdk/java/lang/Thread/virtual/Parking.java line 388:
> 
>> 386:     @ParameterizedTest
>> 387:     @ValueSource(booleans = { true, false })
>> 388:     @DisabledIf("LockingMode#isLegacy")
> 
> Would you mind checking if the import DisabledIf can be removed from these tests? I think we only used it to conditionally run when not legacy mode.

That imports became unused everywhere, so I removed them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163397316

From duke at openjdk.org  Tue Jun 24 09:18:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 09:18:17 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v2]
In-Reply-To: <pllFKwg5aSsCkm1mUWTRKPc9c32k8EQdou4vVuasujo=.7384cd93-4b30-477a-93df-3701c956529c@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <pllFKwg5aSsCkm1mUWTRKPc9c32k8EQdou4vVuasujo=.7384cd93-4b30-477a-93df-3701c956529c@github.com>
Message-ID: <X33UAiStphnAoCb7Hol_bxWLajcHL6I51np9IcDqDlM=.c204829a-72c1-457d-8474-c60608dac799@github.com>

On Mon, 23 Jun 2025 17:04:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8359437: Addressed reviewers' comments
>>  - 8359437: Addressed reviewers' comments
>
> test/hotspot/jtreg/gtest/LockStackGtests.java line 26:
> 
>> 24: 
>> 25: /* @test
>> 26:  * @summary Run LockStack gtests with LockingMode=2
> 
> All gtests are executed with default vm flags in GTestWrapper.java so this while test should be just removed.

Addressed in the latest commits.

> test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 37:
> 
>> 35:  * @bug 8318757
>> 36:  * @summary Test concurrent monitor deflation by MonitorDeflationThread and thread dumping
>> 37:  * @library /test/lib /
> 
> The '/' shouldn't be required for whitebox. Could you please remove it.

Addressed in the latest commits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163386476
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163386162

From duke at openjdk.org  Tue Jun 24 09:18:17 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 09:18:17 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v2]
In-Reply-To: <8zcivFIhzh6QymXS119iTVwdzyufdXBaeOR4_dEjlig=.b1683573-13cb-4b40-baf3-8b609680e86f@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <8zcivFIhzh6QymXS119iTVwdzyufdXBaeOR4_dEjlig=.b1683573-13cb-4b40-baf3-8b609680e86f@github.com>
Message-ID: <eEavoMGCIg8ZjamlxenZot7jEo01uipeXhzeCrLIk-c=.027eb402-ac36-4614-a889-731422d0a592@github.com>

On Tue, 24 Jun 2025 03:09:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8359437: Addressed reviewers' comments
>>  - 8359437: Addressed reviewers' comments
>
> test/jtreg-ext/requires/VMProps.java line 424:
> 
>> 422:      * Note: Lightweight locking does not support RTM (for now).
>> 423:      */
>> 424:     protected String vmRTMCompiler() {
> 
> [JDK-8358542](https://bugs.openjdk.org/browse/JDK-8358542) exists to remove this so you would need to add that bug id to this PR. However, it seems the bug management for this has gotten completely messed up so you may need to scrap this PR and file a new bug and PR for this part.

Issue added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163399542

From dholmes at openjdk.org  Tue Jun 24 09:56:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 09:56:30 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v5]
In-Reply-To: <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>
Message-ID: <hbmz41ma9n7TesckKhYZBoA-HlqOmhBEtcOnSYwsOSI=.f7555164-5eb0-43d8-8034-7f95381d9dfc@github.com>

On Mon, 23 Jun 2025 12:06:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This uses names for frame types for stackmaps in the verifier and redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/classfile/stackMapTable.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/classfile/stackMapTable.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thanks Coleen!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25870#pullrequestreview-2953046279

From duke at openjdk.org  Tue Jun 24 09:59:50 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 09:59:50 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v3]
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <pl5GWD_ACwmKhlPcG48-2fkk4DUrHvxF0yudA5W60U8=.c38d60b8-eae0-46bf-9273-c43106d030f1@github.com>

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8359437: Addressed reviewer's comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25847/files
  - new: https://git.openjdk.org/jdk/pull/25847/files/215ee92d..9a8d5191

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=01-02

  Stats: 30 lines in 3 files changed: 6 ins; 21 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25847/head:pull/25847

PR: https://git.openjdk.org/jdk/pull/25847

From duke at openjdk.org  Tue Jun 24 09:59:51 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 09:59:51 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v2]
In-Reply-To: <K13gNeQwfKA981EEa3a2PqvCmgGWFIDpe9CwWwhCWI0=.786037b5-5fa8-428f-928a-34abf40f33e7@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <2evgySdW1pYxc1xd3rTGwfq0boMISr07cgPlzkFWTwo=.5d91ad21-c829-4080-ba57-20a92ab82bbf@github.com>
 <K13gNeQwfKA981EEa3a2PqvCmgGWFIDpe9CwWwhCWI0=.786037b5-5fa8-428f-928a-34abf40f33e7@github.com>
Message-ID: <xONpsyoJHK9WhKG0XDjHYv-smWeQ0f9Sr_WlNt8JOek=.da46359a-429e-450a-8a18-1df505f98bd8@github.com>

On Tue, 24 Jun 2025 09:14:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8359437: Addressed reviewers' comments
>>  - 8359437: Addressed reviewers' comments
>
> test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 80:
> 
>> 78:             monitors[index] = new Object();
>> 79:             synchronized (monitors[index]) {
>> 80:                 WB.forceInflateMonitorLockedObject(monitors[index]);
> 
> This is now the only use of the new WB method and we can replace this with a simple:
> 
> monitors[index].wait(1);
> 
> as the `wait` forces inflation. Then we can deleted the new WB stuff.

Good catch! It required adding try/catch to the test as `wait()` is throwing `InterruptedException`, addressed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163501835

From dholmes at openjdk.org  Tue Jun 24 10:08:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 10:08:36 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v3]
In-Reply-To: <pl5GWD_ACwmKhlPcG48-2fkk4DUrHvxF0yudA5W60U8=.c38d60b8-eae0-46bf-9273-c43106d030f1@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <pl5GWD_ACwmKhlPcG48-2fkk4DUrHvxF0yudA5W60U8=.c38d60b8-eae0-46bf-9273-c43106d030f1@github.com>
Message-ID: <m1CI03xSxbZo1EpxMxJwTLP6Gm-5rRyv8KEqnJY9mCc=.99efa74e-f9ab-4a38-bacd-8d6e2ab6b9b3@github.com>

On Tue, 24 Jun 2025 09:59:50 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Addressed reviewer's comments.

test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 79:

> 77:     }
> 78: 
> 79:     static private void createMonitors() throws InterruptedException {

I would have put the try/catch around the wait to minimise the number of changes.

test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 86:

> 84:             monitors[index] = new Object();
> 85:             synchronized (monitors[index]) {
> 86:                 monitors[index].wait(1);

Suggestion:

                // Force inflation
                monitors[index].wait(1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163523429
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163521570

From duke at openjdk.org  Tue Jun 24 11:16:21 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 11:16:21 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v4]
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8359437: Addressed reviewer's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25847/files
  - new: https://git.openjdk.org/jdk/pull/25847/files/9a8d5191..17f3b2d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=02-03

  Stats: 14 lines in 1 file changed: 5 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25847/head:pull/25847

PR: https://git.openjdk.org/jdk/pull/25847

From duke at openjdk.org  Tue Jun 24 11:16:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 11:16:23 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v3]
In-Reply-To: <m1CI03xSxbZo1EpxMxJwTLP6Gm-5rRyv8KEqnJY9mCc=.99efa74e-f9ab-4a38-bacd-8d6e2ab6b9b3@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <pl5GWD_ACwmKhlPcG48-2fkk4DUrHvxF0yudA5W60U8=.c38d60b8-eae0-46bf-9273-c43106d030f1@github.com>
 <m1CI03xSxbZo1EpxMxJwTLP6Gm-5rRyv8KEqnJY9mCc=.99efa74e-f9ab-4a38-bacd-8d6e2ab6b9b3@github.com>
Message-ID: <ck1gerTr7jg1vppTrkOoGYd0D2_7j_0tIJ_3CPUTb90=.637991bf-1da1-4f3a-ba40-54a6e278d801@github.com>

On Tue, 24 Jun 2025 10:05:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359437: Addressed reviewer's comments.
>
> test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 79:
> 
>> 77:     }
>> 78: 
>> 79:     static private void createMonitors() throws InterruptedException {
> 
> I would have put the try/catch around the wait to minimise the number of changes.

Makes sense! Addressed in the latest commit.

> test/hotspot/jtreg/runtime/Monitor/ConcurrentDeflation.java line 86:
> 
>> 84:             monitors[index] = new Object();
>> 85:             synchronized (monitors[index]) {
>> 86:                 monitors[index].wait(1);
> 
> Suggestion:
> 
>                 // Force inflation
>                 monitors[index].wait(1);

Addressed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163681754
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163681481

From dholmes at openjdk.org  Tue Jun 24 12:00:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 24 Jun 2025 12:00:38 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v4]
In-Reply-To: <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>
Message-ID: <0zbpdvXTBgLoPsgCBLfAoCNRshJJElA12NIN5hHuF1Y=.512fdbfd-cc1d-4137-8e17-22b438de7eef@github.com>

On Tue, 24 Jun 2025 11:16:21 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Addressed reviewer's comments

LGTM!  Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2953475858

From coleenp at openjdk.org  Tue Jun 24 12:10:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 12:10:32 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <AKAlwoqY12rOJx2b6f6HHTHgsuPjDQ-88kFqjhFWujM=.afb244a8-3541-44e3-97c2-2f593ef28e19@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <AKAlwoqY12rOJx2b6f6HHTHgsuPjDQ-88kFqjhFWujM=.afb244a8-3541-44e3-97c2-2f593ef28e19@github.com>
Message-ID: <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com>

On Mon, 23 Jun 2025 21:18:09 GMT, Alex Menkov <amenkov 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 87:
> 
>> 85:         }
>> 86:         return 0;
>> 87:     }
> 
> I understand, that this is copy of the old code, but this method does not look good.
> - it would be better to return -1 if the string not found (0 is valid offset)
> - calculation of the buf's upper bound is incorrect when offset > 0
> I'd suggest to update it to something like (not tested, also need to update callers to compare with -1)
> 
> 
> private static int getStringIndex(String needle, byte[] buf, int offset) {
>     byte[] needleArray = needle.getBytes(StandardCharsets.US_ASCII);
>     for (int i = offset; i < buf.length - needleArray.length; i++) 
>         if (Arrays.equals(buf, offset, offset + needleArray.length,
>                           needleArray, 0, needleArray.length)) {
>             return offset;
>         }
>     }
>     return -1;
> }

I did copy this code.  I was hoping instead of class byte modifications that someone would suggest a Classfile API way to modify the class file bytes. @liach ? That way the class names don't have to be the same length.  Above seems better  code but I have to debug it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2163791674

From coleenp at openjdk.org  Tue Jun 24 12:33:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 12:33:36 GMT
Subject: RFR: 8359920: Use names for frame types in stackmaps [v5]
In-Reply-To: <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
 <r1mwLp2cmcLY-_kxGm0WLsF_zEAh69dyavE-sVs1bzE=.93de8e20-5fde-4723-900c-2451594b8e87@github.com>
Message-ID: <51dGYjMxe6B2AipdwdKDhFCKon3SczezZDtGQGJWPVY=.c798feac-da3f-4cb8-bfb2-bdede9c65034@github.com>

On Mon, 23 Jun 2025 12:06:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This uses names for frame types for stackmaps in the verifier and redefinition.
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update src/hotspot/share/prims/jvmtiRedefineClasses.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/classfile/stackMapTable.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/classfile/stackMapTable.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

I think this came out really well.  Thanks for your suggestions, David. Thanks for reviewing Matias, Serguei and Johan.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25870#issuecomment-3000213571

From coleenp at openjdk.org  Tue Jun 24 12:33:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 12:33:36 GMT
Subject: Integrated: 8359920: Use names for frame types in stackmaps
In-Reply-To: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
References: <ysZfoKHBG4pVgFgeUq45vyQrVJZeVottJ00jFHzDf4k=.c5d94299-c740-4c7c-af06-ca1b8c5412fb@github.com>
Message-ID: <iOSgIKlUxUBUjnLQqM52RpoNl6KX0IdUBlcsbdgq4Ew=.64839215-6363-4a39-ae92-f5e9ca6e1bb2@github.com>

On Wed, 18 Jun 2025 12:13:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This uses names for frame types for stackmaps in the verifier and redefinition.
> Tested with tier1-7.

This pull request has now been integrated.

Changeset: 28e96e33
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28e96e333b61dfe60a84a48ff59bdf10c529f8be
Stats:     41 lines in 3 files changed: 18 ins; 0 del; 23 mod

8359920: Use names for frame types in stackmaps

Reviewed-by: dholmes, jsjolen, matsaave, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25870

From alanb at openjdk.org  Tue Jun 24 12:47:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jun 2025 12:47:35 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v4]
In-Reply-To: <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>
Message-ID: <kYQQbmMw4I8t0X9Fmrsziag0pi1vOAFN-zFik5vUGUk=.217e195d-1e8c-48a8-b9b3-612f58fcdcc9@github.com>

On Tue, 24 Jun 2025 11:16:21 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Addressed reviewer's comments

test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 280:

> 278: 
> 279:     static boolean preemptableVirtualThread() {
> 280:         return is_virtual && !isBoundVThread;

I think this is the last usage of ManagementFactory and HotSpotDiagnosticMXBean in this test so the imports can be expunged.

test/jdk/jdk/internal/vm/Continuation/Basic.java line 426:

> 424:         return ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
> 425:                     .getVMOption("LockingMode").getValue().equals("1");
> 426:     }

Likely the same here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163891432
PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163896486

From coleenp at openjdk.org  Tue Jun 24 12:53:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 12:53:28 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <nM9THesjxpAyWp18skZjl7Y6Er0wjYeGKY8tz8-DAZ4=.b3247d71-36c7-447f-8d7b-9c40ccedcf00@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Hi Aleksey.  The consensus around here is that this should go in JDK 25 so it gets the usual end of release testing, and doesn't go through a special process for update release.  This fixes a regression where we have no workaround.  If any disasters happen, we can change the BinarySearchThreshold in the source code as a fix, and/or make it a diagnostic option.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-3000349581

From shade at openjdk.org  Tue Jun 24 13:04:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jun 2025 13:04:28 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <f7VFGleV4OiSLZjHPSuje4hVGnh0WiX8c4I37MfBFtU=.f05b3b09-3dda-47b5-a30a-0b883124febf@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Yeah, as I said, can take it both ways. Picking this up to JDK 25 works for me as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-3000404473

From coleenp at openjdk.org  Tue Jun 24 13:06:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 13:06:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <_f9CuTsqV-WEq5F8dLzaSFckSe3YdyUGVVTOZWdnWXQ=.4008de9c-1812-4768-aaf8-a464ab100925@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

jclass is a strong root so jclass will keep the Method alive until the jni local is released.  If the method belongs to jclass.
I think the whole worry about stale jmethodIDs is if there's native or JVMTI (also native) code that squirrels them away somewhere then tries to call JNI call Method or JVMTI with this old jmethodID value.  Once we validate the method inside the VM, a safepoint cannot make the method go away if it's holder is alive.   We might need to strengthen this by holding a class holder if we don't already. This is preexisting the change here.
The jmethodID table is so that jmethodID isn't a stale pointer itself and doesn't require us to hold a stale pointer, but whether it can return a stale Method* (now and before this change) is something we should figure out how it should work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3000411580

From duke at openjdk.org  Tue Jun 24 13:25:20 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 13:25:20 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8359437: Addressed reviewer's comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25847/files
  - new: https://git.openjdk.org/jdk/pull/25847/files/17f3b2d4..02565157

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=03-04

  Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25847/head:pull/25847

PR: https://git.openjdk.org/jdk/pull/25847

From duke at openjdk.org  Tue Jun 24 13:25:20 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 13:25:20 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <kYQQbmMw4I8t0X9Fmrsziag0pi1vOAFN-zFik5vUGUk=.217e195d-1e8c-48a8-b9b3-612f58fcdcc9@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>
 <kYQQbmMw4I8t0X9Fmrsziag0pi1vOAFN-zFik5vUGUk=.217e195d-1e8c-48a8-b9b3-612f58fcdcc9@github.com>
Message-ID: <gg466JQ6pHguP6HDwNyAut9KZHiB7QfmzEkn6yDWryc=.de5ad627-da2c-40df-b37d-e9c35b00f9d3@github.com>

On Tue, 24 Jun 2025 12:44:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359437: Addressed reviewer's comment
>
> test/jdk/jdk/internal/vm/Continuation/Basic.java line 426:
> 
>> 424:         return ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class)
>> 425:                     .getVMOption("LockingMode").getValue().equals("1");
>> 426:     }
> 
> Likely the same here.

Correct, addressed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163993099

From duke at openjdk.org  Tue Jun 24 13:25:20 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 24 Jun 2025 13:25:20 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v4]
In-Reply-To: <kYQQbmMw4I8t0X9Fmrsziag0pi1vOAFN-zFik5vUGUk=.217e195d-1e8c-48a8-b9b3-612f58fcdcc9@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <SGnrY1jPfC9MYzZE-51ckWoHh2cCtJXB2ja0_2MaipI=.b0ecfaf1-007c-48d5-ab72-a2fe3e5b3f40@github.com>
 <kYQQbmMw4I8t0X9Fmrsziag0pi1vOAFN-zFik5vUGUk=.217e195d-1e8c-48a8-b9b3-612f58fcdcc9@github.com>
Message-ID: <-UvM8zh4XOerhMCMCBPHzOvWu7yrRX4F90ZrM0uHT5o=.3f96c2c7-29b2-4670-bbe5-c1e82932d22c@github.com>

On Tue, 24 Jun 2025 12:43:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359437: Addressed reviewer's comments
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 280:
> 
>> 278: 
>> 279:     static boolean preemptableVirtualThread() {
>> 280:         return is_virtual && !isBoundVThread;
> 
> I think this is the last usage of ManagementFactory and HotSpotDiagnosticMXBean in this test so the imports can be expunged.

Correct, addressed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2163992589

From phh at openjdk.org  Tue Jun 24 13:54:05 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 24 Jun 2025 13:54:05 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case exit
 codes after JDK-8245129
Message-ID: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>

jstat test-only fix.

1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented '-'.

Modified tests pass.

-------------

Commit messages:
 - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

Changes: https://git.openjdk.org/jdk/pull/25951/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25951&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279005
  Stats: 76 lines in 16 files changed: 60 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25951.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25951/head:pull/25951

PR: https://git.openjdk.org/jdk/pull/25951

From coleenp at openjdk.org  Tue Jun 24 13:55:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 13:55:29 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <8820nqtQq82MXXPZpDkQWttOVzUFqgzNYoSQVMNpRP4=.44be289d-9053-4720-93f2-23a91350d444@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Thank you for your feedback and comments for this.  Here goes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-3000595520

From phh at openjdk.org  Tue Jun 24 13:59:30 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 24 Jun 2025 13:59:30 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129
In-Reply-To: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
Message-ID: <Ynq4hk0cXEhDwKgpU7JJOUmEFtKdCXzhuoQE1VVBwpc=.5152e89a-d7e0-4192-8323-243940a919cf@github.com>

On Tue, 24 Jun 2025 13:48:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Please review a jstat test-only fix.
> 
> 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
> 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented '-'.
> 
> Modified tests pass.

Windows GHA failures are infra-related and unrelated to this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25951#issuecomment-3000612238

From kustos at gmx.net  Tue Jun 24 14:30:05 2025
From: kustos at gmx.net (Philippe Marschall)
Date: Tue, 24 Jun 2025 16:30:05 +0200
Subject: Interest in Java based attach provider implementation?
In-Reply-To: <112cc394-b8a9-412a-9ca8-114a73994607@oracle.com>
References: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
 <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
 <112cc394-b8a9-412a-9ca8-114a73994607@oracle.com>
Message-ID: <34520a71-a101-4973-8eaa-db2f4eef9fa4@gmx.net>

Hello

Since the audience has been expanded let me summarize what would be 
needed to make jdk.attach free of JNI on Unix (AIX, Linux, macOS). 
jdk.attach currently uses JNI for four different things.

1. reading and writing unix domain sockets
2. accessing uid, guid and permissions of a file
3. sending SIGQUIT to an arbitrary PID, including self in the case of 
self attach
4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid}) on macOS

For 1. and 2. there are already supported Java based APIs and I have 
patches in case somebody is willing to sponsor this work / open a JIRA.

3. kill(SIGQUIT)

This can be done quite easily using FFM as the signature of kill() is 
quite simple. The signature and values are the same an Linux and macOS 
and I assume AIX as well, but I don't have access to a machine to 
verify. Overlap with existing code is with ProcessHandleImpl.destroy0 
which sends SIGKILL or SIGTERM to a PID but performs additional checks. 
So an API to send a signal to a PID would be needed. It is my 
understanding that jdk.internal.misc.Signal only supports sending signal 
to self.

4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid})

This is more complicated as the kinfo_proc and extern_proc structs are 
quite large. jextract is the easiest way to come up with the 
definitions. However the amount of generated code is quite large even 
after filtering. The generated code can be further cut down using manual 
editing. I have not yet looked into replacing not needed struct fields 
with padding. To the best of my knowledge jextract hasn't the been 
included into the JDK build.
Overlap here is in ProcessHandleImpl_macosx.c with the functions 
os_getParentPidAndTimings and getUID but they access different fields of 
extern_proc.
Honestly here I'm not sure why this check is needed at all. The 
reasoning given for the check in VirtualMachineImpl.c would in my option 
apply to Linux and AIX as well but this check is not performed there. 
Removing this check from the macOS implementation would obviously be the 
easiest.

I can't speak for Windows as I'm not familiar enough with Windows APIs.

Cheers
Philippe


On 19.06.25 14:40, Magnus Ihse Bursie wrote:
> Hi Philippe,
> 
> There is an ongoing effort about "Panamization" (that is, adapting it to 
> use FFM instead of JNI) of native code in the JDK in general. This is 
> discussed on the core-libs-dev mailing list. I've cc:ed them. I think it 
> would be beneficial if you coordinate your efforts with the Panamization 
> effort.
> 
> /Magnus
> 
> 
> On 2025-06-15 17:43, Philippe Marschall wrote:
>> Hello
>>
>> I further pursued the approach
>>
>> - Rebased the Linux implementation [1], implemented the permission 
>> check using JSR 203 and the Unix domain sockets using JEP 380.
>> - Applied the same changes to the AIX implementation [2].
>> - Switched Linux to an FFM based kill implementation [3], completely 
>> getting rid of JNI.
>> -? Updated the macOS implementation [4], implemented the permission 
>> check using JSR 203 and the Unix domain sockets using JEP 380.
>> - Switched macOS to an FFM based kill and sysctl implementation [5], 
>> completely getting rid of JNI.
>>
>> I ran the serviceability test suite on Linux and macOS and it passes. 
>> I manually verified that I can attach to JVMs using local builds.
>>
>> I could not test on AIX.
>>
>> ?[1] https://github.com/marschall/jdk/ 
>> commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
>> ?[2] https://github.com/marschall/jdk/ 
>> commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
>> ?[3] https://github.com/marschall/jdk/ 
>> commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559
>> ?[4] https://github.com/marschall/jdk/ 
>> commit/93372a124eca6078fde5597c2498b381a4ef5dfa
>> ?[5] https://github.com/marschall/jdk/commit/ 
>> c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b
>>
>> Cheers
>> Philippe
>>
>> On 20.04.22 22:13, Philippe Marschall wrote:
>>> Hello
>>>
>>> I hope this is the right mailing list. I recently had a look at the
>>> Linux attach provider implementation and could not help but noticing
>>> that a large part, if not all of it, could be replaced with Java.
>>> Besides getting rid of the C code this should allow us to unify the AIX,
>>> Linux and macOS implementations under a single Unix implementation.
>>>
>>> The permission check can be implemented using JSR 203 [1] to access uid,
>>> gid and file mode and using jdk.internal.misc.VM to get the euid and 
>>> egid.
>>>
>>> Reading and writing to Unix domain sockets can be done through JEP 
>>> 380 [2].
>>>
>>> Sending SIGQUIT to a process could in theory done through JEP 102 [3]
>>> however sending SIGQUIT to self is currently blocked. This is required
>>> for the self attach mechanism. There a very small C function is still
>>> needed for now, this is hopefully portable.
>>>
>>> I did a small prototype [4]. The tier1 suite runs and I can attach to a
>>> local JVM.
>>>
>>> The overhead will likely be a bit higher as we go through more JDK
>>> abstractions.
>>>
>>> ??[1] https://jcp.org/en/jsr/detail?id=203
>>> ??[2] https://openjdk.java.net/jeps/380
>>> ??[3] https://openjdk.java.net/jeps/102
>>> ??[4]
>>> https://github.com/marschall/jdk/ 
>>> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc
>>>
>>> Cheers
>>> Philippe
>>


From eosterlund at openjdk.org  Tue Jun 24 14:48:33 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 24 Jun 2025 14:48:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <A7cj8KWh-v8BogImcrG4JNP0rMsssBgnlpGY14kbmlA=.de52026b-46d6-4742-a9ca-5bb3e0ba5a52@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

This looks good to me. Thanks for building the table!

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2954192642

From aboldtch at openjdk.org  Tue Jun 24 14:48:34 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 24 Jun 2025 14:48:34 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <LLDjr_p8d9pWcCjZCJR-SInxLcyhG6afqZYjZa8TZ1s=.3ada2632-58ab-4675-ad0c-7e8ada82cb7f@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Looks good. Thanks.

_Feels like `JmethodIdCreation_lock` might not be needed now but it is also easier to reason about things when we serialize the modifications._

-------------

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2954200289

From eosterlund at openjdk.org  Tue Jun 24 14:48:34 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 24 Jun 2025 14:48:34 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <xLVmjg1RjqCXLY0c4xFtg9NADyUakjs6pmuDywVrjhM=.50072f65-4ee4-46a4-b59a-99e3254e4d3b@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <pfYjl3ZpqaTm-qXaYFzfQCZEuAoxNt-OGPHcwxUd_dM=.e59e3b27-a08f-48b2-8162-50a28b4d9628@github.com>
 <xLVmjg1RjqCXLY0c4xFtg9NADyUakjs6pmuDywVrjhM=.50072f65-4ee4-46a4-b59a-99e3254e4d3b@github.com>
Message-ID: <VD0-QRCwzdrbboyAnB1xOnpxpW0INH3rcCc9SNHcA-Q=.234c366d-6cb4-4927-afa2-e4fe6fa7fffa@github.com>

On Tue, 24 Jun 2025 02:36:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> the `cls` parameter is never actually used. So while it is supposed to refer to the class you have the static method jMethodID for, there is no requirement that it actually does, and could even be null.

Not passing in the cls parameter, would be a clear user error though, right? And one that would have crashed before, because if you racingly execute bytecodes of a class that is being unloaded, things would blow up one way or another. To me it seems like the user should just pass in the class as intended and then all is good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3000808219

From weijun at openjdk.org  Tue Jun 24 14:56:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 14:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
Message-ID: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>

On Wed, 18 Jun 2025 16:43:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.
>
> Thank you for the clarification.

However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164251035

From weijun at openjdk.org  Tue Jun 24 15:01:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:

> 47: .Principal.=\t????\u0020
> 48: .Public.Credential.=\t??????:\u0020
> 49: .Private.Credential.=\t??????:\u0020

Why aren't the 2 lines above updated like in lines 46 and 47?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164262664

From coleenp at openjdk.org  Tue Jun 24 15:02:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 15:02:30 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <MghgiGmKP3265exTAzBT2mfaAp-HIx4sNaegT0pa-7g=.42343c94-e219-4bd8-a147-31fe0f6a148e@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

oops I guess I need approval, even though it was a clean backport.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-3000854295

From weijun at openjdk.org  Tue Jun 24 15:01:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
Message-ID: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>

On Tue, 24 Jun 2025 14:54:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thank you for the clarification.
>
> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164261187

From shade at openjdk.org  Tue Jun 24 15:08:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jun 2025 15:08:29 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <6zTZj2C_IgbPbPaZkkvNLVjqb_cyRXTky6NZjxJYoG4=.9b083646-d8a5-49ea-a539-efeaeb725ea1@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25877#pullrequestreview-2954275829

From iklam at openjdk.org  Tue Jun 24 15:08:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 24 Jun 2025 15:08:29 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <iOPwNTebZqJwbsmJIlDUpiLmxvsKFV8RQUo5__pB0qY=.efba0523-430c-4e04-96f8-9a8b9cde8dc5@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25877#pullrequestreview-2954281986

From liach at openjdk.org  Tue Jun 24 15:59:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Jun 2025 15:59:32 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <AKAlwoqY12rOJx2b6f6HHTHgsuPjDQ-88kFqjhFWujM=.afb244a8-3541-44e3-97c2-2f593ef28e19@github.com>
 <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com>
Message-ID: <kgRT4xZGIpcmupqC5d7sS3NiG2Gg0NevFqM_UXpYr_0=.c185619b-426a-4766-8ea7-27b4b9924b97@github.com>

On Tue, 24 Jun 2025 12:07:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/lib/RedefineClassHelper.java line 87:
>> 
>>> 85:         }
>>> 86:         return 0;
>>> 87:     }
>> 
>> I understand, that this is copy of the old code, but this method does not look good.
>> - it would be better to return -1 if the string not found (0 is valid offset)
>> - calculation of the buf's upper bound is incorrect when offset > 0
>> I'd suggest to update it to something like (not tested, also need to update callers to compare with -1)
>> 
>> 
>> private static int getStringIndex(String needle, byte[] buf, int offset) {
>>     byte[] needleArray = needle.getBytes(StandardCharsets.US_ASCII);
>>     for (int i = offset; i < buf.length - needleArray.length; i++) 
>>         if (Arrays.equals(buf, offset, offset + needleArray.length,
>>                           needleArray, 0, needleArray.length)) {
>>             return offset;
>>         }
>>     }
>>     return -1;
>> }
>
> I did copy this code.  I was hoping instead of class byte modifications that someone would suggest a Classfile API way to modify the class file bytes. @liach ? That way the class names don't have to be the same length.  Above seems better  code but I have to debug it now.

`jdk.internal.classfile.components` has a `ClassRemapper` that may serve this purpose. It updates all internal names and occurrences in descriptors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2164386948

From serge.chernyshev at bell-sw.com  Tue Jun 24 16:04:04 2025
From: serge.chernyshev at bell-sw.com (Sergey Chernyshev)
Date: Tue, 24 Jun 2025 18:04:04 +0200
Subject: [External] : Re: RFR: 8319589: Attach from root to a user java
 process not supported in Mac [v2]
In-Reply-To: <9f2b0a55-4a12-4033-8a7c-48129352e330@oracle.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <81oslKJVyJOL-dNDKv4r-fIEVbRF7G1vjHVBEsqNT8s=.83cd9c45-7a41-4202-89c8-82b37f6b80ca@github.com>
 <tYl_yPungG-foQekVlGyro-UpiLJT807s08qCbykWzI=.c436bd5b-c7b4-4906-9011-0c351cb73398@github.com>
 <c6886778-6239-44b6-b8a7-2f0ffbd5cf2f@oracle.com>
 <b4da9552-1164-4974-8307-696a46160b6b@bell-sw.com>
 <d8fa80f0-929a-4e5b-8beb-92d8046af486@oracle.com>
 <9f2b0a55-4a12-4033-8a7c-48129352e330@oracle.com>
Message-ID: <2fa5eb1d-0beb-4117-bf6c-6d66c1c3d236@bell-sw.com>

Hi Larry,

Thanks for this note! If I understand correctly, "zz" corresponds to the 
first 10 bits of the encoded UUID attribute of LDAP user record, where 
all bits are set. Such records have UUIDs that start with FFFFEEEE-. 
They are special purpose?user accounts, apart from `root`, that have 
their temp directories in zz bucket. If it's ignored, it will not be 
possible to attach/list JVMs running under special purpose accounts 
(which is theoretically possible).

Thanks,
Sergey

Am 18.06.25 um 23:51 schrieb Laurence Cable:
> I believe you can ignore bucket "zz"
>
> - Larry
>
> On 6/18/25 2:46 PM, Laurence Cable wrote:
>>
>>
>> On 6/18/25 12:44 PM, Sergey Chernyshev wrote:
>>> Hi Larry,
>>>
>>> Thank you for your comments! Yes, it's probably more like base 32 / 
>>> 5 bits per symbol. The function is actually __user_local_dirname, 
>>> it's exported by CoreServices (libsystem_coreservices.dylib). One 
>>> can dlopen() 
>>> /System/Library/Frameworks/CoreServices.framework/Versions/Current/CoreServices 
>>> and then lookup the __user_local_dirname (still works in 15.5 
>>> Sequoia). The problem is that the function is undocumented, it is 
>>> not exposed in any platform SDK headers and it is not reachable from 
>>> any documented api except for the confstr(), at least what i am 
>>> aware of. With the introduction of dyld shared cache in Big Sur the 
>>> approach became even less attractive. 
>>
>> Its probably not worth it, I followed a similar (fruitless) trail to 
>> the same conclusion a couple of years ago ... :(
>>
>>> I might need to look deeper into it.
>>>
>>> Thanks,
>>> Sergey
>>>
>>>
>>> Am 18.06.25 um 19:23 schrieb Laurence Cable:
>>>> I believe that somewhere in the bowels of MacOS libc there is a 
>>>> (hopefully public) function that will map a UID to the UUID used to 
>>>> construct
>>>> the per-user directory path from a base 36(?) encoded string 
>>>> thereof, the leading 2 characters of which form the "buckets" in 
>>>> /var/folders
>>>> and the remainder of the encoded string forms the per user 
>>>> directory with the appropriate bucket...
>>>>
>>>> if might make sense to perform a serious investigation to locate 
>>>> this function and then simply make a native call to map the target 
>>>> JVM euid
>>>> to the uuid and encode it, from which the actual /var/folders/... 
>>>> path can be constructed avoiding a costly traversal of the 
>>>> /var/folders
>>>> structure in the search for hsperfdata_user files?
>>>>
>>>> Rgds
>>>>
>>>> - Larry
>>>>
>>>> On 6/18/25 9:40 AM, Sergey Chernyshev wrote:
>>>>> 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 
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250624/cf2e65c1/attachment-0001.htm>

From shade at openjdk.org  Tue Jun 24 17:07:27 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 24 Jun 2025 17:07:27 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129
In-Reply-To: <Ynq4hk0cXEhDwKgpU7JJOUmEFtKdCXzhuoQE1VVBwpc=.5152e89a-d7e0-4192-8323-243940a919cf@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
 <Ynq4hk0cXEhDwKgpU7JJOUmEFtKdCXzhuoQE1VVBwpc=.5152e89a-d7e0-4192-8323-243940a919cf@github.com>
Message-ID: <S2y5IHdoT-oYbKhhAJmfbmljasvqESlz7l61Pz_8O-o=.542b1003-83ea-4946-9584-451ec1fe53f8@github.com>

On Tue, 24 Jun 2025 13:56:40 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Windows GHA failures are infra-related and unrelated to this change.

You can pull in from current master to get them fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25951#issuecomment-3001233870

From coleenp at openjdk.org  Tue Jun 24 17:12:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 17:12:41 GMT
Subject: [jdk25] Integrated: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <w1_RyjglRabWwwyZBM4iUNttXupfzemn06JP_stPcgQ=.3ed18634-9e38-4eae-a59d-dff33e969f9a@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0694cc1d
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0694cc1d527db17f2e5cdd4f9d2489ba04adfef5
Stats:     924 lines in 18 files changed: 854 ins; 20 del; 50 mod

8352075: Perf regression accessing fields

Reviewed-by: shade, iklam
Backport-of: e18277b470a162b9668297e8e286c812c4b0b604

-------------

PR: https://git.openjdk.org/jdk/pull/25877

From coleenp at openjdk.org  Tue Jun 24 17:12:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 17:12:39 GMT
Subject: [jdk25] RFR: 8352075: Perf regression accessing fields
In-Reply-To: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
References: <hn_k9tZkiYvZE9k_4be5-qVchIpcahXi8-iDGwTEceI=.894f5575-8b1c-495d-9d1b-abe648e5f124@github.com>
Message-ID: <aDvmlMhl0EzsQNuLe7pgmXqTcRH3mKhhKcLXsZKBYGQ=.06aedbce-3988-457c-9e9b-3f9646f7e540@github.com>

On Wed, 18 Jun 2025 14:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e18277b4](https://github.com/openjdk/jdk/commit/e18277b470a162b9668297e8e286c812c4b0b604) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Radim Vansa on 12 Jun 2025 and was reviewed by Coleen Phillimore, Ioi Lam and Johan Sj?len.
> 
> This has been running cleanly in CI for a week now.
> 
> Thanks!

Thank you Aleksey and Ioi.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25877#issuecomment-3001247661

From coleenp at openjdk.org  Tue Jun 24 17:17:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 17:17:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <nZIlwur1Gb_IQkMq_F2ie-7O7f-8Nq3wMBo6q1EvEEs=.e59501ab-9910-40bc-b652-5b8e837cc602@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Thank you for reviewing from the GC and class unloading perspective, Axel and Erik.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3001264941

From phh at openjdk.org  Tue Jun 24 17:48:56 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 24 Jun 2025 17:48:56 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129 [v2]
In-Reply-To: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
Message-ID: <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>

> Please review a jstat test-only fix.
> 
> 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
> 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented by '-'.
> 
> Modified tests pass.

Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8279005
 - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25951/files
  - new: https://git.openjdk.org/jdk/pull/25951/files/201f1f5e..1b9b31b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25951&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25951&range=00-01

  Stats: 2863 lines in 190 files changed: 1035 ins; 520 del; 1308 mod
  Patch: https://git.openjdk.org/jdk/pull/25951.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25951/head:pull/25951

PR: https://git.openjdk.org/jdk/pull/25951

From phh at openjdk.org  Tue Jun 24 17:48:56 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 24 Jun 2025 17:48:56 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129
In-Reply-To: <S2y5IHdoT-oYbKhhAJmfbmljasvqESlz7l61Pz_8O-o=.542b1003-83ea-4946-9584-451ec1fe53f8@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
 <Ynq4hk0cXEhDwKgpU7JJOUmEFtKdCXzhuoQE1VVBwpc=.5152e89a-d7e0-4192-8323-243940a919cf@github.com>
 <S2y5IHdoT-oYbKhhAJmfbmljasvqESlz7l61Pz_8O-o=.542b1003-83ea-4946-9584-451ec1fe53f8@github.com>
Message-ID: <ogVXh_VNaeHRmCkYt9pqFpc1itMpLNu97NcvkY9PyZY=.0cce83e5-d012-4d6c-90bb-206f723e3d44@github.com>

On Tue, 24 Jun 2025 17:05:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Windows GHA failures are infra-related and unrelated to this change.
>
>> Windows GHA failures are infra-related and unrelated to this change.
> 
> You can pull in from current master to get them fixed.

Done. Thanks, @shipilev.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25951#issuecomment-3001363003

From sspitsyn at openjdk.org  Tue Jun 24 18:02:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 18:02:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <r10eWAd5KLl0LSl2zC572lIIs3gwULTFynb5mhcNBag=.29051f67-aea6-4a38-a239-66309081aad9@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2954810575

From amenkov at openjdk.org  Tue Jun 24 20:52:27 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 24 Jun 2025 20:52:27 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v2]
In-Reply-To: <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
Message-ID: <1VowGd8j_hD2G9_CcSgx9BzuloEhtITXoZtqOYMhoXA=.23217ad6-62bb-4643-ab7b-0b9cffb425f7@github.com>

On Tue, 24 Jun 2025 06:54:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. The fix is to wait for the first `THREAD_START` event at the `VM_INIT` event.
>> 
>> The update includes some other changes and minor refactoring:
>>  - the file `libMAAThreadStart.c` has been renamed to `libMAAThreadStart.cpp`
>>  - the test library `jvmti_common.hpp` is used where it is possible
>>  - static variable `printdump` has been removed
>>  - the static block with `loadLibrary` has been removed from the `MAAThreadStart.java`
>>  
>>  Testing:
>>   - ran the modified test locally
>>   - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - corrected the Copyright line
>  - small corrections and indentation fixes

I don't see how waiting in VMInit can help here.
Phase is set before posting VMInit events.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3001822541

From coleenp at openjdk.org  Tue Jun 24 21:35:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 24 Jun 2025 21:35:44 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <-CyJHR3KLJKebYK5HMcpQkY5AoRsPTrI6U4iu0CL3_Q=.d5689e6c-aefa-422a-9e66-75a8d080c696@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Thank you Serguei and Dan for reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3001955294

From achung at openjdk.org  Tue Jun 24 21:47:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jun 2025 21:47:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v5]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <D5DGFra1xHGKB6ITrD1TV1PQcZNS_7nlA8GfD8cwQ6w=.c87859b8-fb89-4d2e-93a4-d9c0e3e44f21@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/90bfd7bd..97f3fe37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=03-04

  Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From cjplummer at openjdk.org  Tue Jun 24 22:57:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 24 Jun 2025 22:57:29 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129 [v2]
In-Reply-To: <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
 <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
Message-ID: <oBHNLpkxNfrBBKafsD1MnA8knF4keD2Tn2_fvAexHa4=.283cd4f7-9517-463c-b0de-8f94eaf0afc6@github.com>

On Tue, 24 Jun 2025 17:48:56 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Please review a jstat test-only fix.
>> 
>> 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
>> 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented by '-'.
>> 
>> Modified tests pass.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8279005
>  - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

Changes look good. I think you can also close [JDK-8268485](https://bugs.openjdk.org/browse/JDK-8268485)

test/jdk/sun/tools/jstat/lineCounts1.awk line 32:

> 30: 	}
> 31: 
> 32: /^[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+\.[0-9]+$/	{

This would be a lot easier to read if written to verify that the `[ ]*([0-9]+.[0-9]+|-)` pattern appears 13 times, but I suppose that would be allowing a `-` in some cases that currently don't allow it.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25951#pullrequestreview-2955620503
PR Review Comment: https://git.openjdk.org/jdk/pull/25951#discussion_r2165077204

From sspitsyn at openjdk.org  Tue Jun 24 23:00:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 23:00:43 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v2]
In-Reply-To: <1VowGd8j_hD2G9_CcSgx9BzuloEhtITXoZtqOYMhoXA=.23217ad6-62bb-4643-ab7b-0b9cffb425f7@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
 <1VowGd8j_hD2G9_CcSgx9BzuloEhtITXoZtqOYMhoXA=.23217ad6-62bb-4643-ab7b-0b9cffb425f7@github.com>
Message-ID: <WnoyjEchpbvnTPUflfLXct024tcmJNYZnfx66m6Fo1U=.bb974253-d70f-4aa5-ba12-db806307e464@github.com>

On Tue, 24 Jun 2025 20:50:19 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I don't see how waiting in VMInit can help here.
>  Phase is set before posting VMInit events.

Agreed, thanks!
I've also found it out from the JVMTI `VMInit` event spec.
Then I do not see a way to guarantee any thread to get started in the early `VM_START` phase.
It means we have to remove this test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002098917

From cjplummer at openjdk.org  Tue Jun 24 23:03:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 24 Jun 2025 23:03:27 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v2]
In-Reply-To: <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
Message-ID: <TxBvcNguSDCTma6SEWgK-t0ZQctPOzqMopcDQgLO_SI=.07c4f169-023a-4c8e-96c1-f406dbc8331d@github.com>

On Tue, 24 Jun 2025 06:54:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. The fix is to wait for the first `THREAD_START` event at the `VM_INIT` event.
>> 
>> The update includes some other changes and minor refactoring:
>>  - the file `libMAAThreadStart.c` has been renamed to `libMAAThreadStart.cpp`
>>  - the test library `jvmti_common.hpp` is used where it is possible
>>  - static variable `printdump` has been removed
>>  - the static block with `loadLibrary` has been removed from the `MAAThreadStart.java`
>>  
>>  Testing:
>>   - ran the modified test locally
>>   - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - corrected the Copyright line
>  - small corrections and indentation fixes

Did you rename libMAAThreadStart.c or delete it and create a new file? I think the latter because I'm not seeing any diffs for the actual changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002103622

From sspitsyn at openjdk.org  Tue Jun 24 23:12:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 23:12:43 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
Message-ID: <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>

> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. There is no way to fix the test so, it is being removed.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove the ModuleAwareAgents/ThreadStart test as there is no way to fix it

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25948/files
  - new: https://git.openjdk.org/jdk/pull/25948/files/2d7840f1..e737f5ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25948&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25948&range=01-02

  Stats: 184 lines in 2 files changed: 0 ins; 184 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25948.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25948/head:pull/25948

PR: https://git.openjdk.org/jdk/pull/25948

From sspitsyn at openjdk.org  Tue Jun 24 23:12:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 23:12:43 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v2]
In-Reply-To: <TxBvcNguSDCTma6SEWgK-t0ZQctPOzqMopcDQgLO_SI=.07c4f169-023a-4c8e-96c1-f406dbc8331d@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
 <TxBvcNguSDCTma6SEWgK-t0ZQctPOzqMopcDQgLO_SI=.07c4f169-023a-4c8e-96c1-f406dbc8331d@github.com>
Message-ID: <G_s8Qf6Vd4bB5PGqfOzyteOD38s5-m054LoHSCueQfM=.37e2acf2-6146-40d9-8d0a-ccb45c5cc235@github.com>

On Tue, 24 Jun 2025 23:01:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Did you rename libMAAThreadStart.c or delete it and create a new file? I think the latter because I'm not seeing any diffs for the actual changes.

I've renamed it. Don't know why there were no actual diffs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002117343

From sspitsyn at openjdk.org  Tue Jun 24 23:12:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 24 Jun 2025 23:12:43 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v2]
In-Reply-To: <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <4NcijocbINk8gLL1zFZai8A4AWk73emnZo_3ZKOIFIc=.266582d6-95b1-422a-90e1-aeaa651fb2f5@github.com>
Message-ID: <Ecy50uNDEuca040Re0LmOVplMoiHrNllYJAaowakQTo=.b8b3eed8-9a05-4dac-a653-8e1f0a9b4c7f@github.com>

On Tue, 24 Jun 2025 06:54:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. There is no way to fix the test so, it is being removed.
>
> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - corrected the Copyright line
>  - small corrections and indentation fixes

I've decided to remove the test, so it has been removed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002119269

From phh at openjdk.org  Tue Jun 24 23:19:27 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 24 Jun 2025 23:19:27 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129 [v2]
In-Reply-To: <oBHNLpkxNfrBBKafsD1MnA8knF4keD2Tn2_fvAexHa4=.283cd4f7-9517-463c-b0de-8f94eaf0afc6@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
 <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
 <oBHNLpkxNfrBBKafsD1MnA8knF4keD2Tn2_fvAexHa4=.283cd4f7-9517-463c-b0de-8f94eaf0afc6@github.com>
Message-ID: <cPG1hOWPmvnY0eSoDE0oXa2zmpe5aK4gQ4EH2_DwI1U=.a6784221-a11f-4d51-a32d-25291e90d26b@github.com>

On Tue, 24 Jun 2025 22:55:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8279005
>>  - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129
>
> Changes look good. I think you can also close [JDK-8268485](https://bugs.openjdk.org/browse/JDK-8268485)

Thanks for the review, @plummercj. Yes, [JDK-8268485](https://bugs.openjdk.org/browse/JDK-8268485) looks like a dup.

> test/jdk/sun/tools/jstat/lineCounts1.awk line 32:
> 
>> 30: 	}
>> 31: 
>> 32: /^[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*[0-9]+[ ]*[0-9]+\.[0-9]+[ ]*([0-9]+|-)[ ]*([0-9]+\.[0-9]+|-)[ ]*[0-9]+\.[0-9]+$/	{
> 
> This would be a lot easier to read if written to verify that the `[ ]*([0-9]+.[0-9]+|-)` pattern appears 13 times, but I suppose that would be allowing a `-` in some cases that currently don't allow it.

True.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25951#issuecomment-3002130888
PR Review Comment: https://git.openjdk.org/jdk/pull/25951#discussion_r2165117631

From amenkov at openjdk.org  Tue Jun 24 23:56:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 24 Jun 2025 23:56:28 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
Message-ID: <XeH49Q-pp9SxlaoI4TpirYzjxn5CXaJdlKky1sXIUi0=.b25b0a90-17b4-433b-9ef2-4a72c5eeef7b@github.com>

On Tue, 24 Jun 2025 23:12:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. There is no way to fix the test so, it is being removed.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove the ModuleAwareAgents/ThreadStart test as there is no way to fix it

Marked as reviewed by amenkov (Reviewer).

I thought if we need some sanity test for ThreadStart event with can_generate_early_vmstart capability, but looking at the spec I see no relations between them. So it's unclear what was the purpose of the test.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25948#pullrequestreview-2955731806
PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002184878

From cjplummer at openjdk.org  Wed Jun 25 00:11:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 00:11:35 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
Message-ID: <4Uh8ghEnUqGNR-vj3OM80wx5nlqkCr03aJiy-pa4mK8=.9060f169-1ebb-45f4-9d79-0e2e388ef31c@github.com>

On Tue, 24 Jun 2025 23:12:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. There is no way to fix the test so, it is being removed.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove the ModuleAwareAgents/ThreadStart test as there is no way to fix it

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25948#pullrequestreview-2955762581

From dnguyen at openjdk.org  Wed Jun 25 00:30:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jun 2025 00:30:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
Message-ID: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>

On Tue, 24 Jun 2025 14:59:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to german translations
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
> 
>> 47: .Principal.=\t????\u0020
>> 48: .Public.Credential.=\t??????:\u0020
>> 49: .Private.Credential.=\t??????:\u0020
> 
> Why aren't the 2 lines above updated like in lines 46 and 47?

I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.

I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2165200706

From cjplummer at openjdk.org  Wed Jun 25 00:40:42 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 00:40:42 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due to
 unknown thread type JfrRecorderThread
Message-ID: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>

Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).

I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).

Testing (in progress):

- [x] tier1 ci
- [x] tier1 ci with -XX:StartFlightRecording 
- [ ] tier5 ci

-------------

Commit messages:
 - revisit my ABC's
 - Make JfrRecorderThread known to SA

Changes: https://git.openjdk.org/jdk/pull/25960/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25960&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360312
  Stats: 25 lines in 5 files changed: 13 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25960/head:pull/25960

PR: https://git.openjdk.org/jdk/pull/25960

From sspitsyn at openjdk.org  Wed Jun 25 01:03:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 01:03:27 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <XeH49Q-pp9SxlaoI4TpirYzjxn5CXaJdlKky1sXIUi0=.b25b0a90-17b4-433b-9ef2-4a72c5eeef7b@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
 <XeH49Q-pp9SxlaoI4TpirYzjxn5CXaJdlKky1sXIUi0=.b25b0a90-17b4-433b-9ef2-4a72c5eeef7b@github.com>
Message-ID: <TYYllsafW5-JUY7gNKYXN-FpfMzBmPJ8XFEr9xXcG0c=.d544efd1-e266-48d2-a5a3-4ecb16500967@github.com>

On Tue, 24 Jun 2025 23:53:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I thought if we need some sanity test for ThreadStart event with can_generate_early_vmstart capability, but looking at the spec I see no relations between them. So it's unclear what was the purpose of the test.

The test purpose was to ensure the `ThreadStart` are posted in the early `VM_START` phase. The issue is that a few system threads are triggered to start in the early `VM_START` but there is no guaranty they are really started in that phase because of a race with the VM initializing thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002273203

From amenkov at openjdk.org  Wed Jun 25 01:14:29 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 25 Jun 2025 01:14:29 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <TYYllsafW5-JUY7gNKYXN-FpfMzBmPJ8XFEr9xXcG0c=.d544efd1-e266-48d2-a5a3-4ecb16500967@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
 <XeH49Q-pp9SxlaoI4TpirYzjxn5CXaJdlKky1sXIUi0=.b25b0a90-17b4-433b-9ef2-4a72c5eeef7b@github.com>
 <TYYllsafW5-JUY7gNKYXN-FpfMzBmPJ8XFEr9xXcG0c=.d544efd1-e266-48d2-a5a3-4ecb16500967@github.com>
Message-ID: <wYjpslNhPHtlpVaeJZT6zyQjp81RLwad4aUFboVo9dk=.40804e40-c325-4533-b470-b5ec2331688c@github.com>

On Wed, 25 Jun 2025 00:59:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > I thought if we need some sanity test for ThreadStart event with can_generate_early_vmstart capability, but looking at the spec I see no relations between them. So it's unclear what was the purpose of the test.
> 
> The test purpose was to ensure the `ThreadStart` are posted in the early `VM_START` phase. The issue is that a few system threads are triggered to start in the early `VM_START` but there is no guaranty they are really started in that phase because of a race with the VM initializing thread.

Oh, ok. So without can_generate_early_vmstart ThreadStart events for the system threads in most cases are not posted at all (as they are posted in PRIMORDIAL phase)?
Then maybe we should keep the test, but drop the requirement that the events are posted in START phase? And the test needs explanation what it does and why.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002288544

From sspitsyn at openjdk.org  Wed Jun 25 01:52:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 01:52:26 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <wYjpslNhPHtlpVaeJZT6zyQjp81RLwad4aUFboVo9dk=.40804e40-c325-4533-b470-b5ec2331688c@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
 <XeH49Q-pp9SxlaoI4TpirYzjxn5CXaJdlKky1sXIUi0=.b25b0a90-17b4-433b-9ef2-4a72c5eeef7b@github.com>
 <TYYllsafW5-JUY7gNKYXN-FpfMzBmPJ8XFEr9xXcG0c=.d544efd1-e266-48d2-a5a3-4ecb16500967@github.com>
 <wYjpslNhPHtlpVaeJZT6zyQjp81RLwad4aUFboVo9dk=.40804e40-c325-4533-b470-b5ec2331688c@github.com>
Message-ID: <5-ZEGocoQXPmWCb_3K_ikKNd9ISlfh_9f1iEtc5YlUs=.ccc32129-eb0d-4bf5-a250-07ee9e4cfe62@github.com>

On Wed, 25 Jun 2025 01:12:06 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> So without can_generate_early_vmstart ThreadStart events for the system threads in most cases are not posted at all (as they are posted in PRIMORDIAL phase)?

No threads are started in PRIMORDIAL phase they are started either in VM_START of LIVE phase.
As we can not guaranty any threads to be started in VM_START phase then the test has no verification goal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002333491

From dholmes at openjdk.org  Wed Jun 25 02:38:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 02:38:31 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <ZgF51aumDAVyAglZM6kBwLgjOzbKcRXNVWvyHTKG288=.fe6cb280-0db6-4c7d-82a3-2610a174f533@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2956079608

From dholmes at openjdk.org  Wed Jun 25 02:38:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 02:38:32 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <VD0-QRCwzdrbboyAnB1xOnpxpW0INH3rcCc9SNHcA-Q=.234c366d-6cb4-4927-afa2-e4fe6fa7fffa@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <pfYjl3ZpqaTm-qXaYFzfQCZEuAoxNt-OGPHcwxUd_dM=.e59e3b27-a08f-48b2-8162-50a28b4d9628@github.com>
 <xLVmjg1RjqCXLY0c4xFtg9NADyUakjs6pmuDywVrjhM=.50072f65-4ee4-46a4-b59a-99e3254e4d3b@github.com>
 <VD0-QRCwzdrbboyAnB1xOnpxpW0INH3rcCc9SNHcA-Q=.234c366d-6cb4-4927-afa2-e4fe6fa7fffa@github.com>
Message-ID: <kYU9C4KDeEaixuRZOuihkv46qBeN9aTZeaNiIjOYvuw=.1dc33c1f-9d4f-48dc-9ffe-fed90bf220d1@github.com>

On Tue, 24 Jun 2025 14:46:12 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > the `cls` parameter is never actually used. So while it is supposed to refer to the class you have the static method jMethodID for, there is no requirement that it actually does, and could even be null.
> 
> Not passing in the cls parameter, would be a clear user error though, right? And one that would have crashed before, because if you racingly execute bytecodes of a class that is being unloaded, things would blow up one way or another. To me it seems like the user should just pass in the class as intended and then all is good.

The point is to try and make things more robust when the user does the unexpected. As Coleen stated we are trying to handle cases where JNI code looks up a jMethodID in one place, stashes it away and then uses it elsewhere with no guarantee the class is being kept alive. I agree you would think they would have, and pass in, the original jclass reference, but the fact we don't actually use that value is not hard to determine and JNI code can take advantage of that - treating the `jMethodId` as an effective raw pointer to a method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3002494069

From dholmes at openjdk.org  Wed Jun 25 02:38:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 02:38:32 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <_f9CuTsqV-WEq5F8dLzaSFckSe3YdyUGVVTOZWdnWXQ=.4008de9c-1812-4768-aaf8-a464ab100925@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <_f9CuTsqV-WEq5F8dLzaSFckSe3YdyUGVVTOZWdnWXQ=.4008de9c-1812-4768-aaf8-a464ab100925@github.com>
Message-ID: <oP41p_djpcL0vJy0jvis8ShP40L3Qrlx73DZ08uw1DE=.158da893-3011-41c7-a8ce-aa8498d9a771@github.com>

On Tue, 24 Jun 2025 13:04:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The jmethodID table is so that jmethodID isn't a stale pointer itself and doesn't require us to hold a stale pointer, but whether it can return a stale Method* (now and before this change) is something we should figure out how it should work.

That's fine. I (per my response to Thomas) thought the new approach also closed the door on unsafe usage of the `jMethodID`, but that is not the case. It probably does close the door quite a bit in relation to current approach though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3002503846

From dholmes at openjdk.org  Wed Jun 25 02:51:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 02:51:36 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>
Message-ID: <wq12cy7G-Rf5vRpTcgJlQREWFwjuxdp8Ey4buX03xxA=.8c01d593-9593-4750-9da5-b823241d8c1a@github.com>

On Tue, 24 Jun 2025 13:25:20 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Addressed reviewer's comment

Still good.

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2956124578
PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2956125925

From sspitsyn at openjdk.org  Wed Jun 25 03:08:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 03:08:28 GMT
Subject: RFR: 8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart
 failed with Didn't get ThreadStart events in VM early start phase!
 [v3]
In-Reply-To: <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
 <RPx1A84MqYjCz7zDpqIgcP-7N9n7c8t4DoPWgbdmgAM=.1fbb10b3-a853-4484-98f6-7303fa3e2340@github.com>
Message-ID: <QBZxA2o6FAem04jPSnKHPbTnPbSckma1rnZfsuceC2M=.94988a90-03d9-4325-a45d-2d6078451d12@github.com>

On Tue, 24 Jun 2025 23:12:43 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. There is no way to fix the test so, it is being removed.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove the ModuleAwareAgents/ThreadStart test as there is no way to fix it

Alex and Chris, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25948#issuecomment-3002690451

From dholmes at openjdk.org  Wed Jun 25 04:50:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 04:50:27 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread
In-Reply-To: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
Message-ID: <-vXX2eYTSYa1uGoZpVKeI3co2ygb5tvf133u5u7lFCA=.d668d80a-f55d-4d32-b205-ed64e9a94c1a@github.com>

On Tue, 24 Jun 2025 21:15:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
> 
> Testing (in progress):
> 
> - [x] tier1 ci
> - [x] tier1 ci with -XX:StartFlightRecording 
> - [ ] tier5 ci

Would a simple forward declaration of `class JfrRecordThread` in vmStructs.cpp avoid the need to move the class definition to the header file?

Otherwise fix looks good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2956528984

From sspitsyn at openjdk.org  Wed Jun 25 05:32:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 05:32:36 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <kgRT4xZGIpcmupqC5d7sS3NiG2Gg0NevFqM_UXpYr_0=.c185619b-426a-4766-8ea7-27b4b9924b97@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <AKAlwoqY12rOJx2b6f6HHTHgsuPjDQ-88kFqjhFWujM=.afb244a8-3541-44e3-97c2-2f593ef28e19@github.com>
 <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com>
 <kgRT4xZGIpcmupqC5d7sS3NiG2Gg0NevFqM_UXpYr_0=.c185619b-426a-4766-8ea7-27b4b9924b97@github.com>
Message-ID: <1WAK-jwxvbp541uQys8DQvX0XdWJU4qp6LkqwiqJYvM=.e4adb6be-e910-4639-8836-45eac9037ab3@github.com>

On Tue, 24 Jun 2025 15:56:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I did copy this code.  I was hoping instead of class byte modifications that someone would suggest a Classfile API way to modify the class file bytes. @liach ? That way the class names don't have to be the same length.  Above seems better  code but I have to debug it now.
>
> `jdk.internal.classfile.components` has a `ClassRemapper` that may serve this purpose. It updates all internal names and occurrences in descriptors.

BTW, I've also noticed this issue with returning 0 but forgot to post my question. This suggestion from Alex looks good to me, at least, if the `ClassRemapper` is tricky to borrow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2165816599

From sspitsyn at openjdk.org  Wed Jun 25 05:35:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 05:35:28 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <LWSmmcWfalhvkPLBhGLy9jSKTOpRJMCWY7bpm0Pr1Vw=.19a18ecc-18c0-4a6e-810e-2981d8c62f37@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
 <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
 <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>
 <LWSmmcWfalhvkPLBhGLy9jSKTOpRJMCWY7bpm0Pr1Vw=.19a18ecc-18c0-4a6e-810e-2981d8c62f37@github.com>
Message-ID: <DocWuLC_rUzGXj2bR4JUE_a6ZRgzGFbSonrJbrwFRrQ=.92521ee8-7a1a-4570-9d7a-ac59d9a8f208@github.com>

On Mon, 23 Jun 2025 14:38:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> My question was because there are checks for `null` in this class:
>> 
>> public void add(Role role)
>>         throws IllegalArgumentException {
>> 
>>         if (role == null) {
>>             throw new IllegalArgumentException("Invalid parameter");
>>         }
>>         checkTypeSafe(role);
>>         super.add(role);
>>     }
>> 
>> It is kind of confusing and not clear where `null` is allowed and where it is not.
>> Should it be more consistent?
>
> Sorry, to be clearer:
> 
> javax/management/AttributeList does accept nulls being added, and should continue to do so because it might be a disruptive change.
> 
> RoleList and RoleUnresolvedList do not accept null Role/RoleUnresolved objects: they document that the add() method throws if given a null.
> 
> We don't have a need to change either behaviour about accepting nulls.
> It should be clear when reading the api docs.  It might be unclear as I am grouping together somewhat unrelated classes here.   There is no reason for a user of AttributeList to expect it behaves the same way as a RoleList.
> 
> But we do want to stop accepting alien Objects!

Okay, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2165819639

From sspitsyn at openjdk.org  Wed Jun 25 05:38:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 05:38:27 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <HIUWIhn9eUZ7YIWvDXaAyPiVymZIGDyZZx8gQSKB9_w=.df4cd850-fe93-431d-bbe3-987631294d8e@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Joe asked a question in related CSR. I'm also interested to know the answer. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3003393244

From sspitsyn at openjdk.org  Wed Jun 25 05:52:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 05:52:29 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread
In-Reply-To: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
Message-ID: <w8Ng07vK8CroY1SwMx6vlxAy0tfVfH_7xgSD2KVu0JY=.b8f5df56-802c-4a7b-aba6-272ce7b38a23@github.com>

On Tue, 24 Jun 2025 21:15:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
> 
> Testing (in progress):
> 
> - [x] tier1 ci
> - [x] tier1 ci with -XX:StartFlightRecording 
> - [ ] tier5 ci

This looks good except the copyright header update in last file.

test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

This seems to be an incorrect way to update the copyright header.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2956718918
PR Review Comment: https://git.openjdk.org/jdk/pull/25960#discussion_r2165838975

From sspitsyn at openjdk.org  Wed Jun 25 06:08:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 06:08:29 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
Message-ID: <32NU2OhUbtw0YH1mgTJIA2YH5Ba3-jrse1Vk_7ydq90=.754db6bf-85b7-489a-8f58-17fe6720c2d7@github.com>

On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
>> 
>> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
>> 
>> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   startLocalDebugee renamed to startDebugee

This cleanup looks good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25887#pullrequestreview-2956754646

From cjplummer at openjdk.org  Wed Jun 25 06:34:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 06:34:10 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
Message-ID: <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>

> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
> 
> Testing (in progress):
> 
> - [x] tier1 ci
> - [x] tier1 ci with -XX:StartFlightRecording 
> - [x] tier5 ci

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25960/files
  - new: https://git.openjdk.org/jdk/pull/25960/files/a679b236..28a97a11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25960&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25960&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25960/head:pull/25960

PR: https://git.openjdk.org/jdk/pull/25960

From cjplummer at openjdk.org  Wed Jun 25 06:34:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 06:34:10 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <-vXX2eYTSYa1uGoZpVKeI3co2ygb5tvf133u5u7lFCA=.d668d80a-f55d-4d32-b205-ed64e9a94c1a@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <-vXX2eYTSYa1uGoZpVKeI3co2ygb5tvf133u5u7lFCA=.d668d80a-f55d-4d32-b205-ed64e9a94c1a@github.com>
Message-ID: <8e1B3OlCE23T-_4_mHcJ6GIxpAAv0NNTDx8MSkZMxlA=.1046aa86-0a10-4abc-8d0a-7f1374e283a5@github.com>

On Wed, 25 Jun 2025 04:48:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Would a simple forward declaration of `class JfrRecordThread` in vmStructs.cpp avoid the need to move the class definition to the header file?

vmStructs does a sizeof(JfrRecordThread) so it needs the full class definition, not just a declaration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25960#issuecomment-3003507738

From cjplummer at openjdk.org  Wed Jun 25 06:34:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 06:34:10 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <w8Ng07vK8CroY1SwMx6vlxAy0tfVfH_7xgSD2KVu0JY=.b8f5df56-802c-4a7b-aba6-272ce7b38a23@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <w8Ng07vK8CroY1SwMx6vlxAy0tfVfH_7xgSD2KVu0JY=.b8f5df56-802c-4a7b-aba6-272ce7b38a23@github.com>
Message-ID: <opjIQfp6I1s0f4HVCqLHTlFxEimK827qZfajYAEHjQ4=.868e8210-f053-4c97-b674-622ddb3b0bcd@github.com>

On Wed, 25 Jun 2025 05:48:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix copyright
>
> test/hotspot/jtreg/serviceability/sa/ClhsdbJstackWithConcurrentLock.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> This seems to be an incorrect way to update the copyright header.

Yes, I will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25960#discussion_r2165892011

From dholmes at openjdk.org  Wed Jun 25 06:52:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 06:52:34 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
Message-ID: <nmdHOifhKy6KjmWpsv_yZDVTtgySMZ2WIjqqU2-tSd0=.d3fae2a4-5572-40f3-83d7-64f2e8d5e402@github.com>

On Wed, 25 Jun 2025 06:34:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
>> 
>> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
>> 
>> Testing (in progress):
>> 
>> - [x] tier1 ci
>> - [x] tier1 ci with -XX:StartFlightRecording 
>> - [x] tier5 ci
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2956862618

From sspitsyn at openjdk.org  Wed Jun 25 08:03:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 08:03:29 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
Message-ID: <OevKZ6QjHoV_lJYj5EqSMDZINdjGh4VSExdUL9sAx2E=.32b7dd4e-bb91-44ee-8da1-7b820a45892a@github.com>

On Wed, 25 Jun 2025 06:34:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
>> 
>> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
>> 
>> Testing (in progress):
>> 
>> - [x] tier1 ci
>> - [x] tier1 ci with -XX:StartFlightRecording 
>> - [x] tier5 ci
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2957075591

From kevinw at openjdk.org  Wed Jun 25 08:11:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 08:11:32 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
Message-ID: <lIdpZiSFwcTm2wJlWZKV_DgIplReoT6h-vjOgbVHgZY=.5a18a748-e64d-4275-9c3b-9e44e0ffe7de@github.com>

On Wed, 25 Jun 2025 06:34:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
>> 
>> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
>> 
>> Testing (in progress):
>> 
>> - [x] tier1 ci
>> - [x] tier1 ci with -XX:StartFlightRecording 
>> - [x] tier5 ci
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

Marked as reviewed by kevinw (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 200:

> 198:             " (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread," +
> 199:             " DeoptimizeObjectsALotThread, StringDedupThread, NotificationThread, ServiceThread," +
> 200:             "JfrRecorderThread, or JvmtiAgentThread)", e);

nitpicking: space?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2957100831
PR Review Comment: https://git.openjdk.org/jdk/pull/25960#discussion_r2166077918

From ayang at openjdk.org  Wed Jun 25 08:39:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 08:39:42 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v15]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <YYY-JJeecROuWdlIn4WUdgrG_CesMrVwLKP8jIS7fr0=.cadbcb7c-57a3-49c5-90d5-c1af951f3ee5@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - ... and 11 more: https://git.openjdk.org/jdk/compare/75ce44aa...7f733137

-------------

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=14
  Stats: 4371 lines in 31 files changed: 520 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From kevinw at openjdk.org  Wed Jun 25 10:06:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 10:06:13 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
Message-ID: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>

ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

-------------

Commit messages:
 - ThreadSnapshot comment
 - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited
 - 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch

Changes: https://git.openjdk.org/jdk/pull/25958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359870
  Stats: 10 lines in 4 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From alanb at openjdk.org  Wed Jun 25 10:18:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Jun 2025 10:18:27 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <h9X1bwFDN5qIlL544Xkn_XB34R49P7-oKEcg0IxPwrA=.aeb19213-9ac4-40cb-b1d8-3f48b34129da@github.com>

On Tue, 24 Jun 2025 17:00:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 184:

> 182:         if (snapshot == null) {
> 183:             return; // Terminated
> 184:         }

Would it be possible to use this instance, otherwise the thread counts will be confusing.


--- a/src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java
+++ b/src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java
@@ -178,8 +178,11 @@ private static void dumpThreads(ThreadContainer container, TextWriter writer) {
     }
 
     private static void dumpThread(Thread thread, TextWriter writer) {
-        ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
         Instant now = Instant.now();
+        ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
+        if (snapshot == null) {
+            return;  // thread terminated
+        }
         Thread.State state = snapshot.threadState();
         writer.println("#" + thread.threadId() + " "" + snapshot.threadName()
                 + "" " + (thread.isVirtual() ? "virtual " : "") + state + " " + now);
@@ -284,8 +287,9 @@ private static void dumpThreads(ThreadContainer container, JsonWriter jsonWriter
         Iterator<Thread> threads = container.threads().iterator();
         while (threads.hasNext()) {
             Thread thread = threads.next();
-            dumpThread(thread, jsonWriter);
-            threadCount++;
+            if (dumpThread(thread, jsonWriter)) {
+                threadCount++;
+            }
         }
         jsonWriter.endArray(); // threads
 
@@ -305,9 +309,12 @@ private static void dumpThreads(ThreadContainer container, JsonWriter jsonWriter
      * Write a thread to the given JSON writer.
      * @throws UncheckedIOException if an I/O error occurs
      */
-    private static void dumpThread(Thread thread, JsonWriter jsonWriter) {
+    private static boolean dumpThread(Thread thread, JsonWriter jsonWriter) {
         Instant now = Instant.now();
         ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
+        if (snapshot == null) {
+            return false;  // thread terminated
+        }
         Thread.State state = snapshot.threadState();
         StackTraceElement[] stackTrace = snapshot.stackTrace();
 
@@ -369,6 +376,7 @@ private static void dumpThread(Thread thread, JsonWriter jsonWriter) {
         }
 
         jsonWriter.endObject();
+        return true;
     }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2166358603

From kevinw at openjdk.org  Wed Jun 25 10:21:27 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 10:21:27 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
In-Reply-To: <h9X1bwFDN5qIlL544Xkn_XB34R49P7-oKEcg0IxPwrA=.aeb19213-9ac4-40cb-b1d8-3f48b34129da@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <h9X1bwFDN5qIlL544Xkn_XB34R49P7-oKEcg0IxPwrA=.aeb19213-9ac4-40cb-b1d8-3f48b34129da@github.com>
Message-ID: <M59DAnxGqO6UDdDCRpx8eUJbe8FPtvrn547L_E-tW5E=.f4e6f4cc-3497-4377-9a48-bb6dc21cb6a5@github.com>

On Wed, 25 Jun 2025 10:15:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 184:
> 
>> 182:         if (snapshot == null) {
>> 183:             return; // Terminated
>> 184:         }
> 
> Would it be possible to use this instance, otherwise the thread counts will be confusing.
> 
> 
> --- a/src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java
> +++ b/src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java
> @@ -178,8 +178,11 @@ private static void dumpThreads(ThreadContainer container, TextWriter writer) {
>      }
>  
>      private static void dumpThread(Thread thread, TextWriter writer) {
> -        ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
>          Instant now = Instant.now();
> +        ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
> +        if (snapshot == null) {
> +            return;  // thread terminated
> +        }
>          Thread.State state = snapshot.threadState();
>          writer.println("#" + thread.threadId() + " "" + snapshot.threadName()
>                  + "" " + (thread.isVirtual() ? "virtual " : "") + state + " " + now);
> @@ -284,8 +287,9 @@ private static void dumpThreads(ThreadContainer container, JsonWriter jsonWriter
>          Iterator<Thread> threads = container.threads().iterator();
>          while (threads.hasNext()) {
>              Thread thread = threads.next();
> -            dumpThread(thread, jsonWriter);
> -            threadCount++;
> +            if (dumpThread(thread, jsonWriter)) {
> +                threadCount++;
> +            }
>          }
>          jsonWriter.endArray(); // threads
>  
> @@ -305,9 +309,12 @@ private static void dumpThreads(ThreadContainer container, JsonWriter jsonWriter
>       * Write a thread to the given JSON writer.
>       * @throws UncheckedIOException if an I/O error occurs
>       */
> -    private static void dumpThread(Thread thread, JsonWriter jsonWriter) {
> +    private static boolean dumpThread(Thread thread, JsonWriter jsonWriter) {
>          Instant now = Instant.now();
>          ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
> +        if (snapshot == null) {
> +            return false;  // thread terminated
> +        }
>          Thread.State state = snapshot.threadState();
>          StackTraceElement[] stackTrace = snapshot.stackTrace();
>  
> @@ -369,6 +376,7 @@ private static void dumpThread(Thread thread, JsonWriter jsonWriter) {
>          }
>  
>          jsonWriter.endObject();
> +        return true;
>      }

Yes, will do that to fix the threadCount...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2166363495

From coleenp at openjdk.org  Wed Jun 25 11:09:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 11:09:36 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <eEavoMGCIg8ZjamlxenZot7jEo01uipeXhzeCrLIk-c=.027eb402-ac36-4614-a889-731422d0a592@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <8zcivFIhzh6QymXS119iTVwdzyufdXBaeOR4_dEjlig=.b1683573-13cb-4b40-baf3-8b609680e86f@github.com>
 <eEavoMGCIg8ZjamlxenZot7jEo01uipeXhzeCrLIk-c=.027eb402-ac36-4614-a889-731422d0a592@github.com>
Message-ID: <eIRIkjAI2Y5teYRh0rwiJsICJsjjM8iOaGGiGM7IVeg=.53e03fa0-30a6-4188-9262-4ec775f9780e@github.com>

On Tue, 24 Jun 2025 09:12:00 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> test/jtreg-ext/requires/VMProps.java line 424:
>> 
>>> 422:      * Note: Lightweight locking does not support RTM (for now).
>>> 423:      */
>>> 424:     protected String vmRTMCompiler() {
>> 
>> [JDK-8358542](https://bugs.openjdk.org/browse/JDK-8358542) exists to remove this so you would need to add that bug id to this PR. However, it seems the bug management for this has gotten completely messed up so you may need to scrap this PR and file a new bug and PR for this part.
>
> Issue added.

Since you added issue JDK-8358542, can you also remove the function under this: vmRTMCPU - that function isn't referenced anywhere either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2166447777

From alanb at openjdk.org  Wed Jun 25 11:16:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Jun 2025 11:16:46 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>
Message-ID: <Zta2hW_x2TyhfQJp_FKm4HJ79DSBfxlANNkKIpu1fkI=.53a204d7-f4d6-4708-816a-5ed34301f0cc@github.com>

On Tue, 24 Jun 2025 13:25:20 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Addressed reviewer's comment

test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 477:

> 475:     boolean shouldPin() {
> 476:         // Returns false since we never pin after we removed legacy locking.
> 477:         return traceHas(Op.PIN::contains) && false;

Are you planning to remove this method and update verifyPin, or maybe there will be a follow-on JBS issue for this cleanup?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2166459367

From duke at openjdk.org  Wed Jun 25 11:26:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 25 Jun 2025 11:26:22 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v6]
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8359437: Removed vmRTMCPU from VMProps.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25847/files
  - new: https://git.openjdk.org/jdk/pull/25847/files/02565157..6534afaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25847&range=04-05

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25847/head:pull/25847

PR: https://git.openjdk.org/jdk/pull/25847

From coleenp at openjdk.org  Wed Jun 25 11:28:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 11:28:42 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v6]
In-Reply-To: <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
Message-ID: <PdPqrDK6A2YDta-cSro2ohIGy82IOeIhasCiXloAjwo=.9b509a82-8ce6-4d4d-837c-8f5c45311a72@github.com>

On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Removed vmRTMCPU from VMProps.java

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2957771841

From duke at openjdk.org  Wed Jun 25 11:38:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 25 Jun 2025 11:38:35 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <Zta2hW_x2TyhfQJp_FKm4HJ79DSBfxlANNkKIpu1fkI=.53a204d7-f4d6-4708-816a-5ed34301f0cc@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>
 <Zta2hW_x2TyhfQJp_FKm4HJ79DSBfxlANNkKIpu1fkI=.53a204d7-f4d6-4708-816a-5ed34301f0cc@github.com>
Message-ID: <MXPOYWZAcfTLErx3yhu_OuYDaQ0TxHBsbblxEBKLxCw=.8f979999-202d-4ad0-afcd-69c28819fac7@github.com>

On Wed, 25 Jun 2025 11:13:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359437: Addressed reviewer's comment
>
> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 477:
> 
>> 475:     boolean shouldPin() {
>> 476:         // Returns false since we never pin after we removed legacy locking.
>> 477:         return traceHas(Op.PIN::contains) && false;
> 
> Are you planning to remove this method and update verifyPin, or maybe there will be a follow-on JBS issue for this cleanup?

Removal will be done in phase 2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2166498312

From kevinw at openjdk.org  Wed Jun 25 11:50:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 11:50:42 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v2]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <3i_6AJxEAX1a4dfB2lYuPRLSfF6UInmOF1KG5_PfTpA=.f54ff353-78e7-4ad8-9906-fd9a5963ea42@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  ThreadDumper thread count

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/33248d9d..e4a7b546

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=00-01

  Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From kevinw at openjdk.org  Wed Jun 25 11:53:44 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 11:53:44 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v3]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <zAaWpdmEUBSghPUCsPY1kDiq89Sleb6FBNM_OyKpdb4=.8b773064-95f0-4f52-acdb-1dd117b818fc@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Correct THROW macro

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/e4a7b546..089dcf49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From kevinw at openjdk.org  Wed Jun 25 12:02:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 12:02:11 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v4]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <ZDO-rZzpaaYoxjbZQ8MMBnO6hOSA4tCJyq36AvbUx7Y=.aa0b612d-951a-4af1-b118-682051b43815@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - newline
 - Test fails on minimal VM: require jvmti feature

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/089dcf49..0dc95941

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From per-ake.minborg at oracle.com  Wed Jun 25 09:09:42 2025
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Wed, 25 Jun 2025 09:09:42 +0000
Subject: Interest in Java based attach provider implementation?
In-Reply-To: <34520a71-a101-4973-8eaa-db2f4eef9fa4@gmx.net>
References: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
 <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
 <112cc394-b8a9-412a-9ca8-114a73994607@oracle.com>
 <34520a71-a101-4973-8eaa-db2f4eef9fa4@gmx.net>
Message-ID: <SA1PR10MB783263EFA3EB43F14BA1D2E3DA7BA@SA1PR10MB7832.namprd10.prod.outlook.com>

Hi Philippe!

Thanks for your interest and efforts in modernizing the JDK to use the FFM API to replace older code. As mentioned before, we are running an effort called "Panamization" within the JDK community to push in this direction.

Here is an example of a PR that might be helpful when writing such code: https://github.com/openjdk/jdk/pull/25546


[https://opengraph.githubassets.com/072f4c9fd78eedb780c9b704f4f6470ace3a8c466871641aa051ad542f972791/openjdk/jdk/pull/25546]<https://github.com/openjdk/jdk/pull/25546>
WIP: Panamize KQueue selector implementation by DarraghClarke ? Pull Request #25546 ? openjdk/jdk<https://github.com/openjdk/jdk/pull/25546>
This is a draft to hopefully facilitate some discussions and feedback about the panamization of Kqueue This is based on the work that was previously shared in #22307 , The main change since then is...
github.com
I am willing to help/sponsor your efforts. Maybe we could start with 3. kill, which seems to be a low-hanging fruit. Making this consistent with the above PR would be a good first step.

I will contact you directly via the above email.

Best, Per Minborg

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Philippe Marschall <kustos at gmx.net>
Sent: Tuesday, June 24, 2025 4:30 PM
To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Interest in Java based attach provider implementation?

Hello

Since the audience has been expanded let me summarize what would be
needed to make jdk.attach free of JNI on Unix (AIX, Linux, macOS).
jdk.attach currently uses JNI for four different things.

1. reading and writing unix domain sockets
2. accessing uid, guid and permissions of a file
3. sending SIGQUIT to an arbitrary PID, including self in the case of
self attach
4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid}) on macOS

For 1. and 2. there are already supported Java based APIs and I have
patches in case somebody is willing to sponsor this work / open a JIRA.

3. kill(SIGQUIT)

This can be done quite easily using FFM as the signature of kill() is
quite simple. The signature and values are the same an Linux and macOS
and I assume AIX as well, but I don't have access to a machine to
verify. Overlap with existing code is with ProcessHandleImpl.destroy0
which sends SIGKILL or SIGTERM to a PID but performs additional checks.
So an API to send a signal to a PID would be needed. It is my
understanding that jdk.internal.misc.Signal only supports sending signal
to self.

4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid})

This is more complicated as the kinfo_proc and extern_proc structs are
quite large. jextract is the easiest way to come up with the
definitions. However the amount of generated code is quite large even
after filtering. The generated code can be further cut down using manual
editing. I have not yet looked into replacing not needed struct fields
with padding. To the best of my knowledge jextract hasn't the been
included into the JDK build.
Overlap here is in ProcessHandleImpl_macosx.c with the functions
os_getParentPidAndTimings and getUID but they access different fields of
extern_proc.
Honestly here I'm not sure why this check is needed at all. The
reasoning given for the check in VirtualMachineImpl.c would in my option
apply to Linux and AIX as well but this check is not performed there.
Removing this check from the macOS implementation would obviously be the
easiest.

I can't speak for Windows as I'm not familiar enough with Windows APIs.

Cheers
Philippe


On 19.06.25 14:40, Magnus Ihse Bursie wrote:
> Hi Philippe,
>
> There is an ongoing effort about "Panamization" (that is, adapting it to
> use FFM instead of JNI) of native code in the JDK in general. This is
> discussed on the core-libs-dev mailing list. I've cc:ed them. I think it
> would be beneficial if you coordinate your efforts with the Panamization
> effort.
>
> /Magnus
>
>
> On 2025-06-15 17:43, Philippe Marschall wrote:
>> Hello
>>
>> I further pursued the approach
>>
>> - Rebased the Linux implementation [1], implemented the permission
>> check using JSR 203 and the Unix domain sockets using JEP 380.
>> - Applied the same changes to the AIX implementation [2].
>> - Switched Linux to an FFM based kill implementation [3], completely
>> getting rid of JNI.
>> -  Updated the macOS implementation [4], implemented the permission
>> check using JSR 203 and the Unix domain sockets using JEP 380.
>> - Switched macOS to an FFM based kill and sysctl implementation [5],
>> completely getting rid of JNI.
>>
>> I ran the serviceability test suite on Linux and macOS and it passes.
>> I manually verified that I can attach to JVMs using local builds.
>>
>> I could not test on AIX.
>>
>>  [1] https://github.com/marschall/jdk/
>> commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
>>  [2] https://github.com/marschall/jdk/
>> commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
>>  [3] https://github.com/marschall/jdk/
>> commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559
>>  [4] https://github.com/marschall/jdk/
>> commit/93372a124eca6078fde5597c2498b381a4ef5dfa
>>  [5] https://github.com/marschall/jdk/commit/
>> c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b
>>
>> Cheers
>> Philippe
>>
>> On 20.04.22 22:13, Philippe Marschall wrote:
>>> Hello
>>>
>>> I hope this is the right mailing list. I recently had a look at the
>>> Linux attach provider implementation and could not help but noticing
>>> that a large part, if not all of it, could be replaced with Java.
>>> Besides getting rid of the C code this should allow us to unify the AIX,
>>> Linux and macOS implementations under a single Unix implementation.
>>>
>>> The permission check can be implemented using JSR 203 [1] to access uid,
>>> gid and file mode and using jdk.internal.misc.VM to get the euid and
>>> egid.
>>>
>>> Reading and writing to Unix domain sockets can be done through JEP
>>> 380 [2].
>>>
>>> Sending SIGQUIT to a process could in theory done through JEP 102 [3]
>>> however sending SIGQUIT to self is currently blocked. This is required
>>> for the self attach mechanism. There a very small C function is still
>>> needed for now, this is hopefully portable.
>>>
>>> I did a small prototype [4]. The tier1 suite runs and I can attach to a
>>> local JVM.
>>>
>>> The overhead will likely be a bit higher as we go through more JDK
>>> abstractions.
>>>
>>>   [1] https://jcp.org/en/jsr/detail?id=203
>>>   [2] https://openjdk.java.net/jeps/380
>>>   [3] https://openjdk.java.net/jeps/102
>>>   [4]
>>> https://github.com/marschall/jdk/
>>> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc
>>>
>>> Cheers
>>> Philippe
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250625/36390b76/attachment-0001.htm>

From alanb at openjdk.org  Wed Jun 25 12:33:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Jun 2025 12:33:28 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v4]
In-Reply-To: <ZDO-rZzpaaYoxjbZQ8MMBnO6hOSA4tCJyq36AvbUx7Y=.aa0b612d-951a-4af1-b118-682051b43815@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ZDO-rZzpaaYoxjbZQ8MMBnO6hOSA4tCJyq36AvbUx7Y=.aa0b612d-951a-4af1-b118-682051b43815@github.com>
Message-ID: <-NYiRIpr54nXkuUcOJ0O1zr_xo5PtSULMbMKsxjoYUY=.4a44e324-584c-4ff9-8d24-8884563b07e9@github.com>

On Wed, 25 Jun 2025 12:02:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - newline
>  - Test fails on minimal VM: require jvmti feature

src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 317:

> 315:         ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
> 316:         if (snapshot == null) {
> 317:             return false; // Terminated

This is okay. Do you mind change these two to say "thread terminated"?  We will eventually replace this as it's only a temporary that this scenario is even possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2166601207

From kevinw at openjdk.org  Wed Jun 25 13:02:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 13:02:03 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - comment update
 - comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/0dc95941..d8143785

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=03-04

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From kevinw at openjdk.org  Wed Jun 25 13:02:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 13:02:03 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v4]
In-Reply-To: <-NYiRIpr54nXkuUcOJ0O1zr_xo5PtSULMbMKsxjoYUY=.4a44e324-584c-4ff9-8d24-8884563b07e9@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ZDO-rZzpaaYoxjbZQ8MMBnO6hOSA4tCJyq36AvbUx7Y=.aa0b612d-951a-4af1-b118-682051b43815@github.com>
 <-NYiRIpr54nXkuUcOJ0O1zr_xo5PtSULMbMKsxjoYUY=.4a44e324-584c-4ff9-8d24-8884563b07e9@github.com>
Message-ID: <MW4TrbGrq5wWIeqigL33NRa1dPbgFbXXfJIeOmsaxw4=.32d93e57-c07e-4131-befc-46eb6d164e8d@github.com>

On Wed, 25 Jun 2025 12:30:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - newline
>>  - Test fails on minimal VM: require jvmti feature
>
> src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 317:
> 
>> 315:         ThreadSnapshot snapshot = ThreadSnapshot.of(thread);
>> 316:         if (snapshot == null) {
>> 317:             return false; // Terminated
> 
> This is okay. Do you mind change these two to say "thread terminated"?  We will eventually replace this as it's only a temporary that this scenario is even possible.

Sure!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2166653464

From mbaesken at openjdk.org  Wed Jun 25 14:14:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 25 Jun 2025 14:14:39 GMT
Subject: RFR: 8360518: Docker tests do not work when asan is configured
Message-ID: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>

When the address sanitizer ASAN is configured, we run into errors in the docker tests.
Example hotspot/jtreg/containers/docker/DockerBasicTest.java :

[STDOUT]
/jdk/bin/java: error while loading shared libraries: libasan.so.8: cannot open shared object file: No such file or directory

Reason is that the asan-enabled binaries need additional dependencies and those are not available in the current docker/container setups.
Maybe we should skip those tests when asan is enabled.

-------------

Commit messages:
 - JDK-8360518

Changes: https://git.openjdk.org/jdk/pull/25980/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25980&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360518
  Stats: 23 lines in 23 files changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25980.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25980/head:pull/25980

PR: https://git.openjdk.org/jdk/pull/25980

From rkennke at openjdk.org  Wed Jun 25 15:46:29 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 25 Jun 2025 15:46:29 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129 [v2]
In-Reply-To: <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
 <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
Message-ID: <txyPeie-fdCgM7fNO_3pkcAQRYNHIHQDvG_BwS_fNWY=.f333050f-4131-4144-a6a7-1ad53ad9687c@github.com>

On Tue, 24 Jun 2025 17:48:56 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Please review a jstat test-only fix.
>> 
>> 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
>> 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented by '-'.
>> 
>> Modified tests pass.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8279005
>  - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

Looks reasonable to me. Thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25951#pullrequestreview-2958715845

From phh at openjdk.org  Wed Jun 25 15:55:33 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 25 Jun 2025 15:55:33 GMT
Subject: RFR: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129 [v2]
In-Reply-To: <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
 <tpGdxmJT2MYJeKaLaCt3e7pw1RVLIxcXFbQYNRcHMdA=.c40c646c-4d31-45be-83a3-1f1f73d06c1b@github.com>
Message-ID: <z0HRfMJShD0DoVE8K7iw0Eq7Dt3Eh58WKoe9cIO2V7Q=.5e7b2f2b-f36d-43c6-bac1-07d1659dda86@github.com>

On Tue, 24 Jun 2025 17:48:56 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Please review a jstat test-only fix.
>> 
>> 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
>> 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented by '-'.
>> 
>> Modified tests pass.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8279005
>  - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

Thanks, Roman!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25951#issuecomment-3005289084

From phh at openjdk.org  Wed Jun 25 15:55:34 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 25 Jun 2025 15:55:34 GMT
Subject: Integrated: 8279005: sun/tools/jstat tests do not check for test case
 exit codes after JDK-8245129
In-Reply-To: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
References: <Tj_fOnLw31fuOLg9sbQOoTTykqE6PWeOz75Qp2aJ-Fg=.849d523e-95b2-4d83-b766-a2dd29f6e311@github.com>
Message-ID: <h5DCyNQ2UrIiuKLre9A2ym538PZc8O0n9YmD1RVI4Dc=.4dff2185-fd46-4b27-af45-46004d4446c4@github.com>

On Tue, 24 Jun 2025 13:48:02 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Please review a jstat test-only fix.
> 
> 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing.
> 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used) / capacity), see src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options, search for "gcutil". G1, ZGC, and Shenandoah may return zero capacity for any or all of survivor spaces, eden, old gen, metaspace, and compressed class space, leading to an occupancy result represented by '-'.
> 
> Modified tests pass.

This pull request has now been integrated.

Changeset: c90c31b0
Author:    Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c90c31b07ef64eca65be5018a7757b960552f88a
Stats:     76 lines in 16 files changed: 60 ins; 0 del; 16 mod

8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

Reviewed-by: cjplummer, rkennke

-------------

PR: https://git.openjdk.org/jdk/pull/25951

From jlu at openjdk.org  Wed Jun 25 17:01:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 17:01:42 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
 <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
Message-ID: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>

On Wed, 25 Jun 2025 00:27:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
>> 
>>> 47: .Principal.=\t????\u0020
>>> 48: .Public.Credential.=\t??????:\u0020
>>> 49: .Private.Credential.=\t??????:\u0020
>> 
>> Why aren't the 2 lines above updated like in lines 46 and 47?
>
> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.
> 
> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167196792

From achung at openjdk.org  Wed Jun 25 17:08:20 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 17:08:20 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - update majorticks translation
 - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
 - fix colon in chinese security.properties file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/97f3fe37..67990651

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=04-05

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From kevinw at openjdk.org  Wed Jun 25 17:09:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:09:45 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object [v2]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <xrWAZjmBevHlyEXToiNZIjLouh7cOVvvpKS1XJVCq0I=.2d7f7b87-9210-4fd4-8a64-2805f466216d@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - fewer checkTypeSafe calls in RoleList and RoleUnresolvedList
 - Merge remote-tracking branch 'upstream/master' into 8359809_AttributeList_stricter
 - test/jdk/javax/management/generified/ListTypeCheckTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/50904f10..afb05434

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=00-01

  Stats: 9942 lines in 385 files changed: 3586 ins; 3841 del; 2515 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

PR: https://git.openjdk.org/jdk/pull/25856

From kevinw at openjdk.org  Wed Jun 25 17:09:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:09:45 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <T1j2j84OBTnLTE4qzNqU1WTim3LhBoBN7Abtnf_uYfI=.f48a8cab-f957-415d-9d80-9723f0347c65@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

I will update the CSR to clarify/answer the questions.

I've updated the PR to remove a few checkTypeSafe() calls: they are generally wanted when we add an Object or Collection, but not needed in e.g. an add(Role) method that specifically takes the type that we want.  This is why there are api doc additions for the overridden methods that take Object or Collection, and not for the non-overridden add methods that take a specific type (they don't check the type and throw).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3005521578

From achung at openjdk.org  Wed Jun 25 17:14:30 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 17:14:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
 <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
 <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>
Message-ID: <CMnvjWZDePPSAZ69wSOKZLnscDx2R5vNhJAw1OkZTi8=.c81ae441-6667-41df-8e84-2eeec2fb3d15@github.com>

On Wed, 25 Jun 2025 16:59:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.
>> 
>> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.
>
> If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced.

There's more full width colons spread around in different properties files and I think the translation team just revisits lines and decides to change the colon, so these changes look a bit random to us. I've updated these specific colons to full width for now but I think it might be better to just let the translation team update them for each drop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167222866

From kevinw at openjdk.org  Wed Jun 25 17:28:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:28:11 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v3]
In-Reply-To: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
Message-ID: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>

> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
> 
> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
> 
> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  more comments!

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25758/files
  - new: https://git.openjdk.org/jdk/pull/25758/files/6f28e857..48c46627

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25758&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25758&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25758.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25758/head:pull/25758

PR: https://git.openjdk.org/jdk/pull/25758

From kevinw at openjdk.org  Wed Jun 25 17:28:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:28:13 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v2]
In-Reply-To: <xiUjG--xMPf_APiSSqHujEr5Wji7UnaUhtwrbXmbj-Q=.05e40d15-324c-4589-b386-affa62c23786@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
 <xiUjG--xMPf_APiSSqHujEr5Wji7UnaUhtwrbXmbj-Q=.05e40d15-324c-4589-b386-affa62c23786@github.com>
Message-ID: <32flfDhWgDdP5fZ23Vb9Dw8x65BwjMMRAHxOZFugcuI=.7f838402-2f11-4e7c-8f9c-6875c95fe435@github.com>

On Fri, 20 Jun 2025 17:05:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
>>  - spelling
>>  - Exception name
>>  - whitespace
>>  - whitespace
>>  - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization
>
> src/java.management/share/classes/javax/management/ImmutableDescriptor.java line 141:
> 
>> 139:             bad = true;
>> 140:         if (!bad) {
>> 141:             hashCode = -1; // Force recalculation
> 
> Nit: Would it make sense to add same comment to the lines: 445, 452,473, 493?

Sure, done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25758#discussion_r2167248301

From cjplummer at openjdk.org  Wed Jun 25 17:31:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 17:31:47 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v3]
In-Reply-To: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
Message-ID: <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>

> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
> 
> Testing (in progress):
> 
> - [x] tier1 ci
> - [x] tier1 ci with -XX:StartFlightRecording 
> - [x] tier5 ci

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  add missing space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25960/files
  - new: https://git.openjdk.org/jdk/pull/25960/files/28a97a11..8de19276

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25960&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25960&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25960/head:pull/25960

PR: https://git.openjdk.org/jdk/pull/25960

From cjplummer at openjdk.org  Wed Jun 25 17:31:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 17:31:47 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v2]
In-Reply-To: <lIdpZiSFwcTm2wJlWZKV_DgIplReoT6h-vjOgbVHgZY=.5a18a748-e64d-4275-9c3b-9e44e0ffe7de@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <lHUAappKJegWSxLo0t61Pbs6usFsnRDEK_s56n2cwIk=.367c1028-e3f4-4b36-a9ec-63c8cdf3c606@github.com>
 <lIdpZiSFwcTm2wJlWZKV_DgIplReoT6h-vjOgbVHgZY=.5a18a748-e64d-4275-9c3b-9e44e0ffe7de@github.com>
Message-ID: <RWSqevdTlvEq5mIXKWQcArh6OUhyP_RGN_uHSNwFZQs=.b772fc4e-054a-4a55-92fb-043a985e4957@github.com>

On Wed, 25 Jun 2025 08:07:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix copyright
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 200:
> 
>> 198:             " (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread," +
>> 199:             " DeoptimizeObjectsALotThread, StringDedupThread, NotificationThread, ServiceThread," +
>> 200:             "JfrRecorderThread, or JvmtiAgentThread)", e);
> 
> nitpicking: space?

Good catch. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25960#discussion_r2167253978

From cjplummer at openjdk.org  Wed Jun 25 17:48:28 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 17:48:28 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v3]
In-Reply-To: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
Message-ID: <ymJG6feIs-vy8g5HGodPikDxcIyR3BfjN7V04DSAF6U=.8a6ba3b8-09dd-4893-8340-b20abbb4e54c@github.com>

On Wed, 25 Jun 2025 17:28:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments!

Looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25758#pullrequestreview-2959116228

From dcubed at openjdk.org  Wed Jun 25 17:51:35 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Jun 2025 17:51:35 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <WD1IpKrax6v1JfX1OECFKacNy1GYU_Lwk0wiYAPI49g=.4a2d116b-0974-4ef6-b81c-71fa20f4013e@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

I've made another pass through this PR. Just a few more nits.

src/hotspot/share/oops/instanceKlass.cpp line 2481:

> 2479: 
> 2480: // Make a jmethodID for all methods in this class.
> 2481: // This makes getting all method ids much, much faster with classes with more than 8

Perhaps:

// Make a jmethodID for all methods in this class. This makes getting
// all method ids much, much faster with classes with more than 8


for a better looking flow.

src/hotspot/share/oops/instanceKlass.cpp line 4279:

> 4277: // This nulls out jmethodIDs for all obsolete methods in the previous version of the 'klass'.
> 4278: // These obsolete methods only exist in the previous version and we're about to delete the memory for them.
> 4279: // The jmethodID for these are deallocated when we unload the class, so this doesn't remove them from the table.

nit typo: s/jmethodID/jmethodIDs/

src/hotspot/share/oops/jmethodIDTable.cpp line 190:

> 188:   // - multiple redefined versions may share jmethodID slots and if a method
> 189:   //   has already been rewired to a newer version we could be clearing reference
> 190:   //   to a still existing method instance.

Perhaps:

  //   has already been rewired to a newer version we could be clearing he
  //   reference to a still existing method instance.

src/hotspot/share/runtime/mutexLocker.cpp line 236:

> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
> 235: 
> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1);    // used for creating jmethodIDs locks HandshakeState_lock

Perhaps:

  MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1);    // used for creating jmethodIDs, can lock HandshakeState_lock which is at nosafepoint

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2958999974
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2167214224
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2167231725
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2167249362
PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2167284891

From dcubed at openjdk.org  Wed Jun 25 17:51:36 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Jun 2025 17:51:36 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <F3hIv3kNRwezM0Vm_E4NfrCU-JlNMVldvMGhDHwvEhU=.15957c17-a97e-47de-a855-33cc97b675b3@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <blJ85J1ZwaCY7BwqRYkxJQ-IYGCN4VJP26anQkIvkvM=.d0a58217-9a95-41e9-982c-5c132a4eefe9@github.com>
 <F3hIv3kNRwezM0Vm_E4NfrCU-JlNMVldvMGhDHwvEhU=.15957c17-a97e-47de-a855-33cc97b675b3@github.com>
Message-ID: <YmDuQkSqHW8IfcEutZGRJEVZ5yGSdQrK8US-Q5kZEo8=.a029ceeb-7013-41cb-ae3e-94f22546231e@github.com>

On Wed, 18 Jun 2025 11:59:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/jmethodIDTable.hpp line 31:
>> 
>>> 29: #include "memory/allocation.hpp"
>>> 30: 
>>> 31: // Class for associating Method with jmethodID
>> 
>> nit typo: please add an ending period to the comment.
>
> fixed.

Hmmm... I'm still not seeing the ending period...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2167251132

From naoto at openjdk.org  Wed Jun 25 17:53:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jun 2025 17:53:41 GMT
Subject: RFR: 8360554: Use the title from the JSON RFC for the @spec tag
Message-ID: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>

A minor doc fix. Avoiding @spec reference clash in the doc build

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25985/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25985&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360554
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25985/head:pull/25985

PR: https://git.openjdk.org/jdk/pull/25985

From coleenp at openjdk.org  Wed Jun 25 18:06:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 18:06:45 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v4]
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: <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@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:

  Use ClassFile API to replace the class name.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/ed342127..b0fe16c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=02-03

  Stats: 54 lines in 1 file changed: 15 ins; 38 del; 1 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 dcubed at openjdk.org  Wed Jun 25 18:17:38 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Jun 2025 18:17:38 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <Bp23UdvEu6o16opt2v6eqhQYlsr_GD3IhxFqda_Z9UE=.77b49931-9151-47ba-92f2-e7402d8348dc@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Another way to look at the safety of the new mechanism is to
consider the use of jmethodIDs from the `AsyncGetCallTrace` API:


src/hotspot/share/prims/forte.cpp:

108 2025.06.25 12:09:14 $ cat /tmp/fred
// Forte Analyzer AsyncGetCallTrace() entry point. Currently supported
// on Linux X86, Solaris SPARC and Solaris X86.
//
// Async-safe version of GetCallTrace being called from a signal handler
// when a LWP gets interrupted by SIGPROF but the stack traces are filled
// with different content (see below).
//
// This function must only be called when JVM/TI
// CLASS_LOAD events have been enabled since agent startup. The enabled
// event will cause the jmethodIDs to be allocated at class load time.
// The jmethodIDs cannot be allocated in a signal handler because locks
// cannot be grabbed in a signal handler safely.
//
// void (*AsyncGetCallTrace)(ASGCT_CallTrace *trace, jint depth, void* ucontext)
//
// Called by the profiler to obtain the current method call stack trace for
// a given thread. The thread is identified by the env_id field in the
// ASGCT_CallTrace structure. The profiler agent should allocate a ASGCT_CallTrace
// structure with enough memory for the requested stack depth. The VM fills in
// the frames buffer and the num_frames field.
//
// Arguments:
//
//   trace    - trace data structure to be filled by the VM.
//   depth    - depth of the call stack trace.
//   ucontext - ucontext_t of the LWP
//
// ASGCT_CallTrace:
//   typedef struct {
//       JNIEnv *env_id;
//       jint num_frames;
//       ASGCT_CallFrame *frames;
//   } ASGCT_CallTrace;
//
// Fields:
//   env_id     - ID of thread which executed this trace.
//   num_frames - number of frames in the trace.
//                (< 0 indicates the frame is not walkable).
//   frames     - the ASGCT_CallFrames that make up this trace. Callee followed by callers.
//
//  ASGCT_CallFrame:
//    typedef struct {
//        jint lineno;
//        jmethodID method_id;
//    } ASGCT_CallFrame;
//
//  Fields:
//    1) For Java frame (interpreted and compiled),
//       lineno    - bci of the method being executed or -1 if bci is not available
//       method_id - jmethodID of the method being executed
//    2) For native method
//       lineno    - (-3)
//       method_id - jmethodID of the method being executed


The `AsyncGetCallTrace` API returns jmethodIDs without explicitly
associated jclass references. The `AsyncGetCallTrace` API relies on
JVM/TI CLASS_LOAD events to have been enabled since agent startup for
jmethodID creation. Implicit in that requirement is the agent keeping a
jclass reference for each CLASS_LOAD event so that the class cannot be
unloaded while the data returned by `AsyncGetCallTrace` is processed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3005716494

From dcubed at openjdk.org  Wed Jun 25 18:25:33 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Jun 2025 18:25:33 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
Message-ID: <Z4qy6p_W_4UBPa2ecsgAeotaOsJ08auGivMX4tLpb-c=.7f2acadb-e9e8-442a-8191-754b03c718e8@github.com>

On Fri, 20 Jun 2025 20:41:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the test

Ping @jbachorik for discussions about the safety of jmethodIDs...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3005733626

From lmesnik at openjdk.org  Wed Jun 25 18:29:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Jun 2025 18:29:36 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v6]
In-Reply-To: <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
Message-ID: <L_Nr16VPeLJ3qbmJy1Hpv8oKdtzy7TLE63nr46Zpm6c=.de9b3649-f03c-4bc2-b90f-953ccf68dbe1@github.com>

On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Removed vmRTMCPU from VMProps.java

Thanks for addressing feedback.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2959215575

From liach at openjdk.org  Wed Jun 25 18:52:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Jun 2025 18:52:30 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v4]
In-Reply-To: <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com>
Message-ID: <Q0hfIzFs9WL1tnROo8hDYYu_VawKI0BZAxXFrT-zYr4=.2d895a0e-3d19-4608-8e62-666b60f4c64f@github.com>

On Wed, 25 Jun 2025 18:06:45 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:
> 
>   Use ClassFile API to replace the class name.

test/lib/RedefineClassHelper.java line 95:

> 93:         ClassDesc newClassDesc = ClassDesc.of(newClassName);
> 94:         byte[] newBytes = ClassFile.of().build(newClassDesc,
> 95:             classBuilder -> {

Can replace this lambda with `classModel::forEach` method reference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167390696

From fbredberg at openjdk.org  Wed Jun 25 19:00:38 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 25 Jun 2025 19:00:38 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v6]
In-Reply-To: <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
Message-ID: <qaWPtJs6UG68aVKHXqL16kwpnpz7rdA9JYJx2XPXdA4=.cecdbec3-9295-4334-8d84-ccccff552b0e@github.com>

On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Removed vmRTMCPU from VMProps.java

Great work, and thanks for bringing this over the finishing line.

-------------

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2959309747

From kevinw at openjdk.org  Wed Jun 25 19:03:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 19:03:28 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v3]
In-Reply-To: <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>
Message-ID: <VmbflOYy_foNt5B37D_lwydVJsyrVuiz3BEBuSVb8qs=.2e126d93-bbc0-4dc2-a0fc-0782e4fd0112@github.com>

On Wed, 25 Jun 2025 17:31:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
>> 
>> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
>> 
>> Testing (in progress):
>> 
>> - [x] tier1 ci
>> - [x] tier1 ci with -XX:StartFlightRecording 
>> - [x] tier5 ci
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing space

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2959316852

From sspitsyn at openjdk.org  Wed Jun 25 19:24:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 19:24:32 GMT
Subject: Integrated: 8225354:
 serviceability/jvmti/ModuleAwareAgents/ThreadStart failed with Didn't get
 ThreadStart events in VM early start phase!
In-Reply-To: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
References: <4dQbXXrIS6xqUx5L2_uxTiqXPMHs34g-iAHnY5E9NDM=.6c57a673-9ab3-48e4-8680-004231509d21@github.com>
Message-ID: <Lqc5B7-vs4_EtpzxumsXb08idgltOKbyVols7GwHIwE=.7cbe69ce-6b96-4c5a-a3fe-a2cfe520e137@github.com>

On Tue, 24 Jun 2025 06:31:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test incorrectly expects that some system threads must be started in the `early JVMTI_PHASE_START` phase. However, there is a race here and it is possible that the `JVMTI_PHASE_LIVE` phase is reached before any system thread has been started. There is no way to fix the test so, it is being removed.

This pull request has now been integrated.

Changeset: 52526080
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52526080bae4fb69172d8c87403510aa4d3c8942
Stats:     230 lines in 3 files changed: 0 ins; 230 del; 0 mod

8225354: serviceability/jvmti/ModuleAwareAgents/ThreadStart failed with Didn't get ThreadStart events in VM early start phase!

Reviewed-by: amenkov, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/25948

From amenkov at openjdk.org  Wed Jun 25 20:21:29 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 25 Jun 2025 20:21:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
Message-ID: <rBzRyzVF9QUK-jj8L86LsiOudR29CQvftn-Lib34STM=.ea48cb42-5664-4c06-b592-f46efeee9743@github.com>

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2959538506

From achung at openjdk.org  Wed Jun 25 20:22:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 20:22:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
Message-ID: <Bot3EolwZjhUb3m62TbiB2D7LtowSu6VLXRIBmM2XfI=.92f0274b-629b-4b02-b25e-ecb71ff7f3c8@github.com>

On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update majorticks translation
>  - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
>  - fix colon in chinese security.properties file

Currently running tests and everything looks green so far, @aivanov-jdk @sormuras do the German localizations look fine?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-3006029100

From coleenp at openjdk.org  Wed Jun 25 20:37:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 20:37:28 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v2]
In-Reply-To: <1WAK-jwxvbp541uQys8DQvX0XdWJU4qp6LkqwiqJYvM=.e4adb6be-e910-4639-8836-45eac9037ab3@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <d2dy5AlzqOLGnYd8z3ih1ng79TTvAU9I-156HYm4WAo=.2d1d451a-0086-4b16-b23c-f7606bb7688a@github.com>
 <AKAlwoqY12rOJx2b6f6HHTHgsuPjDQ-88kFqjhFWujM=.afb244a8-3541-44e3-97c2-2f593ef28e19@github.com>
 <1zzIHXPvss5McCGoZ7FoZLbI6_myMc88RgbL6Qsy7vA=.f5b038f3-c677-4855-aa9d-6e853e58f7f8@github.com>
 <kgRT4xZGIpcmupqC5d7sS3NiG2Gg0NevFqM_UXpYr_0=.c185619b-426a-4766-8ea7-27b4b9924b97@github.com>
 <1WAK-jwxvbp541uQys8DQvX0XdWJU4qp6LkqwiqJYvM=.e4adb6be-e910-4639-8836-45eac9037ab3@github.com>
Message-ID: <Z1oelMrYNWV3w6Y_imY7MNlJR4L-lVZOthm4qFvw_6U=.c98625a8-60e8-402e-a690-cc5f2d2603a1@github.com>

On Wed, 25 Jun 2025 05:30:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> `jdk.internal.classfile.components` has a `ClassRemapper` that may serve this purpose. It updates all internal names and occurrences in descriptors.
>
> BTW, I've also noticed this issue with returning 0 but forgot to post my question. This suggestion from Alex looks good to me, at least, if the `ClassRemapper` is tricky to borrow.

ClassRemapper is a nice way to do this but it requires all the tests and the test jar build to use @modules to access it, so I chose a different way with the ClassFile API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167581218

From coleenp at openjdk.org  Wed Jun 25 20:43:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 20:43:17 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v5]
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: <vac-9kW4rzGynJbvjIiGY3Cvju-FdQMKQvPZWbuieb4=.3f8def19-199e-4f7c-a8f7-21759a987fb4@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:

  Update test/lib/RedefineClassHelper.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/b0fe16c9..a8ed67c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 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 25 20:43:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 20:43:17 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v4]
In-Reply-To: <Q0hfIzFs9WL1tnROo8hDYYu_VawKI0BZAxXFrT-zYr4=.2d895a0e-3d19-4608-8e62-666b60f4c64f@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com>
 <Q0hfIzFs9WL1tnROo8hDYYu_VawKI0BZAxXFrT-zYr4=.2d895a0e-3d19-4608-8e62-666b60f4c64f@github.com>
Message-ID: <7j7Xdx2EvvrB9TPVAy-kWwFIpG-kdPiSPCgOdQ5ahU8=.20d49ce8-98a2-446d-9ae4-4d16fdea52ae@github.com>

On Wed, 25 Jun 2025 18:50:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use ClassFile API to replace the class name.
>
> test/lib/RedefineClassHelper.java line 95:
> 
>> 93:         ClassDesc newClassDesc = ClassDesc.of(newClassName);
>> 94:         byte[] newBytes = ClassFile.of().build(newClassDesc,
>> 95:             classBuilder -> {
> 
> Can replace this lambda with `classModel::forEach` method reference.

Thanks for the suggestion!  Testing now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167589887

From liach at openjdk.org  Wed Jun 25 20:43:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 25 Jun 2025 20:43:18 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v4]
In-Reply-To: <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com>
Message-ID: <Iv1KyPymicKbd-xgsiDvsY-X9lDbVw-gEeHd-BKeR_g=.e5566a29-1caa-4e2a-a11e-44ee5208b31d@github.com>

On Wed, 25 Jun 2025 18:06:45 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:
> 
>   Use ClassFile API to replace the class name.

test/lib/RedefineClassHelper.java line 99:

> 97:                     classBuilder.with(ce);
> 98:                 }
> 99:             });

Suggestion:

        byte[] newBytes = ClassFile.of().build(newClassDesc, classModel::forEach);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2167585017

From dholmes at openjdk.org  Wed Jun 25 20:51:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 20:51:30 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
Message-ID: <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

Something still bugging me about this one. From JBS it looked to me like we were dealing with a virtual thread but your change is for the non-virtual thread. And Alan says something about this only being possible due to a temporary condition. So I'm still unclear exactly what the problem is, or why it appeared. Where does the initial "thread" argument come from in the Java code? Is it the one that has terminated, if so why is there not an `isAlive()` check somewhere?

And how does this lead to the bad oop?

src/hotspot/share/services/threadService.cpp line 1477:

> 1475:     java_thread = java_lang_Thread::thread(thread_h());
> 1476:     if (java_thread == nullptr) {
> 1477:         return nullptr; // thread terminated

If you return here what does that mean for the null check at line 1483? Is that code now dead?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2959619173
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2167605967

From coleenp at openjdk.org  Wed Jun 25 21:00:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 25 Jun 2025 21:00:15 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
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: <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@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:

  Made it even shorter.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/a8ed67c0..3285f4d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 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 kevinw at openjdk.org  Wed Jun 25 21:04:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 21:04:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
Message-ID: <g8EOHsnKCax7aGhcJrVELQTzTDTaiqNdZ_uPp0Zk1iQ=.75f5891a-ba57-428c-89fa-bae6ed922051@github.com>

On Wed, 25 Jun 2025 20:48:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - comment update
>>  - comment update
>
> src/hotspot/share/services/threadService.cpp line 1477:
> 
>> 1475:     java_thread = java_lang_Thread::thread(thread_h());
>> 1476:     if (java_thread == nullptr) {
>> 1477:         return nullptr; // thread terminated
> 
> If you return here what does that mean for the null check at line 1483? Is that code now dead?

Here, we have this extra null check when is_virtual is false.  If not is_virtual, we really need a java_thread, or give up.
Down at 1483 we might have have is_virtual true, and we also may have found a java_thread, so I think we need both checks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2167627054

From jlu at openjdk.org  Wed Jun 25 21:19:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:19:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
Message-ID: <7w3okXKFhjzXb1zG6J-pfS1skbQqOsmKnt9Wpxap83o=.1fb9f308-b219-4acb-9b75-8de05c43055d@github.com>

On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update majorticks translation
>  - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
>  - fix colon in chinese security.properties file

Overall looks correct to me, and it seems you addressed all of the suggestions left by other reviewers. I skimmed most of the files for any glaring issues and also spot checked a few to make sure their associated English file had the correct corresponding change.

Left some small comments which should be addressed.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties line 36:

> 34: MSG_Help_mac_install=\  --mac-dmg-content <Pfad zu zus?tzlichem Inhalt>[,<Pfad zu zus?tzlichem Inhalt>...]\n          Nimmt den gesamten referenzierten Inhalt in die DMG-Datei auf.\n          Diese Option kann mehrmals verwendet werden. \n
> 35: MSG_Help_mac_launcher=\  --mac-package-identifier <ID-Zeichenfolge>\n          Eine ID, die die Anwendung f?r macOS eindeutig identifiziert\n          Standardwert ist der Hauptklassenname.\n          Es d?rfen nur alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-)\n          und Punkte (.) verwendet werden.\n  --mac-package-name <Namenszeichenfolge>\n          Name der Anwendung, wie in der Men?leiste angezeigt\n          Dieser kann vom Anwendungsnamen abweichen.\n          Er darf maximal 15 Zeichen enthalten und muss f?r die Anzeige\n          in der Men?leiste und im Infofenster der Anwendung geeignet sein.\n          Standardwert: Anwendungsname.\n  --mac-package-signing-prefix <Pr?fixzeichenfolge>\n          Beim Signieren des Anwendungspackages wird dieser Wert\n          allen zu signierenden Komponenten ohne vorhandene\n          Package-ID als Pr?fix vorangestellt.\n  --mac-sign\n          Anforderung zum Signieren des Packages oder des vordefinierten\n
 Anwendungsimages\n  --mac-signing-keychain <Schl?sselbundname>\n          Name des Schl?sselbundes f?r die Suche nach der Signaturidentit?t\n          Bei fehlender Angabe werden die Standardschl?sselbunde verwendet.\n  --mac-signing-key-user-name <Teamname>\n          Team- oder Benutzernamensteil der Apple-Signaturidentit?ten. Um direkt zu steuern,\n          welche Signaturidentit?t zum Signieren eines Anwendungsimages oder\n          Installationsprogramms verwendet wird, verwenden Sie --mac-app-image-sign-identity und/oder\n          --mac-installer-sign-identity. Diese Option kann nicht mit\n          --mac-app-image-sign-identity oder --mac-installer-sign-identity kombiniert werden.\n  --mac-app-image-sign-identity <identity>\n          Zum Signieren des Anwendungsimages verwendete Identit?t. Dieser Wert wird\n          direkt an die Option --sign des Tools "codesign" ?bergeben. Diese Option kann nicht\n          mit --mac-signing-key-user-name kombiniert werden.\n  
 --mac-installer-sign-identity <identity>\n          Zum Signieren des Installationsprogramms "pkg" verwendete Identit?t. Dieser Wert wird\n          direkt an die Option --sign des Tools "productbuild" ?bergeben. Diese Option\n          kann nicht mit --mac-signing-key-user-name kombiniert werden.\n  --mac-app-store\n          Gibt an, dass die jpackage-Ausgabe f?r den\n          Mac App Store bestimmt ist.\n  --mac-entitlements <Dateipfad>\n          Pfad zu einer Datei mit Berechtigungen, die beim Signieren\n          von ausf?hrbaren Dateien und Librarys im Bundle verwendet werden sollen.\n  --mac-app-category <Kategoriezeichenfolge>\n          Zeichenfolge f?r das Erstellen von LSApplicationCategoryType in\n          Anwendungs-plist. Standardwert: "utilities".\n
> 36: MSG_Help_linux_install=\  --linux-package-name <Packagename>\n          Name f?r das Linux-Package, Standardwert: Anwendungsname\n  --linux-deb-maintainer <E-Mail-Adresse>\n          Maintainer f?r .deb-Package\n  --linux-menu-group <Men?gruppenname>\n          Men?gruppe, in der diese Anwendung abgelegt wird\n  --linux-package-deps <package-dep-string>\n          Erforderliche Packages oder Funktionen f?r die Anwendung\n  --linux-rpm-license-type <Typzeichenfolge>\n          Typ der Lizenz ("License: <Wert>" der RPM-SPEC-Datei)\n  --linux-app-release <Releasewert>\n          Releasewert der RPM-SPEC-Datei <Name> oder \n          Debian-Revisionswert der DEB-Kontrolldatei\n  --linux-app-category <Kategoriewert>\n          Gruppenwert der RPM-SPEC-Datei <Name> oder \n          Abschnittswert der DEB-Kontrolldatei\n  --linux-shortcut\n          Erstellt eine Verkn?pfung f?r die Anwendung.\n

"package-dep-string" is within "<>" and should not be translated. ja and zh_CN locales remain un-translated as well. I'd like this particular one to be reverted back and we can file an issue with the translation team.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_en.wxl line 1:

> 1: <?xml version="1.0" encoding="utf-8"?>

This change can be reverted, the English file should not be touched anyways during l10n.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959683606
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167643767
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167645253

From kevinw at openjdk.org  Wed Jun 25 21:26:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 21:26:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
Message-ID: <niN-M-iJKHC5QhvtGtvBlgTr2ygodTk0_BR7UQuHeys=.fc2409f9-f97d-4e5d-9f32-40b02816236e@github.com>

On Wed, 25 Jun 2025 20:48:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Something still bugging me about this one. From JBS it looked to me like we were dealing with a virtual thread but your change is for the non-virtual thread. And Alan says something about this only being possible due to a temporary condition. So I'm still unclear exactly what the problem is, or why it appeared. Where does the initial "thread" argument come from in the Java code? Is it the one that has terminated, if so why is there not an `isAlive()` check somewhere?
> 
> And how does this lead to the bad oop?

Yes, I was reproducing with a regular non-virtual thread exiting.  We have the the j.l.Thread Object and could for it being TERMINATED earlier in HeapDumper/Snapshot, but leaving it to the last moment avoids a bigger window where it could terminate.

(Maybe there is somewhere this should intersect with ThreadSMR...?)

On the bad oop:
I enabled the test to run in debug vm for my own testing, but in one of the earlier release crashes at:

V  [libjvm.so+0x47bb10]  AccessInternal::PostRuntimeDispatch<G1BarrierSet::AccessBarrier<286822ul, G1BarrierSet>, (AccessInternal::BarrierType)3, 286822ul>::oop_access_barrier(oopDesc*, long)+0x0  (accessBackend.hpp:228)
V  [libjvm.so+0x10e1c1a]  vframeStream::vframeStream(oopDesc*, Handle)+0x7a  (vframe.cpp:523)
V  [libjvm.so+0x1068a51]  GetThreadSnapshotClosure::do_thread(Thread*)+0x7d1  (threadService.cpp:1319)
V  [libjvm.so+0x106691d]  ThreadSnapshotFactory::get_thread_snapshot(_jobject*, JavaThread*)+0x80d  (threadService.cpp:1482)
V  [libjvm.so+0xae23d5]  JVM_CreateThreadSnapshot+0x75  (jvm.cpp:2966)
j  jdk.internal.vm.ThreadSnapshot.create(Ljava/lang/Thread;)Ljdk/internal/vm/ThreadSnapshot;+0 java.base at 25-ea
...

Line number info puts it in the _java_thread == null branch of:
threadService.cpp
1317     vframeStream vfst(_java_thread != nullptr
1318       ? vframeStream(_java_thread, false, true, vthread_carrier)
1319       : vframeStream(java_lang_VirtualThread::continuation(_thread_h()))); <---

And it's looking inside the Handle _thread_h() within GetThreadSnapshotClosure which was setup by get_thread_snapshot, and it's a null pointer, as
Instructions:
=>0x00007ffadc251b10:   8b 14 37 31 c0 85 d2 74 18 89 d0 48 8d 15 1e ee
   mov    edx,DWORD PTR [rdi+rsi*1]   and RDI=0x0000000000000000

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3006190183

From achung at openjdk.org  Wed Jun 25 21:28:16 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 21:28:16 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  revert german translation, revert english wxl format change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/67990651..d54f457d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=05-06

  Stats: 21 lines in 2 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From jlu at openjdk.org  Wed Jun 25 21:43:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:43:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <L30V0OupKPnDuj1v0M_paL96VPnJ4FBQpxbR-csL9qw=.c5a4c608-2a73-4002-95ad-7af701fad29e@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959749881

From dcubed at openjdk.org  Wed Jun 25 22:13:29 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 25 Jun 2025 22:13:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
Message-ID: <6sxeRs0jaGtjCoxcJLBksWiyacOvRkSn40GXcLNKEos=.e4736687-f826-4a11-977e-9b0cf765e046@github.com>

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

Changes requested by dcubed (Reviewer).

src/hotspot/share/services/threadService.cpp line 1477:

> 1475:     java_thread = java_lang_Thread::thread(thread_h());
> 1476:     if (java_thread == nullptr) {
> 1477:         return nullptr; // thread terminated

This is not the right way to determine if you have a valid JavaThread
when you have created a ThreadsListHandle. This code near the top
of `ThreadSnapshotFactory::get_thread_snapshot` is not right:


  ThreadsListHandle tlh(THREAD);
  ResourceMark rm(THREAD);
  HandleMark   hm(THREAD);
  Handle thread_h(THREAD, JNIHandles::resolve(jthread));


The above code was added by:
[JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) ThreadSnapshot to take snapshot of thread for thread dumps

Here's the example code from src/hotspot/share/runtime/threadSMR.hpp:

// JNI jobject example:
//   jobject jthread = ...;
//   :
//   ThreadsListHandle tlh;
//   JavaThread* jt = nullptr;
//   bool is_alive = tlh.cv_internal_thread_to_JavaThread(jthread, &jt, nullptr);
//   if (is_alive) {
//     :  // do stuff with 'jt'...
//   }


So instead of this line:

Handle thread_h(THREAD, JNIHandles::resolve(jthread));

which does not guarantee you a valid JavaThread handle, you should
use `tlh.cv_internal_thread_to_JavaThread` to get a `JavaThread*`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2959809320
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2167723492

From jlu at openjdk.org  Wed Jun 25 22:55:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 22:55:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
 <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>
Message-ID: <9xiUCl6NKMT520fpbnfGriItpYYHh93M9Gn2T5nfEIE=.3e8ab340-855f-47cb-87ba-1d3275a37598@github.com>

On Tue, 24 Jun 2025 14:58:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".
>
> Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

As discussed offline, since there are many instances of this, we will file an issue with the translation team and see if they will agree to the suggested changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167774594

From dholmes at openjdk.org  Wed Jun 25 23:53:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 25 Jun 2025 23:53:28 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <6sxeRs0jaGtjCoxcJLBksWiyacOvRkSn40GXcLNKEos=.e4736687-f826-4a11-977e-9b0cf765e046@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <6sxeRs0jaGtjCoxcJLBksWiyacOvRkSn40GXcLNKEos=.e4736687-f826-4a11-977e-9b0cf765e046@github.com>
Message-ID: <XsLqb1GyRm-D5T7ZVQMPQ08LhQ1FDPx8yuMnz7e8C6Q=.f721eb84-2176-4c17-b19e-34670a250890@github.com>

On Wed, 25 Jun 2025 22:08:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - comment update
>>  - comment update
>
> src/hotspot/share/services/threadService.cpp line 1477:
> 
>> 1475:     java_thread = java_lang_Thread::thread(thread_h());
>> 1476:     if (java_thread == nullptr) {
>> 1477:         return nullptr; // thread terminated
> 
> This is not the right way to determine if you have a valid JavaThread
> when you have created a ThreadsListHandle. This code near the top
> of `ThreadSnapshotFactory::get_thread_snapshot` is not right:
> 
> 
>   ThreadsListHandle tlh(THREAD);
>   ResourceMark rm(THREAD);
>   HandleMark   hm(THREAD);
>   Handle thread_h(THREAD, JNIHandles::resolve(jthread));
> 
> 
> The above code was added by:
> [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) ThreadSnapshot to take snapshot of thread for thread dumps
> 
> Here's the example code from src/hotspot/share/runtime/threadSMR.hpp:
> 
> // JNI jobject example:
> //   jobject jthread = ...;
> //   :
> //   ThreadsListHandle tlh;
> //   JavaThread* jt = nullptr;
> //   bool is_alive = tlh.cv_internal_thread_to_JavaThread(jthread, &jt, nullptr);
> //   if (is_alive) {
> //     :  // do stuff with 'jt'...
> //   }
> 
> 
> So instead of this line:
> 
> Handle thread_h(THREAD, JNIHandles::resolve(jthread));
> 
> which does not guarantee you a valid JavaThread handle, you should
> use `tlh.cv_internal_thread_to_JavaThread` to get a `JavaThread*`.

Great catch Dan! I totally missed the TLH at the start of `get_thread_snapshot`. I knew something was off here but couldn't quite put my finger on it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2167822932

From dnguyen at openjdk.org  Thu Jun 26 00:18:39 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Jun 2025 00:18:39 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <Qjn1b786Q_fqBZXGYAGl3IMk-YzmCrxtqRKk89XCng4=.e49c60eb-2751-41b4-ab25-283c00b3bb4d@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Marked as reviewed by dnguyen (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959999177

From dholmes at openjdk.org  Thu Jun 26 00:40:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 26 Jun 2025 00:40:28 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <niN-M-iJKHC5QhvtGtvBlgTr2ygodTk0_BR7UQuHeys=.fc2409f9-f97d-4e5d-9f32-40b02816236e@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
 <niN-M-iJKHC5QhvtGtvBlgTr2ygodTk0_BR7UQuHeys=.fc2409f9-f97d-4e5d-9f32-40b02816236e@github.com>
Message-ID: <VhSGf3zuEY5hzYuNfrGwyy878H6XpAC9brHFGVknA4s=.2761f625-bea7-4858-9014-c19c6aeb9002@github.com>

On Wed, 25 Jun 2025 21:24:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Line number info puts it in the _java_thread == null branch of: threadService.cpp 
> 1317 vframeStream vfst(_java_thread != nullptr 
> 1318 ? vframeStream(_java_thread, false, true, vthread_carrier) 
> 1319 : vframeStream(java_lang_VirtualThread::continuation(_thread_h()))); <---
> 
> And it's looking inside the Handle _thread_h() within GetThreadSnapshotClosure which was setup by get_thread_snapshot, and it's a null pointer,

But `_thread_h()` has already been used a number of times before we get here and if it were null we should have crashed long ago. ???

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3006621489

From sspitsyn at openjdk.org  Thu Jun 26 05:01:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 26 Jun 2025 05:01:38 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
Message-ID: <Pf--zU47KLb0I3pHCSZHBJieAki1LYP9_wkvHQL2VJA=.3f60c492-80de-4e6b-a866-195853ee2279@github.com>

On Wed, 25 Jun 2025 21:00:15 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:
> 
>   Made it even shorter.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2960551515

From sspitsyn at openjdk.org  Thu Jun 26 05:01:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 26 Jun 2025 05:01:39 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v4]
In-Reply-To: <7j7Xdx2EvvrB9TPVAy-kWwFIpG-kdPiSPCgOdQ5ahU8=.20d49ce8-98a2-446d-9ae4-4d16fdea52ae@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <0tK3-NDLGlbyx_Y1OdoVDvEbRGH7IaYn7rPFYE3eng8=.cb985667-6f5b-4599-8feb-a593fbe13172@github.com>
 <Q0hfIzFs9WL1tnROo8hDYYu_VawKI0BZAxXFrT-zYr4=.2d895a0e-3d19-4608-8e62-666b60f4c64f@github.com>
 <7j7Xdx2EvvrB9TPVAy-kWwFIpG-kdPiSPCgOdQ5ahU8=.20d49ce8-98a2-446d-9ae4-4d16fdea52ae@github.com>
Message-ID: <hwLY37g2yHkHglYJbF3JOKwZexvgFS__Hd4VSDgtWHM=.4177bf1f-90cc-4d55-870b-1ca4781ed56b@github.com>

On Wed, 25 Jun 2025 20:39:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/lib/RedefineClassHelper.java line 95:
>> 
>>> 93:         ClassDesc newClassDesc = ClassDesc.of(newClassName);
>>> 94:         byte[] newBytes = ClassFile.of().build(newClassDesc,
>>> 95:             classBuilder -> {
>> 
>> Can replace this lambda with `classModel::forEach` method reference.
>
> Thanks for the suggestion!  Testing now.

Final version of this method is nice!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168108584

From lmesnik at openjdk.org  Thu Jun 26 05:05:30 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 26 Jun 2025 05:05:30 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
Message-ID: <MYN6cPpXYxqDO1uOob_JnqUgHeVNt1eAArYiT79BrgI=.d01ea3e0-0d43-4545-9a9b-cdd4ad061932@github.com>

On Wed, 25 Jun 2025 21:00:15 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:
> 
>   Made it even shorter.

Looks

test/lib/RedefineClassHelper.java line 35:

> 33: import jdk.test.lib.helpers.ClassFileInstaller;
> 34: 
> 35: import static jdk.test.lib.Asserts.assertTrue;

Is it really needed? I can't see that assertion were added.

-------------

Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2960558507
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168113468

From sspitsyn at openjdk.org  Thu Jun 26 05:06:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 26 Jun 2025 05:06:29 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v3]
In-Reply-To: <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>
Message-ID: <tLJTNx8tASZ31Ydk7-p98W7T0ghfjpH7FMl4fJ2rYrs=.82342ee0-9f40-475a-b110-a2b0b2215d1c@github.com>

On Wed, 25 Jun 2025 17:31:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
>> 
>> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
>> 
>> Testing (in progress):
>> 
>> - [x] tier1 ci
>> - [x] tier1 ci with -XX:StartFlightRecording 
>> - [x] tier5 ci
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing space

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25960#pullrequestreview-2960559224

From sspitsyn at openjdk.org  Thu Jun 26 05:21:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 26 Jun 2025 05:21:32 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v3]
In-Reply-To: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
Message-ID: <nMHYVxqyCwBtkqqxQ1blB2VlgiI6xm8fSGNK2RvAdFY=.4eaac677-8623-4e24-97bc-a4c2e3e65b99@github.com>

On Wed, 25 Jun 2025 17:28:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments!

Marked as reviewed by sspitsyn (Reviewer).

src/java.management/share/classes/javax/management/ImmutableDescriptor.java line 141:

> 139:             bad = true;
> 140:         if (!bad) {
> 141:             hashCode = -1; // Force recalculation

Nit: Better to start the comment with low case. Same for other comments.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25758#pullrequestreview-2960588030
PR Review Comment: https://git.openjdk.org/jdk/pull/25758#discussion_r2168131452

From cstein at openjdk.org  Thu Jun 26 05:23:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 26 Jun 2025 05:23:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <4Yu9Xo_LEoSLn6WwWbZB5GoLk0YroJfIT8B2izB5Y2k=.372e1dfb-bf3f-4ca7-be8c-edf13e87533c@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

German `_de` translations look good to me.

-------------

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2960590912

From alanb at openjdk.org  Thu Jun 26 05:53:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 05:53:28 GMT
Subject: RFR: 8360554: Use the title from the JSON RFC for the @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <qfJMhGkrjvkjkJM86-XTcRKBlh0DgAgHIk6XjVWzZN0=.80f00121-f0d7-4229-a0f4-fc26ba5f028b@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25985#pullrequestreview-2960662795

From alanb at openjdk.org  Thu Jun 26 05:59:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 05:59:35 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v6]
In-Reply-To: <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
Message-ID: <QfoqzAhPHG4csO6j0qTa59GQhd-dsUH5jzwU3tyFuls=.277afd27-00b3-48b9-a517-43291beb32e1@github.com>

On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Removed vmRTMCPU from VMProps.java

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25847#pullrequestreview-2960685033

From alanb at openjdk.org  Thu Jun 26 05:59:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 05:59:36 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v5]
In-Reply-To: <MXPOYWZAcfTLErx3yhu_OuYDaQ0TxHBsbblxEBKLxCw=.8f979999-202d-4ad0-afcd-69c28819fac7@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <TA2qvEWDka-G0B0IGTL_h0_5oNtN8JzyEcRx_VRfOpY=.8da716d3-af48-4a9c-9f76-1263a4f9d447@github.com>
 <Zta2hW_x2TyhfQJp_FKm4HJ79DSBfxlANNkKIpu1fkI=.53a204d7-f4d6-4708-816a-5ed34301f0cc@github.com>
 <MXPOYWZAcfTLErx3yhu_OuYDaQ0TxHBsbblxEBKLxCw=.8f979999-202d-4ad0-afcd-69c28819fac7@github.com>
Message-ID: <-uNZ-9Lyqc6JzRJNBqSqw6KbARrJowx8a6MDMT-OIZc=.5cc39187-9b92-492d-a949-d7d33a8e25f9@github.com>

On Wed, 25 Jun 2025 11:35:51 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> test/jdk/jdk/internal/vm/Continuation/Fuzz.java line 477:
>> 
>>> 475:     boolean shouldPin() {
>>> 476:         // Returns false since we never pin after we removed legacy locking.
>>> 477:         return traceHas(Op.PIN::contains) && false;
>> 
>> Are you planning to remove this method and update verifyPin, or maybe there will be a follow-on JBS issue for this cleanup?
>
> Removal will be done in phase 2.

Next phase is okay too, just need to remember as it will be confusing for a time to have it return false unconditionally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25847#discussion_r2168188065

From alanb at openjdk.org  Thu Jun 26 06:06:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 06:06:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
Message-ID: <4hLF410lF9EFIriy-NuDlj97eLzkM2hclxro5Hf6xlo=.b96e68e9-83d6-4823-bac4-c3d944bc67dc@github.com>

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 31:

> 29:  * @requires !vm.debug & (vm.compMode != "Xcomp")
> 30:  * @requires (vm.opt.TieredStopAtLevel == null | vm.opt.TieredStopAtLevel == 4)
> 31:  * @requires vm.jvmti

This seems like a separate discussion as the minimal VM doesn't have the M&M support so something isn't right if somehow is testing a run-time image that contains jdk.management and only the minimal VM. I assume it's just a drive-by change here but I think part of a bigger discussion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2168202465

From duke at openjdk.org  Thu Jun 26 07:29:37 2025
From: duke at openjdk.org (duke)
Date: Thu, 26 Jun 2025 07:29:37 GMT
Subject: RFR: 8359437: Make users and test suite not able to set
 LockingMode flag [v6]
In-Reply-To: <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
 <e36W6gRvoU6i8FHxF660_n-wfspTPiYJeApmG0xIE7g=.da31188f-e541-4a88-9e49-4c74dff2b037@github.com>
Message-ID: <y4oW4uSYJ62zw3RvV1LYjijFPRzPLlKxgUaRVpJkdKU=.236c8917-2143-40cf-96c6-a1f15fbbf14e@github.com>

On Wed, 25 Jun 2025 11:26:22 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
>> 
>> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
>> 
>> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
>> 
>> Lightweight locking is the default locking from now on.
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359437: Removed vmRTMCPU from VMProps.java

@toxaart 
Your change (at version 6534afaaeb8777fcb068710f6488efc35ff55af5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25847#issuecomment-3007469560

From dholmes at openjdk.org  Thu Jun 26 07:39:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 26 Jun 2025 07:39:32 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
Message-ID: <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>

On Wed, 25 Jun 2025 21:00:15 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:
> 
>   Made it even shorter.

This looks really neat. A couple of nits and a query.

test/lib/RedefineClassHelper.java line 29:

> 27: import java.lang.classfile.ClassFile;
> 28: import java.lang.classfile.ClassModel;
> 29: import java.util.Map;

Nit: import out of order

test/lib/RedefineClassHelper.java line 74:

> 72: 
> 73:     private static byte[] getBytecodes(ClassLoader loader, String name) throws Exception {
> 74:         try(InputStream is = loader.getResourceAsStream(name + ".class")) {

Suggestion:

        try (InputStream is = loader.getResourceAsStream(name + ".class")) {

test/lib/RedefineClassHelper.java line 92:

> 90:         byte[] buf = getBytecodes(loader, oldClassName);
> 91:         ClassModel classModel = ClassFile.of().parse(buf);
> 92:         return ClassFile.of().build(ClassDesc.of(newClassName), classModel::forEach);

That's cool! I have no idea how to read it to understand what it does, but it is cool it can be done in one line. :)

Seriously though, which part of that is doing the actual replace??

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2961031930
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168385540
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168392685
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168399258

From duke at openjdk.org  Thu Jun 26 07:44:42 2025
From: duke at openjdk.org (Anton Artemov)
Date: Thu, 26 Jun 2025 07:44:42 GMT
Subject: Integrated: 8359437: Make users and test suite not able to set
 LockingMode flag
In-Reply-To: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
References: <pEp0ZDwz5ieOsvWO_rkXtW1oxKgGATZ8iHGChY0Tqu0=.d1bf7557-bea2-423f-a70f-2705b6fdccc5@github.com>
Message-ID: <w9uDgZuUsVafTymvFtOUb8NgHOC6ICgFVDMFH72gCv0=.ccd0b3d7-c7ca-4b8b-a451-92ad8c0d72f0@github.com>

On Tue, 17 Jun 2025 08:39:49 GMT, Anton Artemov <duke at openjdk.org> wrote:

> This PR contains changes for the 1st phase of the `LockingMode` flag obsoletion. 
> 
> The work is done by @fbredber, I have taken it over and am finishing it while he's on vacation. 
> 
> In the 1st phase one keeps the `LockingMode` variable in all places, but makes it non-settable from the command line. All the C1 and C2 code related to legacy locking will still be in place (but as dead code) and removed later (phase 2).
> 
> Lightweight locking is the default locking from now on.
> 
> Tested in tiers 1 - 7.

This pull request has now been integrated.

Changeset: 5039b42d
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5039b42de170769797312969185ee9d67f34cf24
Stats:     1154 lines in 34 files changed: 24 ins; 1044 del; 86 mod

8359437: Make users and test suite not able to set LockingMode flag
8358542: Remove RTM test VMProps

Co-authored-by: Fredrik Bredberg <fbredberg at openjdk.org>
Reviewed-by: coleenp, lmesnik, fbredberg, alanb, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/25847

From kevinw at openjdk.org  Thu Jun 26 08:26:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 26 Jun 2025 08:26:32 GMT
Subject: RFR: 8360554: Use the title from the JSON RFC for the @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <hDG7lLchkORyyn2Bo-7FFKqPqVRvP47TvcPARI3rUJk=.7b872e21-0936-4232-a396-4dd048b570cc@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

Sure, looks good.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25985#pullrequestreview-2961203385

From kevinw at openjdk.org  Thu Jun 26 08:29:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 26 Jun 2025 08:29:29 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <XsLqb1GyRm-D5T7ZVQMPQ08LhQ1FDPx8yuMnz7e8C6Q=.f721eb84-2176-4c17-b19e-34670a250890@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <6sxeRs0jaGtjCoxcJLBksWiyacOvRkSn40GXcLNKEos=.e4736687-f826-4a11-977e-9b0cf765e046@github.com>
 <XsLqb1GyRm-D5T7ZVQMPQ08LhQ1FDPx8yuMnz7e8C6Q=.f721eb84-2176-4c17-b19e-34670a250890@github.com>
Message-ID: <UeevvX3OnOnXb7FbnmN3CB4_YYlkURHC8NSRn847CVo=.49e032a4-efe3-4dbe-8377-735f9dcced53@github.com>

On Wed, 25 Jun 2025 23:50:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/services/threadService.cpp line 1477:
>> 
>>> 1475:     java_thread = java_lang_Thread::thread(thread_h());
>>> 1476:     if (java_thread == nullptr) {
>>> 1477:         return nullptr; // thread terminated
>> 
>> This is not the right way to determine if you have a valid JavaThread
>> when you have created a ThreadsListHandle. This code near the top
>> of `ThreadSnapshotFactory::get_thread_snapshot` is not right:
>> 
>> 
>>   ThreadsListHandle tlh(THREAD);
>>   ResourceMark rm(THREAD);
>>   HandleMark   hm(THREAD);
>>   Handle thread_h(THREAD, JNIHandles::resolve(jthread));
>> 
>> 
>> The above code was added by:
>> [JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) ThreadSnapshot to take snapshot of thread for thread dumps
>> 
>> Here's the example code from src/hotspot/share/runtime/threadSMR.hpp:
>> 
>> // JNI jobject example:
>> //   jobject jthread = ...;
>> //   :
>> //   ThreadsListHandle tlh;
>> //   JavaThread* jt = nullptr;
>> //   bool is_alive = tlh.cv_internal_thread_to_JavaThread(jthread, &jt, nullptr);
>> //   if (is_alive) {
>> //     :  // do stuff with 'jt'...
>> //   }
>> 
>> 
>> So instead of this line:
>> 
>> Handle thread_h(THREAD, JNIHandles::resolve(jthread));
>> 
>> which does not guarantee you a valid JavaThread handle, you should
>> use `tlh.cv_internal_thread_to_JavaThread` to get a `JavaThread*`.
>
> Great catch Dan! I totally missed the TLH at the start of `get_thread_snapshot`. I knew something was off here but couldn't quite put my finger on it.

Yes thanks Dan! Will update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2168498780

From ayang at openjdk.org  Thu Jun 26 10:17:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 10:17:13 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v16]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  remove-young-resize-after-full-gc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/7f733137..271a8916

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=14-15

  Stats: 59 lines in 3 files changed: 9 ins; 40 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Thu Jun 26 10:17:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 10:17:13 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <0l1GXiRVXTfUaPsDPyirWY0RnyyjxO95GfqnED2O1nw=.6f9d7504-3708-48f0-9e28-689772339276@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
 <0l1GXiRVXTfUaPsDPyirWY0RnyyjxO95GfqnED2O1nw=.6f9d7504-3708-48f0-9e28-689772339276@github.com>
Message-ID: <9F00iiZ3YclXm-0yJsaCC5z_MqZjUqvlKg8a8UvpRnE=.d010c44c-10d8-4ab8-8af2-77db2952d128@github.com>

On Mon, 19 May 2025 11:05:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Added checking for `from_space`.
>> 
>> If all live-objs don't fit in old-gen, leftovers will be kept in its own space.
>> 
>> 
>>   // Summarize the remaining spaces in the young gen.  The initial target space
>>   // is the old gen.  If a space does not fit entirely into the target, then the
>>   // remainder is compacted into the space itself and that space becomes the new
>>   // target.
>
>> If all live-objs don't fit in old-gen, leftovers will be kept in its own space.
> 
> Thanks for clarifying.

I removed this method, and added comments why it's undesirable to do young-gen resizing after a full-gc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2168706034

From coleenp at openjdk.org  Thu Jun 26 11:58:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 11:58:11 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
Message-ID: <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>

On Thu, 26 Jun 2025 07:30:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made it even shorter.
>
> test/lib/RedefineClassHelper.java line 29:
> 
>> 27: import java.lang.classfile.ClassFile;
>> 28: import java.lang.classfile.ClassModel;
>> 29: import java.util.Map;
> 
> Nit: import out of order

I like the imports when they're grouped by things they support.  Map isn't being used in the final version though.

> test/lib/RedefineClassHelper.java line 92:
> 
>> 90:         byte[] buf = getBytecodes(loader, oldClassName);
>> 91:         ClassModel classModel = ClassFile.of().parse(buf);
>> 92:         return ClassFile.of().build(ClassDesc.of(newClassName), classModel::forEach);
> 
> That's cool! I have no idea how to read it to understand what it does, but it is cool it can be done in one line. :)
> 
> Seriously though, which part of that is doing the actual replace??

Java's gone overly terse, but if you look at the n-1 commit, the classModel::forEach copies everything in the class to the new class.  At least that's what Chen told me and it seems to do.  Isn't this cool?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168886521
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2168884543

From coleenp at openjdk.org  Thu Jun 26 11:58:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 11:58:11 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v7]
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: <DdTqN9gra6nyK-QNbUBtJk35Svm1FP_9jIMGmtVPmWY=.5269ea49-70c5-4a48-8ce1-1c4c763572de@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 two additional commits since the last revision:

 - Update test/lib/RedefineClassHelper.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Fix imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/3285f4d5..21223e37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=05-06

  Stats: 7 lines in 1 file changed: 1 ins; 3 del; 3 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  Thu Jun 26 12:10:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 12:10:34 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <WD1IpKrax6v1JfX1OECFKacNy1GYU_Lwk0wiYAPI49g=.4a2d116b-0974-4ef6-b81c-71fa20f4013e@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <WD1IpKrax6v1JfX1OECFKacNy1GYU_Lwk0wiYAPI49g=.4a2d116b-0974-4ef6-b81c-71fa20f4013e@github.com>
Message-ID: <tE0v8J9G2Gkr3Dky1cmD8jaPnOgNjbgWthqMjYIi3nE=.c5ce928f-7811-4dca-b13e-18cc08fd3ca6@github.com>

On Wed, 25 Jun 2025 17:48:02 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the test
>
> src/hotspot/share/runtime/mutexLocker.cpp line 236:
> 
>> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
>> 235: 
>> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1);    // used for creating jmethodIDs locks HandshakeState_lock
> 
> Perhaps:
> 
>   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1);    // used for creating jmethodIDs, can lock HandshakeState_lock which is at nosafepoint

ugh that makes the line too long for me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2168911755

From coleenp at openjdk.org  Thu Jun 26 12:20:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 12:20:57 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v11]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <Npal_8nTbvlL_KWgTzyUO-p-L4k6o4p2f0lZeh_c1gc=.5f7f70fb-9d66-4291-befb-c3d63deef614@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More comment grammar fixes, thank you for reading the comments again, Dan!

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/66eb4269..cc0d6dda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=09-10

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From kevinw at openjdk.org  Thu Jun 26 12:22:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 26 Jun 2025 12:22:32 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <4hLF410lF9EFIriy-NuDlj97eLzkM2hclxro5Hf6xlo=.b96e68e9-83d6-4823-bac4-c3d944bc67dc@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <4hLF410lF9EFIriy-NuDlj97eLzkM2hclxro5Hf6xlo=.b96e68e9-83d6-4823-bac4-c3d944bc67dc@github.com>
Message-ID: <Wz0Pbm-3zTweUTy-20mbJgy9S31oX4qj7EFl-FgtImQ=.eb9680a8-791b-4f2d-9a79-b9a12c04bf2b@github.com>

On Thu, 26 Jun 2025 06:04:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This seems like a separate discussion as the minimal VM doesn't have the M&M support

Sure, it's maybe off topic.  I now see that few tests handle this.
I hit it as a minimal build showed me I had the wrong THROW macro, so in getting that right, I want to build and test such a VM.
This test fails to load ManagementFactory with such a build (expected but confusing).  It should skip.

I realise many tests will fail on such a build.  We could use
  @requires vm.flavor != "minimal"
or
 @requires vm.jvmti
or just leave the failure in.  I don't need to commit this test param change now.

Relatedly:
I saw the tes timeout in debug builds on win and mac (as expected).
On Linux, fastdebug builds run OK and could be useful.  If further testing doesn't find an issue, I can do:

- * @requires !vm.debug & (vm.compMode != "Xcomp")
+ * @requires vm.compMode != "Xcomp"
+ * @requires !vm.debug || (os.family == "linux")

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2168933479

From sgehwolf at openjdk.org  Thu Jun 26 12:35:28 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 26 Jun 2025 12:35:28 GMT
Subject: RFR: 8360518: Docker tests do not work when asan is configured
In-Reply-To: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
References: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
Message-ID: <JRxsz3ti30Wp-5-hdvHrlK9xk8CeVRxU-RBbFQvvjTo=.90175d3a-6027-4e08-9efa-2992108ffbeb@github.com>

On Wed, 25 Jun 2025 14:09:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When the address sanitizer ASAN is configured, we run into errors in the docker tests.
> Example hotspot/jtreg/containers/docker/DockerBasicTest.java :
> 
> [STDOUT]
> /jdk/bin/java: error while loading shared libraries: libasan.so.8: cannot open shared object file: No such file or directory
> 
> Reason is that the asan-enabled binaries need additional dependencies and those are not available in the current docker/container setups.
> Maybe we should skip those tests when asan is enabled.

Seems fine to me.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25980#pullrequestreview-2961937524

From syan at openjdk.org  Thu Jun 26 12:35:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 26 Jun 2025 12:35:29 GMT
Subject: RFR: 8360518: Docker tests do not work when asan is configured
In-Reply-To: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
References: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
Message-ID: <_SrsAyYvN9cq232gYiGFmkzUb5QMBqlkom7VrQsPBgc=.2c72fdf6-3ed5-48c4-8743-6f0602a69ada@github.com>

On Wed, 25 Jun 2025 14:09:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When the address sanitizer ASAN is configured, we run into errors in the docker tests.
> Example hotspot/jtreg/containers/docker/DockerBasicTest.java :
> 
> [STDOUT]
> /jdk/bin/java: error while loading shared libraries: libasan.so.8: cannot open shared object file: No such file or directory
> 
> Reason is that the asan-enabled binaries need additional dependencies and those are not available in the current docker/container setups.
> Maybe we should skip those tests when asan is enabled.

Should we should copy the dependent files such as libasan.so.8 to docker images when build it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25980#issuecomment-3006718477

From sgehwolf at openjdk.org  Thu Jun 26 12:40:27 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 26 Jun 2025 12:40:27 GMT
Subject: RFR: 8360518: Docker tests do not work when asan is configured
In-Reply-To: <_SrsAyYvN9cq232gYiGFmkzUb5QMBqlkom7VrQsPBgc=.2c72fdf6-3ed5-48c4-8743-6f0602a69ada@github.com>
References: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
 <_SrsAyYvN9cq232gYiGFmkzUb5QMBqlkom7VrQsPBgc=.2c72fdf6-3ed5-48c4-8743-6f0602a69ada@github.com>
Message-ID: <nFHoBnLMf2VgLUaMLL7Evgu4RDLLhEO03LsMjRRdfkw=.a8a67fa8-3541-42f6-be6e-45c316e79569@github.com>

On Thu, 26 Jun 2025 01:26:38 GMT, SendaoYan <syan at openjdk.org> wrote:

> Should we should copy the dependent files such as libasan.so.8 to docker images when build it.

See:
https://bugs.openjdk.org/browse/JDK-8333144?focusedId=14792939&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14792939

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25980#issuecomment-3008347106

From asemenov at openjdk.org  Thu Jun 26 13:28:44 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 26 Jun 2025 13:28:44 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object()
Message-ID: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>

The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.

The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.


Found by Linux Verification Center (linuxtesting.org) with SVACE. signed-off-by: Artem Semenov (savoptik at altlinux.org).

-------------

Commit messages:
 - 8360664 Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()

Changes: https://git.openjdk.org/jdk/pull/26002/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360664
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26002/head:pull/26002

PR: https://git.openjdk.org/jdk/pull/26002

From asemenov at openjdk.org  Thu Jun 26 14:00:43 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 26 Jun 2025 14:00:43 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
Message-ID: <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>

> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.

Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8360664 Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()
  
  Found by Linux Verification Center (linuxtesting.org) with SVACE.
  signed-off-by: Artem Semenov <savoptik at altlinux.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26002/files
  - new: https://git.openjdk.org/jdk/pull/26002/files/ee6a0ff7..e69c49c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26002/head:pull/26002

PR: https://git.openjdk.org/jdk/pull/26002

From iwalulya at openjdk.org  Thu Jun 26 15:40:30 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 15:40:30 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v16]
In-Reply-To: <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>
Message-ID: <P2i4hJfjR2uZwFXcdIcj28i8LDvMlLM6aQsRolnXlNc=.5622e075-fbc1-426c-b8fc-fd4045cea656@github.com>

On Thu, 26 Jun 2025 10:17:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove-young-resize-after-full-gc

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/parallel/psYoungGen.cpp line 305:

> 303:                                                eden_space()->top(),
> 304:                                                sizeof(HeapWord));
> 305:     if (word_size > available_word_size) {

Would it be useful to `log_trace` this situaton?

src/hotspot/share/gc/parallel/psYoungGen.cpp line 321:

> 319: }
> 320: 
> 321: void PSYoungGen::compute_desired_sizes(bool is_survivor_overflowing,

Probably subjective, but as suggested on a recent review, is it easier to read if you returned the results in a Pair<size_t, size_t>?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2950871762
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169356093
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169350754

From iwalulya at openjdk.org  Thu Jun 26 15:40:33 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 15:40:33 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v14]
In-Reply-To: <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>
Message-ID: <rdBFXf7-F7TgNvzjJrqZ5727MT7-B7bAvZb-gXuM4Oc=.0216769c-da6c-4b0f-81c6-c051debfac15@github.com>

On Mon, 23 Jun 2025 08:34:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang 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 pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - Merge branch 'master' into pgc-size-policy
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/516197f5...41027bdf

src/hotspot/share/gc/parallel/psScavenge.cpp line 539:

> 537:   if (!young_gen->to_space()->is_empty()) {
> 538:     // To-space is not empty; should run full-gc instead.
> 539:     log_debug(gc, ergo)("non-empty to-space; full-gc instead");

"To-space is not empty; should run full-gc instead" seems like a better log string if we need logging here

src/hotspot/share/gc/parallel/psVirtualspace.cpp line 66:

> 64:     _committed_high_addr += bytes;
> 65:   } else {
> 66:     log_warning(gc)("expand_by commit %zu bytes failed", bytes);

probably leftover from debugging, if not, then maybe improve the log string

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2162115342
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2162111028

From cjplummer at openjdk.org  Thu Jun 26 15:43:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 26 Jun 2025 15:43:27 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
Message-ID: <VYV5mAMB0HgnUh--2cx_YdYgk86G-b9RWhE5KW7K8pg=.376d4538-7599-41c5-b472-085c1383b6d2@github.com>

On Thu, 26 Jun 2025 14:00:43 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8360664 Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()
>   
>   Found by Linux Verification Center (linuxtesting.org) with SVACE.
>   signed-off-by: Artem Semenov <savoptik at altlinux.org>

It's concerning that we don't have tests cases that uncover these bugs. Perhaps it's not actually possible for NULL to be passed when constructing CallbackWrapper.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3008932024

From liach at openjdk.org  Thu Jun 26 16:11:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Jun 2025 16:11:16 GMT
Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests
 [v5]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <gjp4FJf9yoF5RkVYFlARr2NF-CLI-DH9wcoBS5FNWLY=.2a680fa0-d7a1-48d9-804b-dc9d285478f5@github.com>

> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
  
  Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/4fc1b513..020659f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25124&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

PR: https://git.openjdk.org/jdk/pull/25124

From naoto at openjdk.org  Thu Jun 26 16:11:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:11:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <yCfy1s78TO0A4KkM8-Dsfwel3MyFrljHZZfcOY31X6o=.9826e189-d4d2-4166-9634-e35bd79cf55d@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Looks fine to me. Thanks, Alisen!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2962676541

From liach at openjdk.org  Thu Jun 26 16:36:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 26 Jun 2025 16:36:37 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
Message-ID: <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>

On Thu, 26 Jun 2025 11:52:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/lib/RedefineClassHelper.java line 92:
>> 
>>> 90:         byte[] buf = getBytecodes(loader, oldClassName);
>>> 91:         ClassModel classModel = ClassFile.of().parse(buf);
>>> 92:         return ClassFile.of().build(ClassDesc.of(newClassName), classModel::forEach);
>> 
>> That's cool! I have no idea how to read it to understand what it does, but it is cool it can be done in one line. :)
>> 
>> Seriously though, which part of that is doing the actual replace??
>
> Java's gone overly terse, but if you look at the n-1 commit, the classModel::forEach copies everything in the class to the new class.  At least that's what Chen told me and it seems to do.  Isn't this cool?

> Seriously though, which part of that is doing the actual replace??

`ClassDesc.of(newClassName)` defines a new class with the new name, and the lambda just copies everything over as-is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169460161

From naoto at openjdk.org  Thu Jun 26 16:38:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:38:36 GMT
Subject: RFR: 8360554: Use the title from the JSON RFC for the @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <9UIjzlXgNNAJ6owE-VNNSdL-vmDnwDyTlamdbcvEGvw=.739d16f8-565d-4c09-ba7a-f46428d1e6d9@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25985#issuecomment-3009080948

From dcubed at openjdk.org  Thu Jun 26 16:38:36 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 26 Jun 2025 16:38:36 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v11]
In-Reply-To: <Npal_8nTbvlL_KWgTzyUO-p-L4k6o4p2f0lZeh_c1gc=.5f7f70fb-9d66-4291-befb-c3d63deef614@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <Npal_8nTbvlL_KWgTzyUO-p-L4k6o4p2f0lZeh_c1gc=.5f7f70fb-9d66-4291-befb-c3d63deef614@github.com>
Message-ID: <NlaQjf7tVQ2b8apa3FDxp1ELYqOez85tIDwL_qpu1x8=.0b4ec494-6d29-442d-8be6-31c98091962f@github.com>

On Thu, 26 Jun 2025 12:20:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comment grammar fixes, thank you for reading the comments again, Dan!

Thanks for making the wording tweaks.

-------------

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2962742782

From naoto at openjdk.org  Thu Jun 26 16:38:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:38:37 GMT
Subject: Integrated: 8360554: Use the title from the JSON RFC for the @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <V2Xc0v7pxJtI4CzrsbPVvwhN_DQtQXSA7uCWraaHSys=.4331129b-f35b-43c8-ac75-3189990100f9@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

This pull request has now been integrated.

Changeset: 83fe688d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83fe688d809ca783f8ebf6528a1cf4540d698fb1
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8360554: Use the title from the JSON RFC for the @spec tag

Reviewed-by: alanb, kevinw

-------------

PR: https://git.openjdk.org/jdk/pull/25985

From dcubed at openjdk.org  Thu Jun 26 16:38:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 26 Jun 2025 16:38:37 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <tE0v8J9G2Gkr3Dky1cmD8jaPnOgNjbgWthqMjYIi3nE=.c5ce928f-7811-4dca-b13e-18cc08fd3ca6@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <WD1IpKrax6v1JfX1OECFKacNy1GYU_Lwk0wiYAPI49g=.4a2d116b-0974-4ef6-b81c-71fa20f4013e@github.com>
 <tE0v8J9G2Gkr3Dky1cmD8jaPnOgNjbgWthqMjYIi3nE=.c5ce928f-7811-4dca-b13e-18cc08fd3ca6@github.com>
Message-ID: <qZwzSdJFYKdzmBKhLkBM0Jkg_Hy0CkHgYALZXT4q3aM=.a6397a84-ffd8-4348-bdff-a3e1dfde83ed@github.com>

On Thu, 26 Jun 2025 12:08:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 236:
>> 
>>> 234:   MUTEX_DEFN(Notification_lock               , PaddedMonitor, service);          // used for notification thread operations
>>> 235: 
>>> 236:   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1);    // used for creating jmethodIDs locks HandshakeState_lock
>> 
>> Perhaps:
>> 
>>   MUTEX_DEFN(JmethodIdCreation_lock          , PaddedMutex  , nosafepoint-1);    // used for creating jmethodIDs, can lock HandshakeState_lock which is at nosafepoint
>
> ugh that makes the line too long for me.

How about just: s/locks/can also lock/

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2169462310

From alanb at openjdk.org  Thu Jun 26 16:41:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 16:41:28 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <Wz0Pbm-3zTweUTy-20mbJgy9S31oX4qj7EFl-FgtImQ=.eb9680a8-791b-4f2d-9a79-b9a12c04bf2b@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <4hLF410lF9EFIriy-NuDlj97eLzkM2hclxro5Hf6xlo=.b96e68e9-83d6-4823-bac4-c3d944bc67dc@github.com>
 <Wz0Pbm-3zTweUTy-20mbJgy9S31oX4qj7EFl-FgtImQ=.eb9680a8-791b-4f2d-9a79-b9a12c04bf2b@github.com>
Message-ID: <THSHqIz-CxKb_QAG5Ez3YH1tcwGlO54uokOV6ODPyKE=.dc9064dc-e8b4-4083-a6f1-36cad82b1c70@github.com>

On Thu, 26 Jun 2025 12:20:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > This seems like a separate discussion as the minimal VM doesn't have the M&M support
> 
> Sure, it's maybe off topic. I now see that few tests handle this. I hit it as a minimal build showed me I had the wrong THROW macro, so in getting that right, I want to build and test such a VM. This test fails to load ManagementFactory with such a build (expected but confusing). It should skip.

I think you drop the change to the test as testing minimal VM is a bigger discussion. The make target for the compact profiles was removed in JDK 9 so would require running jlink to create a run-time image to test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2169467764

From asotona at openjdk.org  Thu Jun 26 16:50:29 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 26 Jun 2025 16:50:29 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
 <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>
Message-ID: <cpXcKOhPRBxjzYex8ksNboV9x5NtbcvvN0sGQ2nBSGY=.2a62e1f3-b6e2-4b08-b822-8d036d5feed4@github.com>

On Thu, 26 Jun 2025 16:34:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Java's gone overly terse, but if you look at the n-1 commit, the classModel::forEach copies everything in the class to the new class.  At least that's what Chen told me and it seems to do.  Isn't this cool?
>
>> Seriously though, which part of that is doing the actual replace??
> 
> `ClassDesc.of(newClassName)` defines a new class with the new name, and the lambda just copies everything over as-is.

It can be also written as:
`return ClassFile.of().transform(classModel, ClassDesc.of(newClassName), ClassTransform.ACCEPT_ALL`

But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself.

Full class remapping was a job of https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/classfile/components/ClassRemapper.html which unfortunately didn't make it from 23 preview to 24 :(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169481261

From aivanov at openjdk.org  Thu Jun 26 17:32:34 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Jun 2025 17:32:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:

> 459: SliderDemo.majorticks=Hauptteilstriche
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften

@sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).

Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?

Should *Beschriften* rather be *Beschriftung*?

Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 463:

> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
> 462: SliderDemo.minorticks=Hilfsteilstriche
> 463: SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, mit Teilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einem sichtbaren Label versehen sind

This one is repetitive:
Suggestion:

SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einer sichtbaren Beschriftung versehen sind

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169540017
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169535281

From cstein at openjdk.org  Thu Jun 26 17:44:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 26 Jun 2025 17:44:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
 <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
Message-ID: <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>

On Thu, 26 Jun 2025 17:22:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert german translation, revert english wxl format change
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:
> 
>> 459: SliderDemo.majorticks=Hauptteilstriche
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
> 
> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).
> 
> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?
> 
> Should *Beschriften* rather be *Beschriftung*?
> 
> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?

You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung)

> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation?

Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like:

_Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169576244

From coleenp at openjdk.org  Thu Jun 26 18:01:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 18:01:58 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v12]
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Improved comments, not too wide for my screen...

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25267/files
  - new: https://git.openjdk.org/jdk/pull/25267/files/cc0d6dda..8ef3f190

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25267&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25267/head:pull/25267

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Thu Jun 26 18:01:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 18:01:59 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v11]
In-Reply-To: <Npal_8nTbvlL_KWgTzyUO-p-L4k6o4p2f0lZeh_c1gc=.5f7f70fb-9d66-4291-befb-c3d63deef614@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <Npal_8nTbvlL_KWgTzyUO-p-L4k6o4p2f0lZeh_c1gc=.5f7f70fb-9d66-4291-befb-c3d63deef614@github.com>
Message-ID: <PGVX8JMX_YCEzOciQ5cWHT3ZdVqIDs7Xtpdk3Fh_fsw=.3a40b32c-991d-4bc5-ba15-f808d0f0ab3b@github.com>

On Thu, 26 Jun 2025 12:20:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More comment grammar fixes, thank you for reading the comments again, Dan!

// This function must only be called when JVM/TI
// CLASS_LOAD events have been enabled since agent startup. The enabled
// event will cause the jmethodIDs to be allocated at class load time.
// The jmethodIDs cannot be allocated in a signal handler because locks
// cannot be grabbed in a signal handler safely.


I do not see any code that creates jmethodIDs for all the methods in a ClassLoad JVMTI event.  ACGCT does call 


trace->frames[count].method_id = method->find_jmethod_id_or_null();


so it won't create jmethodIDs from a signal handler.  Keeping them live for the frames depends on when the native caller of ASGCT uses the trace that is returned.  If the frames are still on the call stack, the methods cannot be unloaded because they're still on the call stack.  If the frames returned by ASGCT are stored somewhere else, and accessed later, they could be null.  I don't see any code that makes this work tbh.  Most methods do not have jmethodIDs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3009304966

From coleenp at openjdk.org  Thu Jun 26 18:28:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 18:28:32 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v10]
In-Reply-To: <qZwzSdJFYKdzmBKhLkBM0Jkg_Hy0CkHgYALZXT4q3aM=.a6397a84-ffd8-4348-bdff-a3e1dfde83ed@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <JJcLQDwtRQK4a6dVdB7_y5INrT4z3Ue-asOthD_u8dg=.80f372e3-5bc2-43dd-a3d1-283ab45b4e64@github.com>
 <WD1IpKrax6v1JfX1OECFKacNy1GYU_Lwk0wiYAPI49g=.4a2d116b-0974-4ef6-b81c-71fa20f4013e@github.com>
 <tE0v8J9G2Gkr3Dky1cmD8jaPnOgNjbgWthqMjYIi3nE=.c5ce928f-7811-4dca-b13e-18cc08fd3ca6@github.com>
 <qZwzSdJFYKdzmBKhLkBM0Jkg_Hy0CkHgYALZXT4q3aM=.a6397a84-ffd8-4348-bdff-a3e1dfde83ed@github.com>
Message-ID: <qbKNkIzs9sOlaAcRclkA0G7XUAtY6VduWqJZ7YqVT18=.1eae59af-bbb1-47f4-8884-8dfd24cf7d7c@github.com>

On Thu, 26 Jun 2025 16:35:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> ugh that makes the line too long for me.
>
> How about just: s/locks/can also lock/

Done - that's not too wide for my screen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25267#discussion_r2169688031

From coleenp at openjdk.org  Thu Jun 26 18:44:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 18:44:29 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <cpXcKOhPRBxjzYex8ksNboV9x5NtbcvvN0sGQ2nBSGY=.2a62e1f3-b6e2-4b08-b822-8d036d5feed4@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
 <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>
 <cpXcKOhPRBxjzYex8ksNboV9x5NtbcvvN0sGQ2nBSGY=.2a62e1f3-b6e2-4b08-b822-8d036d5feed4@github.com>
Message-ID: <P7T_d1MQlB3SYnSvZNpQ5zTzc0ZNldkFpPq8kHm0mGs=.36235f2e-00d7-47d6-8e84-b4beb0d10807@github.com>

On Thu, 26 Jun 2025 16:47:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>>> Seriously though, which part of that is doing the actual replace??
>> 
>> `ClassDesc.of(newClassName)` defines a new class with the new name, and the lambda just copies everything over as-is.
>
> It can be also written as:
> `return ClassFile.of().transform(classModel, ClassDesc.of(newClassName), ClassTransform.ACCEPT_ALL`
> 
> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself.
> 
> Full class remapping was a job of https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/classfile/components/ClassRemapper.html which unfortunately didn't make it from 23 preview to 24 :(

Yes, I wanted to use the ClassRemapper but all the tests that used RedefineClassHelper would have had to add @modules.  We can change it later when ClassRemapper becomes available without adding modules.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169711642

From coleenp at openjdk.org  Thu Jun 26 18:44:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 26 Jun 2025 18:44:29 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
Message-ID: <dvzEXl7Bz91eDHGUtmyHGgcOsd_pNKE-89m885SFsq8=.445d2209-62b6-4eac-af92-0d00de56d493@github.com>

On Thu, 26 Jun 2025 11:53:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/lib/RedefineClassHelper.java line 29:
>> 
>>> 27: import java.lang.classfile.ClassFile;
>>> 28: import java.lang.classfile.ClassModel;
>>> 29: import java.util.Map;
>> 
>> Nit: import out of order
>
> I like the imports when they're grouped by things they support.  Map isn't being used in the final version though.

fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2169712542

From ayang at openjdk.org  Thu Jun 26 19:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 19:17:11 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v17]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - remove-young-resize-after-full-gc
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - ... and 15 more: https://git.openjdk.org/jdk/compare/20e0055e...eeda1eb8

-------------

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=16
  Stats: 4362 lines in 31 files changed: 506 ins; 3470 del; 386 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Thu Jun 26 19:25:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 19:25:32 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v14]
In-Reply-To: <rdBFXf7-F7TgNvzjJrqZ5727MT7-B7bAvZb-gXuM4Oc=.0216769c-da6c-4b0f-81c6-c051debfac15@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>
 <rdBFXf7-F7TgNvzjJrqZ5727MT7-B7bAvZb-gXuM4Oc=.0216769c-da6c-4b0f-81c6-c051debfac15@github.com>
Message-ID: <1VCKQ3DB7qOy2FYZRgJ1MsjgJn4V0HRjz4jb4qPfYus=.3d9d8374-c422-48b7-a058-cd27f20c9e76@github.com>

On Mon, 23 Jun 2025 17:26:29 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Albert Mingkun Yang 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 pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - version
>>  - Merge branch 'master' into pgc-size-policy
>>  - revert-aliases
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - merge-fix
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/516197f5...41027bdf
>
> src/hotspot/share/gc/parallel/psVirtualspace.cpp line 66:
> 
>> 64:     _committed_high_addr += bytes;
>> 65:   } else {
>> 66:     log_warning(gc)("expand_by commit %zu bytes failed", bytes);
> 
> probably leftover from debugging, if not, then maybe improve the log string

Revised.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169803226

From ayang at openjdk.org  Thu Jun 26 19:25:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 19:25:34 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v16]
In-Reply-To: <P2i4hJfjR2uZwFXcdIcj28i8LDvMlLM6aQsRolnXlNc=.5622e075-fbc1-426c-b8fc-fd4045cea656@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>
 <P2i4hJfjR2uZwFXcdIcj28i8LDvMlLM6aQsRolnXlNc=.5622e075-fbc1-426c-b8fc-fd4045cea656@github.com>
Message-ID: <xAY1UgL6gCJsaj692vUllQx1ZTDyGF66zFTp7HTBf-Y=.e681460e-cbf7-4f45-ab22-8a13516a4119@github.com>

On Thu, 26 Jun 2025 15:35:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove-young-resize-after-full-gc
>
> src/hotspot/share/gc/parallel/psYoungGen.cpp line 305:
> 
>> 303:                                                eden_space()->top(),
>> 304:                                                sizeof(HeapWord));
>> 305:     if (word_size > available_word_size) {
> 
> Would it be useful to `log_trace` this situaton?

You mean we are probably approaching OOM here? However, we can reach here from diff calling-context, we don't know if we are near OOM or not.

> src/hotspot/share/gc/parallel/psYoungGen.cpp line 321:
> 
>> 319: }
>> 320: 
>> 321: void PSYoungGen::compute_desired_sizes(bool is_survivor_overflowing,
> 
> Probably subjective, but as suggested on a recent review, is it easier to read if you returned the results in a Pair<size_t, size_t>?

It probably doesn't make much difference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169802849
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169790986

From achung at openjdk.org  Thu Jun 26 20:56:39 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jun 2025 20:56:39 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d54f457d..dcce2a39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

PR: https://git.openjdk.org/jdk/pull/25839

From achung at openjdk.org  Thu Jun 26 20:56:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jun 2025 20:56:40 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
 <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
 <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>
Message-ID: <SglYkl97hMPTI35H7e9VncJTC3GWAW2mRgU72vGs3eI=.d8f3e462-116e-4530-bc97-bb4cab345fb7@github.com>

On Thu, 26 Jun 2025 17:41:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:
>> 
>>> 459: SliderDemo.majorticks=Hauptteilstriche
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
>> 
>> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).
>> 
>> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?
>> 
>> Should *Beschriften* rather be *Beschriftung*?
>> 
>> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?
>
> You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung)
> 
>> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation?
> 
> Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like:
> 
> _Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_

Maybe better to leave this one as is and next drop the translation team can take another look

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169956970

From dholmes at openjdk.org  Fri Jun 27 04:00:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Jun 2025 04:00:49 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v12]
In-Reply-To: <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>
Message-ID: <fLaMhLmnu4DL9tWGklBFoSpxzmJ1wgdUCDnhGMg4vu0=.e24f3ea3-6e66-4ff6-b2b3-e45432ca5892@github.com>

On Thu, 26 Jun 2025 18:01:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comments, not too wide for my screen...

Still fine

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2964647360

From dholmes at openjdk.org  Fri Jun 27 04:23:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Jun 2025 04:23:39 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <P7T_d1MQlB3SYnSvZNpQ5zTzc0ZNldkFpPq8kHm0mGs=.36235f2e-00d7-47d6-8e84-b4beb0d10807@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
 <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>
 <cpXcKOhPRBxjzYex8ksNboV9x5NtbcvvN0sGQ2nBSGY=.2a62e1f3-b6e2-4b08-b822-8d036d5feed4@github.com>
 <P7T_d1MQlB3SYnSvZNpQ5zTzc0ZNldkFpPq8kHm0mGs=.36235f2e-00d7-47d6-8e84-b4beb0d10807@github.com>
Message-ID: <GnAZcupZstvRpsNbYVNEOtkNHGeSVNfJ2fgVsgF-EQ8=.71b6577c-65e4-4fe3-a0a8-eae2256a2229@github.com>

On Thu, 26 Jun 2025 18:40:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> It can be also written as:
>> `return ClassFile.of().transform(classModel, ClassDesc.of(newClassName), ClassTransform.ACCEPT_ALL`
>> 
>> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself.
>> 
>> Full class remapping was a job of https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/classfile/components/ClassRemapper.html which unfortunately didn't make it from 23 preview to 24 :(
>
> Yes, I wanted to use the ClassRemapper but all the tests that used RedefineClassHelper would have had to add @modules.  We can change it later when ClassRemapper becomes available without adding modules.

> the lambda just copies everything over as-is.
..
> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself.

@coleenp don't we need to class name to be changed everywhere it appears in the classfile? Or do we know these classes are trivial enough that there is only a single occurrence of the name (and everything else is symbolic via the constant pool) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2170732353

From dholmes at openjdk.org  Fri Jun 27 04:23:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Jun 2025 04:23:40 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <GnAZcupZstvRpsNbYVNEOtkNHGeSVNfJ2fgVsgF-EQ8=.71b6577c-65e4-4fe3-a0a8-eae2256a2229@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
 <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>
 <cpXcKOhPRBxjzYex8ksNboV9x5NtbcvvN0sGQ2nBSGY=.2a62e1f3-b6e2-4b08-b822-8d036d5feed4@github.com>
 <P7T_d1MQlB3SYnSvZNpQ5zTzc0ZNldkFpPq8kHm0mGs=.36235f2e-00d7-47d6-8e84-b4beb0d10807@github.com>
 <GnAZcupZstvRpsNbYVNEOtkNHGeSVNfJ2fgVsgF-EQ8=.71b6577c-65e4-4fe3-a0a8-eae2256a2229@github.com>
Message-ID: <c16iUkveQU5whXYe1tadnPHJNu30cPqL9yEUMuCmUEU=.058551a0-bd0b-45f1-8059-6a3cc7273d58@github.com>

On Fri, 27 Jun 2025 04:19:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, I wanted to use the ClassRemapper but all the tests that used RedefineClassHelper would have had to add @modules.  We can change it later when ClassRemapper becomes available without adding modules.
>
>> the lambda just copies everything over as-is.
> ..
>> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself.
> 
> @coleenp don't we need to class name to be changed everywhere it appears in the classfile? Or do we know these classes are trivial enough that there is only a single occurrence of the name (and everything else is symbolic via the constant pool) ?

And `replaceAllStrings` is incorrectly named in that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2170733258

From sspitsyn at openjdk.org  Fri Jun 27 05:10:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 27 Jun 2025 05:10:38 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
Message-ID: <X0gjKY0jD7DAg8IGjkP-6QBuOcVVaPk7M75gn7LGHsU=.709c3dd4-4ec9-4326-9408-2395ebb5ef9c@github.com>

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

This looks mostly okay but I'm waiting for an update suggested by Dan.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2964763745

From sspitsyn at openjdk.org  Fri Jun 27 05:16:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 27 Jun 2025 05:16:42 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v12]
In-Reply-To: <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>
Message-ID: <YqDbM5RvEta6LHXqfi8MT-PJvVX4ebvi385WTfckLcQ=.c265e543-f18b-4c27-90a5-6aa0b713e6fe@github.com>

On Thu, 26 Jun 2025 18:01:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comments, not too wide for my screen...

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25267#pullrequestreview-2964776119

From dholmes at openjdk.org  Fri Jun 27 05:19:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Jun 2025 05:19:46 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
Message-ID: <iJ1fqGjky5Xybny3ZBUlqDSl5GX39Z1G_j0WTbu3FG8=.35b43d03-de1c-4960-933d-ac25f76bece6@github.com>

On Thu, 26 Jun 2025 14:00:43 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8360664 Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()
>   
>   Found by Linux Verification Center (linuxtesting.org) with SVACE.
>   signed-off-by: Artem Semenov <savoptik at altlinux.org>

I think this is a false positive from the static code analyzer. If we are iterating over the heap then the closure is only ever passed actual oops, so it can't be null.

At most I would add an assert, but generally my understanding is that the user of any closure has the responsibility of passing it valid input.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2964779144

From sspitsyn at openjdk.org  Fri Jun 27 05:24:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 27 Jun 2025 05:24:39 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <iJ1fqGjky5Xybny3ZBUlqDSl5GX39Z1G_j0WTbu3FG8=.35b43d03-de1c-4960-933d-ac25f76bece6@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
 <iJ1fqGjky5Xybny3ZBUlqDSl5GX39Z1G_j0WTbu3FG8=.35b43d03-de1c-4960-933d-ac25f76bece6@github.com>
Message-ID: <oLgk3jWJyEEewB3QJ6-vQtSj5wRINkO9APLpKln5oMg=.96378218-8dec-4aaa-b2f8-234a9bbab670@github.com>

On Fri, 27 Jun 2025 05:16:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> At most I would add an assert, but generally my understanding is that the user of any closure has the responsibility of passing it valid input.

Adding asserts sounds like a good suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3011711961

From sspitsyn at openjdk.org  Fri Jun 27 05:29:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 27 Jun 2025 05:29:39 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
Message-ID: <Y5-oQ5HFQnBv2qESxNYHyotOvb0DQf0Z9p1-n0XOZYA=.0d23f856-60a3-44f0-933f-783de6f55fb0@github.com>

On Thu, 26 Jun 2025 14:00:43 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
>> 
>> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.
>
> Artem Semenov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8360664 Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()
>   
>   Found by Linux Verification Center (linuxtesting.org) with SVACE.
>   signed-off-by: Artem Semenov <savoptik at altlinux.org>

I'm a little bit confused why we have twp bugs for this issue.
The bug JDK-8360670 seems to be a dup of:
JDK-8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object()
Should it be closed as a dup?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3011718430

From mbaesken at openjdk.org  Fri Jun 27 06:46:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jun 2025 06:46:42 GMT
Subject: RFR: 8360518: Docker tests do not work when asan is configured
In-Reply-To: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
References: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
Message-ID: <VpVfwX9x_V8MUEBUo8hc0F2oEeDNOcuWe3wkHCYe50w=.029cc2f4-76c1-4434-abee-84c303e69cd8@github.com>

On Wed, 25 Jun 2025 14:09:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When the address sanitizer ASAN is configured, we run into errors in the docker tests.
> Example hotspot/jtreg/containers/docker/DockerBasicTest.java :
> 
> [STDOUT]
> /jdk/bin/java: error while loading shared libraries: libasan.so.8: cannot open shared object file: No such file or directory
> 
> Reason is that the asan-enabled binaries need additional dependencies and those are not available in the current docker/container setups.
> Maybe we should skip those tests when asan is enabled.

Thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25980#issuecomment-3011882972

From mbaesken at openjdk.org  Fri Jun 27 06:46:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Jun 2025 06:46:43 GMT
Subject: Integrated: 8360518: Docker tests do not work when asan is configured
In-Reply-To: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
References: <ZLUP8-Ap-iJ3zOSGBIZ6uRnnD7ElLLhJX6A4gBL3nh0=.94cdf1b3-d6f0-411b-acb9-6d2117271799@github.com>
Message-ID: <6ERwQeDA7fMWBFl59U3xpQbPkmmnO-geBGn33LrLzz0=.d05bece3-d6a8-4278-9f53-42efde8dae61@github.com>

On Wed, 25 Jun 2025 14:09:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When the address sanitizer ASAN is configured, we run into errors in the docker tests.
> Example hotspot/jtreg/containers/docker/DockerBasicTest.java :
> 
> [STDOUT]
> /jdk/bin/java: error while loading shared libraries: libasan.so.8: cannot open shared object file: No such file or directory
> 
> Reason is that the asan-enabled binaries need additional dependencies and those are not available in the current docker/container setups.
> Maybe we should skip those tests when asan is enabled.

This pull request has now been integrated.

Changeset: 01b15bc1
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01b15bc1f961f43ae11db0c15f45763c4ec4180b
Stats:     23 lines in 23 files changed: 23 ins; 0 del; 0 mod

8360518: Docker tests do not work when asan is configured

Reviewed-by: sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/25980

From kevinw at openjdk.org  Fri Jun 27 09:37:41 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 09:37:41 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
Message-ID: <b5Z4NHe9aON4Ri71dKZuJrLsWk6FKna3BNVaFGL2OFo=.b0c97092-fcd5-4c86-90bb-7d697dd83d2f@github.com>

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

I was reproducing this frequently, monitoring with asserts in a fastdebug build and problems started with
ThreadSnapshotFactory::get_thread_snapshot() getting a null from  JNIHandles::resolve(jthread) 

...there are several different crashes in the product build.

> But _thread_h() has already been used a number of times before we get here and if it were null we should have crashed long ago. ???

There can be some that don't cause a problem, like: java_lang_VirtualThread::is_instance(_thread_h());	(includes null check)
..and others are not called.  Hmm maybe there are some that look like they should have crashed, e.g.
1290      _thread_name = OopHandle(oop_storage(), java_lang_Thread::name(_thread_h()));	  <-- name does: return java_thread->obj_field(_name_offset);

...I don't see why this didn't fault in the report from the JBS issue I was interpreting here (not my debug build).  Reordered or something else happened, or just haven't understood enough.  It is much easier to read an assert in get_thread_snapshot than letting it continue and crash in vframestream etc...


But null from JNIHandles::resolve(jthread) is the earliest problem I found.

I'm redoing with the cv_internal_thread_to_JavaThread usage...

A little concerned that 
ThreadsListHandle::cv_internal_thread_to_JavaThread takes jobject jthread, our ref to a java.lang.Thread, and uses 
also calls
811    oop thread_oop = JNIHandles::resolve_non_null(jthread);

...which asserts if contains null, but maybe I don't know all the ThreadsListHandle magic.

I had a day yesterday where the problem would not reproduce at all, which made it hard to verify!  Will update...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3012360012

From duke at openjdk.org  Fri Jun 27 10:12:50 2025
From: duke at openjdk.org (Anton Artemov)
Date: Fri, 27 Jun 2025 10:12:50 GMT
Subject: RFR: 8284016: Normalize handshake closure names
Message-ID: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>

Hi, please consider the following changes:

There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:

`XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`

or

`XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`

or

`XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`

Tested in GHA and tiers 1 - 3.

-------------

Commit messages:
 - 8284016: Fixed ALotOfHandshakeClosure name
 - 8284016: Normalized names of classes derived from HandshakeClosure

Changes: https://git.openjdk.org/jdk/pull/26014/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8284016
  Stats: 165 lines in 25 files changed: 0 ins; 0 del; 165 mod
  Patch: https://git.openjdk.org/jdk/pull/26014.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26014/head:pull/26014

PR: https://git.openjdk.org/jdk/pull/26014

From coleenp at openjdk.org  Fri Jun 27 11:24:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 11:24:59 GMT
Subject: RFR: 8268406: Deallocate jmethodID native memory [v12]
In-Reply-To: <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
 <MhI7r8-DESb7dD8Jqh_BgFjv3z2wuRtoUgKC3On2xdE=.0186bc01-c514-4c6f-b881-57c6bb3ce4f0@github.com>
Message-ID: <R28Y-f75NZnQprupHt_LaNfx1I6eDKcHG-1DoW7hUq8=.2d0a0872-0d91-4d07-b43c-9cea41239415@github.com>

On Thu, 26 Jun 2025 18:01:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
>> 
>> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
>> 
>> Tested with tier1-4, 5-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comments, not too wide for my screen...

Thank you for the reviews, Serguei, David, Dan, Axel and Erik.  And all the discussion, and the idea itself.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-3012657567

From coleenp at openjdk.org  Fri Jun 27 11:25:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 11:25:00 GMT
Subject: Integrated: 8268406: Deallocate jmethodID native memory
In-Reply-To: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
References: <NrZl5yXOiIRbt-6FiwPLPEY04QwU6XzVdPimMOjqKDU=.eec0eae5-0f2f-4dde-a050-e3c639d033e2@github.com>
Message-ID: <MyZ3tVzbIoBPpEt6dqCc2rk8KQIuPT6FwA2duiZpWj0=.098f9807-17cd-474b-91a4-ce46d7453e44@github.com>

On Fri, 16 May 2025 12:18:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses a ConcurrentHashTable to associate Method* with jmethodID, instead of an indirection.  JNI is deprecated in favor of using Panama to call methods, so I don't think we're concerned about JNI performance going forward.  JVMTI uses a lot of jmethodIDs but there aren't any performance tests for JVMTI, but running vmTestbase/nsk/jvmti with in product build with and without this change had no difference in time.
> 
> The purpose of this change is to remove the memory leak when you unload classes: we were leaving the jmethodID memory just in case JVMTI code still had references to that jmethodID and instead of crashing, should get nullptr.  With this change, if JVMTI looks up a jmethodID, we've removed it from the table and will return nullptr.  Redefinition and the InstanceKlass::_jmethod_method_ids is somewhat complicated.  When a method becomes "obsolete" in redefinition, which means that the code in the method is changed, afterward creating a jmethodID from an "obsolete" method will create a new entry in the InstanceKlass table.  This mechanism increases the method_idnum to do this.  In the future maybe we could throw NoSuchMethodError if you try to create a jmethodID out of an obsolete method and remove all this code.  But that's not in this change.
> 
> Tested with tier1-4, 5-7.

This pull request has now been integrated.

Changeset: d8f9b188
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d8f9b188fa488c9c6e343c62a148cfe9fc8a563b
Stats:     695 lines in 16 files changed: 400 ins; 239 del; 56 mod

8268406: Deallocate jmethodID native memory

Reviewed-by: dholmes, sspitsyn, dcubed, eosterlund, aboldtch

-------------

PR: https://git.openjdk.org/jdk/pull/25267

From coleenp at openjdk.org  Fri Jun 27 11:37:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 11:37:30 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v8]
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: <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@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:

  Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/21223e37..17b3b77b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=06-07

  Stats: 18 lines in 2 files changed: 13 ins; 1 del; 4 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  Fri Jun 27 11:37:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 11:37:30 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v7]
In-Reply-To: <DdTqN9gra6nyK-QNbUBtJk35Svm1FP_9jIMGmtVPmWY=.5269ea49-70c5-4a48-8ce1-1c4c763572de@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <DdTqN9gra6nyK-QNbUBtJk35Svm1FP_9jIMGmtVPmWY=.5269ea49-70c5-4a48-8ce1-1c4c763572de@github.com>
Message-ID: <4nEIX_JybFufkCDd80OxD99ToKBEZP15k7qtXlRCPr4=.94c33ec8-faf7-485b-a923-ccb8ae4e0d37@github.com>

On Thu, 26 Jun 2025 11:58:11 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 two additional commits since the last revision:
> 
>  - Update test/lib/RedefineClassHelper.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Fix imports

Also added back the byte[] version of the method that I inadvertently deleted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3012689944

From coleenp at openjdk.org  Fri Jun 27 11:37:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 11:37:31 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <MYN6cPpXYxqDO1uOob_JnqUgHeVNt1eAArYiT79BrgI=.d01ea3e0-0d43-4545-9a9b-cdd4ad061932@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <MYN6cPpXYxqDO1uOob_JnqUgHeVNt1eAArYiT79BrgI=.d01ea3e0-0d43-4545-9a9b-cdd4ad061932@github.com>
Message-ID: <ZdALE988Qzz3aNPSej43q86sVDyEnXE1ba6-qJHZO5o=.f41f37ea-409e-4940-96d2-1902b6c344fb@github.com>

On Thu, 26 Jun 2025 05:03:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Made it even shorter.
>
> test/lib/RedefineClassHelper.java line 35:
> 
>> 33: import jdk.test.lib.helpers.ClassFileInstaller;
>> 34: 
>> 35: import static jdk.test.lib.Asserts.assertTrue;
> 
> Is it really needed? I can't see that assertion were added.

fixed imports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2171715106

From coleenp at openjdk.org  Fri Jun 27 11:37:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 11:37:31 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v6]
In-Reply-To: <c16iUkveQU5whXYe1tadnPHJNu30cPqL9yEUMuCmUEU=.058551a0-bd0b-45f1-8059-6a3cc7273d58@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <vPB47_R-9cZDvCIm17jTlsjELp5Nwi2HmHX-5g60130=.073f44d7-a30d-4182-885c-efc9773d039e@github.com>
 <FlJ0VBhOfOwFrAXVYZoidiv8-PfuetDanfZNHTNS8O8=.abea34ad-c552-4f4a-aec5-6cf2921ef8b4@github.com>
 <yo2RhU8FIlz4PUPS_TkYoppXDxBNikMW9UAE9gsgdGg=.de4a5b44-f61b-4786-946e-9042470372ea@github.com>
 <xfDxZxeRh8pwpHjx_Q2LEnV-nCc_uPN4IKZX893LdfE=.400704d4-a374-4760-9e9e-0c67d57f4336@github.com>
 <cpXcKOhPRBxjzYex8ksNboV9x5NtbcvvN0sGQ2nBSGY=.2a62e1f3-b6e2-4b08-b822-8d036d5feed4@github.com>
 <P7T_d1MQlB3SYnSvZNpQ5zTzc0ZNldkFpPq8kHm0mGs=.36235f2e-00d7-47d6-8e84-b4beb0d10807@github.com>
 <GnAZcupZstvRpsNbYVNEOtkNHGeSVNfJ2fgVsgF-EQ8=.71b6577c-65e4-4fe3-a0a8-eae2256a2229@github.com>
 <c16iUkveQU5whXYe1tadnPHJNu30cPqL9yEUMuCmUEU=.058551a0-bd0b-45f1-8059-6a3cc7273d58@github.com>
Message-ID: <t6i3aNaMelMg5y4D0FbcBTS1r07J9GjNohoYbhqat58=.b276e125-8bb5-4924-a576-c7215c3630fe@github.com>

On Fri, 27 Jun 2025 04:21:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> the lambda just copies everything over as-is.
>> ..
>>> But be aware this code does not change the class name use anywhere in the code, descriptors, handles, annotation, etc..., just the class name itself.
>> 
>> @coleenp don't we need to class name to be changed everywhere it appears in the classfile? Or do we know these classes are trivial enough that there is only a single occurrence of the name (and everything else is symbolic via the constant pool) ?
>
> And `replaceAllStrings` is incorrectly named in that case.

I think if we add less trivial classes to be redefined, we might need to upgrade this to the ClassRemapper.  For now this only renames the classfile.  I've renamed the method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2171711787

From aivanov at openjdk.org  Fri Jun 27 11:57:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jun 2025 11:57:44 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8]
In-Reply-To: <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>
Message-ID: <vWI5H8ceYQIjIidhY4mIYGYza-hAcdeWODbUDEsvWCM=.281ca419-7152-43a9-b2be-8fd5f2e163c8@github.com>

On Thu, 26 Jun 2025 20:56:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2966237280

From asemenov at openjdk.org  Fri Jun 27 12:08:43 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 27 Jun 2025 12:08:43 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <oLgk3jWJyEEewB3QJ6-vQtSj5wRINkO9APLpKln5oMg=.96378218-8dec-4aaa-b2f8-234a9bbab670@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
 <iJ1fqGjky5Xybny3ZBUlqDSl5GX39Z1G_j0WTbu3FG8=.35b43d03-de1c-4960-933d-ac25f76bece6@github.com>
 <oLgk3jWJyEEewB3QJ6-vQtSj5wRINkO9APLpKln5oMg=.96378218-8dec-4aaa-b2f8-234a9bbab670@github.com>
Message-ID: <kap2CKyaG9tnQbcHO8iHWbwo6I3v1t51EzANepGUNIw=.21892aa9-2401-4c54-9bd1-c30fa6f123ee@github.com>

On Fri, 27 Jun 2025 05:22:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > At most I would add an assert, but generally my understanding is that the user of any closure has the responsibility of passing it valid input.
> 
> Adding asserts sounds like a good suggestion.

It seems to me that this won?t be a big problem in this form. I?ve just moved the existing check higher up, where it will prevent dereferencing a null pointer.

However, if you confirm that this is not acceptable, I will replace the check with assert.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3012790447

From kevinw at openjdk.org  Fri Jun 27 12:22:21 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 12:22:21 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Test requires: permit linux debug testing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/d8143785..d14f5228

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From alanb at openjdk.org  Fri Jun 27 12:27:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jun 2025 12:27:44 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
Message-ID: <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>

On Fri, 27 Jun 2025 12:22:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test requires: permit linux debug testing

test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 30:

> 28:  *     an object that is scalar replaced
> 29:  * @requires vm.compMode != "Xcomp"
> 30:  * @requires !vm.debug | (os.family == "linux")

Is this a left over from your local testing? There is nothing Linux specific here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2171915162

From kevinw at openjdk.org  Fri Jun 27 15:02:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 15:02:19 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
 <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>
Message-ID: <3feC9uyBs_fTB_iNDZ1ParDIIxUH1-XJkrznAGrULKo=.221deff1-e3c4-4a49-bf5b-28bea75a88f5@github.com>

On Fri, 27 Jun 2025 12:24:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test requires: permit linux debug testing
>
> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 30:
> 
>> 28:  *     an object that is scalar replaced
>> 29:  * @requires vm.compMode != "Xcomp"
>> 30:  * @requires !vm.debug | (os.family == "linux")
> 
> Is this a left over from your local testing? There is nothing Linux specific here.

I saw the test timeout in debug builds on win and mac (as expected).

On Linux, fastdebug builds run OK, take about 1m30 in CI and could be useful. If further testing doesn't find a timeout issue, I'd like to leave this in, to not exclude linux debug builds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2172202952

From alanb at openjdk.org  Fri Jun 27 15:02:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jun 2025 15:02:20 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <3feC9uyBs_fTB_iNDZ1ParDIIxUH1-XJkrznAGrULKo=.221deff1-e3c4-4a49-bf5b-28bea75a88f5@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
 <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>
 <3feC9uyBs_fTB_iNDZ1ParDIIxUH1-XJkrznAGrULKo=.221deff1-e3c4-4a49-bf5b-28bea75a88f5@github.com>
Message-ID: <g07YvcDKLCHFmhnBkZQiIFY8tF276ot8rbBBlGpkU-k=.b8a7eee8-3a37-4db5-b511-19d6e846db6c@github.com>

On Fri, 27 Jun 2025 14:44:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 30:
>> 
>>> 28:  *     an object that is scalar replaced
>>> 29:  * @requires vm.compMode != "Xcomp"
>>> 30:  * @requires !vm.debug | (os.family == "linux")
>> 
>> Is this a left over from your local testing? There is nothing Linux specific here.
>
> I saw the test timeout in debug builds on win and mac (as expected).
> 
> On Linux, fastdebug builds run OK, take about 1m30 in CI and could be useful. If further testing doesn't find a timeout issue, I'd like to leave this in, to not exclude linux debug builds.

There is nothing Linux in this change or test so I think drop the change to the test and create a separate for the timeout you saw.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2172210930

From kevinw at openjdk.org  Fri Jun 27 15:02:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 15:02:33 GMT
Subject: RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization [v3]
In-Reply-To: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
Message-ID: <aUEon_i5t5cO7-K_tvxvXT-MtYSLb5pJFi8vsDWyNag=.76619804-baa7-4275-80f0-2c8f2695dd00@github.com>

On Wed, 25 Jun 2025 17:28:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments!

Thanks Serguei and Chris for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-3013329005

From kevinw at openjdk.org  Fri Jun 27 15:02:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 15:02:34 GMT
Subject: Integrated: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization
In-Reply-To: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
Message-ID: <YMKt8x0ieUxhOUPtYpmhHUBT_OkGFErDidScLHVYMQ0=.fd20145e-aa95-4418-b2fd-c25f149b4545@github.com>

On Wed, 11 Jun 2025 15:08:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
> 
> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
> 
> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

This pull request has now been integrated.

Changeset: 12196baf
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12196baf6700d00c244747cfa22767e532a4a963
Stats:     82 lines in 2 files changed: 82 ins; 0 del; 0 mod

8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/25758

From kevinw at openjdk.org  Fri Jun 27 15:35:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 15:35:04 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <g07YvcDKLCHFmhnBkZQiIFY8tF276ot8rbBBlGpkU-k=.b8a7eee8-3a37-4db5-b511-19d6e846db6c@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
 <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>
 <3feC9uyBs_fTB_iNDZ1ParDIIxUH1-XJkrznAGrULKo=.221deff1-e3c4-4a49-bf5b-28bea75a88f5@github.com>
 <g07YvcDKLCHFmhnBkZQiIFY8tF276ot8rbBBlGpkU-k=.b8a7eee8-3a37-4db5-b511-19d6e846db6c@github.com>
Message-ID: <uVm-Tb1MDH3bLusrFNLyI1GSSpnLjj0FG_Cej4C9Nv4=.de7c189e-6983-467d-a7e4-c45d410b9cd3@github.com>

On Fri, 27 Jun 2025 14:48:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I saw the test timeout in debug builds on win and mac (as expected).
>> 
>> On Linux, fastdebug builds run OK, take about 1m30 in CI and could be useful. If further testing doesn't find a timeout issue, I'd like to leave this in, to not exclude linux debug builds.
>
> There is nothing Linux in this change or test so I think drop the change to the test and create a separate for the timeout you saw.

Not sure I'm understanding.
This test chooses to rule out running with all debug builds, because it causes timeouts.
I only saw timeouts when I forced it to run in a debug build (win+mac), which are not currently run by choice.
But I'm saying I'm having good results on Linux, so we could weaken that rule, and permit debug builds on Linux.
I can add a comment in the test definition to explain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2172263873

From alanb at openjdk.org  Fri Jun 27 15:35:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jun 2025 15:35:05 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <uVm-Tb1MDH3bLusrFNLyI1GSSpnLjj0FG_Cej4C9Nv4=.de7c189e-6983-467d-a7e4-c45d410b9cd3@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
 <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>
 <3feC9uyBs_fTB_iNDZ1ParDIIxUH1-XJkrznAGrULKo=.221deff1-e3c4-4a49-bf5b-28bea75a88f5@github.com>
 <g07YvcDKLCHFmhnBkZQiIFY8tF276ot8rbBBlGpkU-k=.b8a7eee8-3a37-4db5-b511-19d6e846db6c@github.com>
 <uVm-Tb1MDH3bLusrFNLyI1GSSpnLjj0FG_Cej4C9Nv4=.de7c189e-6983-467d-a7e4-c45d410b9cd3@github.com>
Message-ID: <M0Tw4Ft2-GzsFxd4viSDnkFneiNmlYrwgXXMbaRelgE=.244a9c28-485c-4883-9ceb-07ca9417c4b6@github.com>

On Fri, 27 Jun 2025 15:14:36 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> There is nothing Linux in this change or test so I think drop the change to the test and create a separate for the timeout you saw.
>
> Not sure I'm understanding.
> This test chooses to rule out running with all debug builds, because it causes timeouts.
> I only saw timeouts when I forced it to run in a debug build (win+mac), which are not currently run by choice.
> But I'm saying I'm having good results on Linux, so we could weaken that rule, and permit debug builds on Linux.
> I can add a comment in the test definition to explain.

We added this test that the thread dump can handle eliminated locks. It's not easy to test so deliberately limited to release builds and not -Xcomp. It would require more work on the test to have it be reliable on a wider set of configurations and builds.  There is nothing linux specific. So I think drop the test change from this PR, and create a separate issue to work on a better test for this scenario.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2172294845

From kevinw at openjdk.org  Fri Jun 27 16:00:56 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 16:00:56 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v6]
In-Reply-To: <M0Tw4Ft2-GzsFxd4viSDnkFneiNmlYrwgXXMbaRelgE=.244a9c28-485c-4883-9ceb-07ca9417c4b6@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <ou47lVnG27MkVEArceKwcxbSE4wa9wsDyVoWeeVB9X8=.8596e09f-c838-44f8-bbf5-f88eb1a89221@github.com>
 <VQO_xuUxkASgeC8q6sydar-AUdT6IaTQOQO_W178ULU=.aa7ad874-a83a-4ea2-bd2a-a5405acf8c7c@github.com>
 <3feC9uyBs_fTB_iNDZ1ParDIIxUH1-XJkrznAGrULKo=.221deff1-e3c4-4a49-bf5b-28bea75a88f5@github.com>
 <g07YvcDKLCHFmhnBkZQiIFY8tF276ot8rbBBlGpkU-k=.b8a7eee8-3a37-4db5-b511-19d6e846db6c@github.com>
 <uVm-Tb1MDH3bLusrFNLyI1GSSpnLjj0FG_Cej4C9Nv4=.de7c189e-6983-467d-a7e4-c45d410b9cd3@github.com>
 <M0Tw4Ft2-GzsFxd4viSDnkFneiNmlYrwgXXMbaRelgE=.244a9c28-485c-4883-9ceb-07ca9417c4b6@github.com>
Message-ID: <atklURyW_iDntE_Xm2LjHC1h4nBAbH1Y9aJlq3OUgMo=.8a40300a-9614-4afd-b0c1-21d15739b161@github.com>

On Fri, 27 Jun 2025 15:32:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Not sure I'm understanding.
>> This test chooses to rule out running with all debug builds, because it causes timeouts.
>> I only saw timeouts when I forced it to run in a debug build (win+mac), which are not currently run by choice.
>> But I'm saying I'm having good results on Linux, so we could weaken that rule, and permit debug builds on Linux.
>> I can add a comment in the test definition to explain.
>
> We added this test that the thread dump can handle eliminated locks. It's not easy to test so deliberately limited to release builds and not -Xcomp. It would require more work on the test to have it be reliable on a wider set of configurations and builds.  There is nothing linux specific. So I think drop the test change from this PR, and create a separate issue to work on a better test for this scenario.

Sure then yes it's a temporary leftover from local testing. 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2172314157

From achung at openjdk.org  Fri Jun 27 16:15:51 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 16:15:51 GMT
Subject: Integrated: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <GF5IDxTAhXqzc73VVys13RSJKUc87JeYqSfSPXZjZWM=.997990aa-1178-4323-83b0-de46c0f2b455@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

This pull request has now been integrated.

Changeset: da7080ff
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da7080fffb2389465dc9afca6d02e9085fe15302
Stats:     1196 lines in 71 files changed: 814 ins; 93 del; 289 mod

8359761: JDK 25 RDP1 L10n resource files update

Reviewed-by: aivanov, almatvee, nbenalla, jlu, dnguyen, cstein, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/25839

From lmesnik at openjdk.org  Fri Jun 27 16:55:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 27 Jun 2025 16:55:37 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v8]
In-Reply-To: <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com>
Message-ID: <KwQ1WN6Vb-W4TPfWqaRFkpWpT7UBVt_I3PJt98AilPY=.5408f78b-451c-4ed3-b357-c27f21a8afec@github.com>

On Fri, 27 Jun 2025 11:37:30 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:
> 
>   Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2967240011

From coleenp at openjdk.org  Fri Jun 27 16:55:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 27 Jun 2025 16:55:39 GMT
Subject: RFR: 8284016: Normalize handshake closure names
In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
Message-ID: <7RFaowLX2qq3wCI-adTUMmf6QQt4AjF8ocLkwyNHVJg=.a4e02678-9114-4aef-a4a7-50508d60d736@github.com>

On Fri, 27 Jun 2025 09:10:26 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
> 
> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
> 
> Tested in GHA and tiers 1 - 3.

I found a couple of places to realign the parameters, but otherwise this looks good.  I like the new naming conventions.  We have a lot of handshakes now!
Were you able to build shenandoah (not built by default, need to add --enable-jvm-feature-shenandoahgc to configure)?

src/hotspot/share/prims/jvmtiEnvBase.hpp line 629:

> 627: public:
> 628:   GetCurrentContendedMonitorHandshakeClosure(JvmtiEnv *env,
> 629:                                     JavaThread* calling_thread,

Can you realign these parameters?

src/hotspot/share/prims/jvmtiEnvBase.hpp line 650:

> 648: public:
> 649:   GetStackTraceHandshakeClosure(JvmtiEnv *env, jint start_depth, jint max_count,
> 650:                        jvmtiFrameInfo* frame_buffer, jint* count_ptr)

realign parameters.

src/hotspot/share/prims/jvmtiEnvBase.hpp line 760:

> 758: public:
> 759:   GetSingleStackTraceHandshakeClosure(JvmtiEnv *env, JavaThread *calling_thread,
> 760:                              jthread thread, jint max_frame_count)

Also realign parameters.

src/hotspot/share/prims/jvmtiEnvBase.hpp line 798:

> 796: public:
> 797:   GetFrameLocationHandshakeClosure(JvmtiEnv *env, jint depth,
> 798:                           jmethodID* method_ptr, jlocation* location_ptr)

Also realign parameters.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2967227483
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2172435715
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2172435267
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2172434071
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2172433356

From cjplummer at openjdk.org  Fri Jun 27 17:21:44 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 27 Jun 2025 17:21:44 GMT
Subject: RFR: 8360312: Serviceability Agent tests fail with JFR enabled due
 to unknown thread type JfrRecorderThread [v3]
In-Reply-To: <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
 <0_4zYtZFNx5QA5h_4sQsF1dFV8Zr8dPZZHfKk-UuGRk=.acc9c10c-e720-4101-9e50-5a8edff6035b@github.com>
Message-ID: <b0ZZxBCc6Gax6EA7iI2dWme7--ZLY6uRnccuFKtydMw=.c0a08aee-e46c-4465-8f70-b0aca44e793a@github.com>

On Wed, 25 Jun 2025 17:31:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
>> 
>> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
>> 
>> Testing (in progress):
>> 
>> - [x] tier1 ci
>> - [x] tier1 ci with -XX:StartFlightRecording 
>> - [x] tier5 ci
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing space

Thank you for the reviews Serguei, David, and Kevin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25960#issuecomment-3013850087

From cjplummer at openjdk.org  Fri Jun 27 17:21:44 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 27 Jun 2025 17:21:44 GMT
Subject: Integrated: 8360312: Serviceability Agent tests fail with JFR enabled
 due to unknown thread type JfrRecorderThread
In-Reply-To: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
References: <3XshRFVcxP5VLYu_LNt0qLkXWlxpJREbVreCHZis3Eo=.f826f8cb-8042-42b5-8dd8-e6d5c8f9be39@github.com>
Message-ID: <-pEl3w5pxWYKayDEEwZL4NEVAcOnraU72Yh2X7oJoT4=.9d60ee34-688e-48d0-8e86-60afd89e6506@github.com>

On Tue, 24 Jun 2025 21:15:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Update SA to know about JfrRecorderThread, which was made a JavaThread in JDK 25 by [JDK-8352251](https://bugs.openjdk.org/browse/JDK-8352251).
> 
> I'm also fixing ClhsdbJstackWithConcurrentLock, which was also failing with JFR enabled, but for a different reason (specified heap size was too small).
> 
> Testing (in progress):
> 
> - [x] tier1 ci
> - [x] tier1 ci with -XX:StartFlightRecording 
> - [x] tier5 ci

This pull request has now been integrated.

Changeset: 712d866b
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/712d866b72b43c839c57c3303dfb215f94c0db3b
Stats:     25 lines in 5 files changed: 13 ins; 9 del; 3 mod

8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread

Reviewed-by: sspitsyn, kevinw, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/25960

From cjplummer at openjdk.org  Fri Jun 27 17:31:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 27 Jun 2025 17:31:38 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v2]
In-Reply-To: <kap2CKyaG9tnQbcHO8iHWbwo6I3v1t51EzANepGUNIw=.21892aa9-2401-4c54-9bd1-c30fa6f123ee@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
 <aYpMyI1-2UcB76DZY4Tw1Fn_B08Ss0JwG01x1ZyQDz4=.2f6b8474-4c95-4409-bad9-a60c601d2475@github.com>
 <iJ1fqGjky5Xybny3ZBUlqDSl5GX39Z1G_j0WTbu3FG8=.35b43d03-de1c-4960-933d-ac25f76bece6@github.com>
 <oLgk3jWJyEEewB3QJ6-vQtSj5wRINkO9APLpKln5oMg=.96378218-8dec-4aaa-b2f8-234a9bbab670@github.com>
 <kap2CKyaG9tnQbcHO8iHWbwo6I3v1t51EzANepGUNIw=.21892aa9-2401-4c54-9bd1-c30fa6f123ee@github.com>
Message-ID: <0UUsjnKpCkk0hAUgXZfHR4Vtl2r9-JqY2hAGyNXRz3I=.a05cac71-5193-497e-9f2f-e5b1c65f22ee@github.com>

On Fri, 27 Jun 2025 12:06:21 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> > > At most I would add an assert, but generally my understanding is that the user of any closure has the responsibility of passing it valid input.
> > 
> > 
> > Adding asserts sounds like a good suggestion.
> 
> It seems to me that this won?t be a big problem in this form. I?ve just moved the existing check higher up, where it will prevent dereferencing a null pointer.
> 
> However, if you confirm that this is not acceptable, I will replace the check with assert.

I think it is a matter of having the code accurately document the input requirements. Checking for null and returning makes it look like passing null is ok and might happen. That's not the case though. It should never happen and adding an assert properly documents this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3013875492

From achung at openjdk.org  Fri Jun 27 18:31:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 18:31:40 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>

8359761: JDK 25 RDP1 L10n resource files update

-------------

Commit messages:
 - Backport da7080fffb2389465dc9afca6d02e9085fe15302

Changes: https://git.openjdk.org/jdk/pull/26026/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26026&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1196 lines in 71 files changed: 814 ins; 93 del; 289 mod
  Patch: https://git.openjdk.org/jdk/pull/26026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26026/head:pull/26026

PR: https://git.openjdk.org/jdk/pull/26026

From jlu at openjdk.org  Fri Jun 27 18:48:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Jun 2025 18:48:40 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <K1-1d3pNRFgWpkSWz0z37g8bv6FZDptY3FqWn6mA1YM=.b1642fa3-3131-475d-be48-e46ae826b1ca@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967612181

From aivanov at openjdk.org  Fri Jun 27 18:58:42 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jun 2025 18:58:42 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <kg51-qmlCGiGQD2uT5jUV-tXzjg56nUx10DltgKO0xY=.eec85c62-ad07-4181-bfcb-37b946b625b3@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967634176

From sspitsyn at openjdk.org  Fri Jun 27 19:05:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 27 Jun 2025 19:05:38 GMT
Subject: RFR: 8284016: Normalize handshake closure names
In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
Message-ID: <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>

On Fri, 27 Jun 2025 09:10:26 GMT, Anton Artemov <duke at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
> 
> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
> 
> Tested in GHA and tiers 1 - 3.

Changes requested by sspitsyn (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.hpp line 511:

> 509: };
> 510: 
> 511: class SetForceEarlyReturnHandshakeClosure : public JvmtiUnitedHandshakeClosure {

I do not support this unification over JVMTI files. This make `HandshakeClosure` class names too long.
The JVMTI has a consistent local naming convention to have the suffix `Closure` at the end instead of `HandshakeClosure`. And it is fine because normally there are no other kind of closures in JVMTI code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2967650296
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2172691167

From achung at openjdk.org  Fri Jun 27 19:31:01 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 19:31:01 GMT
Subject: [jdk25] Integrated: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <Lvees89-ahp6rs1DC7OJnMRzhPaBlrM8HoOj1YDdGq4=.d69d8c1f-63dc-43e3-a8d4-bd98d3bb8670@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

This pull request has now been integrated.

Changeset: 12ffb0c1
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12ffb0c131c5100dc23549b9b7216625bc0dab9e
Stats:     1196 lines in 71 files changed: 814 ins; 93 del; 289 mod

8359761: JDK 25 RDP1 L10n resource files update

Reviewed-by: jlu, aivanov
Backport-of: da7080fffb2389465dc9afca6d02e9085fe15302

-------------

PR: https://git.openjdk.org/jdk/pull/26026

From dcubed at openjdk.org  Fri Jun 27 19:50:39 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 27 Jun 2025 19:50:39 GMT
Subject: RFR: 8284016: Normalize handshake closure names
In-Reply-To: <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>
Message-ID: <OxfzZUtbE_DVnlcDyC7_cXzVK_4igL8DrzTwt6voRz4=.05c6969f-5e12-4e2c-b7ad-2dd5b1b674fa@github.com>

On Fri, 27 Jun 2025 19:02:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
>> 
>> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
>> 
>> or
>> 
>> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
>> 
>> Tested in GHA and tiers 1 - 3.
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 511:
> 
>> 509: };
>> 510: 
>> 511: class SetForceEarlyReturnHandshakeClosure : public JvmtiUnitedHandshakeClosure {
> 
> I do not support this unification over JVMTI files. This make `HandshakeClosure` class names too long.
> The JVMTI has a consistent local naming convention to have the suffix `Closure` at the end instead of `HandshakeClosure`. And it is fine because normally there are no other kind of closures in JVMTI code.

Aren't there closures in the JVM/TI tag processing code? I could be remembering wrong...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2172762775

From amenkov at openjdk.org  Fri Jun 27 20:24:39 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 27 Jun 2025 20:24:39 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <VhSGf3zuEY5hzYuNfrGwyy878H6XpAC9brHFGVknA4s=.2761f625-bea7-4858-9014-c19c6aeb9002@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
 <niN-M-iJKHC5QhvtGtvBlgTr2ygodTk0_BR7UQuHeys=.fc2409f9-f97d-4e5d-9f32-40b02816236e@github.com>
 <VhSGf3zuEY5hzYuNfrGwyy878H6XpAC9brHFGVknA4s=.2761f625-bea7-4858-9014-c19c6aeb9002@github.com>
Message-ID: <OD2zZwmclKzwrwpnFSIMzfDHdDqTigI8qZoo5EYrrjQ=.124079b6-bc4c-4b91-b177-0c2c6a49f839@github.com>

On Thu, 26 Jun 2025 00:38:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Line number info puts it in the _java_thread == null branch of: threadService.cpp
> > 1317 vframeStream vfst(_java_thread != nullptr
> > 1318 ? vframeStream(_java_thread, false, true, vthread_carrier)
> > 1319 : vframeStream(java_lang_VirtualThread::continuation(_thread_h()))); <---
> > And it's looking inside the Handle _thread_h() within GetThreadSnapshotClosure which was setup by get_thread_snapshot, and it's a null pointer,
> 
> But `_thread_h()` has already been used a number of times before we get here and if it were null we should have crashed long ago. ???

I believe null here is not result of `_thread_h()`, but is returned by `java_lang_VirtualThread::continuation(...)` because `_thread_h` is lava.lang.Thread object and not java.lang.VirtualThread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3014271659

From amenkov at openjdk.org  Fri Jun 27 20:32:42 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 27 Jun 2025 20:32:42 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <b5Z4NHe9aON4Ri71dKZuJrLsWk6FKna3BNVaFGL2OFo=.b0c97092-fcd5-4c86-90bb-7d697dd83d2f@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <b5Z4NHe9aON4Ri71dKZuJrLsWk6FKna3BNVaFGL2OFo=.b0c97092-fcd5-4c86-90bb-7d697dd83d2f@github.com>
Message-ID: <bjzR-l1wPPXf7YxVjJBSWKPiwWNMtLmV2UF_x0SOi7k=.003e51cc-008a-42f7-9d4c-42777e10a627@github.com>

On Fri, 27 Jun 2025 09:35:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> But null from JNIHandles::resolve(jthread) is the earliest problem I found.
> 
> I'm redoing with the cv_internal_thread_to_JavaThread usage...
> 
> A little concerned that ThreadsListHandle::cv_internal_thread_to_JavaThread takes jobject jthread, our ref to a java.lang.Thread, and uses also calls 811 oop thread_oop = JNIHandles::resolve_non_null(jthread);

JNIHandles::resolve(jthread) can return null only if jthread == nullptr, this should not be possible

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3014285704

From lmesnik at openjdk.org  Sun Jun 29 17:42:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 29 Jun 2025 17:42:50 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
Message-ID: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>

The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.

Here are details:
The breakpoint is set in 2 steps.
1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
 JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
where 
  JvmtiBreakpoint bp(method, location);
is created with this Method* 
Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
 
2) The VMOp is used to add breakpoint into the list 
 VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
  VMThread::execute(&set_breakpoint);
to call  JvmtiBreakpoints::set_at_safepoint()
that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.

So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
VM_RedefineClasses::redefine_single_class()
clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.

Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.

The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.

Looks, like very unlikely but reproducing with stress test after some time.
Verified that the crash is not reproduced anymore with corresponding test after the fix.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/26031/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359366
  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26031/head:pull/26031

PR: https://git.openjdk.org/jdk/pull/26031

From dholmes at openjdk.org  Mon Jun 30 05:00:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Jun 2025 05:00:39 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>

On Sat, 28 Jun 2025 05:02:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.

Approach seems reasonable but it is worrisome that we still have these kinds of issues with class redefinition!  And why has this suddenly appeared? Did a recent code change introduce this bug?

There are a few typos in the change.

src/hotspot/share/prims/jvmtiImpl.cpp line 188:

> 186: 
> 187: void VM_ChangeBreakpoints::doit() {
> 188:  if (_bp->method() != Method::resolve_jmethod_id(_preservred_method)) {

Suggestion:

 if (_bp->method() != Method::resolve_jmethod_id(_preserved_method)) {

src/hotspot/share/prims/jvmtiImpl.cpp line 189:

> 187: void VM_ChangeBreakpoints::doit() {
> 188:  if (_bp->method() != Method::resolve_jmethod_id(_preservred_method)) {
> 189:    // the jmethod_id's method was updated if class redefintion happened for this class

Suggestion:

   // the jmethod_id's method was updated if class redefinition happened for this class

src/hotspot/share/prims/jvmtiImpl.cpp line 191:

> 189:    // the jmethod_id's method was updated if class redefintion happened for this class
> 190:    // after JvmtBreakpoint was created but before JVM_ChangeBreakpoints started
> 191:    // all class breakpoints are cleared during redefinition so don't set/clear this breakpoint

So basically one thread is trying to change this particular BP and it races with another thread that performs redefinition. If the redefinition thread wins then we are turning this current change into a no-op on the basis that the redefinition cleared all BPs anyway so we should not now set this one (if that was requested).

It is very unclear to me how the thread that requested the current change might respond to that request being ignored.

Please add some punctuation to the comment block as it is very hard to read at present. Thanks

src/hotspot/share/prims/jvmtiImpl.hpp line 144:

> 142:   int               _operation;
> 143:   JvmtiBreakpoint*  _bp;
> 144:   jmethodID         _preservred_method; //needed to track class redefintion

Suggestion:

  jmethodID         _preserved_method; //needed to track class redefinition

src/hotspot/share/prims/jvmtiImpl.hpp line 154:

> 152:     _operation = operation;
> 153:     assert(bp != nullptr, "bp != null");
> 154:     _preservred_method = bp->method()->jmethod_id();

Suggestion:

    _preserved_method = bp->method()->jmethod_id();

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2969873307
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174205095
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174206113
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174209649
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174201993
PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174202853

From lmesnik at openjdk.org  Mon Jun 30 05:56:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 05:56:41 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
Message-ID: <_rEYQYLuKwA8su1Kc9Vi-m1kBUVieilE808P1RfkOj8=.7566a310-66d8-4db9-b4cf-7b6e7d742c56@github.com>

On Mon, 30 Jun 2025 04:58:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Approach seems reasonable but it is worrisome that we still have these kinds of issues with class redefinition! And why has this suddenly appeared? Did a recent code change introduce this bug?

There are few things to note here:
1) I recently updated RunThese test  to have more testing in this areas.
2) Coleen, who helped me with class redefinition (many thanks to her!!!) pointed to the change back in 2021 related to this problem 
https://github.com/coleenp/jdk/commit/a05e8e24224b047584c3a273fa7b4fef66798dd6
However, it was not introduced the problem and we would have the same issues before the fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3017892712

From dholmes at openjdk.org  Mon Jun 30 06:00:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Jun 2025 06:00:55 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v8]
In-Reply-To: <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com>
Message-ID: <ZMnJJJcncFC46sTlZtRgjFWUyUFAxSujHKfVnxTJdFg=.ab354b8c-cc4a-4f68-91f5-0a37e94de665@github.com>

On Fri, 27 Jun 2025 11:37:30 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:
> 
>   Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function.

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 56:

> 54:         // redefining the original version of "TestClassXXX" (i.e. "TestClassOld").
> 55:         buf = RedefineClassHelper.replaceClassName(cvar, "TestClassNew", "TestClassXXX");
> 56:         // Now redine the original version of "TestClassXXX" (i.e. "TestClassOld").

Suggestion:

        // Now redefine the original version of "TestClassXXX" (i.e. "TestClassOld").

Pre-existing

test/lib/RedefineClassHelper.java line 85:

> 83:      * @param bytes in original class file.
> 84:      * @param oldClassName old class name.
> 85:      * @param newClassName new class name to replace with old class name.

Suggestion:

     * @param newClassName new class name to replace the old class name.

test/lib/RedefineClassHelper.java line 87:

> 85:      * @param newClassName new class name to replace with old class name.
> 86:      */
> 87:     public static byte[] replaceClassName(byte[] bytes, String oldClassName, String newClassName) throws Exception {

Just realized that `oldClassName` is not actually used. Suggestion:

/*
 * Copy the class defined by `bytes`, replacing the name of the class with `newClassName`, so that both
 * old and new classes can be compiled by jtreg for the test.
 *
 * @param bytes the bytes presenting the original classfile
 * @param newClassName the new class name for the returned class representation
 * @ return a copy of the class represented by `bytes` but with the name `newClassName`
 */
 public static byte[] replaceClassName(byte[] bytes, String newClassName) throws Exception {

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2969920311
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174234229
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174235361
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174242441

From lmesnik at openjdk.org  Mon Jun 30 06:05:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 06:05:39 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
Message-ID: <T4YtAl-zKHw-hCPXmLrNhc_l0fy3F8FdmOXRpHsHYhU=.695b9a41-ebd8-436d-a88a-61bb0c548d50@github.com>

On Mon, 30 Jun 2025 04:42:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 191:
> 
>> 189:    // the jmethod_id's method was updated if class redefintion happened for this class
>> 190:    // after JvmtBreakpoint was created but before JVM_ChangeBreakpoints started
>> 191:    // all class breakpoints are cleared during redefinition so don't set/clear this breakpoint
> 
> So basically one thread is trying to change this particular BP and it races with another thread that performs redefinition. If the redefinition thread wins then we are turning this current change into a no-op on the basis that the redefinition cleared all BPs anyway so we should not now set this one (if that was requested).
> 
> It is very unclear to me how the thread that requested the current change might respond to that request being ignored.
> 
> Please add some punctuation to the comment block as it is very hard to read at present. Thanks

Thanks for feedback.

> It is very unclear to me how the thread that requested the current change might respond to that request being ignored.
> 
The SetBreakpoint returns 'JVMTI_ERROR_NONE' just like method set breakpoint and the breakpoint was removed later by class redfinition.

BTW The alternative would be to replace  _method with new version and set breakpoint like we first redefine classes and then set breakpoint. The both approaches looks valid for specification, I think.

> Please add some punctuation to the comment block as it is very hard to read at present. Thanks
will do this a little bit later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174287943

From duke at openjdk.org  Mon Jun 30 07:43:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 30 Jun 2025 07:43:22 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v2]
In-Reply-To: <7RFaowLX2qq3wCI-adTUMmf6QQt4AjF8ocLkwyNHVJg=.a4e02678-9114-4aef-a4a7-50508d60d736@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <7RFaowLX2qq3wCI-adTUMmf6QQt4AjF8ocLkwyNHVJg=.a4e02678-9114-4aef-a4a7-50508d60d736@github.com>
Message-ID: <VYYZRtNPzO30lb3p0RENFdGx9GMtiry_rPqXmal6MZg=.5473742f-e49f-4401-b6dc-6d0af443ae5d@github.com>

On Fri, 27 Jun 2025 16:45:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I found a couple of places to realign the parameters, but otherwise this looks good. I like the new naming conventions. We have a lot of handshakes now! Were you able to build shenandoah (not built by default, need to add --enable-jvm-feature-shenandoahgc to configure)?

Yes, the code compiles fine with --enable-jvm-feature-shenandoahgc added.

> src/hotspot/share/prims/jvmtiEnvBase.hpp line 629:
> 
>> 627: public:
>> 628:   GetCurrentContendedMonitorHandshakeClosure(JvmtiEnv *env,
>> 629:                                     JavaThread* calling_thread,
> 
> Can you realign these parameters?

Addressed.

> src/hotspot/share/prims/jvmtiEnvBase.hpp line 650:
> 
>> 648: public:
>> 649:   GetStackTraceHandshakeClosure(JvmtiEnv *env, jint start_depth, jint max_count,
>> 650:                        jvmtiFrameInfo* frame_buffer, jint* count_ptr)
> 
> realign parameters.

Addressed.

> src/hotspot/share/prims/jvmtiEnvBase.hpp line 760:
> 
>> 758: public:
>> 759:   GetSingleStackTraceHandshakeClosure(JvmtiEnv *env, JavaThread *calling_thread,
>> 760:                              jthread thread, jint max_frame_count)
> 
> Also realign parameters.

Addressed.

> src/hotspot/share/prims/jvmtiEnvBase.hpp line 798:
> 
>> 796: public:
>> 797:   GetFrameLocationHandshakeClosure(JvmtiEnv *env, jint depth,
>> 798:                           jmethodID* method_ptr, jlocation* location_ptr)
> 
> Also realign parameters.

Addressed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26014#issuecomment-3018119426
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2174428232
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2174428418
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2174428575
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2174429046

From duke at openjdk.org  Mon Jun 30 07:43:21 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 30 Jun 2025 07:43:21 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v2]
In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
Message-ID: <jNWrXGCLiJPDA3MX7YRMGB40PKp4TYRpn3ZO5FbYvHQ=.6a57ef5f-b5d1-4a07-b8d0-09c79c91c81e@github.com>

> Hi, please consider the following changes:
> 
> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
> 
> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
> 
> Tested in GHA and tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8284016: Realigned parameters

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26014/files
  - new: https://git.openjdk.org/jdk/pull/26014/files/fe991cc8..eeb302df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26014.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26014/head:pull/26014

PR: https://git.openjdk.org/jdk/pull/26014

From duke at openjdk.org  Mon Jun 30 07:43:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 30 Jun 2025 07:43:22 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v2]
In-Reply-To: <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>
Message-ID: <cCu2hMKZmGwCx1fOu8vqUcT20KvB8Vs-FJyuYfaX8aU=.36c229e9-7ed8-4db3-b757-b339c2ae1eeb@github.com>

On Fri, 27 Jun 2025 19:02:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284016: Realigned parameters
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 511:
> 
>> 509: };
>> 510: 
>> 511: class SetForceEarlyReturnHandshakeClosure : public JvmtiUnitedHandshakeClosure {
> 
> I do not support this unification over JVMTI files. This make `HandshakeClosure` class names too long.
> The JVMTI has a consistent local naming convention to have the suffix `Closure` at the end instead of `HandshakeClosure`. And it is fine because normally there are no other kind of closures in JVMTI code.

@sspitsyn How about this: instead of xxxHandshakeClosure put xxxHSClosure? HS would stand for Handshake, but the length will increase by only 2 symbols.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2174425304

From iwalulya at openjdk.org  Mon Jun 30 09:45:43 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 09:45:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v17]
In-Reply-To: <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>
Message-ID: <QIkll-XpnhjdS3WJnSynfj90ithzeTtQimWZag7VXBE=.faaaf4e9-6db4-4212-9829-ebf8f0be0ee9@github.com>

On Thu, 26 Jun 2025 19:17:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - cast
>  - remove-young-resize-after-full-gc
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/20e0055e...eeda1eb8

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 354:

> 352: 
> 353: static bool check_gc_heap_free_limit(size_t free_bytes, size_t capacity_bytes) {
> 354:   return free_bytes * 100 / capacity_bytes < GCHeapFreeLimit;

Suggestion:

  return (free_bytes * 100 / capacity_bytes) < GCHeapFreeLimit;

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 425:

> 423:   }
> 424: 
> 425:   if (check_gc_overhead_limit()) {

What is the effect of calling this method twice? Line 400 above, and then again here on line 425. Does that increment `_gc_overhead_counter` twice? More reason why i think the name is confusing.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 756:

> 754: }
> 755: 
> 756: static size_t calculate_free_from_free_ratio_flag(size_t live, uintx free_percent) {

Why refer to the `free_ratio_flag` instead of just `calculate_free_from_free_percent`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2970469808
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174590762
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174637996
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174646534

From iwalulya at openjdk.org  Mon Jun 30 09:45:44 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 09:45:44 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
Message-ID: <2kNEq2gNwn7YKpY5Wj5yAxyKS7J0I64hQ_snRWbPayQ=.b9e3d87e-cb04-423e-b56d-e7a722c16ed5@github.com>

On Mon, 19 May 2025 06:00:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 363:
>> 
>>> 361: }
>>> 362: 
>>> 363: bool ParallelScavengeHeap::check_gc_overhead_limit() {
>> 
>> In main-line code, the method `check_gc_overhead_limit` is invoked by `PSScavenge::invoke` and `PSParallelCompact::invoke_no_policy` so that we can do the check after all the GCs. But now you only use `check_gc_overhead_limit` in `ParallelScavengeHeap::satisfy_failed_allocation`. I suspect whether it can check the gc overhead limit accurately.
>
>> so that we can do the check after all the GCs
> 
> Well, not really. In the old impl, `GCOverheadChecker::check_gc_overhead_limit` calls `set_gc_overhead_limit_exceeded` only for full-gc.
> 
>  > But now you only use check_gc_overhead_limit in ParallelScavengeHeap::satisfy_failed_allocation. I suspect whether it can check the gc overhead limit accurately.
> 
> I believe so.  In the old impl, we don't check gc-overhead for explicit gcs. Only allocation-failure caused gcs are interesting, which all go through `satisfy_failed_allocation`.
> 
> 
>   // Ignore explicit GC's.  Exiting here does not set the flag and
>   // does not reset the count.
>   if (GCCause::is_user_requested_gc(gc_cause) ||
>       GCCause::is_serviceability_requested_gc(gc_cause)) {
>     return;
>   }

`check_gc_overhead_limit` does more than `check`, can we find a more appropriate method name?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174596366

From ayang at openjdk.org  Mon Jun 30 10:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:17:11 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v18]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <0RXvJz_kUMWD8_XusZ0XrlrLQj9960i-iur1w5gpwF4=.b6323262-211a-4ae2-bd2f-1350f6b390ca@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - review
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - remove-young-resize-after-full-gc
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - ... and 17 more: https://git.openjdk.org/jdk/compare/c2d76f98...ec2e3908

-------------

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=17
  Stats: 4362 lines in 31 files changed: 506 ins; 3470 del; 386 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From ayang at openjdk.org  Mon Jun 30 10:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:17:11 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <2kNEq2gNwn7YKpY5Wj5yAxyKS7J0I64hQ_snRWbPayQ=.b9e3d87e-cb04-423e-b56d-e7a722c16ed5@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
 <2kNEq2gNwn7YKpY5Wj5yAxyKS7J0I64hQ_snRWbPayQ=.b9e3d87e-cb04-423e-b56d-e7a722c16ed5@github.com>
Message-ID: <vmNHVwSYlfcV8wdqQzH5N6VgmJLiDwX1onT3570MKM8=.5d2a0fc1-bc17-468a-91b8-d538ff48d5ca@github.com>

On Mon, 30 Jun 2025 09:08:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>>> so that we can do the check after all the GCs
>> 
>> Well, not really. In the old impl, `GCOverheadChecker::check_gc_overhead_limit` calls `set_gc_overhead_limit_exceeded` only for full-gc.
>> 
>>  > But now you only use check_gc_overhead_limit in ParallelScavengeHeap::satisfy_failed_allocation. I suspect whether it can check the gc overhead limit accurately.
>> 
>> I believe so.  In the old impl, we don't check gc-overhead for explicit gcs. Only allocation-failure caused gcs are interesting, which all go through `satisfy_failed_allocation`.
>> 
>> 
>>   // Ignore explicit GC's.  Exiting here does not set the flag and
>>   // does not reset the count.
>>   if (GCCause::is_user_requested_gc(gc_cause) ||
>>       GCCause::is_serviceability_requested_gc(gc_cause)) {
>>     return;
>>   }
>
> `check_gc_overhead_limit` does more than `check`, can we find a more appropriate method name?

The only side-effect is mutating `_gc_overhead_counter`, which I believe is part of checking gc overhead limit. Do you have any names in mind?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174712372

From ayang at openjdk.org  Mon Jun 30 10:17:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:17:12 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v17]
In-Reply-To: <QIkll-XpnhjdS3WJnSynfj90ithzeTtQimWZag7VXBE=.faaaf4e9-6db4-4212-9829-ebf8f0be0ee9@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>
 <QIkll-XpnhjdS3WJnSynfj90ithzeTtQimWZag7VXBE=.faaaf4e9-6db4-4212-9829-ebf8f0be0ee9@github.com>
Message-ID: <p1dthm5Kd35YJTjcZ3NOudqQ_nnHR8KSaqc6nrI4vnk=.d2c02841-7a2d-4a5e-9c2d-2d7c0ba76728@github.com>

On Mon, 30 Jun 2025 09:29:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - cast
>>  - remove-young-resize-after-full-gc
>>  - Merge branch 'master' into pgc-size-policy
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - version
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/20e0055e...eeda1eb8
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 425:
> 
>> 423:   }
>> 424: 
>> 425:   if (check_gc_overhead_limit()) {
> 
> What is the effect of calling this method twice? Line 400 above, and then again here on line 425. Does that increment `_gc_overhead_counter` twice? More reason why i think the name is confusing.

This method checks after-gc gc-ratio and memory limit, so it is meant to be called after every (young/old) gc. (Increment `_gc_overhead_counter` is an impl detail, that is not visible at this abstraction level, IMO.)

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 756:
> 
>> 754: }
>> 755: 
>> 756: static size_t calculate_free_from_free_ratio_flag(size_t live, uintx free_percent) {
> 
> Why refer to the `free_ratio_flag` instead of just `calculate_free_from_free_percent`?

It's mostly due to how the cmdline flag is named. See one of the callsite: `calculate_free_from_free_ratio_flag(old_gen_live_size, MinHeapFreeRatio);`.

I think this method can be renamed after the cmdline flag is renamed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174707957
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174709739

From ayang at openjdk.org  Mon Jun 30 10:24:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:24:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/ec2e3908..d1ff874a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=17-18

  Stats: 9 lines in 3 files changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

PR: https://git.openjdk.org/jdk/pull/25000

From coleenp at openjdk.org  Mon Jun 30 11:22:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 11:22:57 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v9]
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: <NZu9VNxHt-4xOZ2-ckLFngSHmy2zbYLlqLrPFxYi3Ms=.f9f4800d-a3a8-4957-acf9-b676da08c099@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 two additional commits since the last revision:

 - Update test/lib/RedefineClassHelper.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/17b3b77b..8f360d65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=07-08

  Stats: 2 lines in 2 files changed: 0 ins; 0 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 kevinw at openjdk.org  Mon Jun 30 11:24:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jun 2025 11:24:28 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v7]
In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
Message-ID: <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>

> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - remove test definition changes
 - TLH: use cv_internal_thread_to_JavaThread()
 - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited
 - Test requires: permit linux debug testing
 - comment update
 - comment update
 - newline
 - Test fails on minimal VM: require jvmti feature
 - Correct THROW macro
 - ThreadDumper thread count
 - ... and 3 more: https://git.openjdk.org/jdk/compare/80dc9acb...e2043438

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25958/files
  - new: https://git.openjdk.org/jdk/pull/25958/files/d14f5228..e2043438

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=05-06

  Stats: 7800 lines in 367 files changed: 3791 ins; 2583 del; 1426 mod
  Patch: https://git.openjdk.org/jdk/pull/25958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958

PR: https://git.openjdk.org/jdk/pull/25958

From dholmes at openjdk.org  Mon Jun 30 11:24:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Jun 2025 11:24:28 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <OD2zZwmclKzwrwpnFSIMzfDHdDqTigI8qZoo5EYrrjQ=.124079b6-bc4c-4b91-b177-0c2c6a49f839@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <_qD_bLdpHkOQRTWkFV43-L_IGMMgOfosOn7zxb7I7gM=.e2afadc1-1ce1-45da-a695-1920686f8f5f@github.com>
 <niN-M-iJKHC5QhvtGtvBlgTr2ygodTk0_BR7UQuHeys=.fc2409f9-f97d-4e5d-9f32-40b02816236e@github.com>
 <VhSGf3zuEY5hzYuNfrGwyy878H6XpAC9brHFGVknA4s=.2761f625-bea7-4858-9014-c19c6aeb9002@github.com>
 <OD2zZwmclKzwrwpnFSIMzfDHdDqTigI8qZoo5EYrrjQ=.124079b6-bc4c-4b91-b177-0c2c6a49f839@github.com>
Message-ID: <CzZ9u9E6iCaaDP1Z58nGyD-Lum7t8JlTSiXaysAql8c=.05342e15-04d1-41dc-a599-e99192fd443e@github.com>

On Fri, 27 Jun 2025 20:22:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I believe null here is not result of `_thread_h()`, but is returned by `java_lang_VirtualThread::continuation(...)` because `_thread_h` is lava.lang.Thread object and not java.lang.VirtualThread.

That could only happen if we are dealing with a terminated regular thread - which we should never do here if the TLH is used correctly and we only ever pass live threads to `do_thread`, or else the null which means "unmounted virtual thread".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3017944031

From kevinw at openjdk.org  Mon Jun 30 11:26:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jun 2025 11:26:42 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v5]
In-Reply-To: <UeevvX3OnOnXb7FbnmN3CB4_YYlkURHC8NSRn847CVo=.49e032a4-efe3-4dbe-8377-735f9dcced53@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <l3uoeFy8h34z7BH8vIPvvpvrqmV3CA7cmvlkEy3KGog=.feef88d2-8c45-4fff-9e00-92ed3f2c6a52@github.com>
 <6sxeRs0jaGtjCoxcJLBksWiyacOvRkSn40GXcLNKEos=.e4736687-f826-4a11-977e-9b0cf765e046@github.com>
 <XsLqb1GyRm-D5T7ZVQMPQ08LhQ1FDPx8yuMnz7e8C6Q=.f721eb84-2176-4c17-b19e-34670a250890@github.com>
 <UeevvX3OnOnXb7FbnmN3CB4_YYlkURHC8NSRn847CVo=.49e032a4-efe3-4dbe-8377-735f9dcced53@github.com>
Message-ID: <4yFDEaYCx6ooltPbt2hSAd2h2Khnf9ZbAQaZvcK8a8g=.259b71d9-1daa-421b-8226-7e928dfe0f77@github.com>

On Thu, 26 Jun 2025 08:26:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Great catch Dan! I totally missed the TLH at the start of `get_thread_snapshot`. I knew something was off here but couldn't quite put my finger on it.
>
> Yes thanks Dan! Will update.

Thanks for all the hints, updated to use the TLH.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2174844271

From coleenp at openjdk.org  Mon Jun 30 11:38:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 11:38:23 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v10]
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: <p3Fk4sDNm-uQ_1IVTvIlYoMAM0uKZGxKG74lB4FSKEc=.7f4ccbc8-2307-445b-9db6-1a8523b43c56@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:

  Upgraded comment, and removed oldClassName from the bytes version.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/8f360d65..3fc05102

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=08-09

  Stats: 9 lines in 1 file changed: 1 ins; 0 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  Mon Jun 30 11:38:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 11:38:24 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v8]
In-Reply-To: <ZMnJJJcncFC46sTlZtRgjFWUyUFAxSujHKfVnxTJdFg=.ab354b8c-cc4a-4f68-91f5-0a37e94de665@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <-Ml2lEdV97XyLVQXNzAOjtcIvkRg0lFG6eqwccvT5Ig=.1675ffe4-1af1-433a-901f-f67d675ab501@github.com>
 <ZMnJJJcncFC46sTlZtRgjFWUyUFAxSujHKfVnxTJdFg=.ab354b8c-cc4a-4f68-91f5-0a37e94de665@github.com>
Message-ID: <tuTg5mcqGFmrnghEMIJpUWF8m05l2cCobLlia9A0tWA=.2431d0dd-8a5f-4562-851f-cd73c96c1041@github.com>

On Mon, 30 Jun 2025 05:22:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename replaceAllStrings to replaceClassName and add back the byte buffer version of the function.
>
> test/lib/RedefineClassHelper.java line 87:
> 
>> 85:      * @param newClassName new class name to replace with old class name.
>> 86:      */
>> 87:     public static byte[] replaceClassName(byte[] bytes, String oldClassName, String newClassName) throws Exception {
> 
> Just realized that `oldClassName` is not actually used. Suggestion:
> 
> /*
>  * Copy the class defined by `bytes`, replacing the name of the class with `newClassName`, so that both
>  * old and new classes can be compiled by jtreg for the test.
>  *
>  * @param bytes the bytes presenting the original classfile
>  * @param newClassName the new class name for the returned class representation
>  * @ return a copy of the class represented by `bytes` but with the name `newClassName`
>  */
>  public static byte[] replaceClassName(byte[] bytes, String newClassName) throws Exception {

Thanks David for the comment text, I changed it slightly because I didn't understand what the word presenting meant in that sentence.  Also removed the parameter.  We can add it back when the class file remapper API is available without having to add --add-modules to all the tests.  If we need to make the old classfiles substitute more than the name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174862057

From coleenp at openjdk.org  Mon Jun 30 11:56:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 11:56:41 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
Message-ID: <tZrGpazX4T_VfgAysR4rsujIRxpcv-3K-ly9eZWj0-Y=.e980026a-15b6-4f67-aaf3-97cbee9b1875@github.com>

On Mon, 30 Jun 2025 04:38:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
>> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
>> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
>> 
>> Here are details:
>> The breakpoint is set in 2 steps.
>> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
>> where 
>>   JvmtiBreakpoint bp(method, location);
>> is created with this Method* 
>> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>>  
>> 2) The VMOp is used to add breakpoint into the list 
>>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>>   VMThread::execute(&set_breakpoint);
>> to call  JvmtiBreakpoints::set_at_safepoint()
>> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
>> 
>> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
>> VM_RedefineClasses::redefine_single_class()
>> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
>> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
>> 
>> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
>> 
>> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
>> 
>> Looks, like very unlikely but reproducing with stress test after some time.
>> Verified that the crash is not reproduced anymore with corresponding test after the fix.
>> 
>> Many thanks to Coleen for detailed explanation of class redefinition.
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 188:
> 
>> 186: 
>> 187: void VM_ChangeBreakpoints::doit() {
>> 188:  if (_bp->method() != Method::resolve_jmethod_id(_preservred_method)) {
> 
> Suggestion:
> 
>  if (_bp->method() != Method::resolve_jmethod_id(_preserved_method)) {

I see what you're doing.  You're checking if the methodID is changed by redefinition. Can you just check if the method->is_old() and skip the breakpoint then?  Although the callers might want a breakpoint at the new method if it's emcp.  Maybe it could call Method::get_new_method() if is_old and set the breakpoint on the new method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174895443

From duke at openjdk.org  Mon Jun 30 11:57:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 30 Jun 2025 11:57:23 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
Message-ID: <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>

> Hi, please consider the following changes:
> 
> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way:
> 
> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure`
> 
> or
> 
> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure`
> 
> Tested in GHA and tiers 1 - 3.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8284016: Reverted closure names in JVMTI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26014/files
  - new: https://git.openjdk.org/jdk/pull/26014/files/eeb302df..65b9ecc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=01-02

  Stats: 76 lines in 7 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/26014.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26014/head:pull/26014

PR: https://git.openjdk.org/jdk/pull/26014

From duke at openjdk.org  Mon Jun 30 11:57:23 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 30 Jun 2025 11:57:23 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <OxfzZUtbE_DVnlcDyC7_cXzVK_4igL8DrzTwt6voRz4=.05c6969f-5e12-4e2c-b7ad-2dd5b1b674fa@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <hDkiEgm76jJ_6qspuNO_YxlNjVbPiaJtq2wHoB93YBQ=.316ef3e7-7538-4648-8871-88deea8b8954@github.com>
 <OxfzZUtbE_DVnlcDyC7_cXzVK_4igL8DrzTwt6voRz4=.05c6969f-5e12-4e2c-b7ad-2dd5b1b674fa@github.com>
Message-ID: <BbeTm6iCHsR7YGVoOl1u_nDm6vQTP965CNah4RC6yl8=.9beb52f0-a241-458b-8823-5930dffd8763@github.com>

On Fri, 27 Jun 2025 19:48:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.hpp line 511:
>> 
>>> 509: };
>>> 510: 
>>> 511: class SetForceEarlyReturnHandshakeClosure : public JvmtiUnitedHandshakeClosure {
>> 
>> I do not support this unification over JVMTI files. This make `HandshakeClosure` class names too long.
>> The JVMTI has a consistent local naming convention to have the suffix `Closure` at the end instead of `HandshakeClosure`. And it is fine because normally there are no other kind of closures in JVMTI code.
>
> Aren't there closures in the JVM/TI tag processing code? I could be remembering wrong...

I reverted closure names changes in JVMT files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2174895464

From coleenp at openjdk.org  Mon Jun 30 11:59:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 11:59:38 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <tZrGpazX4T_VfgAysR4rsujIRxpcv-3K-ly9eZWj0-Y=.e980026a-15b6-4f67-aaf3-97cbee9b1875@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
 <tZrGpazX4T_VfgAysR4rsujIRxpcv-3K-ly9eZWj0-Y=.e980026a-15b6-4f67-aaf3-97cbee9b1875@github.com>
Message-ID: <cgsQS20ysQIFhrTJTF8_IlLp6wUKFkut8HeLQeCEqOQ=.eb5e965a-ad91-46f3-ae05-83894dd98840@github.com>

On Mon, 30 Jun 2025 11:53:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiImpl.cpp line 188:
>> 
>>> 186: 
>>> 187: void VM_ChangeBreakpoints::doit() {
>>> 188:  if (_bp->method() != Method::resolve_jmethod_id(_preservred_method)) {
>> 
>> Suggestion:
>> 
>>  if (_bp->method() != Method::resolve_jmethod_id(_preserved_method)) {
>
> I see what you're doing.  You're checking if the methodID is changed by redefinition. Can you just check if the method->is_old() and skip the breakpoint then?  Although the callers might want a breakpoint at the new method if it's emcp.  Maybe it could call Method::get_new_method() if is_old and set the breakpoint on the new method?

Or as you say, the breakpoint will be cleared by the redefinition anyway if the VM_ChangeBreakpoints::doit() succeeded before it, so returning an error should be fine too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2174902032

From dholmes at openjdk.org  Mon Jun 30 12:32:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 30 Jun 2025 12:32:42 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v10]
In-Reply-To: <p3Fk4sDNm-uQ_1IVTvIlYoMAM0uKZGxKG74lB4FSKEc=.7f4ccbc8-2307-445b-9db6-1a8523b43c56@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <p3Fk4sDNm-uQ_1IVTvIlYoMAM0uKZGxKG74lB4FSKEc=.7f4ccbc8-2307-445b-9db6-1a8523b43c56@github.com>
Message-ID: <bUkyiqVEF4veEcCOMYblsVTaOCIu_7i8wIJPEZMVeBo=.e85d2d58-c3e6-41cd-b215-2b9e165bc15e@github.com>

On Mon, 30 Jun 2025 11:38:23 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:
> 
>   Upgraded comment, and removed oldClassName from the bytes version.

Update looks good. Just a couple of typos - sorry.

test/lib/RedefineClassHelper.java line 80:

> 78: 
> 79:     /*
> 80:      * Copy the class defined by `bytes`, replacing the nameof the class with `newClassName`,

Suggestion:

     * Copy the class defined by `bytes`, replacing the name of the class with `newClassName`,

test/lib/RedefineClassHelper.java line 85:

> 83:      * @param bytes read from the original class file.
> 84:      * @param newClassName new class name for the returned class representation
> 85:      * @return a copy of the class representated by `bytes` but with the name `newClassName`

Suggestion:

     * @return a copy of the class represented by `bytes` but with the name `newClassName`

test/lib/RedefineClassHelper.java line 99:

> 97:      * @param oldClassName old class name.
> 98:      * @param newClassName new class name to replace with old class name.
> 99:      * @return a copy of the class representated by `bytes` but with the name `newClassName`

Suggestion:

     * @return a copy of the class represented by `bytes` but with the name `newClassName`

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2971040481
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174957181
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174958951
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2174960419

From asemenov at openjdk.org  Mon Jun 30 13:03:23 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 30 Jun 2025 13:03:23 GMT
Subject: RFR: 8360664: Null pointer dereference in
 src/hotspot/share/prims/jvmtiTagMap.cpp in
 IterateOverHeapObjectClosure::do_object() [v3]
In-Reply-To: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
References: <su_uN3UytQwX13Jlsh146UHEhIAnp0AXh_t3ljEDmqk=.04e545d1-4966-43ca-b4b8-e0ca0a7928b7@github.com>
Message-ID: <MwD7f4CR5X3GrfPDIBXn89HtVN5pNkcY0HwhhazWMzM=.610e3c72-2018-4319-8d68-b1546ad63368@github.com>

> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference.
> 
> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  changed if tu assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26002/files
  - new: https://git.openjdk.org/jdk/pull/26002/files/e69c49c8..88f1e494

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26002/head:pull/26002

PR: https://git.openjdk.org/jdk/pull/26002

From kevinw at openjdk.org  Mon Jun 30 13:08:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jun 2025 13:08:28 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object [v3]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <QUnVLEixD1wlX-Fe5XBgzNnUbUcXKMWb8DlDvkNae0U=.49f64722-ef86-4a5f-b8c9-d2392983e5b0@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - (C)
 - Merge remote-tracking branch 'upstream/master' into 8359809_AttributeList_stricter
 - fewer checkTypeSafe calls in RoleList and RoleUnresolvedList
 - Merge remote-tracking branch 'upstream/master' into 8359809_AttributeList_stricter
 - test/jdk/javax/management/generified/ListTypeCheckTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/afb05434..ab4fef2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=01-02

  Stats: 7783 lines in 366 files changed: 3782 ins; 2576 del; 1425 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

PR: https://git.openjdk.org/jdk/pull/25856

From larry.cable at oracle.com  Mon Jun 30 15:38:21 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Mon, 30 Jun 2025 08:38:21 -0700
Subject: Interest in Java based attach provider implementation?
In-Reply-To: <34520a71-a101-4973-8eaa-db2f4eef9fa4@gmx.net>
References: <4b22f750-721f-e178-6618-0f0fb062c921@gmx.net>
 <839c95d5-7965-4065-8d8c-75c21eb79f8e@gmx.net>
 <112cc394-b8a9-412a-9ca8-114a73994607@oracle.com>
 <34520a71-a101-4973-8eaa-db2f4eef9fa4@gmx.net>
Message-ID: <3a603ae5-bef4-44d4-b1df-26b8bc683763@oracle.com>

note that for *nix systems that use SIGQUIT as an initiator for attach, 
there exists a potential fatal "bug" where (especially a programmatic) 
attach attempt may send SIGQUIT before the target/attachee JVM has 
initialized such that its signal handlers
are installed.

If the target JVM has not initialized its sig handlers when SIGQUIT is 
received the default action will occur, which is to terminate
the process.

on Linux, this is avoided by a "busy wait" polling the sigmasks of the 
target processes 'stat' file (in /proc) the only way to obtain
this info on MacOS is to use sysctl as mentioned in (4) below.

I would avoid using jextract to model the kernel structures and simply 
call the existing native API (via FFM instead of JNI as it is today) to 
read the sigmasks - there is no need to go directly to sysctl & kernel 
data structures.

I would certainly *not* remove this as it will cause an (actual) 
regression in behaviors.

As to Windows, it operates differently to *nix, I believe (but I could 
be wrong) due to differences in O.S relating to asynch inter-
process signalling and UDS behavior

Rgds

- Larry

On 6/24/25 7:30 AM, Philippe Marschall wrote:
> Hello
>
> Since the audience has been expanded let me summarize what would be 
> needed to make jdk.attach free of JNI on Unix (AIX, Linux, macOS). 
> jdk.attach currently uses JNI for four different things.
>
> 1. reading and writing unix domain sockets
> 2. accessing uid, guid and permissions of a file
> 3. sending SIGQUIT to an arbitrary PID, including self in the case of 
> self attach
> 4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid}) on macOS
>
> For 1. and 2. there are already supported Java based APIs and I have 
> patches in case somebody is willing to sponsor this work / open a JIRA.
>
> 3. kill(SIGQUIT)
>
> This can be done quite easily using FFM as the signature of kill() is 
> quite simple. The signature and values are the same an Linux and macOS 
> and I assume AIX as well, but I don't have access to a machine to 
> verify. Overlap with existing code is with ProcessHandleImpl.destroy0 
> which sends SIGKILL or SIGTERM to a PID but performs additional 
> checks. So an API to send a signal to a PID would be needed. It is my 
> understanding that jdk.internal.misc.Signal only supports sending 
> signal to self.
>
> 4. sysctl({CTL_KERN, KERN_PROC, KERN_PROC_PID, pid})
>
> This is more complicated as the kinfo_proc and extern_proc structs are 
> quite large. jextract is the easiest way to come up with the 
> definitions. However the amount of generated code is quite large even 
> after filtering. The generated code can be further cut down using 
> manual editing. I have not yet looked into replacing not needed struct 
> fields with padding. To the best of my knowledge jextract hasn't the 
> been included into the JDK build.
> Overlap here is in ProcessHandleImpl_macosx.c with the functions 
> os_getParentPidAndTimings and getUID but they access different fields 
> of extern_proc.
> Honestly here I'm not sure why this check is needed at all. The 
> reasoning given for the check in VirtualMachineImpl.c would in my 
> option apply to Linux and AIX as well but this check is not performed 
> there. Removing this check from the macOS implementation would 
> obviously be the easiest.
>
> I can't speak for Windows as I'm not familiar enough with Windows APIs.
>
> Cheers
> Philippe
>
>
> On 19.06.25 14:40, Magnus Ihse Bursie wrote:
>> Hi Philippe,
>>
>> There is an ongoing effort about "Panamization" (that is, adapting it 
>> to use FFM instead of JNI) of native code in the JDK in general. This 
>> is discussed on the core-libs-dev mailing list. I've cc:ed them. I 
>> think it would be beneficial if you coordinate your efforts with the 
>> Panamization effort.
>>
>> /Magnus
>>
>>
>> On 2025-06-15 17:43, Philippe Marschall wrote:
>>> Hello
>>>
>>> I further pursued the approach
>>>
>>> - Rebased the Linux implementation [1], implemented the permission 
>>> check using JSR 203 and the Unix domain sockets using JEP 380.
>>> - Applied the same changes to the AIX implementation [2].
>>> - Switched Linux to an FFM based kill implementation [3], completely 
>>> getting rid of JNI.
>>> -? Updated the macOS implementation [4], implemented the permission 
>>> check using JSR 203 and the Unix domain sockets using JEP 380.
>>> - Switched macOS to an FFM based kill and sysctl implementation [5], 
>>> completely getting rid of JNI.
>>>
>>> I ran the serviceability test suite on Linux and macOS and it 
>>> passes. I manually verified that I can attach to JVMs using local 
>>> builds.
>>>
>>> I could not test on AIX.
>>>
>>> ?[1] https://github.com/marschall/jdk/ 
>>> commit/3a7796daadad7c9d2d85e9e4623f170baecc0e41
>>> ?[2] https://github.com/marschall/jdk/ 
>>> commit/962729e0bfb6b7d86af303f25c6670d407d1d2d9
>>> ?[3] https://github.com/marschall/jdk/ 
>>> commit/7b5f1bf6f55458a7f69f50b8fdf4986e22202559
>>> ?[4] https://github.com/marschall/jdk/ 
>>> commit/93372a124eca6078fde5597c2498b381a4ef5dfa
>>> ?[5] https://github.com/marschall/jdk/commit/ 
>>> c5faf9655bbb85cc3ed9b2a7ef15b08ab83d1d8b
>>>
>>> Cheers
>>> Philippe
>>>
>>> On 20.04.22 22:13, Philippe Marschall wrote:
>>>> Hello
>>>>
>>>> I hope this is the right mailing list. I recently had a look at the
>>>> Linux attach provider implementation and could not help but noticing
>>>> that a large part, if not all of it, could be replaced with Java.
>>>> Besides getting rid of the C code this should allow us to unify the 
>>>> AIX,
>>>> Linux and macOS implementations under a single Unix implementation.
>>>>
>>>> The permission check can be implemented using JSR 203 [1] to access 
>>>> uid,
>>>> gid and file mode and using jdk.internal.misc.VM to get the euid 
>>>> and egid.
>>>>
>>>> Reading and writing to Unix domain sockets can be done through JEP 
>>>> 380 [2].
>>>>
>>>> Sending SIGQUIT to a process could in theory done through JEP 102 [3]
>>>> however sending SIGQUIT to self is currently blocked. This is required
>>>> for the self attach mechanism. There a very small C function is still
>>>> needed for now, this is hopefully portable.
>>>>
>>>> I did a small prototype [4]. The tier1 suite runs and I can attach 
>>>> to a
>>>> local JVM.
>>>>
>>>> The overhead will likely be a bit higher as we go through more JDK
>>>> abstractions.
>>>>
>>>> ??[1] https://jcp.org/en/jsr/detail?id=203
>>>> ??[2] https://openjdk.java.net/jeps/380
>>>> ??[3] https://openjdk.java.net/jeps/102
>>>> ??[4]
>>>> https://github.com/marschall/jdk/ 
>>>> commit/207dac7e4d1bd65450bbd2c9e14d33fc34b7cebc
>>>>
>>>> Cheers
>>>> Philippe
>>>
>


From coleenp at openjdk.org  Mon Jun 30 16:49:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 16:49:02 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v11]
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: <mIHdl4_tc3bd4M13BlvV2CPjgZafZ7Yn5c7ohmCA7W4=.89aada01-a41a-47ed-a1ab-0c593cd45187@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 three additional commits since the last revision:

 - Update test/lib/RedefineClassHelper.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update test/lib/RedefineClassHelper.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update test/lib/RedefineClassHelper.java
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25857/files
  - new: https://git.openjdk.org/jdk/pull/25857/files/3fc05102..791f2146

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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  Mon Jun 30 16:49:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 30 Jun 2025 16:49:02 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v10]
In-Reply-To: <p3Fk4sDNm-uQ_1IVTvIlYoMAM0uKZGxKG74lB4FSKEc=.7f4ccbc8-2307-445b-9db6-1a8523b43c56@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <p3Fk4sDNm-uQ_1IVTvIlYoMAM0uKZGxKG74lB4FSKEc=.7f4ccbc8-2307-445b-9db6-1a8523b43c56@github.com>
Message-ID: <bEzMgFEiMZxOK2JqugpN9Xz-4DFURhigDtTAl5HYLdk=.212eae0a-08be-44da-aa33-2965a7d89c45@github.com>

On Mon, 30 Jun 2025 11:38:23 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:
> 
>   Upgraded comment, and removed oldClassName from the bytes version.

Thanks David for the suggested changes for the typos, and for the suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3019949813

From kevinw at openjdk.org  Mon Jun 30 17:31:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jun 2025 17:31:53 GMT
Subject: RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of Object [v4]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <HqsWHEsDJ8gsdk92cv7FIIiiR6X56c3vUpOazz8IoLs=.2e9b6edd-d5a6-4bad-8a40-bfd65efb77b3@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Test update, over listIterator and iterator.set()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/ab4fef2f..8b36d3e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=02-03

  Stats: 30 lines in 1 file changed: 12 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

PR: https://git.openjdk.org/jdk/pull/25856

From amenkov at openjdk.org  Mon Jun 30 18:42:41 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 30 Jun 2025 18:42:41 GMT
Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch
 [v7]
In-Reply-To: <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com>
 <S2k8pm9l7CwwBKf5R4pwt-idpLPs01aNnNXtum6zy4U=.10a1952a-5b08-40ef-a2a4-36c3757bdba3@github.com>
Message-ID: <qSDpDgc_hs3__h41XDIxnw_78Q4Vqhn_Cv_JkxuVakY=.90d3aa8d-76ae-4c3b-ac70-1b8efa989ad0@github.com>

On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - remove test definition changes
>  - TLH: use cv_internal_thread_to_JavaThread()
>  - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited
>  - Test requires: permit linux debug testing
>  - comment update
>  - comment update
>  - newline
>  - Test fails on minimal VM: require jvmti feature
>  - Correct THROW macro
>  - ThreadDumper thread count
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/9337a35b...e2043438

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2972270226

From sspitsyn at openjdk.org  Mon Jun 30 20:42:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 30 Jun 2025 20:42:39 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <_rEYQYLuKwA8su1Kc9Vi-m1kBUVieilE808P1RfkOj8=.7566a310-66d8-4db9-b4cf-7b6e7d742c56@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <gQqj1ilOK7nEWYSjlHR57822zOuJ_Wbbn-djIsK1pqs=.8194d0d1-d486-4c5d-9b41-48cdf55be3eb@github.com>
 <_rEYQYLuKwA8su1Kc9Vi-m1kBUVieilE808P1RfkOj8=.7566a310-66d8-4db9-b4cf-7b6e7d742c56@github.com>
Message-ID: <sMa7TfFEBTL5hIBtxSH-ipykDp9k2Xh1S2pH4T00E2k=.d1410313-e79b-41aa-815b-c7513ddc919d@github.com>

On Mon, 30 Jun 2025 05:53:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I recently updated RunThese test to have more testing in this areas.

As I understand you've added some specific stressing to reliably catch issues like this one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3020619772

From sspitsyn at openjdk.org  Mon Jun 30 20:50:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 30 Jun 2025 20:50:38 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <63esK88MOSe9tGzxAaYXMexIoPU5ojz0O0KyYiFchSc=.5c2e0cbc-8fc2-4fd2-b633-204ea8f1080c@github.com>

On Sat, 28 Jun 2025 05:02:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.
> 
> Many thanks to Coleen for detailed explanation of class redefinition.

The issue itself is kind of artificial. The debugger should not set breakpoints concurrently with class redefinitions.
But suppose this can really happen. Then I have a little preference to fix this by setting a breakpoint after redefinition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3020644976

From lmesnik at openjdk.org  Mon Jun 30 21:15:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 21:15:40 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <63esK88MOSe9tGzxAaYXMexIoPU5ojz0O0KyYiFchSc=.5c2e0cbc-8fc2-4fd2-b633-204ea8f1080c@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
 <63esK88MOSe9tGzxAaYXMexIoPU5ojz0O0KyYiFchSc=.5c2e0cbc-8fc2-4fd2-b633-204ea8f1080c@github.com>
Message-ID: <MMQlZJWpsyOIjr6vIOFlNy_DbMrXjXNqzOzokh_SGMg=.4bd05c10-c74d-4d11-a9d8-38341220a7d4@github.com>

On Mon, 30 Jun 2025 20:47:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The issue itself is kind of artificial. The debugger should not set breakpoints concurrently with class redefinitions. But suppose this can really happen. Then I have a little preference to fix this by setting a breakpoint after redefinition when it is possible.

That might happens if the another javaagent request retransformation independently from debugger agent. It indeed quite rare but might happens. 
I planned to change the fix to use methodHandle instead of  jmehtodid. However it means that it is needed to reconstruct breakpoint with new method. I think it is too complicated and can't be well tested. 
Let me publish the second approach to decide what would be better to do with breakpoint.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3020763227

From lmesnik at openjdk.org  Mon Jun 30 21:20:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 21:20:55 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint [v2]
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <JRBsn24tTFekjuIxr60JQgkDLbF5QoKtDUEzJtHnrh4=.5943578f-1b36-47c6-bfd8-8430027a959a@github.com>

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.
> 
> Many thanks to Coleen for detailed explanation of class redefinition.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  changed jmethodid to methodHandle.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26031/files
  - new: https://git.openjdk.org/jdk/pull/26031/files/a6a9f01c..e1524bbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=00-01

  Stats: 16 lines in 2 files changed: 8 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26031.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26031/head:pull/26031

PR: https://git.openjdk.org/jdk/pull/26031

From lmesnik at openjdk.org  Mon Jun 30 21:20:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 21:20:55 GMT
Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in
 JvmtiBreakpoints::clearall_in_class_at_safepoint
In-Reply-To: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
References: <y6xS61w0pgTkG5H_rZK5KaAes7VugntOIfE7REFe4lM=.4baa3438-2ce7-445e-b7ba-03d50e21ca20@github.com>
Message-ID: <sY5-Jp5qmi_hy3jo53-P2v2EpS44XmtrlKFOoDGESPg=.d1c9767b-e714-419e-8bcb-3c0ab264706d@github.com>

On Sat, 28 Jun 2025 05:02:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the 
> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and 
> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints.
> 
> Here are details:
> The breakpoint is set in 2 steps.
> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method,  jlocation location)  convert jmethodID to Method* and call 
>  JvmtiEnv::SetBreakpoint(Method* method, jlocation location)
> where 
>   JvmtiBreakpoint bp(method, location);
> is created with this Method* 
> Note: it is done while thread is in VM state, so Method can't become is_old while this is done.
>  
> 2) The VMOp is used to add breakpoint into the list 
>  VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp);
>   VMThread::execute(&set_breakpoint);
> to call  JvmtiBreakpoints::set_at_safepoint()
> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization.
> 
> So it might be possible that class redefinition  VM_RedefineClasses  operation that redefine the class with this breakpoint happens between steps 1) and 2)
> VM_RedefineClasses::redefine_single_class()
> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread  queue and thus we are still continue to do this operation.
> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set.
> 
> Then old method mights be purged any time once  they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace.
> 
> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also.
> 
> Looks, like very unlikely but reproducing with stress test after some time.
> Verified that the crash is not reproduced anymore with corresponding test after the fix.
> 
> Many thanks to Coleen for detailed explanation of class redefinition.

The fix was updated to use methodHandle instead of jmethodID.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3020794440

From lmesnik at openjdk.org  Mon Jun 30 22:35:38 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 22:35:38 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
Message-ID: <L6xNgR4AUiTHsdB_ewziVRdb3oCQ-SZJIi7wp0yrFEI=.c3517ee3-b66d-4549-8940-0d394333a973@github.com>

On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed.
>> 
>> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods.
>> 
>> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   startLocalDebugee renamed to startDebugee

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25887#pullrequestreview-2972950680

From lmesnik at openjdk.org  Mon Jun 30 22:35:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 22:35:39 GMT
Subject: RFR: 8359958: Cleanup "local" debuggee references after
 JDK-8333117 removed support for non-local debuggees [v2]
In-Reply-To: <L232aowEugYz5O71Mw9ZWPFwIXeMGFpBBOJBjO4t07g=.879ead09-9011-44c5-a59a-ec3aae15bd28@github.com>
References: <TRm28TuV_ovgYwrB1zrxRVMLv-HTbA-6wQ5KirQSVCs=.b2e01af8-c350-4d0f-8d84-c7fc93f9682b@github.com>
 <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com>
 <7HKgdR0w0qzSNE7CsPfobLYodrs8NO8O4oliOPgrEGc=.2f0b7216-138d-4363-a748-8e78a88af023@github.com>
 <L232aowEugYz5O71Mw9ZWPFwIXeMGFpBBOJBjO4t07g=.879ead09-9011-44c5-a59a-ec3aae15bd28@github.com>
Message-ID: <VY9gu5lsb7T44yfLQrmMhElZaC03TWdCRi1HqpWqZBQ=.7f1280db-47a2-4a95-a5b1-1c0c7c67980d@github.com>

On Mon, 23 Jun 2025 17:15:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java line 50:
>> 
>>> 48:  * @see nsk.share.jdwp.Debugee
>>> 49:  */
>>> 50: public class DebugeeProcess {
>> 
>> Are there any reason to make it non-abstract.. Even DebugeeProcess doesn't have abstract methods, only jid/jdwp subclasses might be used.Might be left it abstract?
>
> Currently it is only used via subclasses, but that doesn't necessarily mean it couldn't be used directly. Is there a reason you want to disallow that?

No any particular reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25887#discussion_r2176082458

From lmesnik at openjdk.org  Mon Jun 30 23:28:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 30 Jun 2025 23:28:41 GMT
Subject: RFR: 8359707: Add classfile modification code to
 RedefineClassHelper [v11]
In-Reply-To: <mIHdl4_tc3bd4M13BlvV2CPjgZafZ7Yn5c7ohmCA7W4=.89aada01-a41a-47ed-a1ab-0c593cd45187@github.com>
References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com>
 <mIHdl4_tc3bd4M13BlvV2CPjgZafZ7Yn5c7ohmCA7W4=.89aada01-a41a-47ed-a1ab-0c593cd45187@github.com>
Message-ID: <h2U4wRTcEbLKV7Mve5iO6KOEee5t47ald41NEZxvfug=.abffc9dc-9e2d-4f4b-82e1-177654a56ced@github.com>

On Mon, 30 Jun 2025 16:49:02 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 three additional commits since the last revision:
> 
>  - Update test/lib/RedefineClassHelper.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/lib/RedefineClassHelper.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update test/lib/RedefineClassHelper.java
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 45:

> 43:         ClassVersionAfterRedefine cvar = new ClassVersionAfterRedefine();
> 44: 
> 45:         // Poor man's renaming of class "TestClassOld" to "TestClassXXX"

It is not "poor man's" renaming anymore and RedefineClassHelper.replaceClassName() is self-explanable. So this comment could be just removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2973056824
PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2176137182