From sviswanathan at openjdk.org  Tue Jul  1 00:47:42 2025
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Jul 2025 00:47:42 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <1F2MWloqst4ZYni3KE4o_IOIhVYcw9kjv6TRw3utgy0=.c72ad565-088b-42f3-a14e-1ab264a5fc4e@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26009#pullrequestreview-2973146764

From fyang at openjdk.org  Tue Jul  1 02:12:39 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 1 Jul 2025 02:12:39 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <aH0JtoZCDEnj6PixsxIBXXZs62LEpl8NJaGoq90-xpo=.2f821607-43ea-45f4-987a-8b8453b3d668@github.com>

On Thu, 26 Jun 2025 15:58:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Hotspot tier1 has passed on linux-riscv64. The riscv part seems fine after a cursory look. Thanks for the ping.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2973254676

From jbhateja at openjdk.org  Tue Jul  1 05:44:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 05:44:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <pJYimNDzlpki3-qL8nM4KiFxKALz-B9TQQjWdHS3Mz0=.7841e6f5-f325-4072-8893-2238b400b0a1@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <yLFxvGfpEeemgeePGLOAMTNkzhrFCEmcGYvP_YgV2l8=.e4b1f131-a230-4e3f-ab02-99e28fd242e7@github.com>
 <4JWUyNwX9neYkTIymwpEpaXMig0AGc5ylQvPlWjqLR0=.5ffb5edb-3bb6-4d36-b3a3-820b4cafd704@github.com>
 <pJYimNDzlpki3-qL8nM4KiFxKALz-B9TQQjWdHS3Mz0=.7841e6f5-f325-4072-8893-2238b400b0a1@github.com>
Message-ID: <PZ8S3O3hjSuuIp6KA-nGrXl2ShdMtwo7NchHytWqaPU=.7705d4ce-004a-4cdd-82db-5302986fccfd@github.com>

On Mon, 30 Jun 2025 22:14:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> @jatin-bhateja Pusha is not expected to change any registers. The inadvertent change of registers is very hard to debug. So in my thoughts it is better to have a conservative implementation currently which doesn't change RAX register.
>
> Please see the updated code which fixes the issue by restoring the contents of RAX. The tests are passing with this update.

Thanks @vamsi-parasa , yes this looks fine to me now, I had a similar thought to fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26009#discussion_r2176475736

From jbhateja at openjdk.org  Tue Jul  1 05:48:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 05:48:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <JfzX_i7Ybo8SCY-lA6NL8IP8-aEQBfCvzvPmGB_a_M4=.a183c931-763d-4b04-8000-b63cafab0ae3@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

LGTM.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26009#pullrequestreview-2973586361

From jbhateja at openjdk.org  Tue Jul  1 06:06:40 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Jul 2025 06:06:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <j28wU7dVQ2KuOO3N0UATeOOA3OcXLFjmF512KdnEbTg=.f2f5eb60-95f4-4f76-ac44-7f7fd16255b1@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 387:

> 385:     __ movptr(Address(rsp, (--slot) * wordSize), r29);
> 386:     __ movptr(Address(rsp, (--slot) * wordSize), r30);
> 387:     __ movptr(Address(rsp, (--slot) * wordSize), r31);

I think you should use pushp2 / pop2p for these instructions also , maybe it can be handled along with 
https://github.com/openjdk/jdk/pull/25889

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26009#discussion_r2176501724

From amitkumar at openjdk.org  Tue Jul  1 06:29:41 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 1 Jul 2025 06:29:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
Message-ID: <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>

On Mon, 30 Jun 2025 16:14:44 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
>
>n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."


@adinn is this something which is expected:

Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc

[error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]

Retrying call stack printing without source information...


I don't see any truncation message in the hs_err output.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022029790

From adinn at openjdk.org  Tue Jul  1 07:47:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 07:47:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
Message-ID: <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>

On Tue, 1 Jul 2025 06:27:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar I managed to run the test on an s390x build and it passed. I didn't get any hserr output in the jtr file when I set DEBUG on the command line. So, I modified the test to write the hserr file to system.err unconditionially (i.e. I changed the if at line 137 of MachCodeFramesInErrorFile.java to 'if (true)'.
>> 
>> The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
>> 
>> n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."
>> 
>> If that is the case and if you can reproduce the problem after modifying the test to write the hserr contents unconditionally then you ought to be able to see all the file contents by setting system property javatest.maxOutputSize to a suitable value (default is 100000).
>
>> The System.err output in the jtr file contained [MachCode] sections for 4 compiled methods, including the two that appeared in the stack listing (crashInJava3 and crashInJava2). So, I'm not sure why it is failing.
>>
>>n.b. not all the System.err output ends up in the jtr file because the test harness truncates excessive output. However, I wonder if the problem you are seeing is because the original hserr file is being truncated. It includes a message to that effect starting "Output overflow: ..."
> 
> 
> @adinn is this something which is expected:
> 
> Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
> J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
> j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
> j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
> v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
> 
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
> 
> Retrying call stack printing without source information...
> 
> 
> I don't see any truncation message in the hs_err output.

@offamitkumar Thanks for following up.

> is this something which is expected:

    Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
    J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
    j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
    j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
    v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
    
    [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
    
    Retrying call stack printing without source information...

That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.

The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022350306

From amitkumar at openjdk.org  Tue Jul  1 08:37:41 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 1 Jul 2025 08:37:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
Message-ID: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>

On Tue, 1 Jul 2025 07:44:50 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.

There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022653170

From adinn at openjdk.org  Tue Jul  1 08:37:43 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:37:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <tRiL5T6iD5lp2v_Fe4T3GSmD0CeS-hSpcYWmDx66gbM=.146b6a5e-4499-4d2f-8637-ed811f546742@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <tRiL5T6iD5lp2v_Fe4T3GSmD0CeS-hSpcYWmDx66gbM=.146b6a5e-4499-4d2f-8637-ed811f546742@github.com>
Message-ID: <rSrystcuGWdUXlN8hlm4H7w3CiMieYv3ciJbu4LoOHs=.9a6a1a67-681d-4a26-a9df-0fff8f1f009b@github.com>

On Mon, 30 Jun 2025 20:27:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> src/hotspot/cpu/x86/stubDeclarations_x86.hpp line 121:
> 
>> 119:                 vector_byte_shuffle_mask, vector_byte_shuffle_mask)     \
>> 120:   do_stub(compiler, vector_short_shuffle_mask)                          \
>> 121:   do_arch_entry(x86, compiler, vector_short_shuffle_mask,               \
> 
> Was it bug?

I think this was just a potential bug for the Leyden premain repo not an actual one for that repo and not a bug for mainline.

The declaration was attaching the entry to the wrong stub. I don't think this causes any problem, even in premain, because that wrong stub is still in the same blob as the correct stub. The bad declaration means that when premain saves and restores the entry address it will compute an offset from the wrong base address -- the one for the wrongly declared stub. That means the offset will identify a code address belonging to another stub i.e. it may be negative or greater than the extent of the declared owner. This won't cause a crash because it will still end up pointing at the desired address in the current blob. However, premain really ought to assert that the offset is non-negative and less than the associated stub's extent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176837367

From sspitsyn at openjdk.org  Tue Jul  1 08:41:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 08:41:41 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <BbeTm6iCHsR7YGVoOl1u_nDm6vQTP965CNah4RC6yl8=.9beb52f0-a241-458b-8823-5930dffd8763@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>
 <BbeTm6iCHsR7YGVoOl1u_nDm6vQTP965CNah4RC6yl8=.9beb52f0-a241-458b-8823-5930dffd8763@github.com>
Message-ID: <wb_CuyGWD3G6kTADE-iOTkPxeQAauF1NVfR2Oemu70Y=.0d0faedb-8443-4d98-ae76-489fa305163a@github.com>

On Mon, 30 Jun 2025 11:53:36 GMT, Anton Artemov <duke at openjdk.org> wrote:

> I reverted closure names changes in JVMT files.

Thanks! Unification is good in general but there is a price to pay.
So, we are normally balancing among different requirements. :)
The `HSClosure` suffix is not perfect either because `HS` normally stands for HotSpot.
But I can be wrong with this assumption.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176851022

From adinn at openjdk.org  Tue Jul  1 08:43:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:43:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <Afd5sCYQc6QYVsl998LpjaGXctTqUEFlg0Vtz0uZoyA=.d32011dc-b5b1-434e-a946-874975b90414@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Afd5sCYQc6QYVsl998LpjaGXctTqUEFlg0Vtz0uZoyA=.d32011dc-b5b1-434e-a946-874975b90414@github.com>
Message-ID: <6JrLRhTlBHNeDL9NPy5IE0dPWyVF7ZTeEoH9K90yQQc=.c83860b5-5a93-450b-803f-6c5337270ec3@github.com>

On Mon, 30 Jun 2025 20:47:05 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> src/hotspot/share/runtime/stubCodeGenerator.hpp line 109:
> 
>> 107:   bool _print_code;
>> 108:   BlobId _blob_id;
>> 109: protected:
> 
> Please return spacing for `protected:` line.

Done

> src/hotspot/share/runtime/stubCodeGenerator.hpp line 118:
> 
>> 116: 
>> 117:   MacroAssembler* assembler() const              { return _masm; }
>> 118:   BlobId blob_id()                        { return _blob_id; }
> 
> Align body of methods. May be move them to the left - I don't see why we have such big spacing.

I believe the spacing is meant to align with the declarations that follow.

I have simply realigned the modified line with the old line to avoid unnecessary changes.

> src/hotspot/share/runtime/stubDeclarations.hpp line 1235:
> 
>> 1233:                  do_arch_entry, do_arch_entry_init)                     \
>> 1234: 
>> 1235: 
> 
> No need this empty line.

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176858735
PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176856030
PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176859879

From adinn at openjdk.org  Tue Jul  1 08:52:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:52:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
Message-ID: <rYmS4L6d2XiEr-6Mr-UdpL_J03NS0jnRhdPJW0gRgHo=.ad459a0c-8fce-4538-bc7d-8418dd19d9da@github.com>

On Tue, 1 Jul 2025 08:34:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar Thanks for following up.
>> 
>>> is this something which is expected:
>> 
>>     Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>>     J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
>>     J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
>>     j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
>>     j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
>>     v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
>>     
>>     [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
>>     
>>     Retrying call stack printing without source information...
>> 
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.
>
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
> 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

@offamitkumar 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

Yes please!

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3022753622

From adinn at openjdk.org  Tue Jul  1 08:52:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 08:52:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <ztsZ4lGRaS-DkADj9dQFBBzZ1Y653C_MIqUCI-fXMIM=.d7be0bb9-e3f1-434f-bac5-06dedbc4f51f@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ztsZ4lGRaS-DkADj9dQFBBzZ1Y653C_MIqUCI-fXMIM=.d7be0bb9-e3f1-434f-bac5-06dedbc4f51f@github.com>
Message-ID: <6jkjxCQdnjuzVj9Eeg9jSBRTSdotEy9FTJRQIMtHJrE=.b9a5fedf-af69-48f4-820d-55bdfeed51be@github.com>

On Mon, 30 Jun 2025 20:54:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> src/hotspot/share/runtime/stubRoutines.cpp line 235:
> 
>> 233: SharedRuntime::_jbyte_array_copy_ctr++;      // Slow-path byte array copy
>> 234: #endif // !PRODUCT
>> 235: Copy::conjoint_jbytes_atomic(src, dest, count);
> 
> Why you removed leading spaces here and in the following methods?

Sorry, I mistakenly reformatted more a larger region than I should. Reverted.

> src/hotspot/share/runtime/stubRoutines.cpp line 378:
> 
>> 376: #define RETURN_STUB_PARM(xxx_arraycopy, parm) {                 \
>> 377:     name = parm ? #xxx_arraycopy "_uninit": #xxx_arraycopy;     \
>> 378:     return StubRoutines::xxx_arraycopy(parm); }
> 
> No need these spacing changes - it was fine.

Same issue. All restored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176878410
PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2176879334

From sspitsyn at openjdk.org  Tue Jul  1 09:02:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:02:41 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>
Message-ID: <MzyVONemNx67Fz6TgoBFc5jTmXWryc0nCTeS4kbnN8Q=.190a1c22-956e-4b20-9343-e326621a2144@github.com>

On Mon, 30 Jun 2025 11:57:23 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.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Reverted closure names in JVMTI

This looks okay in general.
I've posted several nits though.

src/hotspot/share/classfile/javaClasses.cpp line 1980:

> 1978:   ResourceMark rm(THREAD);
> 1979:   HandleMark   hm(THREAD);
> 1980:   GetStackTraceHandshakeClosure gstc(Handle(THREAD, java_thread));

Nit: A suggestion to rename: `gstc` => `gsthc` or `gstc` => `hc` or `gstc` => `cl`.

src/hotspot/share/prims/whitebox.cpp line 2288:

> 2286:   };
> 2287: 
> 2288:   ReadMonitorsHandshakeClosure rmc;

Nit: A suggestion to rename: `rmc` => `rmhc` or `rmc` => `cl`.

src/hotspot/share/prims/whitebox.cpp line 2319:

> 2317:     jint num_threads_completed() const { return _num_threads_completed; }
> 2318:   };
> 2319:   TraceSelfHandshakeClosure tsc(Thread::current());

Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`.

src/hotspot/share/prims/whitebox.cpp line 2357:

> 2355:     bool is_alive = tlh.cv_internal_thread_to_JavaThread(thread_handle, &target, nullptr);
> 2356:     if (is_alive) {
> 2357:       TraceSelfHandshakeClosure* tsc = new TraceSelfHandshakeClosure(target);

Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`.

src/hotspot/share/runtime/synchronizer.cpp line 1837:

> 1835:     // A JavaThread needs to handshake in order to safely free the
> 1836:     // ObjectMonitors that were deflated in this cycle.
> 1837:     DeflationHandshakeClosure hfd_hc;

Nit: Rename: `hfd_hc` => `dhc` or `hfd_hc` => `cl`.

src/hotspot/share/runtime/vmThread.cpp line 456:

> 454:       if (HandshakeALot) {
> 455:         MutexUnlocker mul(VMOperation_lock);
> 456:         ALotOfHandshakeClosure hal_cl;

Nit: Rename: `hal_cl` => `aohc` or `hfd_hc` => `cl`.

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

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974276487
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176875478
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176885943
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176889645
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176891619
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176908630
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176911514

From adinn at openjdk.org  Tue Jul  1 09:11:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 09:11:40 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

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

  fix formatting issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/29f02865..7908e895

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

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

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

From duke at openjdk.org  Tue Jul  1 09:39:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 09:39:22 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
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: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@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: Addressed reviewer's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26014/files
  - new: https://git.openjdk.org/jdk/pull/26014/files/65b9ecc5..bb95404c

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

  Stats: 32 lines in 5 files changed: 0 ins; 0 del; 32 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  Tue Jul  1 09:39:22 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 1 Jul 2025 09:39:22 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v3]
In-Reply-To: <MzyVONemNx67Fz6TgoBFc5jTmXWryc0nCTeS4kbnN8Q=.190a1c22-956e-4b20-9343-e326621a2144@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com>
 <MzyVONemNx67Fz6TgoBFc5jTmXWryc0nCTeS4kbnN8Q=.190a1c22-956e-4b20-9343-e326621a2144@github.com>
Message-ID: <yWrC1VBRGIs-r9Oas51SV7tkVNITJT5jdTQSUhFpGCI=.8483e927-5e76-4d33-b62e-6ceec8f4b4e5@github.com>

On Tue, 1 Jul 2025 08:46:37 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: Reverted closure names in JVMTI
>
> src/hotspot/share/classfile/javaClasses.cpp line 1980:
> 
>> 1978:   ResourceMark rm(THREAD);
>> 1979:   HandleMark   hm(THREAD);
>> 1980:   GetStackTraceHandshakeClosure gstc(Handle(THREAD, java_thread));
> 
> Nit: A suggestion to rename: `gstc` => `gsthc` or `gstc` => `hc` or `gstc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

> src/hotspot/share/prims/whitebox.cpp line 2288:
> 
>> 2286:   };
>> 2287: 
>> 2288:   ReadMonitorsHandshakeClosure rmc;
> 
> Nit: A suggestion to rename: `rmc` => `rmhc` or `rmc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

