From duke at openjdk.org  Thu Jan  1 07:52:01 2026
From: duke at openjdk.org (Eunbin Son)
Date: Thu, 1 Jan 2026 07:52:01 GMT
Subject: jmx-dev Integrated: 8374373: Typo in
 VirtualThreadSchedulerMXBean.setParallelism javadoc
In-Reply-To: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
References: <OziFf0Ca4__OA7eKfO2DqXQe-UFZyxg-gk50OJ5twOE=.ff4211a9-6f3e-4aaf-8e60-80a397a6f720@github.com>
Message-ID: <Ky6ElI3CNfPPl0tq4DkXFZeMFDRQSkWMkYBHFMhVN_g=.61363193-699c-4b30-89b7-9e1c9813ef5f@github.com>

On Sat, 27 Dec 2025 09:55:58 GMT, Eunbin Son <duke at openjdk.org> wrote:

> ### Summary
> Fix typo in VirtualThreadSchedulerMXBean Javadoc: "suppored" ? "supported".
> 
> ### Description
> Line 79 in VirtualThreadSchedulerMXBean.java contains a typo in the `@throws UnsupportedOperationException` documentation. The word "suppored" is corrected to "supported".
> 
> ### Bug ID : JDK-8374373
> https://bugs.java.com/bugdatabase/view_bug?bug_id=8374373

This pull request has now been integrated.

Changeset: 752f46d6
Author:    Eunbin Son <thswlsqls at naver.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/752f46d66250dd44e1b13bbdbd86c70a33be3ac2
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism javadoc

Reviewed-by: alanb

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

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

From dholmes at openjdk.org  Tue Jan  6 02:02:16 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jan 2026 02:02:16 GMT
Subject: jmx-dev RFR: 8374316: Update copyright year to 2025 for hotspot
 in files where it was missed [v4]
In-Reply-To: <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
Message-ID: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>

On Sun, 28 Dec 2025 03:56:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
>> 
>> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>> 
>> ~~`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `~~
>> 
>> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into copy_hotspot
>  - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3712798915

From serb at openjdk.org  Wed Jan  7 02:24:25 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 7 Jan 2026 02:24:25 GMT
Subject: jmx-dev RFR: 8374316: Update copyright year to 2025 for hotspot
 in files where it was missed [v4]
In-Reply-To: <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <rLRlxg59ztJPN1eGournxUICh4mvQfqQkNIdbdIhHDM=.4ffd8bb3-8cf5-49e2-af8c-c2a3b23dad7b@github.com>
 <JnDBfpSX2boh4MregZIgWpxg8gmgpal0_p7-cmp92Ok=.53d89bd4-7f69-489b-b18b-d48ff354ecbf@github.com>
Message-ID: <Y5_mNmjjmMarr5d5NPbcv06zyT2FQh35o3TkJarbr1A=.b0715e43-a3fd-4301-b52e-fdf7e54821e9@github.com>

On Tue, 6 Jan 2026 01:58:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>Just be aware that if a file was created as part of a refactoring and the code was taken as-is from an existing file, then the copyright year range should have remained the same as the original file. I don't know if any of the files you modified fall into that category but just wanted to point out that looking at the commit date is not always correct.

I tried to catch rename/move-only or copyright-only changes, but I?m not 100% sure I filtered all of them out.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3717068454

From lkorinth at openjdk.org  Wed Jan  7 12:35:42 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:35:42 GMT
Subject: jmx-dev RFR: 8367993: G1: Speed up ConcurrentMark
 initialization [v2]
In-Reply-To: <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
Message-ID: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>

On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
> 
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>    
>    Reviewed-by: aboldtch
>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>    
>    Reviewed-by: serb, aivanov, dnguyen
>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767

I will redo the merge, I have done something strange.

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595

From lkorinth at openjdk.org  Wed Jan  7 12:58:43 2026
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 7 Jan 2026 12:58:43 GMT
Subject: jmx-dev RFR: 8367993: G1: Speed up ConcurrentMark
 initialization [v3]
In-Reply-To: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
Message-ID: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>

> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
> 
> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
> 
> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
> 
> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:

 - Merge branch '8373253' into 8367993
 - Merge branch 'master' into _8373253
 - Merge branch 'master' into _8367993
 - 8366058: Outdated comment in WinCAPISeedGenerator
   
   Reviewed-by: mullan
 - 8357258: x86: Improve receiver type profiling reliability
   
   Reviewed-by: kvn, vlivanov
 - 8373704: Improve "SocketException: Protocol family unavailable" message
   
   Reviewed-by: lucy, jpai
 - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
   
   Reviewed-by: jiefu, jbhateja, erfang, qamai
 - 8343809: Add requires tag to mark tests that are incompatible with exploded image
   
   Reviewed-by: alanb, dholmes
 - 8374465: Spurious dot in documentation for JVMTI ClassLoad
   
   Reviewed-by: kbarrett
 - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
   
   Reviewed-by: djelinski, mpowers, ascarpino
 - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

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

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02
  Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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

From sjohanss at openjdk.org  Fri Jan  9 08:47:01 2026
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 9 Jan 2026 08:47:01 GMT
Subject: jmx-dev RFR: 8367993: G1: Speed up ConcurrentMark
 initialization [v3]
In-Reply-To: <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <F0yu8OvqtdnssFD3SQoQ4DItAxBELEvwD1aAei2J5M8=.df501c22-ac18-4742-a0ab-ec6d1848be1f@github.com>
Message-ID: <CNxPXaG8qXqVrPo5NsiiGa6M6r3hPE9UcLKaDYkr5is=.26f84708-d442-45b0-b787-fda252292bee@github.com>

On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.
>> 
>> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.
>> 
>> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.
>> 
>> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits:
> 
>  - Merge branch '8373253' into 8367993
>  - Merge branch 'master' into _8373253
>  - Merge branch 'master' into _8367993
>  - 8366058: Outdated comment in WinCAPISeedGenerator
>    
>    Reviewed-by: mullan
>  - 8357258: x86: Improve receiver type profiling reliability
>    
>    Reviewed-by: kvn, vlivanov
>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>    
>    Reviewed-by: lucy, jpai
>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>    
>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>    
>    Reviewed-by: alanb, dholmes
>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>    
>    Reviewed-by: kbarrett
>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>    
>    Reviewed-by: djelinski, mpowers, ascarpino
>  - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68

Thanks for looking into this Leo. 

Overall I think it looks good, just some small questions and suggestions.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637:

> 1635: 
> 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const {
> 1637:   assert(_cm != nullptr, "thread must exist in order to check if mark is terminating");

I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427:

> 2425:   if (_cm->is_fully_initialized()) {
> 2426:     tc->do_thread(_cm->cm_thread());
> 2427:   }

Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()`

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549:

> 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) {
> 2548:   assert(!_cm->in_progress(), "Can not start concurrent operation while in progress");
> 2549:   assert(_cm->is_fully_initialized(), "sanity");

Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert.

src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46:

> 44:     return false;
> 45:   }
> 46: 

Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right?

src/hotspot/share/gc/g1/g1Policy.cpp line 744:

> 742:   if (!_g1h->concurrent_mark()->is_fully_initialized()) {
> 743:     return false;
> 744:   }

Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127:

> 1125: 
> 1126: void G1YoungCollector::collect() {
> 1127:   _g1h->_cm->fully_initialize();

I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)`

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

Changes requested by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503
PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630

From stefank at openjdk.org  Fri Jan  9 12:09:22 2026
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jan 2026 12:09:22 GMT
Subject: jmx-dev RFR: 8367993: G1: Speed up ConcurrentMark
 initialization [v2]
In-Reply-To: <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
References: <BoAV8eR2EWmzvZHkuo_MLRoc8F-1uyxBKXobaFcxFz8=.4bbc7c56-2d86-4eb9-a0f1-3abe4ec74b07@github.com>
 <Sqy2ecoZvJXHPHOfyOKzbCRID4cERqP9gbNciYUX6EY=.c44e3a4d-dfd6-44eb-8bab-668af696fd7b@github.com>
 <rncRewS4A4nkwvAkJRLAAJ-BhEGWXFxsGy8Pl-m0fNI=.af3d6a7d-6a61-4dee-a26a-d09e7215bc4e@github.com>
Message-ID: <aSHHOBAAdNFMkL3dy7qiMutT8mTtX0R5pLQU6kB4Diw=.38610782-7ad7-44f6-9d44-4cf8164b9562@github.com>

On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into _8367993
>>  - 8366058: Outdated comment in WinCAPISeedGenerator
>>    
>>    Reviewed-by: mullan
>>  - 8357258: x86: Improve receiver type profiling reliability
>>    
>>    Reviewed-by: kvn, vlivanov
>>  - 8373704: Improve "SocketException: Protocol family unavailable" message
>>    
>>    Reviewed-by: lucy, jpai
>>  - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently
>>    
>>    Reviewed-by: jiefu, jbhateja, erfang, qamai
>>  - 8343809: Add requires tag to mark tests that are incompatible with exploded image
>>    
>>    Reviewed-by: alanb, dholmes
>>  - 8374465: Spurious dot in documentation for JVMTI ClassLoad
>>    
>>    Reviewed-by: kbarrett
>>  - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket
>>    
>>    Reviewed-by: djelinski, mpowers, ascarpino
>>  - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings
>>    
>>    Reviewed-by: aboldtch
>>  - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test
>>    
>>    Reviewed-by: serb, aivanov, dnguyen
>>  - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767
>
> I will redo the merge, I have done something strange.

@lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels?

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

PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315

From serb at openjdk.org  Mon Jan 12 08:26:49 2026
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 12 Jan 2026 08:26:49 GMT
Subject: jmx-dev RFR: 8374838: Apply java.io.Serial annotations in
 java.management.*
Message-ID: <jpwqK3H_TNXpnxw7EbkAMObsFxW125r52P2a2rZ2A00=.a2095d49-77b3-428f-97a2-b5482e4eaefe@github.com>

Please review the application of the `@Serial` annotation ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the `java.management.*` modules. The goal is to enable stricter compile-time checking of serialization-related declarations.

The change is not small. I could split it, but I decided to do it as a single change since covering the module in one shot is easier than managing a bunch of separate PRs.

Example of a similar change https://github.com/openjdk/jdk/pull/24891.

Note: this annotation can be applied to these methods and fields:
  * private void writeObject(java.io.ObjectOutputStream stream) throws IOException
  * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException
  * private void readObjectNoData() throws ObjectStreamException 
   * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
   * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException
   * private static final ObjectStreamField[] serialPersistentFields
   * private static final long serialVersionUID

Additional changes:
 - Copyright years were updated
 - Imports were not touched much (no sorting or cleanup); the new import was added in a reasonable place
 - In several places `static final long serialVersionUID =` was changed to
 `private static final long serialVersionUID =`

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

Commit messages:
 - 8374838: Apply java.io.Serial annotations in javax.management.*

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

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

From bchristi at openjdk.org  Tue Jan 20 20:31:18 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 20 Jan 2026 20:31:18 GMT
Subject: jmx-dev RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
Message-ID: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>

This brings in cpu26_01 changes.

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

Commit messages:
 - 8368032: Enhance Certificate Checking
 - 8365280: Enhance JOptionPane
 - 8359501: Enhance Handling of URIs
 - 8362632: Improve HttpServer Request handling
 - 8367277: Fix copyright header in JMXInterfaceBindingTest.java
 - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently
 - 8341496: Improve JMX connections
 - 8365058: Enhance CopyOnWriteArraySet
 - 8365271: Improve Swing supports
 - 8362308: Enhance Bitmap operations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a67979c4...07f981f6

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/29331/files
  Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/29331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331

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

From bchristi at openjdk.org  Tue Jan 20 20:34:55 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 20 Jan 2026 20:34:55 GMT
Subject: jmx-dev [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284
Message-ID: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>

This brings in cpu26_01 changes.

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

Commit messages:
 - 8368032: Enhance Certificate Checking
 - 8365280: Enhance JOptionPane
 - 8359501: Enhance Handling of URIs
 - 8362632: Improve HttpServer Request handling
 - 8367277: Fix copyright header in JMXInterfaceBindingTest.java
 - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently
 - 8341496: Improve JMX connections
 - 8365058: Enhance CopyOnWriteArraySet
 - 8365271: Improve Swing supports
 - 8362308: Enhance Bitmap operations
 - ... and 2 more: https://git.openjdk.org/jdk/compare/f4ddafcd...4b0189c4

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/29332/files
  Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/29332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332

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

From kcr at openjdk.org  Tue Jan 20 21:34:45 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jan 2026 21:34:45 GMT
Subject: jmx-dev RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <lgyZ6v95aJQ2wc93EdoJ-t0CX8-HASEbzT8M0yss3Qk=.f6545aa5-52ed-4849-ae60-8ff75fd4cd55@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

LGTM

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684377505

From kcr at openjdk.org  Tue Jan 20 21:35:46 2026
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jan 2026 21:35:46 GMT
Subject: jmx-dev [jdk26] RFR: Merge
 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <tAakA6ADGd9sqbZll-xqpgZDUV6VtWUgCSm3oJQlhV4=.93c63002-5987-481a-b194-341b5faaa3d5@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

LGTM

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684378038

From prr at openjdk.org  Tue Jan 20 22:05:29 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jan 2026 22:05:29 GMT
Subject: jmx-dev RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <L7ot0RSGxYxlzRYGMKEMjILOCiC7wGYhsO7vVvEzPXc=.ba5698e7-be06-497e-8234-395f2cac7556@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684486562

From prr at openjdk.org  Tue Jan 20 22:08:39 2026
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jan 2026 22:08:39 GMT
Subject: jmx-dev [jdk26] RFR: Merge
 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <R0Q7zCwwhcmbvB3Z-GT8SyVv88FiNpJE1sRGDKWVWKs=.1d63c771-76ba-455e-8c48-738cd1cae0f7@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684495706

From smarks at openjdk.org  Wed Jan 21 01:16:18 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jan 2026 01:16:18 GMT
Subject: jmx-dev [jdk26] RFR: Merge
 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <16L6cSilYiC8tbhpmKW2g3X19hE5-A0jHERAtsCJ9S4=.3211d9ae-c184-4ec9-823f-43b77fd49d68@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

The changes in this PR match the list of approved changes for this release.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684928489

From smarks at openjdk.org  Wed Jan 21 01:16:22 2026
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jan 2026 01:16:22 GMT
Subject: jmx-dev RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <d4UEBfgDPeaTQ6MJmVaGLhkMF4MGbJjvaNc4UF0VUPc=.de637b15-3139-4dbf-b863-9d6355b07503@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

The changes in this PR match the list of approved changes for this release.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684928880

From bchristi at openjdk.org  Wed Jan 21 01:33:46 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:33:46 GMT
Subject: jmx-dev [jdk26] RFR: Merge
 4b0189c444a061f4e1e4dd27e7980ebb81252284 [v2]
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <m6au9jDA--T9V-5h9StQxGa1b8s6tQMUQYjj1jGeods=.3d7846c9-f8de-46b2-ad4c-73626b6fdb15@github.com>

> This brings in cpu26_01 changes.

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29332/files
  - new: https://git.openjdk.org/jdk/pull/29332/files/4b0189c4..4b0189c4

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

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

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

From bchristi at openjdk.org  Wed Jan 21 01:33:48 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:33:48 GMT
Subject: jmx-dev [jdk26] Integrated: Merge
 4b0189c444a061f4e1e4dd27e7980ebb81252284
In-Reply-To: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
References: <xlCUF9J2XYemvMqj95EOB8Ffbr6pL_TYMfFyYFE48Ao=.b174dc79-13ed-4e3f-9f16-544e4658f2af@github.com>
Message-ID: <bzGdXAI0-0khn6oK_-Lf3InoJyVt9CL5hoRFPXlHu_w=.3b3e93b5-7484-4499-aecf-80b589c1663a@github.com>

On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

This pull request has now been integrated.

Changeset: 7ac780da
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ac780da7b98d1a44effc86e75b62a1bedc7954b
Stats:     1268 lines in 37 files changed: 965 ins; 148 del; 155 mod

Merge

Reviewed-by: kcr, prr, smarks

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

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

From bchristi at openjdk.org  Wed Jan 21 01:34:06 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:34:06 GMT
Subject: jmx-dev RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 [v2]
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <_R8gyRrfwT8U_cL4_T9ImlWVN5Q3zLKoa61ZVBXQP5E=.8fbf5d4d-4be3-46a9-94c2-b14c0ddef43d@github.com>

> This brings in cpu26_01 changes.

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29331/files
  - new: https://git.openjdk.org/jdk/pull/29331/files/07f981f6..07f981f6

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

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

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

From bchristi at openjdk.org  Wed Jan 21 01:34:09 2026
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 21 Jan 2026 01:34:09 GMT
Subject: jmx-dev Integrated: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325
In-Reply-To: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
References: <y90Mg-cOhG9n_SoJcMrzOKOhYBh-eX_UZk3me1TA_Z0=.1f44a0c1-7428-46c2-a02f-1c84b4f3e8d5@github.com>
Message-ID: <bxGQ21sSA_6fGAy2JNV_X9oo_Q5DnkUjXtfGEKwjJCw=.66feccd4-289e-49a9-bd8c-1accc12fced0@github.com>

On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu26_01 changes.

This pull request has now been integrated.

Changeset: e25a5a48
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e25a5a4821d03680d00ab6bdbec727732add8206
Stats:     1268 lines in 37 files changed: 965 ins; 148 del; 155 mod

Merge

Reviewed-by: kcr, prr, smarks

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

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

From shade at openjdk.org  Wed Jan 21 16:47:43 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Jan 2026 16:47:43 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v5]
In-Reply-To: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
Message-ID: <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>

> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
> 
> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
> 
> Shenandoah added a few asserts to catch these errors:
>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
> 
> ...but G1 would also benefit from the similar safety mechanism.
> 
> This PR strengthens the code to prevent future accidents.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] GHA, cross-compilation only

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

  Some polishing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28703/files
  - new: https://git.openjdk.org/jdk/pull/28703/files/5c2206b9..db78bed3

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

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

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