> src/hotspot/share/prims/whitebox.cpp line 2357:
> 
>> 2355:     bool is_alive = tlh.cv_internal_thread_to_JavaThread(thread_handle, &target, nullptr);
>> 2356:     if (is_alive) {
>> 2357:       TraceSelfHandshakeClosure* tsc = new TraceSelfHandshakeClosure(target);
> 
> Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

> src/hotspot/share/runtime/vmThread.cpp line 456:
> 
>> 454:       if (HandshakeALot) {
>> 455:         MutexUnlocker mul(VMOperation_lock);
>> 456:         ALotOfHandshakeClosure hal_cl;
> 
> Nit: Rename: `hal_cl` => `aohc` or `hfd_hc` => `cl`.

Thanks, makes sense, addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177016990
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017247
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017485
PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017688

From sspitsyn at openjdk.org  Tue Jul  1 09:53:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Jul 2025 09:53:39 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
Message-ID: <0t5vpK_Z-2WRiRvG6gUsq-wfR6_CUUG4yAwPcxNnPmw=.5c6ef9ce-6fdd-469d-a4c8-bdf8d4eea82d@github.com>

On Tue, 1 Jul 2025 09:39:22 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.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Addressed reviewer's comments

Thank you for the update. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974608407

From adinn at openjdk.org  Tue Jul  1 10:21:43 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 10:21:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <aH0JtoZCDEnj6PixsxIBXXZs62LEpl8NJaGoq90-xpo=.2f821607-43ea-45f4-987a-8b8453b3d668@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <aH0JtoZCDEnj6PixsxIBXXZs62LEpl8NJaGoq90-xpo=.2f821607-43ea-45f4-987a-8b8453b3d668@github.com>
Message-ID: <5kA9iwhMigdn2kR4YPyOoF8iM0fn5YbbgbAz4g82NqU=.a5cac722-ead5-418b-b600-69c1215223a9@github.com>

On Tue, 1 Jul 2025 02:10:29 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hotspot tier1 has passed on linux-riscv64. The riscv part seems fine after a cursory look. Thanks for the ping.

@RealFYang Thanks for the test and review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3023205993

From coleenp at openjdk.org  Tue Jul  1 11:23:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 1 Jul 2025 11:23:45 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
Message-ID: <a1tax3OyPoBG25U-Zr3TTbfI4IwzYMCLiiM0F0E1VbI=.428fd292-2861-4bbb-9b44-04bf6b63b1e6@github.com>

On Tue, 1 Jul 2025 09:39:22 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.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Addressed reviewer's comments

Still looks good.  So the pattern is that something that inherits directly from HandshakeClosure is TheThingHandshakeClosure and in the case of JVMTI further inheritance has a shorter name.  Seems fine.  So many handshakes!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974982990

From mhaessig at openjdk.org  Tue Jul  1 11:27:49 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Tue, 1 Jul 2025 11:27:49 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <U2pkrbJtCOAswOM9iXx8kEf2FQuQZDgedCpf0ZHreh0=.f519ca6c-aa4a-465b-9e11-825c9071afc8@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Backing out #24831 sounds reasonable to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3023516324

From duke at openjdk.org  Tue Jul  1 12:19:41 2025
From: duke at openjdk.org (duke)
Date: Tue, 1 Jul 2025 12:19:41 GMT
Subject: RFR: 8284016: Normalize handshake closure names [v4]
In-Reply-To: <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com>
 <sO1Ngr6HidkDtOgPztqRhDCP_TbJ51L-H4pVpB4w2nE=.d9dc89dd-5a02-49f7-a62d-0c169ed2c43d@github.com>
Message-ID: <vp8I3MWFyOjF8XR7NIIb4ZvRIJVOXuxB0nX32VhZoS4=.0db2c1c9-fd1f-4938-981f-5d5c4ba31ace@github.com>

On Tue, 1 Jul 2025 09:39:22 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.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284016: Addressed reviewer's comments

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26014#issuecomment-3023766086

From adinn at openjdk.org  Tue Jul  1 13:18:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 13:18:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
Message-ID: <rR2tUrdK33SZmLZTOUjoAysdVZpYDDIX8Mufn2qqCHA=.fecff99f-baee-4dc0-967b-14baa3bbb52f@github.com>

On Tue, 1 Jul 2025 08:34:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar Thanks for following up.
>> 
>>> is this something which is expected:
>> 
>>     Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>>     J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
>>     J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
>>     j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
>>     j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
>>     v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
>>     
>>     [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
>>     
>>     Retrying call stack printing without source information...
>> 
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.
>
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
> 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

@offamitkumar I'm stumped as to why this could be causing any problem on s390x. The error you are seeing appears to be in happening under frame::next_frame during lookup of the parent frame for the call stub frame. That occurs when printing the 'Native frames' part of the hs_err file content.

If I run my build on an s390 box I don't see that error. The frames are printed to the file as expected. Neither can I see any way in which the changes I have made could influence the stack walk code. They do not change the frame size and layout.

@TheRealMDoerr Would you be able to run hotspot jtreg test runtime/ErrorHandling/MachCodeFramesInErrorFile.java on an s390 box and see if you can reproduce the error that @offamitkumar is seeing?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3023980729

From mdoerr at openjdk.org  Tue Jul  1 14:08:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 14:08:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
Message-ID: <m6spj6cZCBasn_NV2fdLTIz60nJOnTfL8is0fRznWts=.b8a155ed-e60c-47b1-804e-c0a7b269bbf6@github.com>

On Tue, 1 Jul 2025 08:34:32 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @offamitkumar Thanks for following up.
>> 
>>> is this something which is expected:
>> 
>>     Stack: [0x000003ff82980000,0x000003ff82a80000],  sp=0x000003ff82a7e4c8,  free space=1017k
>>     Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>>     J 21 c2 MachCodeFramesInErrorFile$Crasher.crashInJava3(J)V (27 bytes) @ 0x000003ff70657c8a [0x000003ff70657c40+0x000000000000004a]
>>     J 20 c2 MachCodeFramesInErrorFile$Crasher.crashInJava2(J)V (13 bytes) @ 0x000003ff706580c0 [0x000003ff70658040+0x0000000000000080]
>>     j  MachCodeFramesInErrorFile$Crasher.crashInJava1(J)V+9
>>     j  MachCodeFramesInErrorFile$Crasher.main([Ljava/lang/String;)V+71
>>     v  ~StubRoutines::Stub Generator call_stub_stub 0x000003ff70580edc
>>     
>>     [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/amit/jdk/src/hotspot/cpu/s390/frame_s390.inline.hpp:40)]
>>     
>>     Retrying call stack printing without source information...
>> 
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> The stack backtrace in the listing above is broken at the frame for a generated stub (call_stub_stub) so it looks like the stack walk is failing. It ought to continue with a C++ frame for JavaCalls::call_helper and so on right up to the frame for start_thread. I'll check to see if perhaps this might be to do with some change to the stub.
>
>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
> 
> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.

@offamitkumar: Is the crash you reported reproducible? Could it be that `save_return_pc()` is missing in `address generate_call_stub(address& return_address)`? PPC64 has it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3024189963

From adinn at openjdk.org  Tue Jul  1 14:35:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 1 Jul 2025 14:35:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <m6spj6cZCBasn_NV2fdLTIz60nJOnTfL8is0fRznWts=.b8a155ed-e60c-47b1-804e-c0a7b269bbf6@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Drs-wIhbZeZdUZkbW8VUiwjDkOZKwROnLNk5eOIo4m4=.011decb2-f8bb-4e4e-8561-3cbb037b8820@github.com>
 <VylgtqYdxygQtQOUA0wvgpBfVyh2rCkAr_HrO5_p1OA=.5eb102a0-9fef-4a13-85f2-c43dc6e3aae6@github.com>
 <nvMQy96A_nU3cwonakYGZn8ZInFRaeFaZywHeIVWlb4=.b88315ea-bdf1-4e11-b032-8f51a81a1624@github.com>
 <ETwZyLDFnd-S7ZYqbp5STwNWSvXavSn2brQW4C0NSrA=.7aea00d5-7a58-4ca6-9fbe-941cf6236ed6@github.com>
 <uWOzwn0XrPgdqOjIR7asi8b8HOJJnkDYCkIqAkU-vmY=.ba73883f-a5eb-481a-ab0e-41ce763caa92@github.com>
 <m6spj6cZCBasn_NV2fdLTIz60nJOnTfL8is0fRznWts=.b8a155ed-e60c-47b1-804e-c0a7b269bbf6@github.com>
Message-ID: <yxvoSFrkPR6J4ZDwnIZWtB3HCkNsDwvr33WTt5jQGoU=.dfd771ee-a131-4aa4-ba7e-a9fdb2efdec4@github.com>

On Tue, 1 Jul 2025 14:05:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> That does not look right. Was there any more hserr printout after that last line? -- in particular any [MachCode]...[/MachCode] sections? It would help if you could attach the full .jtr file.
>> 
>> There isn't much after this @adinn. It's the hs_err file generated during the test case execution. If you still want to take a look at jtr then I can attach it.
>
> @offamitkumar: Is the crash you reported reproducible? Could it be that `save_return_pc()` is missing in `address generate_call_stub(address& return_address)`? PPC64 has it.

@TheRealMDoerr Hmm, that might possibly be it. It could explain why I am not seeing the error and @offamitkumar is (the failure will depend on what happens to be left lying in the saved PC register). What do you think, Amit?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3024306793

From kvn at openjdk.org  Tue Jul  1 15:45:46 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 1 Jul 2025 15:45:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
Message-ID: <3wvWU3L2EeptYlaNLcut7IaxLUTfY_eWbqzeQu-otu8=.36da587e-8a53-438a-8c95-349e9d8fb636@github.com>

On Tue, 1 Jul 2025 09:11:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix formatting issues

My testing passed. Thank you for addressing my comments.

I assume you will address s390 issue before integration.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2976000297

From wkemper at openjdk.org  Tue Jul  1 21:23:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Jul 2025 21:23:27 GMT
Subject: RFR: gc+regions needs to be at trace, not debug
Message-ID: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>

Readme instructions have incorrect log level

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

Commit messages:
 - gc+regions needs to be at trace, not debug

Changes: https://git.openjdk.org/shenandoah-visualizer/pull/2/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=2&range=00
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah-visualizer/pull/2.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-visualizer.git pull/2/head:pull/2

PR: https://git.openjdk.org/shenandoah-visualizer/pull/2

From sparasa at openjdk.org  Tue Jul  1 21:27:40 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 1 Jul 2025 21:27:40 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <gGuAmunp7iklHitMz-TnjUMQCRBkNdO3AjFOUFP8g6w=.fae3b2fd-2a6c-4760-bdc4-92baaa6bc2b7@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Hi Emanuel (@eme64),

This PR is also ready for integration. Would it be possible for you to run the tests?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3025582589

From sparasa at openjdk.org  Tue Jul  1 21:27:41 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 1 Jul 2025 21:27:41 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <j28wU7dVQ2KuOO3N0UATeOOA3OcXLFjmF512KdnEbTg=.f2f5eb60-95f4-4f76-ac44-7f7fd16255b1@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <j28wU7dVQ2KuOO3N0UATeOOA3OcXLFjmF512KdnEbTg=.f2f5eb60-95f4-4f76-ac44-7f7fd16255b1@github.com>
Message-ID: <uevWlHqvKsXKPns_8xW4zmkLMspTCrOOhobTheDNJ6c=.f7373020-1e23-400f-85ef-00e25439947c@github.com>

On Tue, 1 Jul 2025 06:04:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore the orginal contents of rax
>
> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 387:
> 
>> 385:     __ movptr(Address(rsp, (--slot) * wordSize), r29);
>> 386:     __ movptr(Address(rsp, (--slot) * wordSize), r30);
>> 387:     __ movptr(Address(rsp, (--slot) * wordSize), r31);
> 
> I think you should use pushp2 / pop2p for these instructions also , maybe it can be handled along with 
> https://github.com/openjdk/jdk/pull/25889

Thanks Jatin (@jatin-bhateja) for the review and approval! This modification will be pursued in another PR (say #25889).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26009#discussion_r2178557739

From ysr at openjdk.org  Wed Jul  2 01:00:57 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 2 Jul 2025 01:00:57 GMT
Subject: RFR: gc+regions needs to be at trace, not debug
In-Reply-To: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>
References: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>
Message-ID: <LLDuCsG0BilrM2CxrsRu7Ge4-XGIUK03dzKpgLfM1Vw=.8cbf258e-7670-4985-bf95-2d86ca5269d2@github.com>

On Tue, 1 Jul 2025 21:19:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Readme instructions have incorrect log level

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/shenandoah-visualizer/pull/2#pullrequestreview-2977307071

From rkennke at openjdk.org  Wed Jul  2 05:55:52 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 2 Jul 2025 05:55:52 GMT
Subject: RFR: gc+regions needs to be at trace, not debug
In-Reply-To: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>
References: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>
Message-ID: <9gO1mEb47aKFPIeTl2jlHZLYblJ8YP0_TBKiXlnvK98=.6ea8ddcf-487e-4238-86c1-c655636c591b@github.com>

On Tue, 1 Jul 2025 21:19:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Readme instructions have incorrect log level

Marked as reviewed by rkennke (Reviewer).

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

PR Review: https://git.openjdk.org/shenandoah-visualizer/pull/2#pullrequestreview-2977828940

From duke at openjdk.org  Wed Jul  2 06:52:48 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 2 Jul 2025 06:52:48 GMT
Subject: Integrated: 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: <TOysmxCpnh6Wp026OjPljEDZqxqw6bZ7_L8JoP-k84U=.c47dfeb4-e5be-402f-917c-61e06cd44ce0@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.

This pull request has now been integrated.

Changeset: 0f1cd987
Author:    Anton Artemov <anton.artemov at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f1cd987b3520eaeab31e9faf782d6f81050803a
Stats:     116 lines in 18 files changed: 0 ins; 0 del; 116 mod

8284016: Normalize handshake closure names

Reviewed-by: coleenp, sspitsyn

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

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

From epeter at openjdk.org  Wed Jul  2 08:23:47 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 2 Jul 2025 08:23:47 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Submitted testing for commit 2 / v01 :)

However: I can only test on SSE/AVX machines, so you will have to make sure it runs fine on APX and other architectures that may be impacted.

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3026920797

From haosun at openjdk.org  Wed Jul  2 09:50:47 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 2 Jul 2025 09:50:47 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
Message-ID: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>

On Tue, 1 Jul 2025 09:11:40 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix formatting issues

Hi.

Not a review. Here lists our internal test result.

## 1. VM crashed for arm32

I created one armhf build via cross-compilation and ran `java --version` via Qemu.
Here lists the error log.


$ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
#  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
#
# JRE version:  (26.0) (fastdebug build )
# Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
#
# An error report file with more information is saved as:
# //hs_err_pid117661.log
#
#
qemu: uncaught target signal 6 (Aborted) - core dumped
environment: line 1: 117660 Aborted                 "$@"


It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49

## 2. copyright year should be updated for the following files


src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
src/hotspot/share/c1/c1_CodeStubs.hpp
src/hotspot/share/runtime/stubCodeGenerator.hpp

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027198670

From adinn at openjdk.org  Wed Jul  2 09:58:40 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 09:58:40 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
Message-ID: <VV9NRlIAquMwXoHH0EVMUziWggxFKURd505E_Ol6ShU=.9f43df62-587c-425f-899d-50db48b5d7c5@github.com>

On Mon, 30 Jun 2025 18:28:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> I submitted testing.

@vnkozlov 
> I assume you will address s390 issue before integration.

Amit and Martin followed up on this offline. The problem apppears to be an independent, unrelated issue to do with save and restore of SP at the correct point and they are following it up separately. It only happens intermittently because it depends on what gets left in memory.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027225291

From adinn at openjdk.org  Wed Jul  2 10:06:44 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 10:06:44 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
 <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
Message-ID: <WmRJQtuojke66gpLOJKKh6MrI5VxBEhpMBhjr3RMayc=.91e240ac-ce01-4ace-850e-a2efe90f2149@github.com>

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

@shqking Thank you for testing and reporting the issue and also for noticing the missing copyright updates.

The assertion is happening because the arm-specific stub declarations are inconsistent. The entry declaration for `atomic_store_long_entry` claims it belongs to stub `atomic_load_long` but the current stub is actually `atomic_store_long`.

I will push a patch to fix that and another one for the copyrights.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027247244

From adinn at openjdk.org  Wed Jul  2 10:37:34 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 10:37:34 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v3]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - update copyrights
 - fix inconsistent stub declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/7908e895..e42ec698

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

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

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

From adinn at openjdk.org  Wed Jul  2 10:37:35 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 10:37:35 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
 <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
Message-ID: <tZH39ADnMeVR6_0nj1DKMX1FwfekDXG6NoPKjYoMONc=.00623622-36e2-4378-a598-4c16d4d4dd45@github.com>

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

@shqking I hope the arm build will now work ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027336478

From adinn at openjdk.org  Wed Jul  2 12:06:41 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 2 Jul 2025 12:06:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
Message-ID: <pk8hofhbfqKu8EtnoHxifBUr3Z2UvVTQC55g8T4Ii8g=.889a949b-e2e1-4f23-a611-8baecabd3ab4@github.com>

On Mon, 30 Jun 2025 18:28:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> I submitted testing.

@vnkozlov Could you please rereview this?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3027619494

From sparasa at openjdk.org  Wed Jul  2 15:29:43 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 2 Jul 2025 15:29:43 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>
Message-ID: <bnFvLjs7CcxpghqpArV_ApiKALSKtKWvfG6gRL-FO6k=.8c202c6a-eb05-439d-98a7-51aca94c3cd5@github.com>

On Wed, 2 Jul 2025 08:20:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Submitted testing for commit 2 / v01 :)
> 
> However: I can only test on SSE/AVX machines, so you will have to make sure it runs fine on APX and other architectures that may be impacted.

Thank you, Emanuel! 
Yes, this was tested using Intel SDE to emulate the APX features.

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3028302287

From haosun at openjdk.org  Thu Jul  3 00:17:43 2025
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 3 Jul 2025 00:17:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v2]
In-Reply-To: <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <D-kYuw5q3p4gO0Z7zO5Dd9auoSiBGJTgt2SR_GYVh4A=.686e7a2f-4a21-4aec-b756-777cb2503638@github.com>
 <_cRQRgZa3mOO4O7U4J8c8aLUNRA3_7jBUD9_bUu90Gc=.aca2173a-6edb-4954-b337-5b2348cf2f92@github.com>
Message-ID: <bovYqrJ61tTxcrXitVCTEo9kva41LwyQkjf2A1A6zec=.1cc050f3-ae75-405e-8a0e-711de95487af@github.com>

On Wed, 2 Jul 2025 09:47:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix formatting issues
>
> Hi.
> 
> Not a review. Here lists our internal test result.
> 
> ## 1. VM crashed for arm32
> 
> I created one armhf build via cross-compilation and ran `java --version` via Qemu.
> Here lists the error log.
> 
> 
> $ sudo chroot /sysroot/armhf /tmp/build-armhf/images/jdk/bin/java --version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/tmp/jdk-src/src/hotspot/share/runtime/stubInfo.cpp:416), pid=117661, tid=117663
> #  assert(declaredStub == stub_cursor) failed: Stubgen entry Arm_atomic_store_long_entry declares stub in scope of wrong stub Stub Generator atomic_store_long_stub
> #
> # JRE version:  (26.0) (fastdebug build )
> # Java VM: OpenJDK Server VM (fastdebug 26-internal-git-34ec2f11671, mixed mode, sharing, serial gc, linux-arm)
> # Problematic frame:
> # V  [libjvm.so+0xdf75f4]  StubInfo::process_stubgen_entry(StubGroup&, BlobId&, StubId&, EntryId&, char const*, BlobId, StubId, EntryId, int) [clone .constprop.0]+0x137
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to //core.117661)
> #
> # An error report file with more information is saved as:
> # //hs_err_pid117661.log
> #
> #
> qemu: uncaught target signal 6 (Aborted) - core dumped
> environment: line 1: 117660 Aborted                 "$@"
> 
> 
> It seems that the expected stub Stub Generator is `atomic_load_long_stub`.
> I guess the related code is around https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/stubDeclarations_arm.hpp#L45~L49
> 
> ## 2. copyright year should be updated for the following files
> 
> 
> src/hotspot/cpu/arm/stubRoutinesCrypto_arm.cpp
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_adler.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_aes.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_cos.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_exp.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_ghash.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_log.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly1305.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_pow.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_sin.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tan.cpp
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp
> src/hotspot/share/c1/c1_CodeStubs.hpp
> src/hotspot/share/runtime/stubCodeGenerator.hpp

> @shqking I hope the arm build will now work ok.

Thanks for your fix. Yes. It works now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3029773525

From haosun at openjdk.org  Thu Jul  3 00:17:44 2025
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 3 Jul 2025 00:17:44 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v3]
In-Reply-To: <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>
Message-ID: <l1-vkPYPPSiHQEzJyF4HS84mQ7dbrn1c9inSwSIYM_A=.e5362eeb-a2cb-415b-8b82-2ef2cda7ad2e@github.com>

On Wed, 2 Jul 2025 10:37:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyrights
>  - fix inconsistent stub declarations

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025 Intel Corporation. All rights reserved.

nit: Incorrect format. One comma is missing. Should be `2025,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2181192848

From adinn at openjdk.org  Thu Jul  3 08:40:32 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 08:40:32 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v4]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <myEltdp_Fa6ouP17dm6KdCaDHT16ToRW0t_SkAHH7l8=.c127d22d-1334-4642-b961-4482622093f5@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

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

  fix format for copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/e42ec698..6d4eee55

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

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

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

From adinn at openjdk.org  Thu Jul  3 09:38:48 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 09:38:48 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v3]
In-Reply-To: <l1-vkPYPPSiHQEzJyF4HS84mQ7dbrn1c9inSwSIYM_A=.e5362eeb-a2cb-415b-8b82-2ef2cda7ad2e@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <Cj0pDTuyKoMcS_HG61JRNZdrp05g2_VmRue_te22HDs=.2f7df94f-03c4-45f7-af6f-019bd3c79e47@github.com>
 <l1-vkPYPPSiHQEzJyF4HS84mQ7dbrn1c9inSwSIYM_A=.e5362eeb-a2cb-415b-8b82-2ef2cda7ad2e@github.com>
Message-ID: <FCLuK2shoeZi3d4uHtZAVzs8paahKtxdNPfT5M-gxY0=.853ecd61-fc6a-45de-bcab-19d74011b4e1@github.com>

On Thu, 3 Jul 2025 00:05:17 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyrights
>>  - fix inconsistent stub declarations
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2025 Intel Corporation. All rights reserved.
> 
> nit: Incorrect format. One comma is missing. Should be `2025,`

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2182328732

From adinn at openjdk.org  Thu Jul  3 13:19:32 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 13:19:32 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - save blobs using blob ids
 - make arg in declaration consistent with definition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/6d4eee55..776cbe90

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

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

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

From adinn at openjdk.org  Thu Jul  3 14:43:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 3 Jul 2025 14:43:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
Message-ID: <tnpDZNRpt2Ue-bD6vv8fSxlAwF9Pg4qXeN8XLYxK60w=.1bfe30ff-38b1-447a-a0d0-0544e8dc060c@github.com>

On Thu, 3 Jul 2025 13:19:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition

@ashu-mehra Could you please review this PR. In particular, can you check the modifications I just made to the aotCodeCache blob save/load API. We need to save the blob using a blob id rather than a stub id.

n.b. I had to re-enable the AOTStubCaching flag to test these latest changes (currently, it is always disabled in aotCodeCache.cpp). None of the blob save/restore functionality is exercised without that override.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3032528784

From asmehra at openjdk.org  Thu Jul  3 15:38:46 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 3 Jul 2025 15:38:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <tnpDZNRpt2Ue-bD6vv8fSxlAwF9Pg4qXeN8XLYxK60w=.1bfe30ff-38b1-447a-a0d0-0544e8dc060c@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
 <tnpDZNRpt2Ue-bD6vv8fSxlAwF9Pg4qXeN8XLYxK60w=.1bfe30ff-38b1-447a-a0d0-0544e8dc060c@github.com>
Message-ID: <trlKMVPHfX78lIbqVc2ArlhdZ65wNDVL5T-9MrrXgp8=.28384fee-bcd9-45d7-a712-a4b6d83db2fc@github.com>

On Thu, 3 Jul 2025 14:41:27 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - save blobs using blob ids
>>  - make arg in declaration consistent with definition
>
> @ashu-mehra Could you please review this PR. In particular, can you check the modifications I just made to the aotCodeCache blob save/load API. We need to save the blob using a blob id rather than a stub id.
> 
> n.b. I had to re-enable the AOTStubCaching flag to test these latest changes (currently, it is always disabled in aotCodeCache.cpp). None of the blob save/restore functionality is exercised without that override.

@adinn yes, I have been reviewing it. Slowly making my way through the code :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3032731124

From sparasa at openjdk.org  Thu Jul  3 15:45:41 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 3 Jul 2025 15:45:41 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <bnFvLjs7CcxpghqpArV_ApiKALSKtKWvfG6gRL-FO6k=.8c202c6a-eb05-439d-98a7-51aca94c3cd5@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <07SDzLSgYh87chUsYIvnAuLXvf9qodA4tZlEbO8FYiU=.a0d93ffe-76e1-4e91-b004-2645f03186f2@github.com>
 <bnFvLjs7CcxpghqpArV_ApiKALSKtKWvfG6gRL-FO6k=.8c202c6a-eb05-439d-98a7-51aca94c3cd5@github.com>
Message-ID: <xYBTl1H9ZImgNVL4p1IXaOQp673dnNmQzJ1jCSPepr4=.c31eb9cd-4f1c-449a-8a52-9ed0889fde9d@github.com>

On Wed, 2 Jul 2025 15:27:02 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Submitted testing for commit 2 / v01 :)
>
Hi Emanuel (@eme64), 
If the testing has passed, could you pls let me know?

Thanks,
Vamsi

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3032750246

From stuefe at openjdk.org  Thu Jul  3 16:57:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 3 Jul 2025 16:57:53 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
Message-ID: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>

`ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.

Depending on the size of the numerical address of the forwardee, nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 

Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

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

Commit messages:
 - shenandoahAssertFix

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

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

From asmehra at openjdk.org  Thu Jul  3 19:30:46 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 3 Jul 2025 19:30:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
Message-ID: <4qtYWDGX_L358HCCqENWKFOe4APEk5I96cXs3rsXuZE=.c4016c8e-9f76-4103-9bf8-f7ab75440623@github.com>

On Thu, 3 Jul 2025 13:19:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition

src/hotspot/share/opto/compile.cpp line 976:

> 974:   // try to reuse an existing stub
> 975:   {
> 976:     StubId stub_id = static_cast<StubId>(_stub_id);

`static_cast` can be avoided if `_stub_id` type is changed from `int` to `StubId`. And there is a similar `static_cast` in output.cpp as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2183613368

From asmehra at openjdk.org  Thu Jul  3 19:34:43 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 3 Jul 2025 19:34:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
Message-ID: <ZPlMR3aLsfThYqwbKzFndV2MttxnYi40r-vE0YmRioY=.a7acaf93-fc4f-4f82-a2dd-75fbb1424960@github.com>

On Thu, 3 Jul 2025 13:19:32 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition

Marked as reviewed by asmehra (Committer).

Looks good to me. I have just a minor comment. Thanks for these changes. This should help in simplifying the AOTCodeAddressTable.

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

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2984447568
PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3033390099

From kvn at openjdk.org  Thu Jul  3 19:58:42 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 3 Jul 2025 19:58:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
Message-ID: <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>

On Mon, 30 Jun 2025 18:28:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> I submitted testing.

> @vnkozlov Could you please rereview this?

This looks fine. Please merge latest jdk so I can do additional testing with `AOTStubCaching` enabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3033448504

From epeter at openjdk.org  Fri Jul  4 06:19:51 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 4 Jul 2025 06:19:51 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <An3X6HTGlIHzcHWYgqrFp_GQ383y8Bt2NRWF1H6sqAc=.c5fb973d-8246-487a-8f11-b0a50a9a5a92@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

Our internal testing passes. Fix looks reasonable. Thanks for the work!

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26009#pullrequestreview-2985721144

From duke at openjdk.org  Fri Jul  4 06:19:51 2025
From: duke at openjdk.org (duke)
Date: Fri, 4 Jul 2025 06:19:51 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
Message-ID: <DJUNLWT0eOOLd5Y0TqI_-ZUH69dzW5HYP_U6MMA-l4Q=.ca766898-6be4-4500-b295-7a5dd0be94a9@github.com>

On Mon, 30 Jun 2025 22:19:18 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
>> 
>> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
>> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
>> 
>> Both the issues are fixed in this PR.
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore the orginal contents of rax

@vamsi-parasa 
Your change (at version de7c373f49b14bfb759b6498b7b81a8d0b39a213) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3034667366

From sparasa at openjdk.org  Fri Jul  4 06:19:51 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 4 Jul 2025 06:19:51 GMT
Subject: RFR: 8360775: Fix Shenandoah GC test failures when APX is enabled
 [v2]
In-Reply-To: <An3X6HTGlIHzcHWYgqrFp_GQ383y8Bt2NRWF1H6sqAc=.c5fb973d-8246-487a-8f11-b0a50a9a5a92@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
 <oPyzE7tOJTc5v-cixzWkw2TmYED614bcKSechamz9WQ=.68b8f4e4-d3c2-41e0-a42e-2eb89122bb15@github.com>
 <An3X6HTGlIHzcHWYgqrFp_GQ383y8Bt2NRWF1H6sqAc=.c5fb973d-8246-487a-8f11-b0a50a9a5a92@github.com>
Message-ID: <h-goFbX22rJZwnGu5Fy0R71HhpKvElbQ6xKPaF4HcMs=.6b2a2a5e-85e8-4fda-818e-a1adfa87d769@github.com>

On Fri, 4 Jul 2025 06:14:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Our internal testing passes. Fix looks reasonable. Thanks for the work!

Thank you, Emanuel! :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26009#issuecomment-3034666181

From sparasa at openjdk.org  Fri Jul  4 15:11:47 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 4 Jul 2025 15:11:47 GMT
Subject: Integrated: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
References: <66o1iImVgzmTapY0AEGZeAg_VTj4ZbRc1MSFvgA8qYk=.ab11bc1a-3cb0-4832-82da-4e97ee8aaf9b@github.com>
Message-ID: <EW0wIarX2r97PhyyWdgpvb3IIYBFe6lfFl3jX4umNKU=.78d6deb0-5986-46f6-a02a-3440bfcf35c0@github.com>

On Fri, 27 Jun 2025 00:02:08 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> This PR fixes the test failures seen in many JTreg tests related to Shenandoah GC (`test/hotspot/jtreg/gc/shenandoah/`) with UseAPX. The issues were root caused to: 
> 
> 1. Higher band registers are not saved and restored in Shenandoah load_reference_barrier. 
> 2. Pusha/Popa implementation using push2p/pop2p does not restore the contents of rax.
> 
> Both the issues are fixed in this PR.

This pull request has now been integrated.

Changeset: 1c560727
Author:    Srinivas Vamsi Parasa <sparasa at openjdk.org>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee
Stats:     41 lines in 2 files changed: 40 ins; 0 del; 1 mod

8360775: Fix Shenandoah GC test failures when APX is enabled

Reviewed-by: sviswanathan, jbhateja, epeter

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

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

From adinn at openjdk.org  Sun Jul  6 15:25:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 15:25:46 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v6]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <M4YJwJGbjdQuwyMyG20wRdw45wz-5-7n_B2I3_uXxTA=.7d89c719-9054-4238-a076-63cab8a8ccfe@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

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

  store stub id for opto stub Compile instances as a StubId

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/776cbe90..59479dce

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

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

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

From adinn at openjdk.org  Sun Jul  6 15:25:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 15:25:47 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v5]
In-Reply-To: <4qtYWDGX_L358HCCqENWKFOe4APEk5I96cXs3rsXuZE=.c4016c8e-9f76-4103-9bf8-f7ab75440623@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <R06FYPj9_bfpABSeQGQX2KJbnFb94YN9GmQtn_bwK9w=.b8f8296b-7ceb-417a-8c10-849148be759a@github.com>
 <4qtYWDGX_L358HCCqENWKFOe4APEk5I96cXs3rsXuZE=.c4016c8e-9f76-4103-9bf8-f7ab75440623@github.com>