From shade at openjdk.org  Wed Jan 21 17:35:58 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Jan 2026 17:35:58 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v2]
In-Reply-To: <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
 <gIc95B0VF5sGO0Z6sBX0JE_OLvGNJR77URZFe_vKfpo=.ed0142a9-67ff-4f94-a6ad-1bb8b0104c6c@github.com>
 <2QXqO9Zb2qShuQP-r33WBSkM65HLMQsi5M3x_B0ELJc=.856e0673-41aa-4c45-95d4-c43b7993e488@github.com>
Message-ID: <eybxV-cVb4uNIyiwRpUJY09NjeZ9spSdvx1HHpOeGaE=.67e3686f-4a88-4f52-8cef-59bb1426aae6@github.com>

On Wed, 21 Jan 2026 13:28:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Looks good apart from minor nits (extra spaces). Sorry for taking so long.

No problem, thanks for looking! This is not urgent, one of those "safety in depth" fixes, really.

Refixed the PR after borked merge. Re-ran `hotspot_gc` without issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3779958493

From tschatzl at openjdk.org  Thu Jan 22 12:12:26 2026
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 22 Jan 2026 12:12:26 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v5]
In-Reply-To: <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
 <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
Message-ID: <fVyc43SXnJZgaTyysyBrlHB6tiiphqi8o7q2BJIYcRg=.a6b930d6-2816-4da2-b8c0-8ec6d1bce085@github.com>