Message-ID: <NfgEHEUEWTGAVjH8usTNoMPRQ3Y4AnCuYeWW0B9IRiA=.b66c99c5-a6e0-4bc5-9c55-61bdb232f7d7@github.com>

On Thu, 3 Jul 2025 19:27:05 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - save blobs using blob ids
>>  - make arg in declaration consistent with definition
>
> src/hotspot/share/opto/compile.cpp line 976:
> 
>> 974:   // try to reuse an existing stub
>> 975:   {
>> 976:     StubId stub_id = static_cast<StubId>(_stub_id);
> 
> `static_cast` can be avoided if `_stub_id` type is changed from `int` to `StubId`. And there is a similar `static_cast` in output.cpp as well.

I think this conversion to int was done to avoid a problem with include dependencies. It is certainly not an issue now that StubId is statically generated in a header already included in all affected files. I have pushed a fix to remove the int casts and use StubId instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26004#discussion_r2188392663

From adinn at openjdk.org  Sun Jul  6 16:57:12 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 16:57:12 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Merge branch 'master' into enumerate_entries
 - store stub id for opto stub Compile instances as a StubId
 - save blobs using blob ids
 - make arg in declaration consistent with definition
 - fix format for copyright
 - update copyrights
 - fix inconsistent stub declarations
 - fix formatting issues
 - remove redundant doc comments
 - fix copy paste errors in riscv
 - ... and 8 more: https://git.openjdk.org/jdk/compare/8aa42991...dbc8394a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/59479dce..dbc8394a

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

  Stats: 25634 lines in 968 files changed: 12312 ins; 8365 del; 4957 mod
  Patch: https://git.openjdk.org/jdk/pull/26004.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26004/head:pull/26004

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

From adinn at openjdk.org  Sun Jul  6 16:57:12 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Sun, 6 Jul 2025 16:57:12 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
Message-ID: <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>

On Thu, 3 Jul 2025 19:56:08 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I submitted testing.
>
>> @vnkozlov Could you please rereview this?
> 
> This looks fine. Please merge latest jdk so I can do additional testing with `AOTStubCaching` enabled.

@vnkozlov 
> This looks fine. Please merge latest jdk so I can do additional testing with AOTStubCaching enabled.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3042206980

From duke at openjdk.org  Mon Jul  7 03:02:55 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 7 Jul 2025 03:02:55 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v3]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <6iybzjYUy4NEsceMFvm68jnstlojWf9L3ckRrYvohI0=.95f04354-722d-4751-9a2a-7d21ad7f981f@github.com>

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

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

  Remove unnecessary soft_max_capacity accesses

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25943/files
  - new: https://git.openjdk.org/jdk/pull/25943/files/49bda04e..00034259

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

  Stats: 64 lines in 16 files changed: 4 ins; 32 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25943/head:pull/25943

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

From duke at openjdk.org  Mon Jul  7 03:11:40 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 7 Jul 2025 03:11:40 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v2]
In-Reply-To: <0-_c2MpqhmXuv_rN3VHirKNVbqLn6Y-xEPk2Czj68GY=.af55e164-7565-4a7e-ab89-ffbb989b1401@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <o1wfwjjIJEcEOxI7ZNeNapByyhJsEBi22iu2nDNm3Lw=.954ab02a-5582-4474-ae82-d9a64fa41123@github.com>
 <-6IGc4gDm8t7AEFTtRbpGXLvVXvsKm9QWGfLGaGU2ls=.8c897937-ab45-45f9-bb5d-9ec54fd99563@github.com>
 <0-_c2MpqhmXuv_rN3VHirKNVbqLn6Y-xEPk2Czj68GY=.af55e164-7565-4a7e-ab89-ffbb989b1401@github.com>
Message-ID: <AKT_rfw0fZThyYroK3Zl1dwAMOmX8Ea-UuNJ6WGychY=.94270c28-9953-45ee-8420-34bae32dd7a5@github.com>

On Mon, 30 Jun 2025 23:02:23 GMT, Rui Li <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 1017:
>> 
>>> 1015: size_t ShenandoahGeneration::soft_max_capacity() const {
>>> 1016:   size_t capacity = ShenandoahGenerationalHeap::heap()->soft_max_capacity();
>>> 1017:   log_debug(gc)("soft_max_capacity: %zu", capacity); // TestDynamicSoftMaxHeapSize needs the log line to validate
>> 
>> This will be a hot method. It's called by the heuristic frequently to test if it should start a GC. We may also even test this on the allocation path. I'd rather not have a log level check here just for one test case. Can we move this log message to the place where the value is updated? I expect the value to change _much less_ frequently than it is read.
>
> Agree that the debug log can be too much in the log and impact perf. There is an existing log when soft max is changed: [link](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L865-L868). The problem is, before the fix, when the soft max was changed, gen shen  doesn't read the changed value. That's why I put a log here. Validating log is also indeed a bit fragile. If we remove the log, probably need to think another way to test.
> 
> 
> For removing `soft_max_capacity`: not sure if I understand it right, but I thought `ShenandoahSpaceInfo` was the parent class in the polymorphism ([code](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp#L68)), so the code would work for both gen shen (ShenandoahGeneration) and ShenandoahGlobalGeneration? If we removed `soft_max_capacity ` from ShenandoahSpaceInfo, wouldn't that make heuristics not able to access soft max heap size?

Realized just simply replace `_space_info->soft_max_capacity()` with `ShenandoahHeap::heap()->soft_max_capacity()`. 

Updated in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2188877998

From duke at openjdk.org  Mon Jul  7 03:38:12 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 7 Jul 2025 03:38:12 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v4]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <bpHp-0C2cifPXbK1ibfTwb_CvNUFQjj22Qm0W52Bj5U=.c995fe10-ef26-4f81-881f-354afc92cd1b@github.com>

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

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

  Remove extra arg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25943/files
  - new: https://git.openjdk.org/jdk/pull/25943/files/00034259..503e83ec

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

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

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

From amitkumar at openjdk.org  Mon Jul  7 04:26:43 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 7 Jul 2025 04:26:43 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
 <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
Message-ID: <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>

On Sun, 6 Jul 2025 16:54:01 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> @vnkozlov Could you please rereview this?
>> 
>> This looks fine. Please merge latest jdk so I can do additional testing with `AOTStubCaching` enabled.
>
> @vnkozlov 
>> This looks fine. Please merge latest jdk so I can do additional testing with AOTStubCaching enabled.
> 
> Done.

Hi @adinn, 

could you add these changes fixing test failure on s390: 


diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
index 10e5abe9ce8..687fb764bd8 100644
--- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
+++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
@@ -164,15 +164,16 @@ class StubGenerator: public StubCodeGenerator {
 
       // Save non-volatile registers to ABI of caller frame.
       BLOCK_COMMENT("save registers, push frame {");
-      __ z_stmg(Z_R6, Z_R14, 16, Z_SP);
-      __ z_std(Z_F8, 96, Z_SP);
-      __ z_std(Z_F9, 104, Z_SP);
-      __ z_std(Z_F10, 112, Z_SP);
-      __ z_std(Z_F11, 120, Z_SP);
-      __ z_std(Z_F12, 128, Z_SP);
-      __ z_std(Z_F13, 136, Z_SP);
-      __ z_std(Z_F14, 144, Z_SP);
-      __ z_std(Z_F15, 152, Z_SP);
+      __ save_return_pc();
+      __ z_stmg(Z_R6, Z_R13, 16, Z_SP);
+      __ z_std(Z_F8, 88, Z_SP);
+      __ z_std(Z_F9, 96, Z_SP);
+      __ z_std(Z_F10, 104, Z_SP);
+      __ z_std(Z_F11, 112, Z_SP);
+      __ z_std(Z_F12, 120, Z_SP);
+      __ z_std(Z_F13, 128, Z_SP);
+      __ z_std(Z_F14, 136, Z_SP);
+      __ z_std(Z_F15, 144, Z_SP);
 
       //
       // Push ENTRY_FRAME including arguments:
@@ -337,15 +338,16 @@ class StubGenerator: public StubCodeGenerator {
       __ z_lg(r_arg_result_type, result_type_offset, r_entryframe_fp);
 
       // Restore non-volatiles.
-      __ z_lmg(Z_R6, Z_R14, 16, Z_SP);
-      __ z_ld(Z_F8, 96, Z_SP);
-      __ z_ld(Z_F9, 104, Z_SP);
-      __ z_ld(Z_F10, 112, Z_SP);
-      __ z_ld(Z_F11, 120, Z_SP);
-      __ z_ld(Z_F12, 128, Z_SP);
-      __ z_ld(Z_F13, 136, Z_SP);
-      __ z_ld(Z_F14, 144, Z_SP);
-      __ z_ld(Z_F15, 152, Z_SP);
+      __ restore_return_pc();
+      __ z_lmg(Z_R6, Z_R13, 16, Z_SP);
+      __ z_ld(Z_F8, 88, Z_SP);
+      __ z_ld(Z_F9, 96, Z_SP);
+      __ z_ld(Z_F10, 104, Z_SP);
+      __ z_ld(Z_F11, 112, Z_SP);
+      __ z_ld(Z_F12, 120, Z_SP);
+      __ z_ld(Z_F13, 128, Z_SP);
+      __ z_ld(Z_F14, 136, Z_SP);
+      __ z_ld(Z_F15, 144, Z_SP);
       BLOCK_COMMENT("} restore");
 
       //

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3043435063

From adinn at openjdk.org  Mon Jul  7 08:06:42 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 7 Jul 2025 08:06:42 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
 <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
 <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>
Message-ID: <5BzdvvwkjsUW3ob7HiUnhkI8IxZ7D3YO7iuxblwWhUc=.67d4293e-f373-4d71-a0b2-c43fab99d243@github.com>

On Mon, 7 Jul 2025 04:24:20 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> @vnkozlov 
>>> This looks fine. Please merge latest jdk so I can do additional testing with AOTStubCaching enabled.
>> 
>> Done.
>
> Hi @adinn, 
> 
> could you add these changes fixing test failure on s390: 
> 
> 
> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> index 10e5abe9ce8..687fb764bd8 100644
> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> @@ -164,15 +164,16 @@ class StubGenerator: public StubCodeGenerator {
>  
>        // Save non-volatile registers to ABI of caller frame.
>        BLOCK_COMMENT("save registers, push frame {");
> -      __ z_stmg(Z_R6, Z_R14, 16, Z_SP);
> -      __ z_std(Z_F8, 96, Z_SP);
> -      __ z_std(Z_F9, 104, Z_SP);
> -      __ z_std(Z_F10, 112, Z_SP);
> -      __ z_std(Z_F11, 120, Z_SP);
> -      __ z_std(Z_F12, 128, Z_SP);
> -      __ z_std(Z_F13, 136, Z_SP);
> -      __ z_std(Z_F14, 144, Z_SP);
> -      __ z_std(Z_F15, 152, Z_SP);
> +      __ save_return_pc();
> +      __ z_stmg(Z_R6, Z_R13, 16, Z_SP);
> +      __ z_std(Z_F8, 88, Z_SP);
> +      __ z_std(Z_F9, 96, Z_SP);
> +      __ z_std(Z_F10, 104, Z_SP);
> +      __ z_std(Z_F11, 112, Z_SP);
> +      __ z_std(Z_F12, 120, Z_SP);
> +      __ z_std(Z_F13, 128, Z_SP);
> +      __ z_std(Z_F14, 136, Z_SP);
> +      __ z_std(Z_F15, 144, Z_SP);
>  
>        //
>        // Push ENTRY_FRAME including arguments:
> @@ -337,15 +338,16 @@ class StubGenerator: public StubCodeGenerator {
>        __ z_lg(r_arg_result_type, result_type_offset, r_entryframe_fp);
>  
>        // Restore non-volatiles.
> -      __ z_lmg(Z_R6, Z_R14, 16, Z_SP);
> -      __ z_ld(Z_F8, 96, Z_SP);
> -      __ z_ld(Z_F9, 104, Z_SP);
> -      __ z_ld(Z_F10, 112, Z_SP);
> -      __ z_ld(Z_F11, 120, Z_SP);
> -      __ z_ld(Z_F12, 128, Z_SP);
> -      __ z_ld(Z_F13, 136, Z_SP);
> -      __ z_ld(Z_F14, 144, Z_SP);
> -      __ z_ld(Z_F15, 152, Z_SP);
> +      __ restore_return_pc();
> +      __ z_lmg(Z_R6, Z_R13, 16, Z_SP);
> +      __ z_ld(Z_F8, 88, Z_SP);
> +      __ z_ld(Z_F9, 96, Z_SP);
> +      __ z_ld(Z_F10, 104, Z_SP);
> +      __ z_ld(Z_F11, 112, Z_SP);
> +      __ z_ld(Z_F12, 120, Z_SP);
> +      __ z_ld(Z_F13, 128, Z_SP);
> +      __ z_ld(Z_F14, 136, Z_SP);
> +      __ z_ld(Z_F15, 144, Z_SP);
>        BLOCK_COMMENT("} restore");
>  
>        //

@offamitkumar
> could you add these changes fixing test failure on s390:

I think these need to be included in a separate PR. Your patch fixes a problem that is independent from the current change (it was already there but only manifested after this change).

Separating these issues is important because we may decide to backport your patch (say, to jdk25) and the changes in this PR definitely should not be backported. It also matters because it avoids confusing maintainers over the purpose and scope of these two sets of changes -- this one is meant to be a removal of technical debt with no visible changes to functionality, whereas your patch is remedying a functional defect.

So, please raise a new JIRA indicating what problem the above patch fixes and then create a new PR for the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3043894384

From tschatzl at openjdk.org  Mon Jul  7 13:36:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 13:36:53 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info()
Message-ID: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>

Hi all,

  please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.

The change moves these methods to `protected` visibility.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8361349

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

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

From ayang at openjdk.org  Mon Jul  7 14:04:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 7 Jul 2025 14:04:42 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info()
In-Reply-To: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
Message-ID: <c_fGFeNrF5ysBpWriB_1eA7IoLpvMTCBIApTGpkMKno=.8a22f725-c1af-4296-9913-a1f7d387ac58@github.com>

On Mon, 7 Jul 2025 13:30:44 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
> 
> The change moves these methods to `protected` visibility.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26160#pullrequestreview-2994041889

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From tschatzl at openjdk.org  Mon Jul  7 16:21:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 7 Jul 2025 16:21:57 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v2]
In-Reply-To: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
Message-ID: <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>

> Hi all,
> 
>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
> 
> The change moves these methods to `protected` visibility.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

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

  * iwalulya suggested to make leaf classes use private; although probably one wants to use final, but Hotspot does not seem to use that

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26160/files
  - new: https://git.openjdk.org/jdk/pull/26160/files/d601eb4d..5fd5d6f7

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

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

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

From iwalulya at openjdk.org  Mon Jul  7 16:36:39 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 7 Jul 2025 16:36:39 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v2]
In-Reply-To: <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
Message-ID: <KVlt3wrUbyp2rSUB2PWsOZFPdDoVmI30587-wjKfMzQ=.d667c698-e467-45a4-9cdf-00d23c740f5a@github.com>

On Mon, 7 Jul 2025 16:21:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
>> 
>> The change moves these methods to `protected` visibility.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya suggested to make leaf classes use private; although probably one wants to use final, but Hotspot does not seem to use that

Nit:

src/hotspot/share/gc/epsilon/epsilonHeap.hpp line 52:

> 50:   volatile size_t _last_heap_print;
> 51: 
> 52: private:

private: can be removed.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26160#pullrequestreview-2994627357
PR Review Comment: https://git.openjdk.org/jdk/pull/26160#discussion_r2190587513

From duke at openjdk.org  Mon Jul  7 19:16:39 2025
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Mon, 7 Jul 2025 19:16:39 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v2]
In-Reply-To: <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <cCJ7Qbn_sCgo5FYFSVztzo1cQOgZHIsKNzDh_y33To4=.9e0715c5-165e-4d66-b819-c482209e36d9@github.com>
Message-ID: <w9mMA1CVOfPC9GBDVWjePr7Cr1zmeQ69Yy6H_DAYVYU=.fac7caca-2aaa-4921-ad41-006144704588@github.com>

On Mon, 7 Jul 2025 16:21:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
>> 
>> The change moves these methods to `protected` visibility.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * iwalulya suggested to make leaf classes use private; although probably one wants to use final, but Hotspot does not seem to use that

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/26160#pullrequestreview-2995023091

From kvn at openjdk.org  Mon Jul  7 20:26:40 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 20:26:40 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <5BzdvvwkjsUW3ob7HiUnhkI8IxZ7D3YO7iuxblwWhUc=.67d4293e-f373-4d71-a0b2-c43fab99d243@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <NorYkRiPMJqwJJmg3ZWx3GmJ2nFoCwGgOZDRw94I8P0=.6a4de505-1219-4178-9ec7-c926c1ddb975@github.com>
 <VMtCiXmXa2bUy9M_hqYnCdFMXcbvAr0rFoPyQWgYr_E=.8d4bf65f-4af7-4193-8010-57fc0f37f1b1@github.com>
 <vsiGiDA0ufIe_AhtGBKHvV2Q68iS8-MQHuFbp__zOPA=.86bb86bb-f1f3-4e50-beda-8c8064dd8d48@github.com>
 <Pk26ug5e8lDkMvNm-8l2UFHyklw065XkwiBv8jJwVbU=.312ecd1b-1c3b-44c4-8342-76ce2656428a@github.com>
 <5BzdvvwkjsUW3ob7HiUnhkI8IxZ7D3YO7iuxblwWhUc=.67d4293e-f373-4d71-a0b2-c43fab99d243@github.com>
Message-ID: <KAKLp1nNsaAAg58SdqxkdmmaKOz7foUuoW1vu1yLIGo=.b7fa3adf-a339-4e77-a513-808f05ef5da8@github.com>

On Mon, 7 Jul 2025 08:03:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Hi @adinn, 
>> 
>> could you add these changes fixing test failure on s390: 
>> 
>> 
>> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
>> index 10e5abe9ce8..687fb764bd8 100644
>> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
>> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
>> @@ -164,15 +164,16 @@ class StubGenerator: public StubCodeGenerator {
>>  
>>        // Save non-volatile registers to ABI of caller frame.
>>        BLOCK_COMMENT("save registers, push frame {");
>> -      __ z_stmg(Z_R6, Z_R14, 16, Z_SP);
>> -      __ z_std(Z_F8, 96, Z_SP);
>> -      __ z_std(Z_F9, 104, Z_SP);
>> -      __ z_std(Z_F10, 112, Z_SP);
>> -      __ z_std(Z_F11, 120, Z_SP);
>> -      __ z_std(Z_F12, 128, Z_SP);
>> -      __ z_std(Z_F13, 136, Z_SP);
>> -      __ z_std(Z_F14, 144, Z_SP);
>> -      __ z_std(Z_F15, 152, Z_SP);
>> +      __ save_return_pc();
>> +      __ z_stmg(Z_R6, Z_R13, 16, Z_SP);
>> +      __ z_std(Z_F8, 88, Z_SP);
>> +      __ z_std(Z_F9, 96, Z_SP);
>> +      __ z_std(Z_F10, 104, Z_SP);
>> +      __ z_std(Z_F11, 112, Z_SP);
>> +      __ z_std(Z_F12, 120, Z_SP);
>> +      __ z_std(Z_F13, 128, Z_SP);
>> +      __ z_std(Z_F14, 136, Z_SP);
>> +      __ z_std(Z_F15, 144, Z_SP);
>>  
>>        //
>>        // Push ENTRY_FRAME including arguments:
>> @@ -337,15 +338,16 @@ class StubGenerator: public StubCodeGenerator {
>>        __ z_lg(r_arg_result_type, result_type_offset, r_entryframe_fp);
>>  
>>        // Restore non-volatiles.
>> -      __ z_lmg(Z_R6, Z_R14, 16, Z_SP);
>> -      __ z_ld(Z_F8, 96, Z_SP);
>> -      __ z_ld(Z_F9, 104, Z_SP);
>> -      __ z_ld(Z_F10, 112, Z_SP);
>> -      __ z_ld(Z_F11, 120, Z_SP);
>> -      __ z_ld(Z_F12, 128, Z_SP);
>> -      __ z_ld(Z_F13, 136, Z_SP);
>> -      __ z_ld(Z_F14, 144, Z_SP);
>> -      __ z_ld(Z_F15, 152, Z_SP);
>> +      __ restore_return_pc();
>> +      __ z_lmg(Z_R6, Z_R13, 16, Z_SP);
>> +      __ z_ld(Z_F8, 88, Z_SP);
>> +      __ z_ld(Z_F9, 96, Z_SP);
>> +      __ z_ld(Z_F10, 104, Z_SP);
>> +      __ z_ld(Z_F11, 112, Z_SP);
>> +      __ z_ld(Z_F12, 120, Z_SP);
>> +      __ z_ld(Z_F13, 128, Z_SP);
>> +      __ z_ld(Z_F14, 136, Z_SP);
>> +      __ z_ld(Z_F15, 144, Z_SP);
>>        BLOCK_COMMENT("} restore");
>>  
>>        //
>
> @offamitkumar
>> could you add these changes fixing test failure on s390:
> 
> I think these need to be included in a separate PR. Your patch fixes a problem that is independent from the current change (it was already there but only manifested after this change).
> 
> Separating these issues is important because we may decide to backport your patch (say, to jdk25) and the changes in this PR definitely should not be backported. It also matters because it avoids confusing maintainers over the purpose and scope of these two sets of changes -- this one is meant to be a removal of technical debt with no visible changes to functionality, whereas your patch is remedying a functional defect.
> 
> So, please raise a new JIRA indicating what problem the above patch fixes and then create a new PR for the patch.

Thank you @adinn  for merge. Unfortunately I was not able to enable Stubs caching for testing.
It failed my local testing. `runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java ` test failed on x86 for multiply reasons. Some are ease to fix and some may be not. I gave up after hitting relocation patching issue.

I submitted testing with AOTStubCaching disabled as in current code.

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3046421564

From wkemper at openjdk.org  Mon Jul  7 20:59:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 7 Jul 2025 20:59:55 GMT
Subject: Integrated: gc+regions needs to be at trace, not debug
In-Reply-To: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>
References: <cOMojDn2MzU2-fozHCYGwL-Ciz5lLAMHNWMT9cAo_ac=.9a58de57-d398-48ea-8e46-c7b970914ec0@github.com>
Message-ID: <LQsaOfAJKNRipC-mKP43fEPmSWZIYB5FfqfPrH-AQdI=.c47b7833-d028-4a9b-87ba-c6f9f2e649df@github.com>

On Tue, 1 Jul 2025 21:19:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Readme instructions have incorrect log level

This pull request has now been integrated.

Changeset: 2e6898c9
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-visualizer/commit/2e6898c9d067df731d6dc5aaf3579f0c5ad9c793
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

gc+regions needs to be at trace, not debug

Reviewed-by: ysr, rkennke

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

PR: https://git.openjdk.org/shenandoah-visualizer/pull/2

From kvn at openjdk.org  Mon Jul  7 21:14:53 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 21:14:53 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
Message-ID: <xPU711hVpnxRooP9rp4cjfRR-WbvqkaXq8l8_A_w5sA=.70a8cfcc-8307-4f4f-a1e7-77a83c449f84@github.com>

On Sun, 6 Jul 2025 16:57:12 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into enumerate_entries
>  - store stub id for opto stub Compile instances as a StubId
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition
>  - fix format for copyright
>  - update copyrights
>  - fix inconsistent stub declarations
>  - fix formatting issues
>  - remove redundant doc comments
>  - fix copy paste errors in riscv
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/266fd59e...dbc8394a

I found the cause of my local testing failure. I built with ubsan and hit [JDK-8360942](https://bugs.openjdk.org/browse/JDK-8360942) which I am working on. After applying the fix the test passed. Here other changes you may consider to include because they fix stack overflow stub generation:


diff --git a/src/hotspot/share/code/aotCodeCache.cpp b/src/hotspot/share/code/aotCodeCache.cpp
index 08cd05a64ed..4c080b90acc 100644
--- a/src/hotspot/share/code/aotCodeCache.cpp
+++ b/src/hotspot/share/code/aotCodeCache.cpp
@@ -1298,6 +1314,7 @@ void AOTCodeAddressTable::init_extrs() {
     SET_ADDRESS(_extrs, SharedRuntime::resolve_opt_virtual_call_C);
     SET_ADDRESS(_extrs, SharedRuntime::resolve_virtual_call_C);
     SET_ADDRESS(_extrs, SharedRuntime::resolve_static_call_C);
+    SET_ADDRESS(_extrs, SharedRuntime::throw_StackOverflowError);
     SET_ADDRESS(_extrs, SharedRuntime::throw_delayed_StackOverflowError);
     SET_ADDRESS(_extrs, SharedRuntime::throw_AbstractMethodError);
     SET_ADDRESS(_extrs, SharedRuntime::throw_IncompatibleClassChangeError);
diff --git a/src/hotspot/share/runtime/init.cpp b/src/hotspot/share/runtime/init.cpp
index b54afd9f735..37c13d90e04 100644
--- a/src/hotspot/share/runtime/init.cpp
+++ b/src/hotspot/share/runtime/init.cpp
@@ -147,9 +150,9 @@ jint init_globals() {
   AsyncLogWriter::initialize();

   initial_stubs_init();      // initial stub routines
+  AOTCodeCache::init_early_stubs_table();  // need this after initial_stubs and before generate_initial_stub
   // stack overflow exception blob is referenced by the interpreter
   SharedRuntime::generate_initial_stubs();
-  AOTCodeCache::init_early_stubs_table();  // need this after initial_stubs
   gc_barrier_stubs_init();   // depends on universe_init, must be before interpreter_init
   continuations_init();      // must precede continuation stub generation
   continuation_stubs_init(); // depends on continuations_init

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3046535698

From kvn at openjdk.org  Mon Jul  7 23:26:51 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 7 Jul 2025 23:26:51 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
Message-ID: <G_28XEEvVa4ENk6f3yOtZSIoNzuYHHL4zktZdRG6FL0=.8aff8f11-0a28-40c9-9556-8ecc103a056a@github.com>

On Sun, 6 Jul 2025 16:57:12 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into enumerate_entries
>  - store stub id for opto stub Compile instances as a StubId
>  - save blobs using blob ids
>  - make arg in declaration consistent with definition
>  - fix format for copyright
>  - update copyrights
>  - fix inconsistent stub declarations
>  - fix formatting issues
>  - remove redundant doc comments
>  - fix copy paste errors in riscv
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/7a32697c...dbc8394a

So far testing is fine. I see only failures caused by known AOT stubs caching bug: [JDK-8357593](https://bugs.openjdk.org/browse/JDK-8357593)

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3046794427

From duke at openjdk.org  Tue Jul  8 00:23:55 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 00:23:55 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v5]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

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

  Use comment style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25943/files
  - new: https://git.openjdk.org/jdk/pull/25943/files/503e83ec..8e0b1f21

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

  Stats: 160 lines in 1 file changed: 97 ins; 49 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25943/head:pull/25943

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

From stuefe at openjdk.org  Tue Jul  8 08:28:44 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 08:28:44 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <MTpr4gfUVI80umJYXUVQ9kyE_mLcWpHqmV6B-u7WrUs=.ecb714ac-4acb-4ced-a40a-4b19a4d9604a@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.
> 
> Depending on the size of the non-null bits of the forwardee (whether it spills into the nKlass bits), nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 
> 
> Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

Ping @shipilev, maybe? Or @rkennke? Its really trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/26117#issuecomment-3047877896

From tschatzl at openjdk.org  Tue Jul  8 08:32:18 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 8 Jul 2025 08:32:18 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v3]
In-Reply-To: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
Message-ID: <IatqrJG2oDgzOXFu8TQQpFKwefD2P3qGZvaMCKX4tYs=.52545b7a-4557-40b3-81b8-058dbc2a202d@github.com>

> Hi all,
> 
>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
> 
> The change moves these methods to `protected` visibility.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

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

  * remove one more unnecessary `private`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26160/files
  - new: https://git.openjdk.org/jdk/pull/26160/files/5fd5d6f7..087d72b7

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

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

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

From iwalulya at openjdk.org  Tue Jul  8 08:32:18 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 8 Jul 2025 08:32:18 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v3]
In-Reply-To: <IatqrJG2oDgzOXFu8TQQpFKwefD2P3qGZvaMCKX4tYs=.52545b7a-4557-40b3-81b8-058dbc2a202d@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <IatqrJG2oDgzOXFu8TQQpFKwefD2P3qGZvaMCKX4tYs=.52545b7a-4557-40b3-81b8-058dbc2a202d@github.com>
Message-ID: <1I--DXjCGgzHqtiKzm0OxjTMtURCvO7YFZjjU4iZo_8=.09a6b6ac-dade-4c6a-8a94-c7ce79590dda@github.com>

On Tue, 8 Jul 2025 08:29:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
>> 
>> The change moves these methods to `protected` visibility.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove one more unnecessary `private`

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26160#pullrequestreview-2996527566

From rkennke at openjdk.org  Tue Jul  8 08:51:47 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Jul 2025 08:51:47 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <0tqh-ywEfDa4TN2ihTO5xxgNmpAv1EcJMSJBbzcbBEc=.3f0dffb4-37fc-49c0-a0fa-7e54214e8aec@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.
> 
> Depending on the size of the non-null bits of the forwardee (whether it spills into the nKlass bits), nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 
> 
> Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

Good! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26117#pullrequestreview-2996617172

From shade at openjdk.org  Tue Jul  8 08:56:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 08:56:42 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <ElNQ62y7sHz9RwBdZHtOynC5is9gEfVa7noNClraqCw=.0da72e27-beeb-49ac-9592-6a8892e3d8dc@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.
> 
> Depending on the size of the non-null bits of the forwardee (whether it spills into the nKlass bits), nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 
> 
> Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

There are two peculiarities in this method. It is normally called from diagnostics code, and so we are not 100% sure it it is even safe to reach through the fwdptr for klass. Second, we should be printing the raw header at least in some cases, because again, diagnostics.

Let me think about it...

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

PR Review: https://git.openjdk.org/jdk/pull/26117#pullrequestreview-2996640881

From adinn at openjdk.org  Tue Jul  8 10:59:30 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 8 Jul 2025 10:59:30 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
 - add missing C++ method to AOT cache address table

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26004/files
  - new: https://git.openjdk.org/jdk/pull/26004/files/dbc8394a..a14c9821

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

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

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

From adinn at openjdk.org  Tue Jul  8 10:59:34 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 8 Jul 2025 10:59:34 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v7]
In-Reply-To: <G_28XEEvVa4ENk6f3yOtZSIoNzuYHHL4zktZdRG6FL0=.8aff8f11-0a28-40c9-9556-8ecc103a056a@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <ZgwQZEQi1BIr7XZUEBLKuyyIIaTFsHK2DHtmKvYj7k0=.0f46e67b-c997-48c3-a63f-758c30b8cc35@github.com>
 <G_28XEEvVa4ENk6f3yOtZSIoNzuYHHL4zktZdRG6FL0=.8aff8f11-0a28-40c9-9556-8ecc103a056a@github.com>
Message-ID: <P4dbKQM4Cl8v8uOkrDUbhvR5lIXNrwSl5pIdzbJ6xTY=.c4e95704-c57c-439c-b7b6-597a1fe378e5@github.com>

On Mon, 7 Jul 2025 23:24:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into enumerate_entries
>>  - store stub id for opto stub Compile instances as a StubId
>>  - save blobs using blob ids
>>  - make arg in declaration consistent with definition
>>  - fix format for copyright
>>  - update copyrights
>>  - fix inconsistent stub declarations
>>  - fix formatting issues
>>  - remove redundant doc comments
>>  - fix copy paste errors in riscv
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/e06700a6...dbc8394a
>
> So far testing is fine. I see only failures caused by known AOT stubs caching bug: [JDK-8357593](https://bugs.openjdk.org/browse/JDK-8357593)

@vnkozlov I've pushed the two changes you provided (on the assumption that we are not going to need to backport them to jdk25).
Is there any need for more testing, assuming the latest push passes GHA?
Is there anything I can do to help with JDK-8357593?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3048407148

From dbriemann at openjdk.org  Tue Jul  8 13:27:20 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 8 Jul 2025 13:27:20 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires
Message-ID: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>

Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.

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

Commit messages:
 - 8361599: [PPC64] enable missing tests via jtreg requires

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

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

From shade at openjdk.org  Tue Jul  8 13:28:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 13:28:42 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.
> 
> Depending on the size of the non-null bits of the forwardee (whether it spills into the nKlass bits), nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 
> 
> Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

You know what, this is fine as it is.

The whole business with `ShenandoahForwarding::klass` is super-duper-awkward, and verifier already touches the forwardees using that method in places where it really should not. It needs a more comprehensive fix for `+UCOH`.

It is a mess, but not your mess. So integrate this one, we will figure out `ShenandoahForwarding::klass` after this.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26117#pullrequestreview-2997654169

From stuefe at openjdk.org  Tue Jul  8 13:48:40 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 13:48:40 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
 <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
Message-ID: <E2AFZRuplK_3qEuT7diemMZs8vkRwEMo6nBjHMJv_PE=.4a37a806-b3ce-4991-b15f-fde49d73ca43@github.com>

On Tue, 8 Jul 2025 13:25:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> You know what, this is fine as it is.
> 
> The whole business with `ShenandoahForwarding::klass` is super-duper-awkward, and verifier already touches the forwardees using that method in places where it really should not. It needs a more comprehensive fix for `+UCOH`.
> 
> It is a mess, but not your mess. So integrate this one, we will figure out `ShenandoahForwarding::klass` after this.

I had a similar thought while working on https://bugs.openjdk.org/browse/JDK-8361342 . `ShenandoahForwarding::klass` resolves the narrow Klass pointer, which may already assert if that one is null or invalid. I mentally left it for a rainy friday afternoon to fix.

And yes, printing the raw header (and possibly the first few payload words, to get a bit of the first members) I found very useful. os::print_hex_dump will tiptoe around invalid memory, so that should be fine to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26117#issuecomment-3049039918

From dbriemann at openjdk.org  Tue Jul  8 14:17:21 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 8 Jul 2025 14:17:21 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
Message-ID: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>

> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.

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

  adapt copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26184/files
  - new: https://git.openjdk.org/jdk/pull/26184/files/d0a1efa1..f79e2895

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

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

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

From mdoerr at openjdk.org  Tue Jul  8 14:26:41 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 14:26:41 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <5JXgG6JiUbQ4tvgG_bN_KoZ65M3Y8so4259bmvJufWY=.22c34a1a-dbbe-4bb2-961f-d90097077d5b@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

Looks good and trivial.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26184#pullrequestreview-2997902196

From stuefe at openjdk.org  Tue Jul  8 14:59:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 14:59:49 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror object
 after JDK-8340297
Message-ID: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>

Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 

This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.

For details about this issue, please see the Jira description and comment. The short version is:
- class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
- but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
- But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.

I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.

Therefore I just changed the assertions.

But I would like to hear other people's opinion on this.

Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

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

Commit messages:
 - also fix ShenandoahVerifier
 - start

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

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

From stuefe at openjdk.org  Tue Jul  8 14:59:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Jul 2025 14:59:49 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <sackfq8w9KfzanWVvTwWdBUeR09fu-zAQOyBn0tJsLY=.d0cc8c2c-1acb-478d-b483-44d50a265d88@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

Ping @shipilev or @rkennke?

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049289071

From shade at openjdk.org  Tue Jul  8 15:24:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 15:24:38 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <RadK77QLt6Nwqgxpn39SzuI6jJfCny9d_7pJoSFNK9Q=.d570b367-f213-4253-9cf5-7d65dcd8d0b8@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

Only looked at this briefly, but that sounds like what I did here: https://github.com/openjdk/jdk/pull/21064 -- but forgot to complete it?

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049385835

From shade at openjdk.org  Tue Jul  8 16:32:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Jul 2025 16:32:38 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

> Only looked at this briefly, but that sounds like what I did here: #21064 -- but forgot to complete it?

Yes, it looks like it is! The sequence of events you describe seems to also match [JDK-8340364](https://bugs.openjdk.org/browse/JDK-8340364). So, what do you want to do? I can finish up #21064 and test it with your Metaspace assertion patches, if you want.

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049592995

From wkemper at openjdk.org  Tue Jul  8 17:45:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 17:45:40 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <0RUevGLqg0w1Cx1B9IWhTuNc0ag4FoLfSLEL5_xFcO8=.d65405d3-e713-4c94-a147-89e20dfe13bd@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 274:

> 272:     // During class redefinition the old Klass gets reclaimed and the old mirror oop's Klass reference
> 273:     // nulled out (hence the "klass != nullptr" condition below). However, the mirror oop may have been
> 274:     // forwarded if we are in the mids of an evacuation. In that case, the forwardee's Klass reference

s/mids/midst

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 275:

> 273:     // nulled out (hence the "klass != nullptr" condition below). However, the mirror oop may have been
> 274:     // forwarded if we are in the mids of an evacuation. In that case, the forwardee's Klass reference
> 275:     // is nulled out. The old, forwarded, still still carries the old invalid Klass pointer. It will be

s/still still/still

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26187#discussion_r2193102294
PR Review Comment: https://git.openjdk.org/jdk/pull/26187#discussion_r2193102793

From wkemper at openjdk.org  Tue Jul  8 17:52:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 17:52:37 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

The explanation and the changes make sense to me. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3049812331

From kdnilsen at openjdk.org  Tue Jul  8 17:54:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 8 Jul 2025 17:54:22 GMT
Subject: RFR: 8361529: GenShen: Fix bad assert in swap card tables
Message-ID: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>

The end of range for card marks checked by assert needs to be based from the base of the card table rather than the mapped base of the card table.

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

Commit messages:
 - Assert from byte_map rather than byte_map_base
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 29 more: https://git.openjdk.org/jdk/compare/197fde53...8177e148

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

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

From wkemper at openjdk.org  Tue Jul  8 17:59:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 17:59:39 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v5]
In-Reply-To: <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
Message-ID: <eQVaICGtfLEi5NtlKNbwPNBShEPv6ao93LaMi5VOzBQ=.e5714f13-8c52-4176-b1dd-85e225ea89f7@github.com>

On Tue, 8 Jul 2025 00:23:55 GMT, Rui Li <duke at openjdk.org> wrote:

>> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
>> 
>> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
>> 
>> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use comment style

This is a nice simplification. Thank you!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25943#pullrequestreview-2998614615

From wkemper at openjdk.org  Tue Jul  8 18:17:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 18:17:40 GMT
Subject: RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
References: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
Message-ID: <UG8xCkKAbqOfJXOUM3U_PeBeOX5tzSLUEWlhZ7s-tEM=.325213e8-9b1d-44d7-bf8c-8ebef6cc08e9@github.com>

On Tue, 8 Jul 2025 17:40:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The end of range for card marks checked by assert needs to be based from the base of the card table rather than the mapped base of the card table.

Good catch!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26197#pullrequestreview-2998661511

From duke at openjdk.org  Tue Jul  8 18:33:41 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Jul 2025 18:33:41 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v5]
In-Reply-To: <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <Anad63prUR10XX70A08xo5_rkZ9BG3Ae-FmSZCGFZ2g=.3d21638d-2f8b-4f89-ae7c-19202a113cc5@github.com>
Message-ID: <733Feokyp2nA9L6Gu8hBAVEg6uhleOVN8HkVt5xnpIM=.b0385894-f08f-4f18-8964-e3d468f844dc@github.com>

On Tue, 8 Jul 2025 00:23:55 GMT, Rui Li <duke at openjdk.org> wrote:

>> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
>> 
>> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
>> 
>> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use comment style

@rgithubli 
Your change (at version 8e0b1f21baf44566b5a6fd96af4fc1baf8bbefa3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25943#issuecomment-3049924125

From duke at openjdk.org  Tue Jul  8 18:36:44 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 18:36:44 GMT
Subject: Integrated: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <xamUMOWREx--ZFvSA8rOikbW27p-19hWkZZ_m2FqS9o=.1acdd5dc-e57f-40a5-94e8-2771c5b235e4@github.com>

On Mon, 23 Jun 2025 21:42:36 GMT, Rui Li <duke at openjdk.org> wrote:

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

This pull request has now been integrated.

Changeset: fa32bfe1
Author:    Rui Li <ruiamzn at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa32bfe11300fdadb35f083037f6ab2a8985d210
Stats:     177 lines in 17 files changed: 78 ins; 32 del; 67 mod

8358529: GenShen: Heuristics do not respond to changes in SoftMaxHeapSize

Reviewed-by: wkemper

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

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

From kdnilsen at openjdk.org  Tue Jul  8 19:01:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 8 Jul 2025 19:01:55 GMT
Subject: Integrated: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
References: <pYH9uTcD83vkBg1YQtMRUB_QLsmcnry_j-NixjlCHYU=.725800bc-0f02-4838-8909-9d3446e962af@github.com>
Message-ID: <3jFy8asl8ptBrD-YW-MzccYdjeLYaAPPVzzo_DC2Spc=.41194616-4de3-4c7c-a25c-9dece2c7d433@github.com>

On Tue, 8 Jul 2025 17:40:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The end of range for card marks checked by assert needs to be based from the base of the card table rather than the mapped base of the card table.

This pull request has now been integrated.

Changeset: 1de2acea
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1de2acea77da57fd44b214332a73cc6621806e4d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361529: GenShen: Fix bad assert in swap card tables

Reviewed-by: wkemper

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

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

From kvn at openjdk.org  Tue Jul  8 19:35:41 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Jul 2025 19:35:41 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <BpQyVhtMBFbk9P_ezpQWZPduk6_ost5Up5wlIHijPxk=.7517cff4-7d93-4373-997d-5f270fb324c9@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

My testing passed without new failures

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26004#pullrequestreview-2998887858

From mdoerr at openjdk.org  Tue Jul  8 21:27:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Jul 2025 21:27:40 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <orPjcR3bMIWArtp2E1LbMqsWXRGGo2hRx-i_-BSH_yQ=.566a1dbd-f4c4-4683-9903-5c0e2dfddf13@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

Tests have passed on linux PPC64 Big Endian.

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

PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3050341686

From wkemper at openjdk.org  Tue Jul  8 21:44:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 21:44:21 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
Message-ID: <wlEKBWTvDBf7jiIQqvLtJZF41ShnSRnJWdeg86BoCwY=.705be354-0ae1-4d89-b111-48bad51e4f71@github.com>

Clean backport. Makes generational mode honor `SoftMaxHeapSize`.

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

Commit messages:
 - Backport fa32bfe11300fdadb35f083037f6ab2a8985d210

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/202/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358529
  Stats: 177 lines in 17 files changed: 78 ins; 32 del; 67 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/202.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/202/head:pull/202

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/202

From wkemper at openjdk.org  Tue Jul  8 21:44:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 21:44:50 GMT
Subject: RFR: 8361529: GenShen: Fix bad assert in swap card tables
Message-ID: <3axTqne52QjuuUN00cR9lgSeJCWt-ItS9QfYaRb8txs=.117a6ea7-3686-4e0f-95bc-ad5b2f71b5f9@github.com>

Clean backport. Fixes assertion logic.

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

Commit messages:
 - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/203

From duke at openjdk.org  Tue Jul  8 22:02:04 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 22:02:04 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not use
 SoftMaxHeapSize
Message-ID: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>

Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 

This change replaces those usages with soft max heap size values.

tier1 tests are in progress

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

Commit messages:
 - Fix after 8358529
 - 8359868: Shenandoah: Free threshold heuristic does not use SoftMaxHeapSize

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

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

From wkemper at openjdk.org  Tue Jul  8 22:02:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 22:02:05 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not
 use SoftMaxHeapSize
In-Reply-To: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
References: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
Message-ID: <TPAhBi99vhUp7fPcy9e-xfpS681bJeSlaaTYmTmfHJc=.9f12b69e-d6ba-43d4-ae80-f6afeacddace@github.com>

On Tue, 8 Jul 2025 18:42:49 GMT, Rui Li <duke at openjdk.org> wrote:

> Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 
> 
> This change replaces those usages with soft max heap size values.
> 
> tier1 tests are in progress

LGTM. Thank you!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26199#pullrequestreview-2999155933

From duke at openjdk.org  Tue Jul  8 22:02:05 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 22:02:05 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not
 use SoftMaxHeapSize
In-Reply-To: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
References: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
Message-ID: <gy-9QbsF4gZK5n-U1u12LR2Ucbvit05gTpuQHZWECQc=.a74eefab-7f55-40c4-a77b-5764eef05b84@github.com>

On Tue, 8 Jul 2025 18:42:49 GMT, Rui Li <duke at openjdk.org> wrote:

> Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 
> 
> This change replaces those usages with soft max heap size values.
> 
> tier1 tests are in progress

Moved to ready for review a bit late - after the approval. Checking if integrating now works.

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

PR Comment: https://git.openjdk.org/jdk/pull/26199#issuecomment-3050396990

From duke at openjdk.org  Tue Jul  8 22:02:05 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 8 Jul 2025 22:02:05 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not use
 SoftMaxHeapSize
In-Reply-To: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
References: <dsQeUOpKugZaj-1AbmMsPHAoRbS0nnnj4U6Y3rQ1ZIs=.78c0bde5-b0f0-4de3-9125-917e6b0eaf9d@github.com>
Message-ID: <zhwvV1N11d0rkGB4FNlLkLCZwk1muMefK2hBBLa-WH8=.021b47e7-2bb3-4c80-b202-6c9ad0332be9@github.com>

On Tue, 8 Jul 2025 18:42:49 GMT, Rui Li <duke at openjdk.org> wrote:

> Shenandoah some of the usages of [ShenandoahMinFreeThreshold](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L193) and [ShenandoahCriticalFreeThreshold](https://github.com/openjdk/jdk/blob/ba0c12231b0f5b680951e75765b5d292f31a2cbc/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp#L445) use max capacity instead of [soft max capacity](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gc_globals.hpp#L528). 
> 
> This change replaces those usages with soft max heap size values.
> 
> tier1 tests are in progress

This pull request has now been integrated.

Changeset: 974ad4e8
Author:    Rui Li <ruiamzn at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/974ad4e8cdddee7d932e8375258067f9d2ca6a8b
Stats:     7 lines in 4 files changed: 0 ins; 3 del; 4 mod

8359868: Shenandoah: Free threshold heuristic does not use SoftMaxHeapSize

Reviewed-by: wkemper

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

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

From wkemper at openjdk.org  Tue Jul  8 23:07:06 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Jul 2025 23:07:06 GMT
Subject: Integrated: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
In-Reply-To: <wlEKBWTvDBf7jiIQqvLtJZF41ShnSRnJWdeg86BoCwY=.705be354-0ae1-4d89-b111-48bad51e4f71@github.com>
References: <wlEKBWTvDBf7jiIQqvLtJZF41ShnSRnJWdeg86BoCwY=.705be354-0ae1-4d89-b111-48bad51e4f71@github.com>
Message-ID: <UIoi4KFPBfQ6ckZtGpVSKmEvdLeheVft3DQmXpIJOgs=.e053518c-4e03-40b6-b692-80227b4a9a65@github.com>

On Tue, 8 Jul 2025 21:39:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Makes generational mode honor `SoftMaxHeapSize`.

This pull request has now been integrated.

Changeset: 604b3415
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/604b3415087acb1a86d08b9e59de790a481dba68
Stats:     177 lines in 17 files changed: 78 ins; 32 del; 67 mod

8358529: GenShen: Heuristics do not respond to changes in SoftMaxHeapSize

Backport-of: fa32bfe11300fdadb35f083037f6ab2a8985d210

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/202

From stuefe at openjdk.org  Wed Jul  9 05:19:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 05:19:48 GMT
Subject: RFR: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
 <-kBptjCPtjOj8qu50lo22U5Mvo3MBQwV2BzEklONfJE=.617268d4-5077-4453-b2e2-c95f57356cf4@github.com>
Message-ID: <o6I93nN_bT12qouiR7QA0APFhHhFOyMgCk9z2WMwNfU=.753b2e16-6072-4e9b-9cbb-9acc6183a573@github.com>

On Tue, 8 Jul 2025 13:25:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.
>> 
>> Depending on the size of the non-null bits of the forwardee (whether it spills into the nKlass bits), nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 
>> 
>> Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.
>
> You know what, this is fine as it is.
> 
> The whole business with `ShenandoahForwarding::klass` is super-duper-awkward, and verifier already touches the forwardees using that method in places where it really should not. It needs a more comprehensive fix for `+UCOH`.
> 
> It is a mess, but not your mess. So integrate this one, we will figure out `ShenandoahForwarding::klass` after this.

Thanks @shipilev and @rkennke !

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

PR Comment: https://git.openjdk.org/jdk/pull/26117#issuecomment-3051146037

From stuefe at openjdk.org  Wed Jul  9 05:19:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 05:19:49 GMT
Subject: Integrated: 8361363: ShenandoahAsserts::print_obj() does not work for
 forwarded objects and UseCompactObjectHeaders
In-Reply-To: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
References: <4s_GBcnI6wOZOP3s46ms9MGWmFXou4PG4opl9xzm2-o=.42a65ee2-1e15-4395-9146-93c2ea172fb2@github.com>
Message-ID: <ts4-L7hoQP_2gNsFhU34lch1o5zxmfxfnBBNaK_hklQ=.06b16178-8a12-41fd-b07b-4bb070628adb@github.com>

On Thu, 3 Jul 2025 14:22:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> `ShenandoahAsserts::print_obj()` does not work for COH if the object is forwarded, since the mark word is overwritten with a forwarding pointer.
> 
> Depending on the size of the non-null bits of the forwardee (whether it spills into the nKlass bits), nKlass is either zero or garbage. So we get either an "assert(!is_null(v)) failed: narrow klass value can never be zero", or a SIGSEGV. 
> 
> Fix is trivial: don't use obj->klass() directly but get it from ShenandoahForwarding.

This pull request has now been integrated.

Changeset: fe264676
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe264676337cdef0d7477b0b57ff9d2fe8f9fc0f
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8361363: ShenandoahAsserts::print_obj() does not work for forwarded objects and UseCompactObjectHeaders

Reviewed-by: rkennke, shade

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

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

From dbriemann at openjdk.org  Wed Jul  9 07:59:38 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 9 Jul 2025 07:59:38 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <gfK5mNGOiVapPLl8PHQ879-Wz-zmTvzv3PnPnzs28qs=.872affc6-f02c-49a8-be01-55fdacf26846@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

Thanks for testing that!

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

PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3051576708

From duke at openjdk.org  Wed Jul  9 07:59:38 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Jul 2025 07:59:38 GMT
Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2]
In-Reply-To: <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
 <hVzUVM25sUej_-0cnnDqMhL4OSnrIRr8eCawLnjAOzA=.8ebdf503-027a-4483-ad3c-2071f1127e31@github.com>
Message-ID: <TFWJ0pfYtnTicO1u2_rJWFkL9u3UcxqCLP6rJF1NIe8=.2952ab6d-25f0-473a-aac8-c492b6f5f06b@github.com>

On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adapt copyrights

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

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

PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3051578710

From tschatzl at openjdk.org  Wed Jul  9 08:13:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 08:13:44 GMT
Subject: RFR: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info() [v3]
In-Reply-To: <c_fGFeNrF5ysBpWriB_1eA7IoLpvMTCBIApTGpkMKno=.8a22f725-c1af-4296-9913-a1f7d387ac58@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
 <c_fGFeNrF5ysBpWriB_1eA7IoLpvMTCBIApTGpkMKno=.8a22f725-c1af-4296-9913-a1f7d387ac58@github.com>
Message-ID: <Rd6fTIm7N9RtME9nhSq_1e3OQ36Q0869bZ8-m8-mzNQ=.68368e7b-9158-419b-84ca-2a0dc8b30dd2@github.com>

On Mon, 7 Jul 2025 14:01:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove one more unnecessary `private`
>
> Marked as reviewed by ayang (Reviewer).

Thank you for your reviews @albertnetymk @walulyai @abdelhak-zaaim .

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

PR Comment: https://git.openjdk.org/jdk/pull/26160#issuecomment-3051613953

From tschatzl at openjdk.org  Wed Jul  9 08:13:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 9 Jul 2025 08:13:45 GMT
Subject: Integrated: 8361349: Fix visibility of CollectedHeap::stop() and
 ::print_tracing_info()
In-Reply-To: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
References: <h_vTnolI2fX0aoGLvswA3w5z-FuIOCuEupSujVSTlNI=.3ea77b76-3075-4780-91a5-dc3eecaf8901@github.com>
Message-ID: <NzlPXpMLoA_832saZAH_8ylu-lBkyc6jUR1GQWeiWcI=.6e85fb3c-354f-43d7-9eaa-03ad90f289a2@github.com>

On Mon, 7 Jul 2025 13:30:44 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring to improve the visibility of `CollectedHeap::stop()` and `CH::print_tracing_info()`.
> 
> The change moves these methods to `protected` visibility.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 68b27b88
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68b27b88b5160dd2883f93928c5f6ce245412495
Stats:     52 lines in 8 files changed: 27 ins; 25 del; 0 mod

8361349: Fix visibility of CollectedHeap::stop() and ::print_tracing_info()

Reviewed-by: iwalulya, ayang

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

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

From dbriemann at openjdk.org  Wed Jul  9 08:30:48 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Wed, 9 Jul 2025 08:30:48 GMT
Subject: Integrated: 8361599: [PPC64] enable missing tests via jtreg requires
In-Reply-To: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
References: <eKHge8izHdpTNWMRc2eDugDDfP76riAfrbcvkPChzyY=.06d9a207-7669-42f5-bcb7-d12fbf80cbcb@github.com>
Message-ID: <tm55BWns2aAJ76F4KClRO2CIvqvXrBo5CKbk9vEcgDQ=.a23cdf78-65d5-49a4-ab8f-108cab8331be@github.com>

On Tue, 8 Jul 2025 13:19:35 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both.

This pull request has now been integrated.

Changeset: 83feb7a2
Author:    David Briemann <dbriemann at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83feb7a2388e33835b2071cfe0e51ba8b43e241f
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8361599: [PPC64] enable missing tests via jtreg requires

Reviewed-by: mdoerr

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

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

From adinn at openjdk.org  Wed Jul  9 08:47:45 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 9 Jul 2025 08:47:45 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <erE4b8LOPtaN86RCIYcp598SYcFvvAdqcGzy_V_OO8o=.5713eff3-ead9-4173-b72e-2cd5a6e83540@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

@erikj79 This PR seems to be stuck at the integrate stage -- any ideas why?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3051731338

From adinn at openjdk.org  Wed Jul  9 08:51:49 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 9 Jul 2025 08:51:49 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <tj-4vPSN7G-dtAW57xU16gfh6QcX-872-gzCObNZnxY=.a5a4a81e-6a0d-4d90-8b56-ff740d68bd57@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

@erikj79 Dunno what you did but that was quick ;-)
Ta!

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3051744175

From adinn at openjdk.org  Wed Jul  9 08:51:51 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 9 Jul 2025 08:51:51 GMT
Subject: Integrated: 8360707: Globally enumerate all blobs, stubs and entries
In-Reply-To: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
Message-ID: <4FwaYZxJwOB98MPL7D8N8VTbnjiw_3L4Qf8Ehj4Hm-Y=.05774235-6bda-4ff8-9eff-a509c851982c@github.com>

On Thu, 26 Jun 2025 15:58:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.

This pull request has now been integrated.

Changeset: b1fa1ecc
Author:    Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b1fa1ecc988fb07f191892a459625c2c8f2de3b5
Stats:     4137 lines in 102 files changed: 2008 ins; 274 del; 1855 mod

8360707: Globally enumerate all blobs, stubs and entries

Reviewed-by: kvn, fyang, asmehra

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

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

From duke at openjdk.org  Wed Jul  9 10:28:53 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 9 Jul 2025 10:28:53 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <RzsVljkEciO5v59UGiFbhUSNlxNaflWisBIymEXbVnM=.07588a46-706e-45b2-9f04-c71989791f80@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

There?s a?missing ?n??in?the?**PR** and?**JBS** issue?titles:

-JDK-8361342: Sheandoah evacuation may assert on invalid mirror object after JDK-8340297
+JDK-8361342: Shenandoah evacuation may assert on invalid mirror object after JDK-8340297

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3052089153

From stuefe at openjdk.org  Wed Jul  9 11:43:43 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 11:43:43 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
Message-ID: <iPlB8psDzfZwlOzhyjV5CNHuLotYG4duJzK-rVftC4I=.c78e1df7-942d-42f6-ba79-c4dbf9fb27a0@github.com>

On Tue, 8 Jul 2025 17:50:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The explanation and the changes make sense to me. Thank you!

Thanks for the review, @earthling-amzn !

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3052317728

From stuefe at openjdk.org  Wed Jul  9 11:43:42 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Jul 2025 11:43:42 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
Message-ID: <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>

On Tue, 8 Jul 2025 16:30:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Only looked at this briefly, but that sounds like what I did here: #21064 -- but forgot to complete it?
> 
> Yes, it looks like it is! The sequence of events you describe seems to also match [JDK-8340364](https://bugs.openjdk.org/browse/JDK-8340364), which I think we can close as duplicate, as I have not been able to convince even myself is a real bug, not just overzealous verification. So, what do you want to do? I can finish up #21064 and test it with your Metaspace assertion patches, if you want.

Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)

Note that I did not fix up the use of the array mirror klass since I thought it should always be stable. We never redefine array classes. But then it does not hurt either.

I am also preparing a small improvement patch for print_obj, as per our discussion in https://github.com/openjdk/jdk/pull/26117 yesterday, and will put the printing of the mirror klasses there, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3052316755

From shade at openjdk.org  Wed Jul  9 15:18:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Jul 2025 15:18:41 GMT
Subject: RFR: 8361342: Sheandoah evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
 <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>
Message-ID: <iQtBqK9MiV1lDHOgSU3LDqjiEkba1MHDakCt3VgyoC0=.fd09e93e-f11c-4b78-ae07-063fcfd2c783@github.com>

On Wed, 9 Jul 2025 11:41:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)

Sure, OK. Please pick up most of the hunks from https://github.com/openjdk/jdk/pull/21064, including the array mirrors then? I don't see a need to write a full paragraph of text explaining why we need to check for forwarded objects. A simple sentence is enough, and the rest can go into the bug description.

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3053043840

From andrew at openjdk.org  Wed Jul  9 17:35:18 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 17:35:18 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <37pYCIthBpCy9ppIebceCleJHU9nDyr4uRrPJGFG8Z0=.0b839c05-5cdc-4e5e-b732-8ab1e921df05@github.com>

Merge jdk8u462-b01

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

Commit messages:
 - Merge jdk8u462-b01
 - 8293107: GHA: Bump to Ubuntu 22.04
 - Merge
 - 8353433: XCG currency code not recognized in JDK 8u
 - 8351439: [8u] test/java/util/TimeZone/tools/share/Makefile use wrong path to tzdb
 - 8339810: Clean up the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract
 - 8309841: Jarsigner should print a warning if an entry is removed
 - 8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly
 - Merge
 - 8346887: DrawFocusRect() may cause an assertion failure
 - ... and 3 more: https://git.openjdk.org/shenandoah-jdk8u/compare/a67f79a2...c8cb16a9

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=99&range=00.0
 - jdk8u:master: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=99&range=00.1

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/99/files
  Stats: 33 lines in 9 files changed: 11 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/99.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/99/head:pull/99

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/99

From wkemper at openjdk.org  Wed Jul  9 17:57:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 17:57:14 GMT
Subject: RFR: 8361726: Shenandoah: More detailed evacuation instrumentation
Message-ID: <GZr7c2ddNc8mfeVXCDcFxGHAG8w2eit5dfpVZmkdwjY=.fcfb77ed-26d4-428d-8e0a-ad4e96d3c19b@github.com>

Shenandoah has `product only` instrumentation to track evacuation performance. This change introduces more detail by categorizing each evacuation as young, old or promotion.

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

Commit messages:
 - Convert evac tracking back into non-product feature
 - Re-enable evac tracker, account for young/old/promotions

Changes: https://git.openjdk.org/jdk/pull/26222/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26222&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361726
  Stats: 149 lines in 9 files changed: 79 ins; 26 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/26222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26222/head:pull/26222

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

From wkemper at openjdk.org  Wed Jul  9 19:54:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 19:54:42 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
Message-ID: <wnHrJRUliGqUMxjD1aB9lZpYPv58QOLYXFp90bX63HY=.bac9fe16-9b68-41e0-af3e-22494deb294c@github.com>

Clean backport. Missing this change triggers the assertion fixed in https://github.com/openjdk/shenandoah-jdk21u/pull/203.

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

Commit messages:
 - Backport 382f870cd53d69dfc1d2b96150aa2c026e47f642

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/204/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=204&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357976
  Stats: 17 lines in 2 files changed: 10 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/204.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/204/head:pull/204

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/204

From wkemper at openjdk.org  Wed Jul  9 19:59:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 19:59:05 GMT
Subject: Integrated: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <wnHrJRUliGqUMxjD1aB9lZpYPv58QOLYXFp90bX63HY=.bac9fe16-9b68-41e0-af3e-22494deb294c@github.com>
References: <wnHrJRUliGqUMxjD1aB9lZpYPv58QOLYXFp90bX63HY=.bac9fe16-9b68-41e0-af3e-22494deb294c@github.com>
Message-ID: <D_IW6zu6bP6461QbJkn-lxDL5ZAqtq2J2be10RT9UOQ=.86705f9d-2ae1-47ba-bb7e-ff5457d66ed6@github.com>

On Wed, 9 Jul 2025 19:49:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Missing this change triggers the assertion fixed in https://github.com/openjdk/shenandoah-jdk21u/pull/203.

This pull request has now been integrated.

Changeset: 84f417ef
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/84f417ef50475d0e1fe61af0b935d73e0f44573f
Stats:     17 lines in 2 files changed: 10 ins; 4 del; 3 mod

8357976: GenShen crash in swap_card_tables: Should be clean

Backport-of: 382f870cd53d69dfc1d2b96150aa2c026e47f642

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/204

From andrew at openjdk.org  Wed Jul  9 19:59:39 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 19:59:39 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 13 new changesets
Message-ID: <0017a66e-a65e-40d3-a446-4017502efff0@openjdk.org>

Changeset: 8c4a65b9
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-03-05 15:54:49 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/8c4a65b99dca01793faa441a958450dfdb54dcba

8351098: Bump update version of OpenJDK: 8u462

Reviewed-by: serb

! .jcheck/conf
! common/autoconf/version-numbers

Changeset: 79124139
Branch: master
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Date:      2025-03-06 11:10:40 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/79124139a676a555511f4365ce6771a7dc920dcf

8186787: clang-4.0 SIGSEGV in Unsafe_PutByte

Reviewed-by: adinn, andrew
Backport-of: 6dc1d8c06d98e127b022886172e16b90bf357c97

! hotspot/src/share/vm/prims/unsafe.cpp

Changeset: 84576a97
Branch: master
Author:    Taizo Kurashige <taizousum11 at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-03-11 18:55:17 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/84576a9729a299a3931c71091f4d2f205919fa67

8341946: [8u] sun/security/pkcs11/ec/ tests fail on RHEL9

Reviewed-by: phh

! jdk/test/sun/security/pkcs11/PKCS11Test.java

Changeset: 7210b971
Branch: master
Author:    Satyen Subramaniam <ssubramaniam at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-03-12 23:08:32 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/7210b971066c424acda13c4b0caa8ebcb063ace0

8346887: DrawFocusRect() may cause an assertion failure

Reviewed-by: phh, serb
Backport-of: 8eddf67c82a2af4d704c4063ad802640770b3c26

! jdk/src/windows/native/sun/windows/awt_Button.cpp
! jdk/src/windows/native/sun/windows/awt_Checkbox.cpp
! jdk/src/windows/native/sun/windows/awt_Component.cpp

Changeset: d358ad06
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-03-19 10:18:54 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d358ad0639a433254938d85e94c13921a4254e07

Merge


Changeset: 69d9a2f4
Branch: master
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-03-26 14:46:07 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/69d9a2f4bdf1a60e38bda9e69f83c676d963454e

8240235: jdk.test.lib.util.JarUtils updates jar files incorrectly

Reviewed-by: andrew
Backport-of: 2a791467919c9df9869e6fe1e57df0a5caa90d8f

! jdk/test/lib/testlibrary/jdk/testlibrary/JarUtils.java

Changeset: b256b1a1
Branch: master
Author:    Roman Marchenko <rmarchenko at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-03-27 17:10:33 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/b256b1a1ac5603d0103338fa3b00a55d77cc9db9

8309841: Jarsigner should print a warning if an entry is removed

Reviewed-by: andrew
Backport-of: bdfb41f977258831e4b0ceaef5d016d095ab6e7f

! jdk/src/share/classes/sun/security/tools/jarsigner/Main.java
! jdk/src/share/classes/sun/security/tools/jarsigner/Resources.java
+ jdk/test/lib-test/testlibrary/jdk/testlibrary/JarUtilsTest.java
! jdk/test/lib/testlibrary/jdk/testlibrary/JarUtils.java
+ jdk/test/sun/security/tools/jarsigner/RemovedFiles.java

Changeset: af6e57b7
Branch: master
Author:    Martin Balao <mbalao at openjdk.org>
Date:      2025-03-27 22:14:04 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/af6e57b7191ecc23d55658a97228c7311a2c2268

8339810: Clean up the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract

Reviewed-by: yan, andrew
Backport-of: 8fce5275fc94ebc404a6a37f5ea0407140de63c1

! jdk/src/share/classes/sun/tools/jar/Main.java

Changeset: 535e6215
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-04-08 19:01:35 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/535e6215cad8f52a36002ed931273cded219d99f

8351439: [8u] test/java/util/TimeZone/tools/share/Makefile use wrong path to tzdb

Reviewed-by: sgehwolf, dcherepanov

! jdk/test/java/util/TimeZone/tools/share/Makefile

Changeset: 5b97474a
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-11 15:35:06 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/5b97474a9ec27e0d56715d90f3b20cdedbeaad43

8353433: XCG currency code not recognized in JDK 8u

Reviewed-by: mbalao, syan

! jdk/src/share/classes/java/util/CurrencyData.properties

Changeset: 2b557948
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 01:48:50 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/2b557948100d685a97288d83f11a420ec073bc12

Merge


Changeset: 55273f72
Branch: master
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Date:      2025-04-17 10:45:12 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/55273f7267b95cf38743bb32ea61a513fbafb06e

8293107: GHA: Bump to Ubuntu 22.04

Reviewed-by: andrew, sgehwolf
Backport-of: d7536588b38e368eaa6395bcbcc6724a39303fc5

! .github/workflows/submit.yml

Changeset: c8cb16a9
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 18:01:48 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c8cb16a9b56015f1e6b6b5810116c97e4b2a4ed5

Merge jdk8u462-b01

Added tag jdk8u462-b01 for changeset 55273f7267b

! .jcheck/conf
! hotspot/src/share/vm/prims/unsafe.cpp
! .jcheck/conf
! hotspot/src/share/vm/prims/unsafe.cpp


From andrew at openjdk.org  Wed Jul  9 19:59:52 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 19:59:52 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b01 for changeset
 55273f72
Message-ID: <cd876b5b-056f-4618-891f-990b062753f1@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-29 19:14:49 +0000

Added tag jdk8u462-b01 for changeset 55273f7267b
Changeset: 55273f72
Author:    Zdenek Zambersky <zzambers at openjdk.org>
Date:      2025-04-17 10:45:12 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/55273f7267b95cf38743bb32ea61a513fbafb06e


From andrew at openjdk.org  Wed Jul  9 20:00:04 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 20:00:04 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b01 for
 changeset c8cb16a9
Message-ID: <e854c555-a7fd-4b9f-b0c8-a0983cd576f3@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 18:27:51 +0000

Added tag shenandoah8u462-b01 for changeset c8cb16a9b56
Changeset: c8cb16a9
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 18:01:48 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c8cb16a9b56015f1e6b6b5810116c97e4b2a4ed5


From andrew at openjdk.org  Wed Jul  9 20:00:38 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 20:00:38 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <37pYCIthBpCy9ppIebceCleJHU9nDyr4uRrPJGFG8Z0=.0b839c05-5cdc-4e5e-b732-8ab1e921df05@github.com>
References: <37pYCIthBpCy9ppIebceCleJHU9nDyr4uRrPJGFG8Z0=.0b839c05-5cdc-4e5e-b732-8ab1e921df05@github.com>
Message-ID: <AOP1MTO_A8iXdRC_qyi625jP9kk1gI8640NmYStIC6A=.28637757-b7a5-437d-aba1-a725c22d459e@github.com>

> Merge jdk8u462-b01

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/99/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/99/files/c8cb16a9..c8cb16a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=99&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=99&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/99.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/99/head:pull/99

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/99

From iris at openjdk.org  Wed Jul  9 20:00:39 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 9 Jul 2025 20:00:39 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <37pYCIthBpCy9ppIebceCleJHU9nDyr4uRrPJGFG8Z0=.0b839c05-5cdc-4e5e-b732-8ab1e921df05@github.com>
References: <37pYCIthBpCy9ppIebceCleJHU9nDyr4uRrPJGFG8Z0=.0b839c05-5cdc-4e5e-b732-8ab1e921df05@github.com>
Message-ID: <pPEbXA-W6xHJDvcisSS6OgTK9QizYXVdBiZuDd9mpus=.d9314cc5-26a1-48fd-a9a2-4613363d2935@github.com>

On Wed, 9 Jul 2025 17:31:10 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b01

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/99

From andrew at openjdk.org  Wed Jul  9 20:29:00 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 20:29:00 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <l76tEnXgkGJi2Kyy2mxLmVK8H9Jyh9eqrsSDdKIJwqM=.ca7d4021-d2e7-4d3b-86f5-b1ec8c5ee45d@github.com>

Merge jdk8u462-b01

Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

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

Commit messages:
 - Merge jdk8u462-b02
 - 8026976: ECParameters, Point does not match field size

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/100/files
  Stats: 9 lines in 2 files changed: 6 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/100.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/100/head:pull/100

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/100

From wkemper at openjdk.org  Wed Jul  9 21:08:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 21:08:28 GMT
Subject: RFR: 8361529: GenShen: Fix bad assert in swap card tables [v2]
In-Reply-To: <3axTqne52QjuuUN00cR9lgSeJCWt-ItS9QfYaRb8txs=.117a6ea7-3686-4e0f-95bc-ad5b2f71b5f9@github.com>
References: <3axTqne52QjuuUN00cR9lgSeJCWt-ItS9QfYaRb8txs=.117a6ea7-3686-4e0f-95bc-ad5b2f71b5f9@github.com>
Message-ID: <99Ta2Nn3_WVj-WkgeIhLUP9iNo9VKSKGnJbNWTao3Gk=.7dfdf8b4-0a7e-4fb5-a57c-ea851197d5e3@github.com>

> Clean backport. Fixes assertion logic.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into fix-card-table-assert-21
 - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/203/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/203/files/865c27e5..52814297

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=203&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=203&range=00-01

  Stats: 194 lines in 19 files changed: 88 ins; 36 del; 70 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/203.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/203/head:pull/203

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/203

From wkemper at openjdk.org  Wed Jul  9 21:12:16 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Jul 2025 21:12:16 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
Message-ID: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>

Clean backport. Fixes bad pointer in assert.

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

Commit messages:
 - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

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

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

From andrew at openjdk.org  Wed Jul  9 22:16:25 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 22:16:25 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 2 new changesets
Message-ID: <fd0d4d2b-d9d6-44ef-8970-8a8456cb0f8d@openjdk.org>

Changeset: 5e59411b
Branch: master
Author:    Taizo Kurashige <103394724+kurashige23 at users.noreply.github.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2025-05-08 10:06:42 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/5e59411bd3760a4c54bd52d301d882e4a9f5aab4

8026976: ECParameters, Point does not match field size

Reviewed-by: phh, mbalao
Backport-of: 55f5542ca2104df91e14693534cc7b3c36e81953

! jdk/src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java
! jdk/test/ProblemList.txt

Changeset: c85b7c4a
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 20:58:25 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c85b7c4a92b6b38f53f32633e6033c7cd3eb0325

Merge jdk8u462-b02

Added tag jdk8u462-b02 for changeset 5e59411bd3760a4c54bd52d301d882e4a9f5aab4



From duke at openjdk.org  Wed Jul  9 22:16:34 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Jul 2025 22:16:34 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b02 for changeset
 5e59411b
Message-ID: <067d4059-5765-4629-bd28-6f5a7755cfe4@openjdk.org>

Tagged by: Andrew Hughes <gnu.andrew at redhat.com>
Date:      2025-05-13 19:53:01 +0000

Added tag jdk8u462-b02 for changeset 5e59411bd3760a4c54bd52d301d882e4a9f5aab4
Changeset: 5e59411b
Author:    Taizo Kurashige <103394724+kurashige23 at users.noreply.github.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2025-05-08 10:06:42 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/5e59411bd3760a4c54bd52d301d882e4a9f5aab4


From andrew at openjdk.org  Wed Jul  9 22:16:46 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 22:16:46 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b02 for
 changeset c85b7c4a
Message-ID: <3e8605ae-54da-42a0-9b3e-e3caf343ceab@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 21:22:32 +0000

Added tag shenandoah8u462-b02 for changeset c85b7c4a92b
Changeset: c85b7c4a
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 20:58:25 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c85b7c4a92b6b38f53f32633e6033c7cd3eb0325


From andrew at openjdk.org  Wed Jul  9 22:18:41 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 22:18:41 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <l76tEnXgkGJi2Kyy2mxLmVK8H9Jyh9eqrsSDdKIJwqM=.ca7d4021-d2e7-4d3b-86f5-b1ec8c5ee45d@github.com>
References: <l76tEnXgkGJi2Kyy2mxLmVK8H9Jyh9eqrsSDdKIJwqM=.ca7d4021-d2e7-4d3b-86f5-b1ec8c5ee45d@github.com>
Message-ID: <w4ztLFQnVcDjUmhroAGg3AT2iEXOLIUf2Jltiy0Cp2Y=.d17d2400-f3d2-4df0-97d1-64be3739dc57@github.com>

> Merge jdk8u462-b02
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/100/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/100/files/c85b7c4a..c85b7c4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=100&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=100&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/100.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/100/head:pull/100

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/100

From iris at openjdk.org  Wed Jul  9 22:18:42 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 9 Jul 2025 22:18:42 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <l76tEnXgkGJi2Kyy2mxLmVK8H9Jyh9eqrsSDdKIJwqM=.ca7d4021-d2e7-4d3b-86f5-b1ec8c5ee45d@github.com>
References: <l76tEnXgkGJi2Kyy2mxLmVK8H9Jyh9eqrsSDdKIJwqM=.ca7d4021-d2e7-4d3b-86f5-b1ec8c5ee45d@github.com>
Message-ID: <db_zFnivsTZ-BPGe534s_Cud5w5GY2hEunuSgI0aItU=.10a57e32-7f06-4d0c-b27c-9318c24d6fc1@github.com>

On Wed, 9 Jul 2025 20:25:08 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b02
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/100

From andrew at openjdk.org  Wed Jul  9 22:40:12 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 9 Jul 2025 22:40:12 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <sWU6pR6NSkMrDGFbCxXX3VYWBwDUqDSQCpNt9nyF8bo=.f8ad6edb-0a01-4fce-939d-d550b92b7078@github.com>

Merge jdk8u462-b03

Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

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

Commit messages:
 - Merge jdk8u462-b03
 - 8186143: keytool -ext option doesn't accept wildcards for DNS subject alternative names
 - 8071996: split_if accesses NULL region of ConstraintCast

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=101&range=00.0
 - jdk8u:master: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=101&range=00.1

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/101/files
  Stats: 121 lines in 4 files changed: 104 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/101.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/101/head:pull/101

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/101

From dholmes at openjdk.org  Thu Jul 10 00:10:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Jul 2025 00:10:49 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
Message-ID: <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>

On Tue, 8 Jul 2025 10:59:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Use the blob, stub and entry declarations to generate a single global enumeration for all blobs, likewise for all stubs and all entries. Modify stub generators in shared runtime, c1 runtime, c2 runtime and stub generator subsystems and their clients to use those enumerations consistently.
>
> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>  - add missing C++ method to AOT cache address table

After this integration we are seeing crashes on Linux x64 and Aarch64:

assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3054509580

From andrew at openjdk.org  Thu Jul 10 00:13:06 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 00:13:06 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 3 new changesets
Message-ID: <aa4053de-561f-4205-9de2-18dfec1131bd@openjdk.org>

Changeset: eca7a305
Branch: master
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2025-05-13 07:22:11 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/eca7a305e1df50eaf459dcf43448d0ef911da5cc

8071996: split_if accesses NULL region of ConstraintCast

Backport-of: d4d8ef4585c1c6192fe35524faa6c6961d1e7a64

! hotspot/src/share/vm/opto/ifnode.cpp

Changeset: 656b3cfd
Branch: master
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Date:      2025-05-16 18:11:02 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/656b3cfda2d349e8198ee4058d17352887d948f8

8186143: keytool -ext option doesn't accept wildcards for DNS subject alternative names

Reviewed-by: yan
Backport-of: 0c9f8e472f1d452e97b3cbd50b9e5d700fffcd15

! jdk/src/share/classes/sun/security/tools/keytool/Main.java
! jdk/src/share/classes/sun/security/x509/DNSName.java
! jdk/test/sun/security/x509/GeneralName/DNSNameTest.java

Changeset: bbd18868
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 23:15:04 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/bbd18868856a02cea04e18911da23b409c544f76

Merge jdk8u462-b03

Added tag jdk8u462-b03 for changeset 656b3cfda2d349e8198ee4058d17352887d948f8

! hotspot/src/share/vm/opto/ifnode.cpp
! hotspot/src/share/vm/opto/ifnode.cpp


From andrew at openjdk.org  Thu Jul 10 00:13:17 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 00:13:17 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b03 for
 changeset bbd18868
Message-ID: <876d2de4-934e-4593-bdc7-47e2153cdc21@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 23:35:08 +0000

Added tag shenandoah8u462-b03 for changeset bbd18868856
Changeset: bbd18868
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-09 23:15:04 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/bbd18868856a02cea04e18911da23b409c544f76


From duke at openjdk.org  Thu Jul 10 00:13:15 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 00:13:15 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b03 for changeset
 656b3cfd
Message-ID: <98abf68e-6db9-4052-b4bf-4a64f2bbe229@openjdk.org>

Tagged by: Andrew Hughes <gnu.andrew at redhat.com>
Date:      2025-05-23 17:53:24 +0000

Added tag jdk8u462-b03 for changeset 656b3cfda2d349e8198ee4058d17352887d948f8
Changeset: 656b3cfd
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Date:      2025-05-16 18:11:02 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/656b3cfda2d349e8198ee4058d17352887d948f8


From andrew at openjdk.org  Thu Jul 10 00:15:14 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 00:15:14 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <sWU6pR6NSkMrDGFbCxXX3VYWBwDUqDSQCpNt9nyF8bo=.f8ad6edb-0a01-4fce-939d-d550b92b7078@github.com>
References: <sWU6pR6NSkMrDGFbCxXX3VYWBwDUqDSQCpNt9nyF8bo=.f8ad6edb-0a01-4fce-939d-d550b92b7078@github.com>
Message-ID: <IAhwVawL79sdX9rk5-894tvH7OO6nGh5Ki1zMixR0qI=.b58bf71a-be3a-4003-97b6-e74374eeb27c@github.com>

> Merge jdk8u462-b03
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/101/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/101/files/bbd18868..bbd18868

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=101&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=101&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/101.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/101/head:pull/101

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/101

From iris at openjdk.org  Thu Jul 10 00:15:14 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 10 Jul 2025 00:15:14 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <sWU6pR6NSkMrDGFbCxXX3VYWBwDUqDSQCpNt9nyF8bo=.f8ad6edb-0a01-4fce-939d-d550b92b7078@github.com>
References: <sWU6pR6NSkMrDGFbCxXX3VYWBwDUqDSQCpNt9nyF8bo=.f8ad6edb-0a01-4fce-939d-d550b92b7078@github.com>
Message-ID: <4L_SLMyw1oWCveWgFM07NY_1muNRUmRuXjT9arnFjYc=.280c2ed3-be14-49e4-bdb0-c4594dc7dbdd@github.com>

On Wed, 9 Jul 2025 22:36:04 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b03
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/101

From andrew at openjdk.org  Thu Jul 10 00:46:57 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 00:46:57 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <mAWK4FjFkyO1vli2_rw10GXMSeLZTBY5AFkGa95gAVQ=.c5e1864f-1e22-40bd-8c87-079c0557584b@github.com>

Merge jdk8u462-b04

Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

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

Commit messages:
 - Merge jdk8u462-b04
 - 8274597: Some of the dnd tests time out and fail intermittently
 - 8159694: HiDPI, Unity, java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
 - 8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test
 - 8352716: (tz) Update Timezone Data to 2025b
 - 8345133: Test sun/security/tools/jarsigner/TsacertOptionTest.java failed: Warning found in stdout
 - 8046883: com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows
 - 8248001: javadoc generates invalid HTML pages whose ftp:// links are broken
 - 8278472: Invalid value set to CANDIDATEFORM structure
 - 8296631: NSS tests failing on OL9 linux-aarch64 hosts

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/102/files
  Stats: 1019 lines in 36 files changed: 517 ins; 409 del; 93 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/102/head:pull/102

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/102

From stuefe at openjdk.org  Thu Jul 10 06:32:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 10 Jul 2025 06:32:29 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

Thomas Stuefe 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:

 - Alekseys additions
 - Also check array klass
 - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
 - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
 - also fix ShenandoahVerifier
 - start

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26187/files
  - new: https://git.openjdk.org/jdk/pull/26187/files/3d07a9d9..c33cf248

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

  Stats: 982 lines in 56 files changed: 372 ins; 355 del; 255 mod
  Patch: https://git.openjdk.org/jdk/pull/26187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26187/head:pull/26187

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

From stuefe at openjdk.org  Thu Jul 10 06:32:29 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 10 Jul 2025 06:32:29 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <iQtBqK9MiV1lDHOgSU3LDqjiEkba1MHDakCt3VgyoC0=.fd09e93e-f11c-4b78-ae07-063fcfd2c783@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <9pKedSOkTed_GXjn7lLLAF2JE3O6M0wtOHW3_aD2ug0=.9da8b8fd-bba3-486c-8bec-0a8139438994@github.com>
 <cJXUX6NTxhOfamkXEpJrPdTDhp-MOiWM_aR5F-FtoN8=.ee61855f-985f-467e-acd5-1eb6ce855737@github.com>
 <iQtBqK9MiV1lDHOgSU3LDqjiEkba1MHDakCt3VgyoC0=.fd09e93e-f11c-4b78-ae07-063fcfd2c783@github.com>
Message-ID: <is_m4xMmR038cvdGWkt7SbQE0B6EWnYLdl63i1YqjYs=.2e8fd17f-40de-4942-9b50-b67c6f241658@github.com>

On Wed, 9 Jul 2025 15:16:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> > Only looked at this briefly, but that sounds like what I did here: #21064 -- but forgot to complete it?
>>> 
>>> Yes, it looks like it is! The sequence of events you describe seems to also match [JDK-8340364](https://bugs.openjdk.org/browse/JDK-8340364), which I think we can close as duplicate, as I have not been able to convince even myself is a real bug, not just overzealous verification. So, what do you want to do? I can finish up #21064 and test it with your Metaspace assertion patches, if you want.
>> 
>> Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)
>> 
>> Note that I did not fix up the use of the array mirror klass since I thought it should always be stable. We never redefine array classes. But then it does not hurt either.
>> 
>> I am also preparing a small improvement patch for print_obj, as per our discussion in https://github.com/openjdk/jdk/pull/26117 yesterday, and will put the printing of the mirror klasses there, too.
>
>> Thanks, let me just finish this, I need the closure after burning time on this non-bug :-)
> 
> Sure, OK. Please pick up most of the hunks from https://github.com/openjdk/jdk/pull/21064, including the array mirrors then? I don't see a need to write a full paragraph of text explaining why we need to check for forwarded objects. A simple sentence is enough, and the rest can go into the bug description.

@shipilev ok done

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3055805609

From shade at openjdk.org  Thu Jul 10 08:15:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 08:15:44 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
Message-ID: <39tOcsPGG2QXldhRafPyx1pz-NZzGW97AJXbO2aIf1A=.19b3120f-0290-47a6-8bf3-66f5669e6d13@github.com>

On Thu, 10 Jul 2025 06:32:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
>> 
>> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
>> 
>> For details about this issue, please see the Jira description and comment. The short version is:
>> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
>> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
>> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
>> 
>> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
>> 
>> Therefore I just changed the assertions.
>> 
>> But I would like to hear other people's opinion on this.
>> 
>> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.
>
> Thomas Stuefe 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:
> 
>  - Alekseys additions
>  - Also check array klass
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - also fix ShenandoahVerifier
>  - start

Looks fine to me!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26187#pullrequestreview-3004477678

From stuefe at openjdk.org  Thu Jul 10 08:40:39 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 10 Jul 2025 08:40:39 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297
In-Reply-To: <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <rAJyMxGormyrrmtPitsidpMEEiQnjfwtBtm8Zl7pMuQ=.2a3c5c47-7cc1-42fd-bd31-1cc0ed870a01@github.com>
Message-ID: <CCVnBo9RZcdBSWjuFkcsLvHOPueCZ7XQzozEpjJ0tJ8=.8ef77c4a-06d2-4023-bb4c-bb0c6f3bba66@github.com>

On Tue, 8 Jul 2025 17:50:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
>> 
>> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
>> 
>> For details about this issue, please see the Jira description and comment. The short version is:
>> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
>> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
>> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
>> 
>> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
>> 
>> Therefore I just changed the assertions.
>> 
>> But I would like to hear other people's opinion on this.
>> 
>> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.
>
> The explanation and the changes make sense to me. Thank you!

Thanks Aleksey! @earthling-amzn are you happy with this version, too?

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3056345044

From adinn at openjdk.org  Thu Jul 10 10:25:48 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 10:25:48 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
 <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
Message-ID: <qKnuCEcyHb3zzINIQP2jKY48_9bVKKd8R-CGwI_2Nvk=.c1dfa2bd-0e9c-47a2-a351-302ac90ccfd0@github.com>

On Thu, 10 Jul 2025 00:08:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> After this integration we are seeing crashes on Linux x64 and Aarch64:
>   assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

@dholmes-ora Can you provide more detail as to what is failing? Is this a specific build?

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3056788682

From adinn at openjdk.org  Thu Jul 10 11:18:51 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 10 Jul 2025 11:18:51 GMT
Subject: RFR: 8360707: Globally enumerate all blobs, stubs and entries [v8]
In-Reply-To: <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
References: <CiImAyRoKDp11Vy86av85wE6uD7EgBWUnrZ6nofvaiY=.c12ac2b6-b20c-451b-a916-d2e4918de611@github.com>
 <6NoNdJUDn0EChy2-9lfYwW52P430sXcpCUst2A-Xq1s=.387b3b96-c6c7-42a6-b1d8-5b916d2eee04@github.com>
 <YeGETbGKI4bQ1aYP8H2CtxmLpwWbXS4huxo_0oGDDPk=.d1741575-bfd1-4089-b562-218d3a1337d5@github.com>
Message-ID: <PviQrtw5U9m9jo5im2NRmz7yLeyRBlP2qhwOTRMxOQ4=.7dfb25e9-3784-482e-9f83-119841a599ae@github.com>

On Thu, 10 Jul 2025 00:08:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - publish early stubgen initial stubs addresses for shared runtime initial stubs to use
>>  - add missing C++ method to AOT cache address table
>
> After this integration we are seeing crashes on Linux x64 and Aarch64:
> 
> assert(idx2 >= 0 && idx2 >= idx1) failed: bad blob ids first -1 and second -1

@dholmes-ora It's ok I have identified what is going wrong.

The problem appears to occur when either C1 or C2 is omitted from the build. I have raised [JDK-8361844](https://bugs.openjdk.org/browse/JDK-8361844) and have a PR ready which I am checking against tier1 (with a build that omits C2).

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

PR Comment: https://git.openjdk.org/jdk/pull/26004#issuecomment-3057005534

From andrew at openjdk.org  Thu Jul 10 14:53:41 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 14:53:41 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <mAWK4FjFkyO1vli2_rw10GXMSeLZTBY5AFkGa95gAVQ=.c5e1864f-1e22-40bd-8c87-079c0557584b@github.com>
References: <mAWK4FjFkyO1vli2_rw10GXMSeLZTBY5AFkGa95gAVQ=.c5e1864f-1e22-40bd-8c87-079c0557584b@github.com>
Message-ID: <ai1zz2ay37dOJd7yPS2dzgqfeV43M7nTJUxVtndK0HA=.2b82e3e8-0805-4982-b594-3595ff51c39b@github.com>

> Merge jdk8u462-b04
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/102/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/102/files/9c4a0f9e..9c4a0f9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=102&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=102&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/102/head:pull/102

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/102

From iris at openjdk.org  Thu Jul 10 14:53:42 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 10 Jul 2025 14:53:42 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <mAWK4FjFkyO1vli2_rw10GXMSeLZTBY5AFkGa95gAVQ=.c5e1864f-1e22-40bd-8c87-079c0557584b@github.com>
References: <mAWK4FjFkyO1vli2_rw10GXMSeLZTBY5AFkGa95gAVQ=.c5e1864f-1e22-40bd-8c87-079c0557584b@github.com>
Message-ID: <KOSzg1aDuP9Rq5idIMgT3Bb7j8rjqFjGAXUeP062KdI=.c00f7ec6-c722-4658-9bc7-2b5cf19a8f55@github.com>

On Thu, 10 Jul 2025 00:43:29 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b04
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/102

From andrew at openjdk.org  Thu Jul 10 14:54:35 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 14:54:35 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 10 new changesets
Message-ID: <33436995-481e-4ee0-895e-149610880076@openjdk.org>

Changeset: 176d6747
Branch: master
Author:    Taizo Kurashige <tkurashige at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-05-19 13:45:52 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/176d674745b33f86d810732c13465279a5aadeda

8296631: NSS tests failing on OL9 linux-aarch64 hosts

Reviewed-by: phh
Backport-of: 6e1aacdfba5a32f7b071eea8039888d275827e83

+ jdk/test/sun/security/pkcs11/KeyStore/ClientAuthData/cert9.db
+ jdk/test/sun/security/pkcs11/KeyStore/ClientAuthData/key4.db
! jdk/test/sun/security/pkcs11/Secmod/cert9.db
! jdk/test/sun/security/pkcs11/Secmod/key4.db
! jdk/test/sun/security/pkcs11/Secmod/pkcs11.txt
! jdk/test/sun/security/pkcs11/SecmodTest.java
+ jdk/test/sun/security/pkcs11/fips/cert9.db
+ jdk/test/sun/security/pkcs11/fips/key4.db
+ jdk/test/sun/security/pkcs11/fips/pkcs11.txt

Changeset: 1304a9b0
Branch: master
Author:    Taizo Kurashige <tkurashige at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-05-19 13:46:16 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1304a9b0c703c19a17a68da22af6e534f6e320a5

8278472: Invalid value set to CANDIDATEFORM structure

Reviewed-by: phh
Backport-of: 2426d58e592c54de64ebe0f06448d239aeced082

! jdk/src/windows/native/sun/windows/awt_Component.cpp

Changeset: 73dca05a
Branch: master
Author:    Kazuhisa Takakuri <ktakakuri at openjdk.org>
Date:      2025-05-20 02:08:02 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/73dca05a92e7751006622c33335540300bb2bb4d

8248001: javadoc generates invalid HTML pages whose ftp:// links are broken

Reviewed-by: phh
Backport-of: bb95dda0ac5032e4df582f2903dcbbbbaef9e8c4

! langtools/src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! langtools/test/com/sun/javadoc/testHrefInDocComment/TestHrefInDocComment.java
+ langtools/test/com/sun/javadoc/testHrefInDocComment/pkg/J1.java

Changeset: 55e7ecc2
Branch: master
Author:    Kazuhisa Takakuri <ktakakuri at openjdk.org>
Date:      2025-05-20 02:10:39 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/55e7ecc26b80b694b378c4d2d64a5e2da815bc48

8046883: com/sun/jdi/ProcessAttachTest.sh gets "java.io.IOException: Invalid process identifier" on windows

Reviewed-by: phh
Backport-of: 0139a3b9e7d3cbbe2c4efe1653856c2cd2769040

- jdk/test/com/sun/jdi/ProcessAttachDebuggee.java
- jdk/test/com/sun/jdi/ProcessAttachDebugger.java
+ jdk/test/com/sun/jdi/ProcessAttachTest.java
- jdk/test/com/sun/jdi/ProcessAttachTest.sh
- jdk/test/com/sun/jdi/ShutdownDebuggee.java

Changeset: 3e4321d1
Branch: master
Author:    Paul Hohensee <phh at openjdk.org>
Date:      2025-05-20 14:34:23 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3e4321d11e557887378d42258be7130878b9ac5e

8345133: Test sun/security/tools/jarsigner/TsacertOptionTest.java failed: Warning found in stdout

Reviewed-by: rkennke
Backport-of: 153dc6d84300e4c3446e33be820c15336cf45e72

! jdk/test/sun/security/tools/jarsigner/TsacertOptionTest.java

Changeset: 6fd5ba5f
Branch: master
Author:    Satyen Subramaniam <ssubramaniam at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-05-20 17:45:26 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6fd5ba5f62bfffc8b127aec0f56f7b1987dee46d

8352716: (tz) Update Timezone Data to 2025b

Reviewed-by: serb
Backport-of: 1d205f5f0704f251eb68165f3caf1e70d542ae63

! jdk/make/data/tzdata/VERSION
! jdk/make/data/tzdata/asia
! jdk/make/data/tzdata/northamerica
! jdk/make/data/tzdata/southamerica
! jdk/make/data/tzdata/zone.tab
! jdk/test/java/util/TimeZone/TimeZoneData/VERSION
! jdk/test/sun/util/calendar/zi/tzdata/VERSION
! jdk/test/sun/util/calendar/zi/tzdata/asia
! jdk/test/sun/util/calendar/zi/tzdata/northamerica
! jdk/test/sun/util/calendar/zi/tzdata/southamerica
! jdk/test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: 1daca5f4
Branch: master
Author:    Kazuhisa Takakuri <ktakakuri at openjdk.org>
Date:      2025-05-21 08:11:19 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1daca5f46e16a0d257e0f80713bee9a42332f1c3

8274606: Fix jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest.java test

Reviewed-by: phh
Backport-of: 7eb0372e55f23275b12470593adc97f1b79bc965

! jdk/test/javax/xml/jaxp/transform/8268457/SurrogateTest.java

Changeset: b4aa2218
Branch: master
Author:    Taizo Kurashige <tkurashige at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-05-21 16:06:18 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/b4aa2218a462b8db33602943ecb6c71ef44e3f47

8159694: HiDPI, Unity, java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java

Reviewed-by: phh
Backport-of: c3938ec18b4026d70d9654235dcd986d90344f5b

! jdk/test/java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
! jdk/test/java/awt/regtesthelpers/Util.java

Changeset: abda9d84
Branch: master
Author:    Taizo Kurashige <tkurashige at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-05-22 17:38:21 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/abda9d84100179c80c16f642b3ab470a905b3018

8274597: Some of the dnd tests time out and fail intermittently
8028998: [TEST_BUG] [macosx] java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java failed

Reviewed-by: phh
Backport-of: 669ac611b269bbda5c53d84173e5c9d0eb4ce919

! jdk/test/java/awt/dnd/AcceptDropMultipleTimes/AcceptDropMultipleTimes.java
! jdk/test/java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java
! jdk/test/java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java
! jdk/test/java/awt/dnd/MissingDragExitEventTest/MissingDragExitEventTest.java

Changeset: 9c4a0f9e
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 01:12:55 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/9c4a0f9ee182826bdf708b4c7e59a7ec9dd1bc11

Merge jdk8u462-b04

Added tag jdk8u462-b04 for changeset abda9d84100



From andrew at openjdk.org  Thu Jul 10 14:54:45 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 14:54:45 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u472-b00 for
 changeset 9c4a0f9e
Message-ID: <1b989481-618c-4d07-b88c-8ff6d4944101@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 01:42:01 +0000

Added tag shenandoah8u472-b00 for changeset 9c4a0f9ee18
Changeset: 9c4a0f9e
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 01:12:55 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/9c4a0f9ee182826bdf708b4c7e59a7ec9dd1bc11


From duke at openjdk.org  Thu Jul 10 14:54:49 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 14:54:49 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b04 for changeset
 abda9d84
Message-ID: <978e7d81-5a34-4840-ade3-2f9a58b19e23@openjdk.org>

Tagged by: Andrew Hughes <gnu.andrew at redhat.com>
Date:      2025-05-27 18:23:04 +0000

Added tag jdk8u462-b04 for changeset abda9d84100
Changeset: abda9d84
Author:    Taizo Kurashige <tkurashige at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-05-22 17:38:21 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/abda9d84100179c80c16f642b3ab470a905b3018


From andrew at openjdk.org  Thu Jul 10 14:54:55 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 14:54:55 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b04 for
 changeset 9c4a0f9e
Message-ID: <8f57ef8b-85b2-4f58-9608-8b76cdb70bcf@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 01:40:17 +0000

Added tag shenandoah8u462-b04 for changeset 9c4a0f9ee18
Changeset: 9c4a0f9e
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 01:12:55 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/9c4a0f9ee182826bdf708b4c7e59a7ec9dd1bc11


From andrew at openjdk.org  Thu Jul 10 15:23:08 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 15:23:08 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <j6Gd8XCp8tT1nF51fAxywtHljxBukI8rWVa0WC1j0Ac=.37289cc0-14d0-4d0c-860f-eec4f3b31bac@github.com>

Merge jdk8u462-b04

Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

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

Commit messages:
 - Merge jdk8u462-b05
 - 8350498: Remove two Camerfirma root CA certificates
 - 8303770: Remove Baltimore root certificate expiring in May 2025

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/103/files
  Stats: 267 lines in 8 files changed: 2 ins; 242 del; 23 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/103/head:pull/103

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/103

From wkemper at openjdk.org  Thu Jul 10 15:28:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 15:28:09 GMT
Subject: Integrated: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <3axTqne52QjuuUN00cR9lgSeJCWt-ItS9QfYaRb8txs=.117a6ea7-3686-4e0f-95bc-ad5b2f71b5f9@github.com>
References: <3axTqne52QjuuUN00cR9lgSeJCWt-ItS9QfYaRb8txs=.117a6ea7-3686-4e0f-95bc-ad5b2f71b5f9@github.com>
Message-ID: <Zowy4UZtLmp9FI8AHsoAqcGwzSpK0cl9GRTpnLHuTeQ=.94c7e1c7-c767-4f00-86ca-a9a0be099d3f@github.com>

On Tue, 8 Jul 2025 21:39:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes assertion logic.

This pull request has now been integrated.

Changeset: af1707d6
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/af1707d665d0a5667049a8614f0abf538e8e4268
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361529: GenShen: Fix bad assert in swap card tables

Backport-of: 1de2acea77da57fd44b214332a73cc6621806e4d

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/203

From kcr at openjdk.org  Thu Jul 10 15:44:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 15:44:39 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <gb9wpfBvaQAxxdrrQ_6hBUyS3yAVNHuEBOrdJvXJmWo=.6b34beb7-e654-469f-b472-0b801dc667d7@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

If the priority of this bug (I see that the issue type is Task, which seems wrong) is correct, then this doesn't meet the criteria for backporting to JDK 25 during RDP1. See [JEP 3](https://openjdk.org/jeps/3).

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3057987411

From wkemper at openjdk.org  Thu Jul 10 16:04:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 16:04:52 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
Message-ID: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>

Clean backport. Fixes correctness issue in Shenandoah.

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

Commit messages:
 - Backport 382f870cd53d69dfc1d2b96150aa2c026e47f642

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

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

From wkemper at openjdk.org  Thu Jul 10 16:09:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 16:09:39 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <6v1Wq3K1UHTzNkXk43LvNF2w8QJsAPfjGoy0gdxSWCI=.d490d12d-9322-4e5b-b860-80369b3bd7cb@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

Yes, the ticket should have been marked a bug, thank you for fixing that. This change to the assert really should have been made with the same commit where we fixed an issue it uncovered (https://github.com/openjdk/jdk/pull/26246). We can leave the assertion change out, but it's also low risk (only affects Shenandoah debug builds).

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058074838

From kcr at openjdk.org  Thu Jul 10 16:21:38 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:21:38 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
Message-ID: <JrWkIpq1v10HGiFMqQmfY44MI9BMyNignl6HVx3qZhw=.2d48d533-66e9-47f2-a2b3-d3a52526141b@github.com>

On Thu, 10 Jul 2025 15:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes correctness issue in Shenandoah.

If this is objectively a P3, then you could raise the priority. Otherwise, maybe consider backporting it to jdk25u?

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

PR Comment: https://git.openjdk.org/jdk/pull/26246#issuecomment-3058110001

From kcr at openjdk.org  Thu Jul 10 16:25:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:25:37 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <JrWkIpq1v10HGiFMqQmfY44MI9BMyNignl6HVx3qZhw=.2d48d533-66e9-47f2-a2b3-d3a52526141b@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
 <JrWkIpq1v10HGiFMqQmfY44MI9BMyNignl6HVx3qZhw=.2d48d533-66e9-47f2-a2b3-d3a52526141b@github.com>
Message-ID: <ZG1pSBt9wF3qeJhhWkl16iURmLAhItvJKnOVWrITwAA=.b01473b2-98e9-4ac5-97e1-41c9efe0090a@github.com>

On Thu, 10 Jul 2025 16:19:15 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> If this is objectively a P3, then you could raise the priority. Otherwise, maybe consider backporting it to jdk25u?

This comment was meant for PR #26228 -- sorry for the confusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/26246#issuecomment-3058119789

From kcr at openjdk.org  Thu Jul 10 16:26:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:26:39 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <Hr8O3csiQCBloebGSa4NrUByhXY5Zc56JAEhbn3Q6lc=.23051a15-4a35-4199-96d0-a47d4f60c0c3@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

If this is objectively a P3, then you could raise the priority. Otherwise, maybe consider backporting it to jdk25u?

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058118682

From kcr at openjdk.org  Thu Jul 10 16:26:40 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Jul 2025 16:26:40 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Hr8O3csiQCBloebGSa4NrUByhXY5Zc56JAEhbn3Q6lc=.23051a15-4a35-4199-96d0-a47d4f60c0c3@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
 <Hr8O3csiQCBloebGSa4NrUByhXY5Zc56JAEhbn3Q6lc=.23051a15-4a35-4199-96d0-a47d4f60c0c3@github.com>
Message-ID: <vn4fp0UEyTI0cMcBMgAOqmemNtJHkq8tF-g_PaI7WQI=.e870546d-a5f5-4840-8513-5e9c72864191@github.com>

On Thu, 10 Jul 2025 16:22:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> If this is objectively a P3, then you could raise the priority

Since, as you pointed out, this is a follow-on to the other fix, raising the priority seems OK to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058125462

From shade at openjdk.org  Thu Jul 10 16:52:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 16:52:42 GMT
Subject: [jdk25] RFR: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
Message-ID: <AdqMf0PNZajoJrzP7ZMnau8IUXYU4NmAiuYNcpk4XSw=.a1e3637f-5da2-45cd-ac29-cdbdb9643b7e@github.com>

On Thu, 10 Jul 2025 15:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes correctness issue in Shenandoah.

Looks fine for JDK 25.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26246#pullrequestreview-3006542106

From shade at openjdk.org  Thu Jul 10 16:54:37 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Jul 2025 16:54:37 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <0Ex2dRNMWXsjkUvT5IK8g1dFolaby9JV8zCrAKRmf8Q=.f1312480-39bf-436d-b2e4-b1c7a0905b21@github.com>

On Wed, 9 Jul 2025 21:06:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes bad pointer in assert.

There are test failures, I assume they are fixed by https://github.com/openjdk/jdk/pull/26246? Integrate that one first and confirm there are no failures then? (I think you can technically update the `openjdk-bots:backport-earthling-amzn-1de2acea-jdk25` branch, since you probably are a collaborator on that repo, but I have never actually tried.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26228#issuecomment-3058227580

From andrew at openjdk.org  Thu Jul 10 16:56:24 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 16:56:24 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 3 new changesets
Message-ID: <40e1b173-9c2d-4c9b-be39-eccf1d39ed7f@openjdk.org>

Changeset: afd0266e
Branch: master
Author:    Antonio Vieiro <antonio at vieiro.net>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2025-06-03 09:47:35 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/afd0266ef01647ea9cdcb77bb93f46a961872ad6

8303770: Remove Baltimore root certificate expiring in May 2025

Reviewed-by: sgehwolf
Backport-of: c0e7aa6c122e88e0d749ac3e8edf2cda9c5f53da

- jdk/make/data/cacerts/baltimorecybertrustca
! jdk/test/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: c163b402
Branch: master
Author:    Antonio Vieiro <avieirov at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2025-06-03 15:29:05 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c163b402d0620a42a1c8ebaa402124722dc0c8a2

8350498: Remove two Camerfirma root CA certificates

Reviewed-by: sgehwolf
Backport-of: 8894d6ad1b83553a5c60af51fd2de2319fd1d6ec

- jdk/make/data/cacerts/camerfirmachamberscommerceca
- jdk/make/data/cacerts/camerfirmachambersignca
! jdk/src/share/classes/sun/security/validator/CamerfirmaTLSPolicy.java
! jdk/test/sun/security/lib/cacerts/VerifyCACerts.java
! jdk/test/sun/security/ssl/X509TrustManagerImpl/distrust/Camerfirma.java
- jdk/test/sun/security/ssl/X509TrustManagerImpl/distrust/chains/camerfirma/camerfirmachamberscommerceca-chain.pem
- jdk/test/sun/security/ssl/X509TrustManagerImpl/distrust/chains/camerfirma/camerfirmachambersignca-chain.pem

Changeset: d407e3c8
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 15:50:23 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d407e3c8d7a9063094c18e3a113724063ff8fe0b

Merge jdk8u462-b05

Added tag jdk8u462-b05 for changeset c163b402d0620a42a1c8ebaa402124722dc0c8a2



From duke at openjdk.org  Thu Jul 10 16:56:38 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 16:56:38 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b05 for changeset
 c163b402
Message-ID: <a21cc250-b93a-4e7f-b4e2-d0e61d02233c@openjdk.org>

Tagged by: Andrew Hughes <gnu.andrew at redhat.com>
Date:      2025-06-10 00:46:48 +0000

Added tag jdk8u462-b05 for changeset c163b402d0620a42a1c8ebaa402124722dc0c8a2
Changeset: c163b402
Author:    Antonio Vieiro <avieirov at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2025-06-03 15:29:05 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c163b402d0620a42a1c8ebaa402124722dc0c8a2


From andrew at openjdk.org  Thu Jul 10 16:56:40 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 16:56:40 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b05 for
 changeset d407e3c8
Message-ID: <c676e47e-ec92-4591-8a98-29d57258980c@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 16:13:37 +0000

Added tag shenandoah8u462-b05 for changeset d407e3c8d7a
Changeset: d407e3c8
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 15:50:23 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d407e3c8d7a9063094c18e3a113724063ff8fe0b


From andrew at openjdk.org  Thu Jul 10 16:56:46 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 16:56:46 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <j6Gd8XCp8tT1nF51fAxywtHljxBukI8rWVa0WC1j0Ac=.37289cc0-14d0-4d0c-860f-eec4f3b31bac@github.com>
References: <j6Gd8XCp8tT1nF51fAxywtHljxBukI8rWVa0WC1j0Ac=.37289cc0-14d0-4d0c-860f-eec4f3b31bac@github.com>
Message-ID: <2_vfI9SVp41znUjFDDCpuiBhm-zevLbzO-fFrUroCH8=.ce92682e-9ada-4402-8ad0-539d76d9bcaa@github.com>

> Merge jdk8u462-b04
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/103/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/103/files/d407e3c8..d407e3c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=103&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=103&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/103/head:pull/103

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/103

From iris at openjdk.org  Thu Jul 10 16:56:46 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 10 Jul 2025 16:56:46 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <j6Gd8XCp8tT1nF51fAxywtHljxBukI8rWVa0WC1j0Ac=.37289cc0-14d0-4d0c-860f-eec4f3b31bac@github.com>
References: <j6Gd8XCp8tT1nF51fAxywtHljxBukI8rWVa0WC1j0Ac=.37289cc0-14d0-4d0c-860f-eec4f3b31bac@github.com>
Message-ID: <Byi3SO_Cv4mVe44NvmHiyODDLC8TMfDme8GiiQrzjBU=.e1e9ba3c-e3d2-4fa6-83a0-b73403ad15be@github.com>

On Thu, 10 Jul 2025 15:19:14 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b04
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/103

From andrew at openjdk.org  Thu Jul 10 17:26:00 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 17:26:00 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <xQTSZfliBXtLez7kizz7BrIqPhBHK6biDpju2wUuf6E=.67b0f2ab-f648-4abe-a8c5-50a11f279ef4@github.com>

Merge jdk8u462-b06

Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

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

Commit messages:
 - Merge jdk8u462-b06
 - 8356096: ISO 4217 Amendment 179 Update

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/104/files
  Stats: 11 lines in 4 files changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/104/head:pull/104

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/104

From andrew at openjdk.org  Thu Jul 10 19:08:29 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 19:08:29 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 2 new changesets
Message-ID: <c6cb5aa3-8f21-4555-b4ee-00c16fe6af72@openjdk.org>

Changeset: 711caa3c
Branch: master
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-06-09 15:50:15 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/711caa3ce056659a8f54c58b6cbbd3aaa221eaf4

8356096: ISO 4217 Amendment 179 Update

Reviewed-by: sgehwolf, andrew
Backport-of: b8484be137a9d8bf6463188e1fc68b22db0b52c3

! jdk/src/share/classes/java/util/CurrencyData.properties
! jdk/src/share/classes/sun/util/resources/CurrencyNames.properties
! jdk/test/java/util/Currency/ISO4217-list-one.txt
! jdk/test/java/util/Currency/ValidateISO4217.java

Changeset: 1ce7e2ac
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 17:53:26 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1ce7e2ac0265b97debb01074bbe36eceafbbef61

Merge jdk8u462-b06

Added tag jdk8u462-b06 for changeset 711caa3ce056659a8f54c58b6cbbd3aaa221eaf4



From duke at openjdk.org  Thu Jul 10 19:08:38 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 19:08:38 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b06 for changeset
 711caa3c
Message-ID: <5419d190-5c6d-425e-af9a-300216b233b3@openjdk.org>

Tagged by: Andrew Hughes <gnu.andrew at redhat.com>
Date:      2025-06-16 22:32:36 +0000

Added tag jdk8u462-b06 for changeset 711caa3ce056659a8f54c58b6cbbd3aaa221eaf4
Changeset: 711caa3c
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2025-06-09 15:50:15 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/711caa3ce056659a8f54c58b6cbbd3aaa221eaf4


From andrew at openjdk.org  Thu Jul 10 19:08:43 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 19:08:43 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <xQTSZfliBXtLez7kizz7BrIqPhBHK6biDpju2wUuf6E=.67b0f2ab-f648-4abe-a8c5-50a11f279ef4@github.com>
References: <xQTSZfliBXtLez7kizz7BrIqPhBHK6biDpju2wUuf6E=.67b0f2ab-f648-4abe-a8c5-50a11f279ef4@github.com>
Message-ID: <yVXGCj6FcAwgirvQ2p-2kd4WAepH630OBk4GHDlBlJU=.dde28209-a1d9-4777-ac6f-39fa09aeafb3@github.com>

> Merge jdk8u462-b06
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/104/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/104/files/1ce7e2ac..1ce7e2ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=104&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=104&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/104/head:pull/104

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/104

From iris at openjdk.org  Thu Jul 10 19:08:44 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 10 Jul 2025 19:08:44 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <xQTSZfliBXtLez7kizz7BrIqPhBHK6biDpju2wUuf6E=.67b0f2ab-f648-4abe-a8c5-50a11f279ef4@github.com>
References: <xQTSZfliBXtLez7kizz7BrIqPhBHK6biDpju2wUuf6E=.67b0f2ab-f648-4abe-a8c5-50a11f279ef4@github.com>
Message-ID: <DNdG6QRqXxgUIQTBfCiA5N7u4ENdDbnuFJuMgarNT2U=.79115589-a631-4c7c-a9af-b2ac74ece17b@github.com>

On Thu, 10 Jul 2025 17:21:53 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b06
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/104

From andrew at openjdk.org  Thu Jul 10 19:08:41 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 19:08:41 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b06 for
 changeset 1ce7e2ac
Message-ID: <86d3fe54-358c-4a59-87a5-ad9173fb4e7a@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 18:20:41 +0000

Added tag shenandoah8u462-b06 for changeset 1ce7e2ac026
Changeset: 1ce7e2ac
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 17:53:26 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1ce7e2ac0265b97debb01074bbe36eceafbbef61


From andrew at openjdk.org  Thu Jul 10 19:41:57 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 19:41:57 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <K40w3_E7P7CjiRRuXBcU3tZmJ55qafYPQG8Msj0IZ0k=.2dd8a664-226a-49ae-a6db-43ce892a17ba@github.com>

Merge jdk8u462-b07

Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

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

Commit messages:
 - Merge jdk8u462-b07
 - 8359170: Add 2 TLS and 2 CS Sectigo roots

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/105/files
  Stats: 479 lines in 7 files changed: 475 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/105/head:pull/105

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/105

From wkemper at openjdk.org  Thu Jul 10 20:48:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 20:48:11 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not use
 SoftMaxHeapSize
Message-ID: <SEUVGB3drJZsCEqqc7LhNgLPA0N6H-HabJYWnnxswoQ=.c0aa501e-3334-487b-9f87-8069b1a26160@github.com>

Clean backport. Has heuristics use soft max heap for free threshold tests.

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

Commit messages:
 - Backport 974ad4e8cdddee7d932e8375258067f9d2ca6a8b

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/205/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=205&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359868
  Stats: 7 lines in 4 files changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/205.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/205/head:pull/205

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/205

From wkemper at openjdk.org  Thu Jul 10 20:48:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 20:48:11 GMT
Subject: Integrated: 8359868: Shenandoah: Free threshold heuristic does not use
 SoftMaxHeapSize
In-Reply-To: <SEUVGB3drJZsCEqqc7LhNgLPA0N6H-HabJYWnnxswoQ=.c0aa501e-3334-487b-9f87-8069b1a26160@github.com>
References: <SEUVGB3drJZsCEqqc7LhNgLPA0N6H-HabJYWnnxswoQ=.c0aa501e-3334-487b-9f87-8069b1a26160@github.com>
Message-ID: <WhrEKSs-d1QN748BbYoy82yAmjQKT7QtCBOAIQdizFU=.f7a8540e-8483-4b16-aeac-26874783ffe4@github.com>

On Thu, 10 Jul 2025 20:41:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Has heuristics use soft max heap for free threshold tests.

This pull request has now been integrated.

Changeset: 6991ee24
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/6991ee245088910c3766e328eae27d6a99193328
Stats:     7 lines in 4 files changed: 0 ins; 3 del; 4 mod

8359868: Shenandoah: Free threshold heuristic does not use SoftMaxHeapSize

Backport-of: 974ad4e8cdddee7d932e8375258067f9d2ca6a8b

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/205

From andrew at openjdk.org  Thu Jul 10 21:13:41 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 21:13:41 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <K40w3_E7P7CjiRRuXBcU3tZmJ55qafYPQG8Msj0IZ0k=.2dd8a664-226a-49ae-a6db-43ce892a17ba@github.com>
References: <K40w3_E7P7CjiRRuXBcU3tZmJ55qafYPQG8Msj0IZ0k=.2dd8a664-226a-49ae-a6db-43ce892a17ba@github.com>
Message-ID: <r-c_RvOiQekt1NDnut_ufxYBYGWSnKViOhcE5hmH_wE=.76670320-c9f8-4fdf-a4ca-06c01196d771@github.com>

> Merge jdk8u462-b07
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/105/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/105/files/62ca591c..62ca591c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=105&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=105&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/105/head:pull/105

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/105

From iris at openjdk.org  Thu Jul 10 21:13:41 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 10 Jul 2025 21:13:41 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <K40w3_E7P7CjiRRuXBcU3tZmJ55qafYPQG8Msj0IZ0k=.2dd8a664-226a-49ae-a6db-43ce892a17ba@github.com>
References: <K40w3_E7P7CjiRRuXBcU3tZmJ55qafYPQG8Msj0IZ0k=.2dd8a664-226a-49ae-a6db-43ce892a17ba@github.com>
Message-ID: <KPgnd-3WQ84gZZMYUpjNzQxziwXyvnMOVBKMydd0HHk=.6efb6f14-3c94-477a-927f-52dea27a73ab@github.com>

On Thu, 10 Jul 2025 19:38:09 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u462-b07
> 
> Windows build will not run until [JDK-8358538](https://bugs.openjdk.org/browse/JDK-8358538) upgrades us to Windows 2025

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/105

From andrew at openjdk.org  Thu Jul 10 21:14:07 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 21:14:07 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 2 new changesets
Message-ID: <91951eb6-b31d-4115-a706-b58c3c8e57ce@openjdk.org>

Changeset: 1e912a12
Branch: master
Author:    Antonio Vieiro <avieirov at redhat.com>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-06-16 15:12:22 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1e912a129c4074dac8bedbcb77dcb2a8284f5228

8359170: Add 2 TLS and 2 CS Sectigo roots

Reviewed-by: andrew
Backport-of: e00605fcebe7b2716db6b95e7bcae47d85b88dce

+ jdk/make/data/cacerts/sectigocodesignroote46
+ jdk/make/data/cacerts/sectigocodesignrootr46
+ jdk/make/data/cacerts/sectigotlsroote46
+ jdk/make/data/cacerts/sectigotlsrootr46
! jdk/test/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java
+ jdk/test/security/infra/java/security/cert/CertPathValidator/certification/SectigoCSRootCAs.java
! jdk/test/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: 62ca591c
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 20:05:47 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/62ca591cc4bd751eaef14c9e12864f48fe6b5c0e

Merge jdk8u462-b07

Added tag jdk8u462-b07 for changeset 1e912a129c4



From duke at openjdk.org  Thu Jul 10 21:14:16 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 21:14:16 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u462-b07 for changeset
 1e912a12
Message-ID: <45b20acf-898f-458c-946a-ae8363ef428f@openjdk.org>

Tagged by: Andrew Hughes <gnu.andrew at redhat.com>
Date:      2025-06-23 21:00:32 +0000

Added tag jdk8u462-b07 for changeset 1e912a129c4
Changeset: 1e912a12
Author:    Antonio Vieiro <avieirov at redhat.com>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-06-16 15:12:22 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1e912a129c4074dac8bedbcb77dcb2a8284f5228


From andrew at openjdk.org  Thu Jul 10 21:14:20 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 10 Jul 2025 21:14:20 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u462-b07 for
 changeset 62ca591c
Message-ID: <b7f213d9-6243-4a5e-9758-b5b139f3f2f7@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 20:35:27 +0000

Added tag shenandoah8u462-b07 for changeset 62ca591cc4b
Changeset: 62ca591c
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-07-10 20:05:47 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/62ca591cc4bd751eaef14c9e12864f48fe6b5c0e


From wkemper at openjdk.org  Thu Jul 10 22:25:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 22:25:23 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in op_degenerated
Message-ID: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>

Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.

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

Commit messages:
 - STW collections cannot unload classes before reclaiming garbage

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

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

From wkemper at openjdk.org  Thu Jul 10 22:28:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 22:28:46 GMT
Subject: [jdk25] Integrated: 8357976: GenShen crash in swap_card_tables: Should
 be clean
In-Reply-To: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
References: <vzi-UwMVE0gkKazdaRDkY-trwFvfXCTnSOFBRtUDfLc=.f4d19030-c945-4b98-8dad-390c3ce80009@github.com>
Message-ID: <6hhL__DpEBM36_nQlqGIyygV22mSPLA8TLvPchnf2ig=.3ff14783-cb3f-4a47-a607-89618293ee9f@github.com>

On Thu, 10 Jul 2025 15:59:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes correctness issue in Shenandoah.

This pull request has now been integrated.

Changeset: 4d5211cc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d5211ccb0dce13eeef9b7f12d014dd58957c854
Stats:     17 lines in 2 files changed: 10 ins; 4 del; 3 mod

8357976: GenShen crash in swap_card_tables: Should be clean

Reviewed-by: shade
Backport-of: 382f870cd53d69dfc1d2b96150aa2c026e47f642

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

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

From wkemper at openjdk.org  Thu Jul 10 22:37:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 10 Jul 2025 22:37:23 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
 [v2]
In-Reply-To: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
Message-ID: <Fhok0rQR6ovXxjpeTzqcYM54Xj1FL_OSnCKFj8PcYOY=.8456cc8b-8c95-4d2e-9be4-a040478b83f7@github.com>

> Clean backport. Fixes bad pointer in assert.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'jdk-25' into backport-earthling-amzn-1de2acea-jdk25
 - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26228/files
  - new: https://git.openjdk.org/jdk/pull/26228/files/889f5af1..abf285a2

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

  Stats: 97 lines in 12 files changed: 55 ins; 16 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26228/head:pull/26228

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

From ysr at openjdk.org  Fri Jul 11 02:13:40 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Jul 2025 02:13:40 GMT
Subject: RFR: 8350050: Shenandoah: remove support for ShenandoahPacing feature
Message-ID: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>

Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, has been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Shenan
 doah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.

Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.

We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.


### SpecJBB
[Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]

  Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
--------------------------|--------------------|----------------------------------|
+ShenandoahPacing         |              *22.1*          |                                21.5                   |
-ShenandoahPacing          |              24.8            |                               *26.9*                |
Feature deleted entirely    |            **24.4**       |                              **27.6**              |

### Testing:
- SPECjbb
- Code Pipeline Stress
- Perf Dashboard
----------------------------------------------------------------------------------

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

Commit messages:
 - Fix some comments and user instructions / documentation that refer to
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - Merge branch 'master' into pacing
 - ... and 6 more: https://git.openjdk.org/jdk/compare/ee0d309b...645bb879

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

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

From ysr at openjdk.org  Fri Jul 11 02:13:40 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Jul 2025 02:13:40 GMT
Subject: RFR: 8350050: Shenandoah: remove support for ShenandoahPacing
 feature
In-Reply-To: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
References: <Ebt-Q0qwM8B6CdqU9Uv_Cxj9UsjjYJV5hGhQZRTG3ck=.1979e70e-80f6-4f10-bf10-d0685254fc48@github.com>
Message-ID: <a1C4HRWAjRLJ-eGGKUwyQutDaC-C_ev4RPq3EBkFl6I=.6227a6b0-85e5-4351-8282-f09e86dc3114@github.com>

On Wed, 12 Mar 2025 01:11:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Shenandoah's experimental "pacing" feature, currently defaulting to "on", and its set of suboption knobs, has been supported for several releases. The idea is that under increasing allocation rate graceful degradation in application latency is often more desirable to abruptly stalling mutators to collect the heap when the allocators outrun the collector, causing a concurrent mode failure. Unfortunately, our experience with this pacing feature is that it's difficult to easily control the suboption knobs and, for latency sensitive applications, customers often prefer abrupt failure to gradual degradation in latency at the cost of a drop in peak performance, and will almost always size their systems so as to avoid driving the collector into that state. We and, independently, many of our customers noticed that this feature extracted a performance penalty when enabled, and as a result the feature is disabled by default for most production deployments of Shenandoah. For Generational Shen
 andoah, the feature has always been off by default. Inside Amazon, the feature has defaulted to off for several releases.
> 
> Removing support for this feature simplifies some of the allocation and GC control paths allowing further improvements to the allocation paths in the future. Graceful degradation of latency with increasing allocation throughput will be implemented separately using other mechanisms in the near future.
> 
> We measured the impact of this feature on specjbb scores on x86, and found that there was a marked performance improvement comparing +ShenandoahPacing vs -ShenandoahPacing (+12% Shen, +25% GenShen). There was a further small performance improvement in the case of GenShen with the feature completely removed. Actual performance delta may vary depending on host size and isa.
> 
> 
> ### SpecJBB
> [Critical JOPS, relative scores (*previous default*, **new**), average of 5 runs, x64 only]
> 
>   Collector                           |       Shenandoah      |         Generaltional Shenandoah   | 
> --------------------------|--------------------|----------------------------------|
> +ShenandoahPacing         |              *22.1*          |                                21.5                   |
> -ShenandoahPacing          |              24.8            |                               *26.9*                |
> Feature deleted entirely    |            **24.4**       |                              **27.6**              |
> 
> ### Testing:
> - SPECjbb
> - Code Pipeline Stress
> - Perf Dashboard
> ------...

Getting some performance numbers and will open up for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/24002#issuecomment-2873698421

From shade at openjdk.org  Fri Jul 11 05:46:42 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 05:46:42 GMT
Subject: [jdk25] RFR: 8361529: GenShen: Fix bad assert in swap card tables
 [v2]
In-Reply-To: <Fhok0rQR6ovXxjpeTzqcYM54Xj1FL_OSnCKFj8PcYOY=.8456cc8b-8c95-4d2e-9be4-a040478b83f7@github.com>
References: <Ol1PUF-15BXFA2qAoRPXQtkIU7u4GDlv8EfJSwRJkkU=.6ae91678-eefb-4f81-b2f3-03b849ca0149@github.com>
 <Fhok0rQR6ovXxjpeTzqcYM54Xj1FL_OSnCKFj8PcYOY=.8456cc8b-8c95-4d2e-9be4-a040478b83f7@github.com>
Message-ID: <BhVfgaJhJIJALXJx3f1sNRYBBG49tEgV9BklRxLB3Hg=.84c87f22-bc5f-4531-89e7-24329b861e77@github.com>

On Thu, 10 Jul 2025 22:37:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Clean backport. Fixes bad pointer in assert.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'jdk-25' into backport-earthling-amzn-1de2acea-jdk25
>  - Backport 1de2acea77da57fd44b214332a73cc6621806e4d

Looks fine for JDK 25.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26228#pullrequestreview-3008684686

From rkennke at openjdk.org  Fri Jul 11 07:36:41 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 11 Jul 2025 07:36:41 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
Message-ID: <O3VnorJcvpdlNZnZVPBWtVx_wcCovI_xaRQtY0boq2I=.ac4a31e8-795c-4652-8f4d-aff349a6b283@github.com>

On Thu, 10 Jul 2025 06:32:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
>> 
>> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
>> 
>> For details about this issue, please see the Jira description and comment. The short version is:
>> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
>> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
>> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
>> 
>> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
>> 
>> Therefore I just changed the assertions.
>> 
>> But I would like to hear other people's opinion on this.
>> 
>> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.
>
> Thomas Stuefe 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:
> 
>  - Alekseys additions
>  - Also check array klass
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>  - also fix ShenandoahVerifier
>  - start

Looks good, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26187#pullrequestreview-3009025955

From stuefe at openjdk.org  Fri Jul 11 08:05:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 11 Jul 2025 08:05:49 GMT
Subject: RFR: 8361342: Shenandoah: Evacuation may assert on invalid mirror
 object after JDK-8340297 [v2]
In-Reply-To: <O3VnorJcvpdlNZnZVPBWtVx_wcCovI_xaRQtY0boq2I=.ac4a31e8-795c-4652-8f4d-aff349a6b283@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
 <zL_RYdUP4rzjTRcXC-KWL-gTOqpg2EKe46i7ssSP_C4=.2d9b010b-8f4e-4bd2-85a0-50e5b04fe6de@github.com>
 <O3VnorJcvpdlNZnZVPBWtVx_wcCovI_xaRQtY0boq2I=.ac4a31e8-795c-4652-8f4d-aff349a6b283@github.com>
Message-ID: <Ew3ecT56ZxQwIZcajN673PzWpYNPj8uMfdAB1t_dsLw=.6c8545e5-c976-4188-a807-bd68a45ebe00@github.com>

On Fri, 11 Jul 2025 07:34:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Thomas Stuefe 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:
>> 
>>  - Alekseys additions
>>  - Also check array klass
>>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>>  - Merge branch 'master' into JDK-8361342-Sheandoah-evacuation-asserts-on-invalid-mirror-object-after-JDK-8340297
>>  - also fix ShenandoahVerifier
>>  - start
>
> Looks good, thank you!

Thank you, @rkennke !

I will integrate now, since this bug hinders other work I do. @earthling-amzn requested changes to comments, but those comments were removed completely, so I think that request is fulfilled :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26187#issuecomment-3061125318

From stuefe at openjdk.org  Fri Jul 11 08:05:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 11 Jul 2025 08:05:49 GMT
Subject: Integrated: 8361342: Shenandoah: Evacuation may assert on invalid
 mirror object after JDK-8340297
In-Reply-To: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
References: <qfu_8M0KYOCHoBHg1FZ7SjA09ZGhMEoUpUC2Eq2uS8A=.6de5a19e-1a16-4351-ad47-df31352a0c6d@github.com>
Message-ID: <R0RSxRjeMLZIReFLlSfU4BH-vIdE8JgsEN5E9dAkbzY=.97065230-5590-4747-ad2e-ec3f19dc0122@github.com>

On Tue, 8 Jul 2025 14:09:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Shenandoah devs, may I please have thoughts and reviews for this fix. 
> 
> This is a fix for a problem that was uncovered during my ongoing work on Metaspace use-after-free recognition (JDK-8340297). I would like to get this fix into the codebase before eventually pushing JDK-8340297, since I want the fixes to be separate from the patch that introduces stricter testing.
> 
> For details about this issue, please see the Jira description and comment. The short version is:
> - class gets redefined, and therefore its Klass is discarded and its mirror oop left to be eventually collected. Mirror oop's Klass field is nulled out before.
> - but we may be in the middle of an evacuation. So the mirror oop may be forwarded. In that case, class redefinition (correctly) nulls out the forwardee's Klass reference.
> - But that leaves the old forwarded mirror oop untouched, and that still carries the now invalid Klass pointer in its Klass field. That we now notice with JDK-8340297. So, `ShenandoaAsserts::assert_correct` complains about an invalid Klass reference when processing the old mirror oop.
> 
> I thought hard about this, but I believe this is benign, since no code should be accessing the old mirror oop's Klass field, it should always resolve the forwardee first. Class redefinition itself gets the oop address to null out from an OopHandle in Klass, which should contain the forwardee's address if the mirror was forwarded, which should ensure that only the forwardee is nulled out, never the forwarded.
> 
> Therefore I just changed the assertions.
> 
> But I would like to hear other people's opinion on this.
> 
> Note why we never saw this before: Before JDK-8340297 (as in, now), the only check ShenandoaAssert makes for Klass validity is `Metaspace::contains`, which is weak. A reclaimed Klass pointer will still point to Metaspace, so ShenandoaAssert does not complain. Metadata::is_valid() is similarly weak now, since it basically just checks a byte in the object for not null; pretty much any non-null garbage will satisfy this condition.

This pull request has now been integrated.

Changeset: 445e5ecd
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/445e5ecd98f41d4d625af5731f7b5d10c9225e49
Stats:     18 lines in 2 files changed: 8 ins; 0 del; 10 mod

8361342: Shenandoah: Evacuation may assert on invalid mirror object after JDK-8340297

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Reviewed-by: shade, rkennke

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

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

From shade at openjdk.org  Fri Jul 11 09:08:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 09:08:40 GMT
Subject: RFR: 8360288: Shenandoah crash at size_given_klass in
 op_degenerated
In-Reply-To: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
References: <NDi31nsuNiRlG9w7_dNXUty5mel7E-mSYeFrkO7j1Hk=.961eb770-89d8-485e-8383-059cb0362f37@github.com>
Message-ID: <WOBk-ms6PZPo1tVT7IwutS306zP2jYJHD8o4hvj5sGk=.bf05ea3b-108b-4572-95c7-8ca2cbb3fa28@github.com>

On Thu, 10 Jul 2025 22:20:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Both degenerated and full GCs unload classes before reclaiming unmarked humongous objects. This may result in a null klass pointer dereference when asking humongous objects for their size.

Yeah, this evidently does not work, see test failures.

Architecturally, the heuristics should be looking only at region data, without looking at objects. I see we often end up calling `ShenandoahHeapRegion::required_regions(obj->size(), ...)` just to figure out how many HC regions are there in the chain. But we might as well scan regions from the given HS region, until we run out of HC regions.

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

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26256#pullrequestreview-3009352549

From sparasa at openjdk.org  Fri Jul 11 17:10:25 2025
From: sparasa at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 11 Jul 2025 17:10:25 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
Message-ID: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>

Hi all,

This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.

Thanks!

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

Commit messages:
 - Backport 1c560727b850593561982ccc3ed37b0e98b3bbee

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

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

From shade at openjdk.org  Fri Jul 11 17:58:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 17:58:22 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte
 or word?)
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <ACUxxyPULO5HaI92kD9ldLPETWtvG6EZJMnvHsUztPs=.a792b59e-bc05-42b8-9e0c-336cc115b201@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

This looks reasonable.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26259#pullrequestreview-3009267508

From xpeng at openjdk.org  Fri Jul 11 17:58:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Jul 2025 17:58:22 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte or
 word?)
Message-ID: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>

In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.

It should be just one line change like:

if (alloc_capacity(r) >= min_size * HeapWordSize) {
   ...
}



### Test
- [x] make test TEST=hotspot_gc_shenandoah

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

Commit messages:
 - Bug fix: unit mismatch

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

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

From xpeng at openjdk.org  Fri Jul 11 17:58:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Jul 2025 17:58:22 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte
 or word?)
In-Reply-To: <ACUxxyPULO5HaI92kD9ldLPETWtvG6EZJMnvHsUztPs=.a792b59e-bc05-42b8-9e0c-336cc115b201@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
 <ACUxxyPULO5HaI92kD9ldLPETWtvG6EZJMnvHsUztPs=.a792b59e-bc05-42b8-9e0c-336cc115b201@github.com>
Message-ID: <xXGwqGqgirofy8SiwC90tjy6wKiUHqGZ7BYXd4prVSo=.9c16b77b-5abd-43fc-839f-adee30eeb9e8@github.com>

On Fri, 11 Jul 2025 08:34:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This looks reasonable.

Thank you! @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/26259#issuecomment-3063216917

From shade at openjdk.org  Fri Jul 11 18:00:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:00:45 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch (byte
 or word?)
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <XrxhEGZEQRxLcVtBNv8W0Fhqzfn4BivhvBZRg99jhy0=.4ef10a42-7c28-4aa1-b4a1-13272e67e724@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

I just dropped the question from the synopsis, though. Because it is clear from the patch there is a problem. You'll need to adjust the PR title a bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/26259#issuecomment-3063226717

From shade at openjdk.org  Fri Jul 11 18:04:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Jul 2025 18:04:47 GMT
Subject: [jdk25] RFR: 8360775: Fix Shenandoah GC test failures when APX is
 enabled
In-Reply-To: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
References: <lOYu7CyX8YqDS-np6dF7EktqWkeuvyqZYbRQVdytNw4=.b7a8bf22-39d1-4f35-9142-e5eddfdc681a@github.com>
Message-ID: <ipA9SlRuxB82xN9GFkfAsimc1lpscZ5-PF7Uy8XJ1vI=.602c69f9-ccfe-421d-b18a-fde6c82c7e5d@github.com>

On Fri, 11 Jul 2025 17:05:14 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1c560727](https://github.com/openjdk/jdk/commit/1c560727b850593561982ccc3ed37b0e98b3bbee) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Srinivas Vamsi Parasa on 4 Jul 2025 and was reviewed by Sandhya Viswanathan, Jatin Bhateja and Emanuel Peter.
> 
> Thanks!

Looks good, assuming tests are passing.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26271#pullrequestreview-3011405250

From duke at openjdk.org  Fri Jul 11 18:41:21 2025
From: duke at openjdk.org (Rui Li)
Date: Fri, 11 Jul 2025 18:41:21 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
Message-ID: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>

Add logging for Shenandoah as well as Generational Shenandoah. 

Log samples:


######################################
Before gc
######################################
[0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
[0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
[0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
[0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
[0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
[0.231s][debug][gc,heap      ] GC(0)  Reserved region:
[0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
[0.231s][debug][gc,heap      ] GC(0)  Collection set:
[0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
[0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
[0.231s][debug][gc,heap      ] GC(0) 
[0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
[0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
[0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K




######################################
After gc
######################################
[2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
[2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
[2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
[2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
[2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
[2.067s][debug][gc,heap        ] GC(11)  Reserved region:
[2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
[2.067s][debug][gc,heap        ] GC(11)  Collection set:
[2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
[2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
[2.067s][debug][gc,heap        ] GC(11) 
[2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
[2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
[2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

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

Commit messages:
 - 8357818: Shenandoah doesn't use shared API for printing heap before/after GC

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

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

From wkemper at openjdk.org  Fri Jul 11 18:50:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Jul 2025 18:50:42 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <nPQ8Dy-BcWPUfT76N5DRPpQfO3xP_fMfoMTotQ2nxUM=.3074c74c-1daf-4569-a6d1-a0452f89ee53@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

Nice catch!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26259#pullrequestreview-3011528633

From xpeng at openjdk.org  Fri Jul 11 20:12:47 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 11 Jul 2025 20:12:47 GMT
Subject: Integrated: 8361948: Shenandoah: region free capacity unit mismatch
In-Reply-To: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
References: <aPqyfCP5k0ssC2F7H9JL9P9ranhp0EQJb_qs4YjxJsE=.30dc83ab-c6bd-4367-b959-7044f3a35230@github.com>
Message-ID: <pWGZXk-WISixM4wZerBc6ss_ejquOv5z-ueoqXxsGLM=.95e9c91f-2748-4c30-a51a-391cf9c0f5cd@github.com>

On Fri, 11 Jul 2025 07:12:31 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the code path of [mutator allocation](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L883
> ), looks like we assume that ShenandoahAllocRequest::size/min_size and region free capacity have same unit, which is apparently not right, unit used in ShenandoahAllocRequest is word but region free capacity is in bytes.
> 
> It should be just one line change like:
> 
> if (alloc_capacity(r) >= min_size * HeapWordSize) {
>    ...
> }
> 
> 
> 
> ### Test
> - [x] make test TEST=hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 46988e10
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46988e1073e9a2b47491c90143b1f261fe56da56
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361948: Shenandoah: region free capacity unit mismatch

Reviewed-by: shade, wkemper

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

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

From wkemper at openjdk.org  Fri Jul 11 21:46:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Jul 2025 21:46:38 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <LmjrSaOKF8fn708iUyP_OiXbuZgYDrT87trewAkLN-s=.76ff03d1-08d9-461c-b627-5b1e97239b77@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

This looks good to me. Someday we should look at combining some of the other related messages (free set status, e.g.) into `ShenandoahHeap::print_heap_on`.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26272#pullrequestreview-3012097755

From ysr at openjdk.org  Fri Jul 11 22:07:39 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Jul 2025 22:07:39 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
Message-ID: <TBZZcx6kinFlpQAOZhOa6TO4OmilbrPqZNjQ8Xt1qBs=.b14d9d22-f75f-4aec-8cce-26c913502d1a@github.com>

On Fri, 11 Jul 2025 18:24:56 GMT, Rui Li <duke at openjdk.org> wrote:

> Add logging for Shenandoah as well as Generational Shenandoah. 
> 
> Log samples:
> 
> 
> ######################################
> Before gc
> ######################################
> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
> [0.231s][debug][gc,heap      ] GC(0) 
> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
> 
> 
> 
> 
> ######################################
> After gc
> ######################################
> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
> [2.067s][debug][gc,heap        ] GC(11) 
> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K

Left some comments in PR. Will complete review by EOD.

> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):

Looks like Shenandoah/GenShen are missing `increment_total_collections(...)`, which updates the `invocations=...` part. I'd roughly expect it to equal the GC id (or be a tad smaller) `GC(11)`.

> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions

A potential enhancement for GenShen would be to provide used region counts for old and young separately, and to add the "Generational" prefix in:

> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap

Rest looks good, although I want to verify that we print along all gc cycles, not just concurrent ones, as seems to be the case here.

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

PR Review: https://git.openjdk.org/jdk/pull/26272#pullrequestreview-3012130902
PR Comment: https://git.openjdk.org/jdk/pull/26272#issuecomment-3063991526

From wkemper at openjdk.org  Fri Jul 11 22:30:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Jul 2025 22:30:37 GMT
Subject: RFR: 8357818: Shenandoah doesn't use shared API for printing heap
 before/after GC
In-Reply-To: <TBZZcx6kinFlpQAOZhOa6TO4OmilbrPqZNjQ8Xt1qBs=.b14d9d22-f75f-4aec-8cce-26c913502d1a@github.com>
References: <_2I_udsaNtbWYCA8lel3aazBkGmGQqT7tUUuKbsV5qg=.79b998a4-972d-4f18-bd58-28924c8da355@github.com>
 <TBZZcx6kinFlpQAOZhOa6TO4OmilbrPqZNjQ8Xt1qBs=.b14d9d22-f75f-4aec-8cce-26c913502d1a@github.com>
Message-ID: <a2D0dYrWX3Pqegw4wLH43XGW2WkzP7STI0gZC44-NAo=.d9781f9c-a490-43d6-a74b-e1fcaf054872@github.com>

On Fri, 11 Jul 2025 22:03:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Add logging for Shenandoah as well as Generational Shenandoah. 
>> 
>> Log samples:
>> 
>> 
>> ######################################
>> Before gc
>> ######################################
>> [0.231s][debug][gc,heap      ] GC(0) Heap Before GC invocations=0 (full 0):
>> [0.231s][debug][gc,heap      ] GC(0)  Shenandoah Heap
>> [0.231s][debug][gc,heap      ] GC(0)   100M max, 100M soft max, 100M committed, 39686K used
>> [0.231s][debug][gc,heap      ] GC(0)   400 x 256 K regions
>> [0.231s][debug][gc,heap      ] GC(0)  Status: not cancelled
>> [0.231s][debug][gc,heap      ] GC(0)  Reserved region:
>> [0.231s][debug][gc,heap      ] GC(0)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [0.231s][debug][gc,heap      ] GC(0)  Collection set:
>> [0.231s][debug][gc,heap      ] GC(0)   - map (vanilla): 0x0000000000004e70
>> [0.231s][debug][gc,heap      ] GC(0)   - map (biased):  0x0000000000001000
>> [0.231s][debug][gc,heap      ] GC(0) 
>> [0.231s][debug][gc,metaspace ] GC(0) Metaspace Before GC invocations=0 (full 0):
>> [0.231s][debug][gc,metaspace ] GC(0)  Metaspace       used 153K, committed 384K, reserved 1114112K
>> [0.231s][debug][gc,metaspace ] GC(0)   class space    used 3K, committed 128K, reserved 1048576K
>> 
>> 
>> 
>> 
>> ######################################
>> After gc
>> ######################################
>> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
>> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
>> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
>> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
>> [2.067s][debug][gc,heap        ] GC(11)  Status: not cancelled
>> [2.067s][debug][gc,heap        ] GC(11)  Reserved region:
>> [2.067s][debug][gc,heap        ] GC(11)   - [0x00000000f9c00000, 0x0000000100000000) 
>> [2.067s][debug][gc,heap        ] GC(11)  Collection set:
>> [2.067s][debug][gc,heap        ] GC(11)   - map (vanilla): 0x0000000000004e70
>> [2.067s][debug][gc,heap        ] GC(11)   - map (biased):  0x0000000000001000
>> [2.067s][debug][gc,heap        ] GC(11) 
>> [2.067s][debug][gc,metaspace   ] GC(11) Metaspace After GC invocations=0 (full 0):
>> [2.067s][debug][gc,metaspace   ] GC(11)  Metaspace       used 190K, committed 384K, reserved 1114112K
>> [2.067s][debug][gc,metaspace   ] GC(11)   class space    used 4K, committed 128K, reserved 1048576K
>
>> [2.067s][debug][gc,heap        ] GC(11) Heap After GC invocations=0 (full 0):
> 
> Looks like Shenandoah/GenShen are missing `increment_total_collections(...)`, which updates the `invocations=...` part. I'd roughly expect it to equal the GC id (or be a tad smaller) `GC(11)`.
> 
>> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
>> [2.067s][debug][gc,heap        ] GC(11)   100M max, 100M soft max, 100M committed, 101356K used
>> [2.067s][debug][gc,heap        ] GC(11)   400 x 256 K regions
> 
> A potential enhancement for GenShen would be to provide used region counts for old and young separately, and to add the "Generational" prefix in:
> 
>> [2.067s][debug][gc,heap        ] GC(11)  Shenandoah Heap
> 
> Rest looks good, although I want to verify that we print along all gc cycles, not just concurrent ones, as seems to be the case here.

@ysramakrishna , good catch with `increment_total_collections`. The `print_before` and `print_after` calls surround the switch case that handles all GCs (conc, degen, full).

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

PR Comment: https://git.openjdk.org/jdk/pull/26272#issuecomment-3064067648