On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
>> 
>> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
>> 
>> Shenandoah added a few asserts to catch these errors:
>>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
>> 
>> ...but G1 would also benefit from the similar safety mechanism.
>> 
>> This PR strengthens the code to prevent future accidents.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] GHA, cross-compilation only
>
> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Some polishing

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3692138599

From shade at openjdk.org  Thu Jan 22 16:50:58 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Jan 2026 16:50:58 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v5]
In-Reply-To: <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
 <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
Message-ID: <j6yROYsVwvMxUETGpGR619dwu9hyom9Wg8H3YbLly8g=.b2410d35-08b7-4ded-bac9-1d0e8fd656ae@github.com>

On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
>> 
>> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
>> 
>> Shenandoah added a few asserts to catch these errors:
>>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
>> 
>> ...but G1 would also benefit from the similar safety mechanism.
>> 
>> This PR strengthens the code to prevent future accidents.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] GHA, cross-compilation only
>
> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Some polishing

Thanks! The only GHA failure is due to (the absence of): https://github.com/openjdk/jdk/pull/29254. Looking for a second Reviewer!

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

PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3785460384

From duke at openjdk.org  Mon Jan 26 03:52:16 2026
From: duke at openjdk.org (Kent Dong)
Date: Mon, 26 Jan 2026 03:52:16 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v13]
In-Reply-To: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
Message-ID: <Qb9Zzcz6XDloimkaJGLhQWsaC_A2ywg081gQ_4laX_4=.5aa77623-c635-4aea-9622-8e2e57258f55@github.com>

On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8364343
>  - simplify assert
>  - Merge branch 'master' into JDK-8364343
>  - rebind in end_transition only for mount case
>  - Fix comment in inline_native_vthread_start_transition
>  - missing to initialize _is_disabler_at_start
>  - More changes from Coleen's review
>  - Drop VTMS from names
>  - keep preexisting rebind order for mount
>  - Remove INCLUDE_JVMTI macro
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce

Hi guys, would this patch be backported to JDK 25?

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3797793059

From shade at openjdk.org  Mon Jan 26 11:18:00 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 26 Jan 2026 11:18:00 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v5]
In-Reply-To: <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
 <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
Message-ID: <tdyUPTqx6AeEbXGYP6Su2zkGg64OMz8OpkvHYeDurSs=.e848e5b7-85d5-4112-af53-0b2bae8111d5@github.com>

On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
>> 
>> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
>> 
>> Shenandoah added a few asserts to catch these errors:
>>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
>> 
>> ...but G1 would also benefit from the similar safety mechanism.
>> 
>> This PR strengthens the code to prevent future accidents.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] GHA, cross-compilation only
>
> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Some polishing

Still looking for a second Reviewer, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3799053446

From dholmes at openjdk.org  Tue Jan 27 07:40:28 2026
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Jan 2026 07:40:28 GMT
Subject: jmx-dev RFR: 8364343: Virtual Thread transition management
 needs to be independent of JVM TI [v13]
In-Reply-To: <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
References: <aVBbTIzOVP2lQfW12w_wdlnX97wgZ5Eyc3hBI6fTtw8=.82734c0f-86a0-43a4-81c1-b2c9dfc82291@github.com>
 <p6lFKQ-dibdBFgeRjm2oaHSE1MwKSJ1x4gUXJNQRBX4=.96d83b12-93af-44c8-a0d5-50cb7e8e7b8d@github.com>
Message-ID: <zBXn6pLVafOI88NK2n3P_kPzptqM4jTzgYf-VBWQjlA=.2486db9d-f7fa-46cc-9e86-d19d59b62f7f@github.com>

On Wed, 3 Dec 2025 15:27:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes.
>> 
>> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes:
>> 
>> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. 
>> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version.
>> 
>> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`.
>> 
>> - The code was previously structured in t...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into JDK-8364343
>  - simplify assert
>  - Merge branch 'master' into JDK-8364343
>  - rebind in end_transition only for mount case
>  - Fix comment in inline_native_vthread_start_transition
>  - missing to initialize _is_disabler_at_start
>  - More changes from Coleen's review
>  - Drop VTMS from names
>  - keep preexisting rebind order for mount
>  - Remove INCLUDE_JVMTI macro
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/829b8581...444ac0ce

I've added a comment to the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3803589839

From xpeng at openjdk.org  Tue Jan 27 21:08:26 2026
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 27 Jan 2026 21:08:26 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v5]
In-Reply-To: <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
 <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
Message-ID: <fXYZbOeHCei9KOaJHwNvB-YEohPeva5CoRCmJMkAJ3s=.d9fdb429-bfa1-4ca4-adfd-7ae0b7145b87@github.com>

On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
>> 
>> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
>> 
>> Shenandoah added a few asserts to catch these errors:
>>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
>> 
>> ...but G1 would also benefit from the similar safety mechanism.
>> 
>> This PR strengthens the code to prevent future accidents.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] GHA, cross-compilation only
>
> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Some polishing

Thanks for generalize the safety mechanism. Looks good to me, and it is a nice PR to read.

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28703#pullrequestreview-3713454244

From shade at openjdk.org  Wed Jan 28 07:48:03 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Jan 2026 07:48:03 GMT
Subject: jmx-dev RFR: 8373266: Strengthen constant CardTable base
 accesses [v5]
In-Reply-To: <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
 <cnw9XSqFu6iHN7XOyb7sPoKri9GrrQBQPxbBCHy8iHQ=.ad618ecc-bb9c-4d6b-a10b-1f18ee651056@github.com>
Message-ID: <K19C77IZjbsLE0MkauQLhiDuWrUEINWQxKJH2ufRGd0=.cb272f62-063c-4dac-9f6f-9c69864c75df@github.com>

On Wed, 21 Jan 2026 16:47:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
>> 
>> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
>> 
>> Shenandoah added a few asserts to catch these errors:
>>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
>> 
>> ...but G1 would also benefit from the similar safety mechanism.
>> 
>> This PR strengthens the code to prevent future accidents.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>>  - [x] GHA, cross-compilation only
>
> Aleksey Shipilev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Some polishing

Thanks folks! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/28703#issuecomment-3809555279

From shade at openjdk.org  Wed Jan 28 07:48:04 2026
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Jan 2026 07:48:04 GMT
Subject: jmx-dev Integrated: 8373266: Strengthen constant CardTable base
 accesses
In-Reply-To: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
References: <k38G94Tpq-aEKy5qzf8vaCMgcn0KHYw4JTWm0-RWgIQ=.5da23c7e-d826-41c2-b42f-ec2a90fd2213@github.com>
Message-ID: <HrI44x7mTE2-S9vUk6GkIG4t06W_q9r1ni8KXPCNcno=.4947180f-0332-460c-bfdd-3c6b4c893a59@github.com>

On Mon, 8 Dec 2025 18:45:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Shenandoah and G1 are using CardTable for most of its infrastructure, but flip the card tables as they go, and maintain the actual card table reference in TLS. As such, accessing card table base from assembler and compilers runs into risk of accidentally encoding the wrong card table base in generated code. 
> 
> Most of the current code avoids this trouble by carefully implementing their GC barriers to avoid touching shared parts where card table base constness is assumed. _Except_ for JVMCI, that reads the card table base for G1 barrier set, and that is wrong. The JVMCI users would need to rectify this downstream.
> 
> Shenandoah added a few asserts to catch these errors:
>  SHENANDOAHGC_ONLY(assert(!UseShenandoahGC, "Shenandoah byte_map_base is not constant.");)
> 
> ...but G1 would also benefit from the similar safety mechanism.
> 
> This PR strengthens the code to prevent future accidents.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc`
>  - [x] Linux x86_64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] Linux AArch64 server fastdebug, `all` with Serial, Parallel, G1, Shenandoah, Z
>  - [x] GHA, cross-compilation only

This pull request has now been integrated.

Changeset: 88c8a55a
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88c8a55a4337a857ac17ffff068f730f67cf5763
Stats:     99 lines in 15 files changed: 35 ins; 25 del; 39 mod

8373266: Strengthen constant CardTable base accesses

Reviewed-by: tschatzl, xpeng

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

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