From kbarrett at openjdk.org  Sat Nov  1 07:34:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 1 Nov 2025 07:34:03 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <4Yh4KeUItjdDYihe9d1u66tBROofb0pRLDKIdhw-XZo=.cf383363-c963-4871-941d-5e358f74c048@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
 <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>
 <6u0Ia6A2xQnv51Ti0Jchg6rnncfRRvtK5oGS963CeIA=.bc9c1481-60ad-443d-923b-dc86277dbb14@github.com>
 <4Yh4KeUItjdDYihe9d1u66tBROofb0pRLDKIdhw-XZo=.cf383363-c963-4871-941d-5e358f74c048@github.com>
Message-ID: <lys0bB9p3seBZOSTmK56Jn2ci_KLhN0OmXM0kPm1pbI=.1de770da-c33a-4077-8ca2-a70f5100623e@github.com>

On Mon, 27 Oct 2025 08:24:41 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> We (you and me, @fweimer-rh) discussed this a couple of years ago:
>> https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/082324.html
>> 
>> Quoting from here:
>> https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/083142.html
>> 
>> "
>> Empirically, a recursive initialization attempt doesn't make any attempt to
>> throw. Rather, it blocks forever waiting for a futex signal from a thread that
>> succeeds in the initialization. Which of course will never come.
>> 
>> And that makes sense, now that I've looked at the code.
>> 
>> In __cxa_guard_acquire, with _GLIBCXX_USE_FUTEX, if the guard indicates
>> initialization hasn't yet been completed, then it goes into a while loop.
>> This while loop tries to claim initialization.  Failing that, it checks
>> whether initialization is complete.  Failing that, it does a SYS_futex
>> syscall, waiting for some other thread to perform the initialization.  There's
>> nothing there to check for recursion.
>> 
>> throw_recursive_init_exception is only called if single-threaded (either by
>> configuration or at runtime).
>> "
>> 
>> It doesn't look like there have been any relevant changes in that area since
>> then. So I think there is still not a problem here.
>
> @kimbarrett Sorry, I forgot about the old thread. You can get the exception in a single-threaded scenario, something like this:
> 
> 
> struct S {
>   S() {
>     static S s;
>     *this = s;
>   }
> } global;
> 
> 
> Maybe the actual rule is more like this?
> 
>> Functions that may throw exceptions must not be used, unless individual calls ensure that these particular invocations cannot throw exceptions.

Recursively entering a block-scoped static is undefined behavior. That some
configurations of glibc might throw an exception in that situation (even
despite the caller being compiled with exceptions disabled) seems like a
mistake in glibc, and not really our concern. Our code should avoid such a
situation because it's UB, regardless of whether the actual behavior involves
exceptions or nasal demons.

The exception only gets thrown when the application is single-threaded. But at
least the common way to start java (via the launcher) is already
multi-threaded on entry to Threads::create_vm(). So that case doesn't normally
apply to us anyway.

Also, I really don't think we want people trying to figure out whether a
particular call might or might not throw (neither when writing nor when
reading code).

So no, I don't think the proposed rule should be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2483178071

From aph at openjdk.org  Sat Nov  1 09:02:11 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 1 Nov 2025 09:02:11 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v9]
In-Reply-To: <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
Message-ID: <XUdnUlDYEfLJi6qzGosHzp_9tKno0o4RX4E92Q-N4CY=.ad2727a6-0beb-4565-8b07-dca0c532d82e@github.com>

On Tue, 28 Oct 2025 23:18:48 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben 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 three new commits since the last revision:
> 
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a

Marked as reviewed by aph (Reviewer).

But I'm not going to push `SafeFetch` any further. I've said my piece.

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

PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3407023975
PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3476011689

From aph at openjdk.org  Sat Nov  1 09:05:08 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 1 Nov 2025 09:05:08 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v9]
In-Reply-To: <tTgnPha4MRnzl0E8fTYS1CeZ94wkFUSyB58jA-rDYbg=.eb4f8355-bdd2-4328-af08-8b7def6ad33e@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
 <tTgnPha4MRnzl0E8fTYS1CeZ94wkFUSyB58jA-rDYbg=.eb4f8355-bdd2-4328-af08-8b7def6ad33e@github.com>
Message-ID: <SNyc1Zec4JXuml-4sts3nnk3UN2tA2aC-N6m5rRpwCE=.0cdf1fc7-4318-465e-a0e5-feede1d828ff@github.com>

On Thu, 30 Oct 2025 21:10:18 GMT, Dean Long <dlong at openjdk.org> wrote:

> Re: SafeFetch, it is probably OK to make NativePostCallNop_at slightly slower for uses like make_deoptimized(), but the oopmap optimizations like CodeCache::find_blob_and_oopmap() were highly optimized to make loom/VirtualThread performance reasonable. Adding a SafeFetch here might cause a regression.

Sure, but 2 things:
Loom doesn't meed post-call NOPs as much as it used to.
We could fairly easily make SafeFetch much faster than it is, if needs be.
But anyway, I approved this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3476017720

From fandreuzzi at openjdk.org  Sat Nov  1 11:48:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 1 Nov 2025 11:48:04 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
Message-ID: <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>

On Thu, 30 Oct 2025 06:01:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> It would be good if you could provide some ballpark figures on the number of events in a worst-case scenario, so we can determine what GC level is appropriate.

I wrote a simple pathological test with multiple threads interning random strings, [this](https://github.com/user-attachments/files/23282465/out-parallel.txt) is the worst I've seen: 100 deduplication rounds within `3.698s` and `3.729s`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3476289368

From kvn at openjdk.org  Sat Nov  1 15:06:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 1 Nov 2025 15:06:06 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <HQCNu464FkSX8tHp5jE9WYXh0Fl7KLXONAbQIE7hOWg=.f047cff1-b02c-44dd-ac9d-c25d3ce4a6c7@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Approved

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3407565447

From duke at openjdk.org  Sat Nov  1 16:00:22 2025
From: duke at openjdk.org (duke)
Date: Sat, 1 Nov 2025 16:00:22 GMT
Subject: Withdrawn: 8366122: Shenandoah: Implement efficient support for object
 count after gc events
In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com>
Message-ID: <toUHWUnh99ZDRi1tVoWl0dHx_A4yLh8BGTQ6_kbGVKc=.75d986e6-febb-44b5-8ed5-272da5a82fb5@github.com>

On Thu, 28 Aug 2025 01:30:39 GMT, pf0n <duke at openjdk.org> wrote:

> ### Summary
> 
> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work.
> 
> ### Performance
> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen)
> 
> #### Default workload:
> ObjectCountAfterGC disabled (master branch):
> `[807.216s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      264 us)`
> `[807.216s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       91 us)`
> `[807.216s][info][gc,stats    ] Concurrent Mark Roots          =    0.041 s (a =     4099 us)`
> `[807.216s][info][gc,stats    ] Concurrent Marking             =    1.660 s (a =   166035 us)`
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (G)           =    0.004 s (a =      446 us) `
> `[807.216s][info][gc,stats    ] Pause Final Mark (N)           =    0.004 s (a =      357 us)`
> 
> ObjectCountAfterGC disabled (feature branch):
> `[807.104s][info][gc,stats    ] Pause Init Mark (G)            =    0.003 s (a =      302 us)`
> `[807.104s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       92 us) `
> `[807.104s][info][gc,stats    ] Concurrent Mark Roots          =    0.048 s (a =     4827 us)`
> `[807.104s][info][gc,stats    ] Concurrent Marking             =    1.666 s (a =   166638 us) `
> `[807.104s][info][gc,stats    ] Pause Final Mark (G)           =    0.006 s (a =      603 us)`
> `[807.104s][info][gc,stats    ] Pause Final Mark (N)           =    0.005 s (a =      516 us)`
> 
> ObjectCountAfterGC enabled (feature branch)
> `[807.299s][info][gc,stats    ] Pause Init Mark (G)            =    0.002 s (a =      227 us)`
> `[807.299s][info][gc,stats    ] Pause Init Mark (N)            =    0.001 s (a =       89 us) `
> `[807.299s][info][gc,stats    ] Concurrent Mark Roots          =    0.053 s (a =     5279 us)`
> `[807.299s][info][gc,st...

This pull request has been closed without being integrated.

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

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

From lucy at openjdk.org  Sat Nov  1 20:56:02 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Sat, 1 Nov 2025 20:56:02 GMT
Subject: RFR: 8370871: [s390x] consistently update top_frame_sp [v2]
In-Reply-To: <RECvq3eN4_lbuD_mM6e6SxX2ZZfkaw7zB4nkp7OHVK8=.ca5d3ed9-1885-4831-88d4-183f6745e2f7@github.com>
References: <wKwHXS_yLDQbibMRJJFgv_g7VyaiqycRt8oSRwb3apI=.6fd7e15f-55b7-4e09-bdde-e5499e55ec15@github.com>
 <RECvq3eN4_lbuD_mM6e6SxX2ZZfkaw7zB4nkp7OHVK8=.ca5d3ed9-1885-4831-88d4-183f6745e2f7@github.com>
Message-ID: <WvGb2Vg9mkuPLd79DTDwn-uERi8CIHLJb5CKL7DHxww=.7400839c-6d5e-4811-895f-0dc10a2956be@github.com>

On Thu, 30 Oct 2025 06:48:43 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Stores top_frame_sp for interpreter frames consistently. Although this is making one to assert fail in loom port but still I think this should be considered independent bug.
>> 
>> Changes in `generate_throw_exception` also helped with another issue in loom which was resolved by this workaround: https://github.com/offamitkumar/jdk/blob/5cb1322f58a4c676aac59244dcb62d8b67f0ed93/src/hotspot/cpu/s390/continuationFreezeThaw_s390.inline.hpp#L302C1-L318C2, issue: 
>> 
>> In `BasicExt.java` testcase there are two subtests : 
>> ```java 
>>         new Continuation3Frames(TestCaseVariants.THROW_HANDLED_EXCEPTION).runTestCase(4, compPolicy);
>>         new Continuation3Frames(TestCaseVariants.THROW_UNHANDLED_EXCEPTION).runTestCase(4, compPolicy);
>> 
>> 
>> these two testcase were failing because we were overwriting the interpreter frame content as we have to make the native call which saves the register from r6 to r15. So at that time the workaround was necessary, but it turns out that using `top_frame_sp` to extend the frame will fix the overwriting issue.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding assert and frame extension for exception

Looks good.
Consistency rules!

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28042#pullrequestreview-3407720708

From kbarrett at openjdk.org  Sun Nov  2 07:05:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 2 Nov 2025 07:05:24 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <ZOCT202NaByvSrndotd5xVCJT-GrL7Ngo3JhAp-4Y6s=.e8a98f16-d6a4-47eb-971c-f817a32ae361@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Thanks for reviews and comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3477511265

From kbarrett at openjdk.org  Sun Nov  2 07:05:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 2 Nov 2025 07:05:26 GMT
Subject: Integrated: 8369186: HotSpot Style Guide should permit some uses of
 the C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <xgFGfVomszjUfS2ZUHNO841ejlAsV12Vcc0ezo8ZwGA=.0211f02f-1b7a-44a9-a54c-0fdfab8667a3@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

This pull request has now been integrated.

Changeset: e8a1a870
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8a1a8707ee6192c85ac62a2a51c815e07613c38
Stats:     670 lines in 68 files changed: 430 ins; 134 del; 106 mod

8369186: HotSpot Style Guide should permit some uses of the C++ Standard Library

Reviewed-by: jrose, lkorinth, iwalulya, kvn, stefank

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

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

From epeter at openjdk.org  Mon Nov  3 06:58:19 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 3 Nov 2025 06:58:19 GMT
Subject: Integrated: 8370405: C2: mismatched store from MergeStores wrongly
 scalarized in allocation elimination
In-Reply-To: <m9n_1TmV1cv2JTGSmuIjq7EqiC4Lsd_8m7Vg6XuVlh8=.8c341b0f-25e6-4a0d-ae1c-c74c1c1e7b50@github.com>
References: <m9n_1TmV1cv2JTGSmuIjq7EqiC4Lsd_8m7Vg6XuVlh8=.8c341b0f-25e6-4a0d-ae1c-c74c1c1e7b50@github.com>
Message-ID: <mWa1ymirtFAjNoGtjxiFa9JRa4lKALWXM8Wxzuk93Ac=.bf986a73-89d4-4c65-bf6c-c3c4770821c1@github.com>

On Mon, 27 Oct 2025 10:40:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Note: @oliviermattmann found this bug with his whitebox fuzzer. See also https://github.com/openjdk/jdk/pull/27991
> 
> **Analysis**
> We run Escape Analysis, and see that a local array allocation could possibly be removed, we only have matching `StoreI` to the `int[]`. But there is one `StoreI` that is still in a loop, and so we wait with the actual allocation removal until later, hoping it may go away, or drop out of the loop.
> During loop opts, the `StoreI` drops out of the loop, now there should be nothing in the way of allocation removal.
> But now we run `MergeStores`, and merge two of the `StoreI` into a mismatched `StoreL`.
> 
> Then, we eventually remove the allocation, but don't check again if any new mismatched store has appeared.
> Instead of a `ConI`, we receive a `ConL`, for the first of the two merged `StoreI`. The second merged `StoreI` instead captures the state before the `StoreL`, and that is wrong.
> 
> **Solution**
> We should have some assert, that checks that the captured `field_val` corresponds to the expected `field_type`.
> 
> But the real fix was suggested by @merykitty : apparently he just had a similar issue in Valhalla:
> https://github.com/openjdk/valhalla/blame/60af17ff5995cfa5de075332355f7f475c163865/src/hotspot/share/opto/macro.cpp#L709-L713
> (the idea is to bail out of the elimination if any of the found stores are mismatched.)
> 
> **Details**
> 
> How the bad sequence develops, and which components are involved.
> 
> 1) The `SafePoint` contains a `ConL` and 3 `ConI`. (Correct would have been 4 `ConI`)
> 
>   6  ConI  === 23  [[ 4 ]]  #int:16777216
>   7  ConI  === 23  [[ 4 ]]  #int:256
>   8  ConI  === 23  [[ 4 ]]  #int:1048576
>   9  ConL  === 23  [[ 4 ]]  #long:68719476737
>  54  DefinitionSpillCopy  === _ 27  [[ 16 12 4 ]]
>   4  CallStaticJavaDirect  === 47 29 30 26 32 33 0 34 0 54 9 8 7 6  [[ 5 3 52 ]] Static wrapper for: uncommon_trap(reason='unstable_if' action='reinterpret' debug_id='0') # void ( int ) C=0.000100 Test::test @ bci:38 (line 21) reexecute !jvms: Test::test @ bci:38 (line 21)
> 
> 
> 2) This is then encoded into an `ObjectValue`. A `Type::Long` / `ConL` is converted into a `[int=0, long=ConL]` pair, see:
> https://github.com/openjdk/jdk/blob/da7121aff9eccb046b82a75093034f1cdbd9b9e4/src/hotspot/share/opto/output.cpp#L920-L925
> If I understand it right, there zero is just a placeholder.
> 
> And so we get:
> 
> (rr) p sv->print_fields_on(tty)
>         Fields: 0, 68719476737, 1048576, 256, 16777216
> 
> We can see the `zero`, followed by the `ConL`, and then 3 `ConI`.
> 
> This se...

This pull request has now been integrated.

Changeset: 09a047f0
Author:    Emanuel Peter <epeter at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09a047f00c88d14505c42a966dedbc87b9be5bdf
Stats:     375 lines in 5 files changed: 375 ins; 0 del; 0 mod

8370405: C2: mismatched store from MergeStores wrongly scalarized in allocation elimination

Co-authored-by: Olivier Mattmann <olivier.mattmann at bluewin.ch>
Co-authored-by: Quan Anh Mai <qamai at openjdk.org>
Reviewed-by: kvn, qamai

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

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

From epeter at openjdk.org  Mon Nov  3 06:58:18 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 3 Nov 2025 06:58:18 GMT
Subject: RFR: 8370405: C2: mismatched store from MergeStores wrongly
 scalarized in allocation elimination [v2]
In-Reply-To: <drAmXCIdBW6xwHm0yCu5Y9dBM4SGepVArVZGl_j9slM=.9827cfa5-b104-472a-875e-9a6ab227ea49@github.com>
References: <m9n_1TmV1cv2JTGSmuIjq7EqiC4Lsd_8m7Vg6XuVlh8=.8c341b0f-25e6-4a0d-ae1c-c74c1c1e7b50@github.com>
 <JWP6LaG4AYevOWbQhdqq8B9IeS9e9P4prxTMXlxPvyE=.d844c902-734e-43ab-9268-9dbdfc0173c7@github.com>
 <drAmXCIdBW6xwHm0yCu5Y9dBM4SGepVArVZGl_j9slM=.9827cfa5-b104-472a-875e-9a6ab227ea49@github.com>
Message-ID: <njCXqHeSmkKpnL4wfF5UHnFzA5YAaIsIiZvPjigXKLM=.61f90609-b51f-4aaf-9244-3f691109929f@github.com>

On Thu, 30 Oct 2025 07:03:51 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8370405-alloc-elimination-and-MergeStores
>>  - only verify primitive types
>>  - Apply suggestions from code review
>>  - more assert adjustment
>>  - ignore debug flag
>>  - id for tests, and fix up the assert
>>  - pass int for short slot
>>  - another test
>>  - improve test
>>  - wip new IR test
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6dd1ad30...b6e032c2
>
> Regardless, I think this patch makes sense. Bailing out of scalar elimination when we are doing it is better than when we are running EA, and we should generally try to do it if we can.

@merykitty @vnkozlov Thanks for the review and discussion!

@dougxc Thanks for checking for Graal and getting us a quick response :)

And thanks to Olivier Mattmann <[olivier.mattmann at bluewin.ch](mailto:olivier.mattmann at bluewin.ch)> for finding the bug!

@mhaessig I decided to file this RFE, in case someone wants to invest time in it:
[JDK-8371122](https://bugs.openjdk.org/browse/JDK-8371122) C2 Allocation Elimination: handle some mismatched accesses to arrays

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

PR Comment: https://git.openjdk.org/jdk/pull/27997#issuecomment-3479146291

From tschatzl at openjdk.org  Mon Nov  3 07:31:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Nov 2025 07:31:37 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates [v2]
In-Reply-To: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
References: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
Message-ID: <FLKti3NwN_nl_iD5jfAKZl5mV8n45JUv8Ny4Uy09SFI=.bd932271-ce3f-4582-b582-2effbd6218fb@github.com>

> Hi all,
> 
>   please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.
> 
> I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.
> 
> That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).
> 
> This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.
> 
> There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.
> 
> The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.
> 
> Testing: mentioned test case now behaving correctly, tier1-5
> 
> Thanks,
>   Thomas

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

  * walulyai review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27789/files
  - new: https://git.openjdk.org/jdk/pull/27789/files/c8aff5cb..b42f9b20

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

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

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

From jsikstro at openjdk.org  Mon Nov  3 07:53:38 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 3 Nov 2025 07:53:38 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v4]
In-Reply-To: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
Message-ID: <Futbxwin2-tzIyLKBUlTV9T0rqd2cOLWT6rtM39VKBk=.4083c9f1-2b2f-462e-9ef8-0ab372252c64@github.com>

> Hello,
> 
> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
> 
> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
> 
> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
> 
> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, there are trade-offs...

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

 - Merge branch 'master' into JDK-8370345_mutablenumaspace_tlab_accounting
 - Comment on unsafe_max_tlab_alloc alignment
 - unsafe_max_tlab_alloc must be aligned to MinObjAlignmentInBytes
 - 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27935/files
  - new: https://git.openjdk.org/jdk/pull/27935/files/c4cd91a8..0e79d823

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

  Stats: 62841 lines in 832 files changed: 34797 ins; 23295 del; 4749 mod
  Patch: https://git.openjdk.org/jdk/pull/27935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27935/head:pull/27935

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

From azafari at openjdk.org  Mon Nov  3 09:16:05 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 09:16:05 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v3]
In-Reply-To: <_zOzryyrcX3PRWGo7osHOKa9hHfWTsKUi_Sj_bhUMLo=.9c7313b8-268e-41b9-8567-325449c24784@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <_zOzryyrcX3PRWGo7osHOKa9hHfWTsKUi_Sj_bhUMLo=.9c7313b8-268e-41b9-8567-325449c24784@github.com>
Message-ID: <_5iAdylxNdYJ1Uq-_pSz1NUona3Io0P8Nt8MW8lN3Ao=.8264e2bc-c0c2-40ab-82da-2a6578f6ad4d@github.com>

On Mon, 15 Sep 2025 10:20:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   post-cond
>
> src/hotspot/share/oops/klass.hpp line 515:
> 
>> 513: 
>> 514:   // Want a pattern to quickly diff against layout header in register
>> 515:   // find something less clever!
> 
> Comment needs to be updated. It should describe what is being calculated, and the 2nd line
> is presumably resolved by this change.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2485780314

From iwalulya at openjdk.org  Mon Nov  3 09:29:10 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 3 Nov 2025 09:29:10 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates [v2]
In-Reply-To: <FLKti3NwN_nl_iD5jfAKZl5mV8n45JUv8Ny4Uy09SFI=.bd932271-ce3f-4582-b582-2effbd6218fb@github.com>
References: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
 <FLKti3NwN_nl_iD5jfAKZl5mV8n45JUv8Ny4Uy09SFI=.bd932271-ce3f-4582-b582-2effbd6218fb@github.com>
Message-ID: <ql1K2DRAqVrFvT2U282x_bZyU9aDscqyBtjFc9d0yuw=.9381ec3f-f03a-4e63-a10a-b4eb89209550@github.com>

On Mon, 3 Nov 2025 07:31:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.
>> 
>> I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.
>> 
>> That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).
>> 
>> This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.
>> 
>> There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.
>> 
>> The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.
>> 
>> Testing: mentioned test case now behaving correctly, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * walulyai review

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27789#pullrequestreview-3410126117

From azafari at openjdk.org  Mon Nov  3 09:29:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 09:29:28 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
Message-ID: <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>

> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue.
> 
> Tests:
>  mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product}

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

  comments and post-cond

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27288/files
  - new: https://git.openjdk.org/jdk/pull/27288/files/32db16d4..8a3d6d13

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

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

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

From jsikstro at openjdk.org  Mon Nov  3 09:34:23 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 3 Nov 2025 09:34:23 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v4]
In-Reply-To: <T-GJtti_DxJOaINYRg4Ne3LQOS0c2eUvAMCyes0UhC4=.5c6e9fb9-db1e-42c7-a18e-3b76efd3bcdc@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
 <JZlXmvc79AxZNq-kTpOFOcxq0htENPn6eTG1DJ3a0xU=.d9195708-6f44-44ca-9209-351d822c5909@github.com>
 <T-GJtti_DxJOaINYRg4Ne3LQOS0c2eUvAMCyes0UhC4=.5c6e9fb9-db1e-42c7-a18e-3b76efd3bcdc@github.com>
Message-ID: <sSDXl3J8n_GpHW9vyCkuGw3h8Hx1pTW-VraFzuhd9Gs=.24366168-2bfd-4065-8e2b-497467a640ff@github.com>

On Mon, 27 Oct 2025 11:38:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8370345_mutablenumaspace_tlab_accounting
>>  - Comment on unsafe_max_tlab_alloc alignment
>>  - unsafe_max_tlab_alloc must be aligned to MinObjAlignmentInBytes
>>  - 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
>
> Marked as reviewed by ayang (Reviewer).

Thank you for the reviews! @albertnetymk @walulyai
I re-ran testing locally tier1-3 after merging which looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/27935#issuecomment-3479622273

From jsikstro at openjdk.org  Mon Nov  3 09:34:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 3 Nov 2025 09:34:24 GMT
Subject: Integrated: 8370345: Parallel: Rework TLAB accounting in
 MutableNUMASpace
In-Reply-To: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
Message-ID: <JLP1-_iGb3ANO1WOWa0NHFb27NqhyT0zrVfNAbtqnRc=.65a02a9c-fa6b-4b51-96ec-e679b20f4729@github.com>

On Wed, 22 Oct 2025 08:56:22 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
> 
> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
> 
> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
> 
> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, there are trade-offs...

This pull request has now been integrated.

Changeset: 10ea585b
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10ea585b5ca01dc0136fe76a11109d0f17828772
Stats:     71 lines in 5 files changed: 24 ins; 23 del; 24 mod

8370345: Parallel: Rework TLAB accounting in MutableNUMASpace

Reviewed-by: ayang, iwalulya

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

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

From duke at openjdk.org  Mon Nov  3 09:41:26 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 3 Nov 2025 09:41:26 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v9]
In-Reply-To: <SNyc1Zec4JXuml-4sts3nnk3UN2tA2aC-N6m5rRpwCE=.0cdf1fc7-4318-465e-a0e5-feede1d828ff@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TLF2rmTMpYe6kfXCd_wVRURfWR_D1gZ7OV9snnFrfQk=.e0987e92-9ca4-41f0-ab6d-9543ca66e1d1@github.com>
 <tTgnPha4MRnzl0E8fTYS1CeZ94wkFUSyB58jA-rDYbg=.eb4f8355-bdd2-4328-af08-8b7def6ad33e@github.com>
 <SNyc1Zec4JXuml-4sts3nnk3UN2tA2aC-N6m5rRpwCE=.0cdf1fc7-4318-465e-a0e5-feede1d828ff@github.com>
Message-ID: <iwLh8k8YhYwZJjJMHkSRdMe9GNwuVzUlCgKAVYDiku8=.e19b2dfb-8970-4d69-b9a8-908ac250ea92@github.com>

On Sat, 1 Nov 2025 09:01:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Re: SafeFetch, it is probably OK to make NativePostCallNop_at slightly slower for uses like make_deoptimized(), but the oopmap optimizations like CodeCache::find_blob_and_oopmap() were highly optimized to make loom/VirtualThread performance reasonable.  Adding a SafeFetch here might cause a regression.
>
>> Re: SafeFetch, it is probably OK to make NativePostCallNop_at slightly slower for uses like make_deoptimized(), but the oopmap optimizations like CodeCache::find_blob_and_oopmap() were highly optimized to make loom/VirtualThread performance reasonable. Adding a SafeFetch here might cause a regression.
> 
> Sure, but 2 things:
> Loom doesn't meed post-call NOPs as much as it used to.
> We could fairly easily make SafeFetch much faster than it is, if needs be.
> But anyway, I approved this patch.

Thank you for the detailed advice, @theRealAph,

I now see how `SafeFetch` can be valuable independently of whether false-positive matches with the post-call NOP pattern can happen during normal execution. I hadn't considered the stack corruption use case before.

Reviewing the `SafeFetch` implementation, I believe in general case it relies on `sigsetjmp` on POSIX systems and exceptions on Windows.
However, for AArch64, the `SafeFetch32` has an optimized implementation - avoiding `setjmp` or exceptions overhead.
On the fast path, it performs just one load, so any extra performance cost would be due to that path cannot currently be inlined.

There indeed seems to be a way to have it inlined, at least on Linux - via creating an extra ELF section containing addresses of all inlined `SafeFetch` loads and corresponding continuation points, which the signal handler can iterate through. I've not prototyped this, but if feasible, it could make the performance impact of using `SafeFetch` negligible.

Since there isn't necessarily a consensus at this stage on whether `SafeFetch` should be added in this PR, I'd propose opening a separate JBS ticket for it to avoid blocking merge of the exception handler stub code cleanup.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3479653271

From fbredberg at openjdk.org  Mon Nov  3 10:05:35 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 3 Nov 2025 10:05:35 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v4]
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <Cm-LtASdiao6yU339p7msFgrLRytiTXEQ7w_GFPUlu4=.efbf9c02-157f-45e6-905d-caf314c4589c@github.com>

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
 - Update two, after the review
 - Update after review
 - Small arm32 fix
 - Small include line fix
 - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

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

Changes: https://git.openjdk.org/jdk/pull/27915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=03
  Stats: 2972 lines in 80 files changed: 1259 ins; 1425 del; 288 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

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

From alanb at openjdk.org  Mon Nov  3 11:05:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Nov 2025 11:05:05 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <qFhCkT3VEbdySmrc8DCuRhIVxB4IQGQA0eekexXil48=.2aa62e99-ba84-44f5-9f57-84d6fb1b17af@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104:

> 102:        * </pre></blockquote>
> 103:        *
> 104:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.

Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2486085650

From alanb at openjdk.org  Mon Nov  3 11:05:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Nov 2025 11:05:07 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <FvFvVFAL10Z13NMzVOWICfdAriP3g_FDASS1sjt6pIs=.f31d3133-8dfa-492f-ab04-377b2182489a@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
 <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
 <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>
 <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com>
 <FvFvVFAL10Z13NMzVOWICfdAriP3g_FDASS1sjt6pIs=.f31d3133-8dfa-492f-ab04-377b2182489a@github.com>
Message-ID: <8XzXNt3iOeijZtZWB_zdMoWLPadJkgEbmaoqZQjEH1A=.a9fca7c1-9e42-4209-b21f-08af5554d344@github.com>

On Wed, 29 Oct 2025 18:47:13 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> I see that now - fixing ....
>
> I also removed the nested {@code ..} from within the <pre\></pre\> as that also caused an issue

Good. You can move the example to a snippet too and that will  allow the `<pre>` tags to go away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2486086959

From egahlin at openjdk.org  Mon Nov  3 11:46:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 3 Nov 2025 11:46:04 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

Can this be done using a diagnostic command, e.g. AOT.stop? It would allow the recording to be stopped from jcmd and the DiagnosticCommandMBean, without the need for a separate MXBean.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3480099956

From tschatzl at openjdk.org  Mon Nov  3 14:47:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Nov 2025 14:47:39 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates [v2]
In-Reply-To: <ql1K2DRAqVrFvT2U282x_bZyU9aDscqyBtjFc9d0yuw=.9381ec3f-f03a-4e63-a10a-b4eb89209550@github.com>
References: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
 <FLKti3NwN_nl_iD5jfAKZl5mV8n45JUv8Ny4Uy09SFI=.bd932271-ce3f-4582-b582-2effbd6218fb@github.com>
 <ql1K2DRAqVrFvT2U282x_bZyU9aDscqyBtjFc9d0yuw=.9381ec3f-f03a-4e63-a10a-b4eb89209550@github.com>
Message-ID: <tjLORhBsSK8p8T1rlB3hDpSahsmRwMMckYvQ_wwUPcM=.66867e49-eeee-461b-93ef-deb3ac1c2ef1@github.com>

On Mon, 3 Nov 2025 09:26:49 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * walulyai review
>
> Marked as reviewed by iwalulya (Reviewer).

Thanks @walulyai @albertnetymk for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27789#issuecomment-3480915285

From tschatzl at openjdk.org  Mon Nov  3 14:47:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 3 Nov 2025 14:47:41 GMT
Subject: Integrated: 8369111: G1: Determining concurrent start uses
 inconsistent predicates
In-Reply-To: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
References: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
Message-ID: <jYC5QNREHM6IM8o1DgCVL7eh6GvMIlE3wTWWQnwSLcg=.3564feb6-922c-4f8b-ac1e-d3749d2b1a94@github.com>

On Tue, 14 Oct 2025 08:58:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.
> 
> I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.
> 
> That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).
> 
> This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.
> 
> There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.
> 
> The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.
> 
> Testing: mentioned test case now behaving correctly, tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 18e8873c
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18e8873cadf3900139a6555d4a228148a10d2009
Stats:     111 lines in 9 files changed: 35 ins; 8 del; 68 mod

8369111: G1: Determining concurrent start uses inconsistent predicates

Reviewed-by: iwalulya, ayang

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

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

From iwalulya at openjdk.org  Mon Nov  3 15:41:15 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 3 Nov 2025 15:41:15 GMT
Subject: RFR: 8370774: Merge ModRefBarrierSet into CardTableBarrierSet
In-Reply-To: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
References: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
Message-ID: <iqlAbtFHLv4GHJnbjhv_LDwjSo8lU0ZdtBjB_9rVXKY=.6ac926ba-3385-41b5-9a56-62942cebe5a0@github.com>

On Tue, 28 Oct 2025 09:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Merge a class into its sole subclass.
> 
> Many files are changed in this PR, and they can be largely divided into two groups, moving content of `ModRefBarrierSet` into `CardTableBarrierSet` (`src/hotspot/share/gc/`) and platform specific moving content of `ModRefBarrierSetAssembler` into `CardTableBarrierSetAssembler` (`src/hotspot/cpu/`).
> 
> Test: tier1-5 for x64 and aarch64; GHA

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28013#pullrequestreview-3411621214

From duke at openjdk.org  Mon Nov  3 16:10:16 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 3 Nov 2025 16:10:16 GMT
Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1
 volatile field loads [v2]
In-Reply-To: <rkSInDDKHPJxR-E5iJRzlTvwRx3Y7bR9TFTTnnmO1ng=.5da25214-c0b0-4667-ba93-567a46a9c998@github.com>
References: <p7XaTTrJZA65XAB3EoXH_cI34eOKXcSaPozylNiWMss=.4b218507-adbd-4351-996f-88f1c38f5f18@github.com>
 <OQLPzrNubg-pVrE0zS5yVSq9eNDA_kkP40IUR55SAfg=.abfcbcf1-3ed5-4729-b590-ddde46800d89@github.com>
 <rkSInDDKHPJxR-E5iJRzlTvwRx3Y7bR9TFTTnnmO1ng=.5da25214-c0b0-4667-ba93-567a46a9c998@github.com>
Message-ID: <hRCYhdN6OU-F8pMs3qkHhB1hqCDVT4GCcGgVprt2IQQ=.66b2cf27-7a56-4779-bc68-e66f7525ae44@github.com>

On Tue, 7 Oct 2025 10:14:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Samuel Chee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>    
>>    Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd
>>  - Refine code generation for mem2reg_volatile
>>    
>>    The patch is contributed by @theRealAph.
>>    
>>    Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586
>
>> See #27432
> 
> Now that this is integrated, you may proceed.
> 
> Will you also proceed with [8360654](https://github.com/openjdk/jdk/pull/26000)?

Hi @theRealAph,
I've pushed changes for this PR to a new branch https://github.com/openjdk/jdk/compare/master...ruben-arm:jdk:pr-8365147 as Samuel is currently not available. Once he is back, he can update this PR's branch.
In the meanwhile, I'm planning to run more of the `jcstress` testing. I'd appreciate your feedback on the version in the new branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3481304989

From fbredberg at openjdk.org  Mon Nov  3 16:24:32 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 3 Nov 2025 16:24:32 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
Message-ID: <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>

On Thu, 30 Oct 2025 15:54:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment and assert msg

A truly useful enhancement! Just had a few questions / suggestions.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 762:

> 760:   load_const_optimized(bad, 0xbad0101babe00000);
> 761:   for (uint32_t i = 1; i < (sizeof(regs) / sizeof(Register)); i++) {
> 762:     addi(regs[i], regs[0], regs[i]->encoding());

Guess it's a question for @reinrich, but why set up `bad = regs[0]` and then still use `regs[0]` instead of `bad`? 
I think using `bad` would make the code easier to understand than using `regs[0]`.
Suggestion:

    addi(regs[i], bad, regs[i]->encoding());

src/hotspot/share/interpreter/linkResolver.cpp line 1689:

> 1687:   EXCEPTION_MARK;
> 1688:   CallInfo info;
> 1689:   resolve_static_call(info, link_info, ClassInitMode::dont_init, THREAD);

Couldn't you just do `CHECK_AND_CLEAR_NULL` and skip the following `if (HAS_PENDING_EXCEPTION)` statement?

Suggestion:

  resolve_static_call(info, link_info, ClassInitMode::dont_init, CHECK_AND_CLEAR_NULL);

I see the same in functions both above and below this one, is there any reason for this?

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

Marked as reviewed by fbredberg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3411212227
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487050754
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2486618754

From pchilanomate at openjdk.org  Mon Nov  3 16:49:12 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 16:49:12 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
Message-ID: <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>

On Thu, 30 Oct 2025 22:47:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug number in tests
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Fix looks good to me. Only have some comments about the JVMTI agent case, thanks.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 53:

> 51: #endif
> 52: 
> 53:   bool agents_loaded = JvmtiAgentList::has_agents();

I see that for dynamically loaded agents we add to the list after loading the agent. Maybe we should check `JvmtiEnvBase::environments_might_exist()`?

src/hotspot/share/prims/scopedMemoryAccess.cpp line 94:

> 92: 
> 93: static bool is_accessing_session(JavaThread* jt, oop session, bool& in_scoped) {
> 94:   if (jt->is_throwing_unsafe_access_error()) {

If we assume arbitrary Java code in JVMTI callbacks this might return true but the target could be in a different nested scoped access. I think we should check we are in the no agent case before bailing out.

src/hotspot/share/runtime/javaThread.hpp line 1364:

> 1362:   JavaThread* _thread;
> 1363: public:
> 1364:   ThrowingUnsafeAccessError(JavaThread* thread) : _thread(thread) {

If we assume arbitrary Java code in JVMTI callbacks this could be executed recursively and `_throwing_unsafe_access_error` be set to false while we are within the outer caller. Although it?s fine since we will do a full stack walk in `is_accessing_session`, we should add a comment why this recursive case is okay (or save the old value as with `UnlockFlagSaver`).

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

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3411931601
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487147887
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487150214
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487152847

From egahlin at openjdk.org  Mon Nov  3 17:02:33 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 3 Nov 2025 17:02:33 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
Message-ID: <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>

On Sat, 1 Nov 2025 11:45:27 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> > It would be good if you could provide some ballpark figures on the number of events in a worst-case scenario, so we can determine what GC level is appropriate.
> 
> I wrote a simple pathological test with multiple threads interning random strings, [this](https://github.com/user-attachments/files/23282465/out-parallel.txt) is the worst I've seen: 100 deduplication rounds within `3.698s` and `3.729s`.

Thanks for investigating this. It doesn't sound that bad, the event could probably be enabled by default. The elapsed fields, are they the total since the JVM started or from the last round?

We typically try to avoid using "Bytes" in field names, since that information is already available in the content type. Perhaps something else could be used, newSize?

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

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3481567424

From jvernee at openjdk.org  Mon Nov  3 17:27:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Nov 2025 17:27:51 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
 <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
Message-ID: <wc9AKkQdn5XPWl1uDJJ96_UK4txqrhUx2-tIfVqfFYU=.2c930d46-2cca-4bd7-a2df-2a830e48729e@github.com>

On Mon, 3 Nov 2025 16:40:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug number in tests
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 94:
> 
>> 92: 
>> 93: static bool is_accessing_session(JavaThread* jt, oop session, bool& in_scoped) {
>> 94:   if (jt->is_throwing_unsafe_access_error()) {
> 
> If we assume arbitrary Java code in JVMTI callbacks this might return true but the target could be in a different nested scoped access. I think we should check we are in the no agent case before bailing out.

My assumption is that once an unsafe access error is thrown, we don't expect execution to continue. I suppose it is technically possible to catch the exception, either in Java code or in the native agent code, and then try to continue execution, but the program would be in an undefined state at that point already. In other words, I don't think anyone should be continuing execution after this exception happens.

Although, it doesn't seem like a bad idea to keep walking here as a fail safe.

> src/hotspot/share/runtime/javaThread.hpp line 1364:
> 
>> 1362:   JavaThread* _thread;
>> 1363: public:
>> 1364:   ThrowingUnsafeAccessError(JavaThread* thread) : _thread(thread) {
> 
> If we assume arbitrary Java code in JVMTI callbacks this could be executed recursively and `_throwing_unsafe_access_error` be set to false while we are within the outer caller. Although it?s fine since we will do a full stack walk in `is_accessing_session`, we should add a comment why this recursive case is okay (or save the old value as with `UnlockFlagSaver`).

That's a good point. Since this is otherwise unrelated code, I'll make it safe for the re-entrant case as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487300422
PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487303301

From jvernee at openjdk.org  Mon Nov  3 17:30:46 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Nov 2025 17:30:46 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
 <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
Message-ID: <Y1RX9Z66oh6zBx-R1qpxgKUWY7gnRsJearZkyGyVoDg=.b20194ab-e028-4e72-a38b-c177b315c690@github.com>

On Mon, 3 Nov 2025 16:39:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update bug number in tests
>>   
>>   Co-authored-by: Chen Liang <liach at openjdk.org>
>
> src/hotspot/share/prims/scopedMemoryAccess.cpp line 53:
> 
>> 51: #endif
>> 52: 
>> 53:   bool agents_loaded = JvmtiAgentList::has_agents();
> 
> I see that for dynamically loaded agents we add to the list after loading the agent. Maybe we should check `JvmtiEnvBase::environments_might_exist()`?

Ah, thanks for the suggestion. I thought there might have been a way to check this already, but I couldn't find it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487315255

From kbarrett at openjdk.org  Mon Nov  3 18:09:19 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 3 Nov 2025 18:09:19 GMT
Subject: RFR: 8371104: gtests should use wrappers for <limits> and
 <type_traits>
Message-ID: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>

Please review this trivial change, updating HotSpot gtests to include the new
cppstdlib/{limits,type_traits}.hpp wrappers instead of including the Standard
Library headers directly.

Testing: mach5 tier1

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

Commit messages:
 - use type_traits wrapper
 - use limits wrapper

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

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

From jvernee at openjdk.org  Mon Nov  3 18:29:43 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 3 Nov 2025 18:29:43 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
Message-ID: <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Review comments Patricio

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27919/files
  - new: https://git.openjdk.org/jdk/pull/27919/files/7a793468..9e7e59b8

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

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

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

From rrich at openjdk.org  Mon Nov  3 18:33:52 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 3 Nov 2025 18:33:52 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
Message-ID: <KWU0IKs1p_d8pneJNoXJUq_btwtXVmAoHgh3SBIUYTw=.3f8c5c6f-9b22-4976-a7bb-c3819c6fac38@github.com>

On Mon, 3 Nov 2025 16:11:38 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment and assert msg
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 762:
> 
>> 760:   load_const_optimized(bad, 0xbad0101babe00000);
>> 761:   for (uint32_t i = 1; i < (sizeof(regs) / sizeof(Register)); i++) {
>> 762:     addi(regs[i], regs[0], regs[i]->encoding());
> 
> Guess it's a question for @reinrich, but why set up `bad = regs[0]` and then still use `regs[0]` instead of `bad`? 
> I think using `bad` would make the code easier to understand than using `regs[0]`.
> Suggestion:
> 
>     addi(regs[i], bad, regs[i]->encoding());

Thanks for looking at the ppc part @fbredber 
Your suggestion is good. I think the loop should be reversed too. Then the addi after it can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487475002

From rrich at openjdk.org  Mon Nov  3 18:38:06 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 3 Nov 2025 18:38:06 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
Message-ID: <RvS8-qNisqNghcBV_fQ8tKBuABKyVRF49jMxsC8XogA=.5a3376df-e4dc-40ce-bedb-836c77deaf56@github.com>

On Thu, 30 Oct 2025 15:54:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment and assert msg

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 764:

> 762:     addi(regs[i], regs[0], regs[i]->encoding());
> 763:   }
> 764:   addi(regs[0], regs[0], regs[0]->encoding());

Based on @fbredber's suggestion:
Suggestion:

  load_const_optimized(bad, 0xbad0101babe00000);
  for (int i = (sizeof(regs) / sizeof(Register)) - 1; i >= 0; i--) {
    addi(regs[i], bad, regs[i]->encoding());
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487483352

From pchilanomate at openjdk.org  Mon Nov  3 18:54:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 18:54:15 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
Message-ID: <-FOyxYPMnMfseoEVE0gqhuWFKT2s04ZLcKvyKF28zwE=.2c7eef23-1b9a-4339-89c6-58117a625848@github.com>

On Mon, 3 Nov 2025 16:22:13 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> A truly useful enhancement! Just had a few questions / suggestions.
>
Thanks for the review Fred!

> src/hotspot/share/interpreter/linkResolver.cpp line 1689:
> 
>> 1687:   EXCEPTION_MARK;
>> 1688:   CallInfo info;
>> 1689:   resolve_static_call(info, link_info, ClassInitMode::dont_init, THREAD);
> 
> Couldn't you just do `CHECK_AND_CLEAR_NULL` and skip the following `if (HAS_PENDING_EXCEPTION)` statement?
> 
> Suggestion:
> 
>   resolve_static_call(info, link_info, ClassInitMode::dont_init, CHECK_AND_CLEAR_NULL);
> 
> I see the same in functions both above and below this one, is there any reason for this?

Yes, I agree. I see there are a couple of instances of this pattern in this file as you point out, so if you are okay I?d prefer to file a separate bug to clean them all up together.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3482021139
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487524814

From pchilanomate at openjdk.org  Mon Nov  3 19:03:07 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:03:07 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

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

  Suggested fix in macroAssembler_ppc.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/ffcd92a6..4dff05a8

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

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

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

From pchilanomate at openjdk.org  Mon Nov  3 19:03:08 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:03:08 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <RvS8-qNisqNghcBV_fQ8tKBuABKyVRF49jMxsC8XogA=.5a3376df-e4dc-40ce-bedb-836c77deaf56@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <RvS8-qNisqNghcBV_fQ8tKBuABKyVRF49jMxsC8XogA=.5a3376df-e4dc-40ce-bedb-836c77deaf56@github.com>
Message-ID: <oqP5lvEv9ruXBE8ioohHijsgqB5ryRZgreLn6y3YJ-Y=.57206e3c-c712-48f9-bc37-fb57b549e992@github.com>

On Mon, 3 Nov 2025 18:34:59 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment and assert msg
>
> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 764:
> 
>> 762:     addi(regs[i], regs[0], regs[i]->encoding());
>> 763:   }
>> 764:   addi(regs[0], regs[0], regs[0]->encoding());
> 
> Based on @fbredber's suggestion:
> Suggestion:
> 
>   load_const_optimized(bad, 0xbad0101babe00000);
>   for (int i = (sizeof(regs) / sizeof(Register)) - 1; i >= 0; i--) {
>     addi(regs[i], bad, regs[i]->encoding());
>   }

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2487538760

From pchilanomate at openjdk.org  Mon Nov  3 19:46:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:46:11 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
Message-ID: <xefjJ4TIiyCSXHRFFlG7HnrRk1LWhWIlyiglZYHLAf8=.bcfe1a6d-2458-4c98-897e-ee0ca8ca2bf2@github.com>

On Mon, 3 Nov 2025 18:29:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments Patricio

Fix looks good to me, thanks!

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27919#pullrequestreview-3412633838

From pchilanomate at openjdk.org  Mon Nov  3 19:46:13 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 3 Nov 2025 19:46:13 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v5]
In-Reply-To: <wc9AKkQdn5XPWl1uDJJ96_UK4txqrhUx2-tIfVqfFYU=.2c930d46-2cca-4bd7-a2df-2a830e48729e@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <erby5LUW_c3mxbTY1ROQb5BMVYkarXxaOuA30i2tY8o=.0041c7cf-0f4e-45cd-83c2-021558e64517@github.com>
 <nGGrGFalSiDdMsHB7qnmAhqOC4tKmanFYZoM5UEzOQI=.89ef612b-3c7f-493b-b9bb-a11a0abf5f74@github.com>
 <wc9AKkQdn5XPWl1uDJJ96_UK4txqrhUx2-tIfVqfFYU=.2c930d46-2cca-4bd7-a2df-2a830e48729e@github.com>
Message-ID: <LrtVJifqupZEPTTFjyyBw9uKGryGDHsAj9n8UEUwQAU=.6bc353c6-9183-4cee-b01d-ae782e1dd6f4@github.com>

On Mon, 3 Nov 2025 17:24:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> My assumption is that once an unsafe access error is thrown, we don't expect execution to continue. I suppose it is technically possible to catch the exception, either in Java code or in the native agent code, and then try to continue execution, but the program would be in an undefined state at that point already. In other words, I don't think anyone should be continuing execution after this exception happens.
>
Yes, makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27919#discussion_r2487654019

From macarte at openjdk.org  Mon Nov  3 20:08:22 2025
From: macarte at openjdk.org (Mat Carter)
Date: Mon, 3 Nov 2025 20:08:22 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
 <3w1fRC9HqhTnBzUPCsGGsw0q8H-wcY-km96h5W0S3To=.28f02299-e10b-4a20-a407-1a208e764a75@github.com>
Message-ID: <ul3465RuqLeBGnl4bn0RPmrvhrFY0k1uCV_hT3tWgSk=.1708b2a8-62d5-43bd-a813-a4b568156273@github.com>

On Mon, 3 Nov 2025 11:42:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Can this be done using a diagnostic command, e.g. AOT.stop? It would allow the recording to be stopped from jcmd and the DiagnosticCommandMBean, without the need for a separate MXBean.

Thank you for the suggestion

To answer your first question, we do have a diagnostic command (AOT.end_recording) and it would precede the AOT MXBean into mainline and it's PR is here: https://github.com/openjdk/jdk/pull/27965

The longer goal for this MXBean is to provide additional methods that would aid in monitoring (isRecording, currentRecordingLength etc.), however we decided to reduce the scope of the MXBean for main line while we continue to test the monitoring functionality in leyden/premain

Historically the diagnostic command came after the MXBean in leyden/premain, however I decided to implement the diagnostic command with the necessary JVM hooks first to simplify review

So technically we could delay this PR and still have the required functionality in mainline, I'd like to hear from the other reviewers on this matter

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3482353337

From eosterlund at openjdk.org  Mon Nov  3 21:10:00 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 3 Nov 2025 21:10:00 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
 <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
Message-ID: <dVfOLhSkfBz7zhE4EEqyX3Q7kAkKJ4Os4D-Enyqqsdg=.a37cc396-4514-4642-9510-7b8be901fddc@github.com>

On Thu, 23 Oct 2025 16:06:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
>> 
>> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.
>
>> > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
>> 
>> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.
> 
> We have 
> 
> 
> #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)
> #define INCLUDE_CDS_JAVA_HEAP 1
> 
> 
> So we need to make sure it works for 32 bit as well.

@iklam does this look okay now?

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3482604226

From heidinga at openjdk.org  Mon Nov  3 21:35:01 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 3 Nov 2025 21:35:01 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <qFhCkT3VEbdySmrc8DCuRhIVxB4IQGQA0eekexXil48=.2aa62e99-ba84-44f5-9f57-84d6fb1b17af@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
 <qFhCkT3VEbdySmrc8DCuRhIVxB4IQGQA0eekexXil48=.2aa62e99-ba84-44f5-9f57-84d6fb1b17af@github.com>
Message-ID: <6LpN0Ae8kfDApFOPUYrbdqz2fRh8HVvvbCa8kiEEFS0=.31761484-c4c1-428c-9974-d2bdec3b587d@github.com>

On Mon, 3 Nov 2025 11:01:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test based on comments
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 104:
> 
>> 102:        * </pre></blockquote>
>> 103:        *
>> 104:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.
> 
> Someone is bound to ask what happens if the "endRecording" operation is performed concurrently and there is recording in progress. Does one or all return true? I don't think it matters, the bigger issue here is that returning false means the recording has already ended or it failed. If it failed, why did it fail? I realize the intention is to add some properties and further operations to this MXBean but I think it would be good to think through if starting with a boolean returning operation is going to be problematic in the future.

I see a couple of cases for when `endRecording` is called:
1) Within the same process to generate a cache - given the api will only return `true` to one caller, that caller is the only one who can be responsible for taking further action (copying the cache somewhere, etc).  Already ended or failed makes no difference operationally.

2) From a monitoring process - again only the successful case matters.  All failures (already ended or failed) are indistinguishable.  No further action can be taken by the observer.  It's only the success case that matters

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2487912197

From iklam at openjdk.org  Tue Nov  4 00:09:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 00:09:15 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v14]
In-Reply-To: <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
Message-ID: <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>

On Thu, 30 Oct 2025 08:43:45 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update

The updated version looks good to me.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3413414459

From duke at openjdk.org  Tue Nov  4 00:11:20 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Nov 2025 00:11:20 GMT
Subject: Withdrawn: 8354555: Add generic JFR events for TaskTerminator
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <6C63KrwSNS7jTc5SHtpknktCbt6kCAx12FM6NDEDPt8=.0da94a30-3bae-40ac-b4c0-a40b55876123@github.com>

On Wed, 16 Apr 2025 08:24:15 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
> 
> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
> 
> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
> 
> For the test, I have manually tested different GCs with Flight Recording enabled and verified the events:
> G1:
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0108 ms
>   gcId = 0
>   gcWorkerId = 8
>   name = "Termination"
>   eventThread = "GC Thread#4" (osThreadId = 20483)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0467 ms
>   gcId = 0
>   gcWorkerId = 2
>   name = "Termination"
>   eventThread = "GC Thread#2" (osThreadId = 21251)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:34.124 (2025-05-22)
>   duration = 0.0474 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination"
>   eventThread = "GC Thread#8" (osThreadId = 36359)
> }
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000834 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:09:41.925 (2025-05-22)
>   duration = 0.000166 ms
>   gcId = 14
>   gcWorkerId = 7
>   name = "Termination: Parallel Marking"
>   eventThread = "GC Thread#1" (osThreadId = 21507)
> }
> 
> 
> Shenandoah: 
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0202 ms
>   gcId = 0
>   gcWorkerId = 0
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#3" (osThreadId = 13827)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0205 ms
>   gcId = 0
>   gcWorkerId = 1
>   name = "Termination: Concurrent Mark"
>   eventThread = "Shenandoah GC Threads#1" (osThreadId = 14339)
> }
> 
> jdk.GCPhaseParallel {
>   startTime = 23:39:58.890 (2025-05-22)
>   duration = 0.0127 ms
>   gcId = 0
>   gcWorkerId = 5
>   name = "Termination: Final Mark"
>   eventThread = "Shenandoah G...

This pull request has been closed without being integrated.

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

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

From kbarrett at openjdk.org  Tue Nov  4 04:29:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Nov 2025 04:29:12 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>
Message-ID: <Zvkwt1iR2wEHvg13gFQi6hfMlU9xeWNgndw0WYvbW-o=.84a9841c-3cf8-42cd-8c5b-5328309920a2@github.com>

On Mon, 3 Nov 2025 09:29:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue.
>> 
>> Tests:
>>  mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product}
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments and post-cond

src/hotspot/share/oops/klass.hpp line 514:

> 512:   }
> 513: 
> 514:   // Find the right-most non-zero (e.g., ...1000) bit of the diff of array-of-boolean and array-of-byte layout helpers.

Callers don't care whether it's the rightmost bit, only that it's a single
bit. (Some callers use log2_exact to get the bit position.) So a more
pedantically correct description might be something like "Return a value
containing a single set bit that is in the bitset difference between the
layout helpers for array-of-boolean and array-of-byte."

src/hotspot/share/oops/klass.hpp line 525:

> 523:     // So use alternate form of negation to avoid warning.
> 524:     uint result = candidates & (~candidates + 1);
> 525:     assert(((result - 1) & result) == 0, "post-condition");

Use `power_of_2(result)`.  For completeness, also consider checking other post-conditions - result is set
in zlh and clear in blh.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2488596063
PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2488602736

From kbarrett at openjdk.org  Tue Nov  4 04:29:13 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Nov 2025 04:29:13 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <rX_0t2D2dF27V0h1fCxFEJPY66_aWjl3gxaOcKxLj8I=.cdcc1a01-2b1e-4ad3-91ed-7b87c56ae390@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <rX_0t2D2dF27V0h1fCxFEJPY66_aWjl3gxaOcKxLj8I=.cdcc1a01-2b1e-4ad3-91ed-7b87c56ae390@github.com>
Message-ID: <CF0Zu9iLi22KTcWJ_D94efRgjoLrNkqw8ueI8EbwtEk=.9dd99110-4010-47b2-88c7-5c969fffb8c7@github.com>

On Mon, 15 Sep 2025 19:10:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments and post-cond
>
> src/hotspot/share/oops/klass.hpp line 518:
> 
>> 516:   static int layout_helper_boolean_diffbit() {
>> 517:     uint zlh = checked_cast<uint>(array_layout_helper(T_BOOLEAN));
>> 518:     uint blh = checked_cast<uint>(array_layout_helper(T_BYTE));
> 
> Use of check_cast is probably wrong. I think an alh is negative. Oops, my mistake. It probably doesn't fail currently because of [JDK-8314258](https://bugs.openjdk.org/browse/JDK-8314258).

Note that by "my mistake" I meant it was a mistake to use `checked_cast` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2488603639

From amitkumar at openjdk.org  Tue Nov  4 05:02:17 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 4 Nov 2025 05:02:17 GMT
Subject: RFR: 8370871: [s390x] consistently update top_frame_sp [v2]
In-Reply-To: <RECvq3eN4_lbuD_mM6e6SxX2ZZfkaw7zB4nkp7OHVK8=.ca5d3ed9-1885-4831-88d4-183f6745e2f7@github.com>
References: <wKwHXS_yLDQbibMRJJFgv_g7VyaiqycRt8oSRwb3apI=.6fd7e15f-55b7-4e09-bdde-e5499e55ec15@github.com>
 <RECvq3eN4_lbuD_mM6e6SxX2ZZfkaw7zB4nkp7OHVK8=.ca5d3ed9-1885-4831-88d4-183f6745e2f7@github.com>
Message-ID: <UxA5_RsUulYTe-eT4h2jiGiGZrZk-IhmJ8gBbrldctA=.65a73bb8-313a-4dd0-b588-668823872785@github.com>

On Thu, 30 Oct 2025 06:48:43 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Stores top_frame_sp for interpreter frames consistently. Although this is making one to assert fail in loom port but still I think this should be considered independent bug.
>> 
>> Changes in `generate_throw_exception` also helped with another issue in loom which was resolved by this workaround: https://github.com/offamitkumar/jdk/blob/5cb1322f58a4c676aac59244dcb62d8b67f0ed93/src/hotspot/cpu/s390/continuationFreezeThaw_s390.inline.hpp#L302C1-L318C2, issue: 
>> 
>> In `BasicExt.java` testcase there are two subtests : 
>> ```java 
>>         new Continuation3Frames(TestCaseVariants.THROW_HANDLED_EXCEPTION).runTestCase(4, compPolicy);
>>         new Continuation3Frames(TestCaseVariants.THROW_UNHANDLED_EXCEPTION).runTestCase(4, compPolicy);
>> 
>> 
>> these two testcase were failing because we were overwriting the interpreter frame content as we have to make the native call which saves the register from r6 to r15. So at that time the workaround was necessary, but it turns out that using `top_frame_sp` to extend the frame will fix the overwriting issue.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding assert and frame extension for exception

Thanks for the reviews and approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/28042#issuecomment-3483862621

From amitkumar at openjdk.org  Tue Nov  4 05:02:18 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 4 Nov 2025 05:02:18 GMT
Subject: Integrated: 8370871: [s390x] consistently update top_frame_sp
In-Reply-To: <wKwHXS_yLDQbibMRJJFgv_g7VyaiqycRt8oSRwb3apI=.6fd7e15f-55b7-4e09-bdde-e5499e55ec15@github.com>
References: <wKwHXS_yLDQbibMRJJFgv_g7VyaiqycRt8oSRwb3apI=.6fd7e15f-55b7-4e09-bdde-e5499e55ec15@github.com>
Message-ID: <x1ObvlMN_ejxfoRBaBWOVFLHYcQGPJ-K-YeS4--rbXk=.7acf1204-9679-4c68-b89a-0a4c6822792a@github.com>

On Wed, 29 Oct 2025 09:40:34 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Stores top_frame_sp for interpreter frames consistently. Although this is making one to assert fail in loom port but still I think this should be considered independent bug.
> 
> Changes in `generate_throw_exception` also helped with another issue in loom which was resolved by this workaround: https://github.com/offamitkumar/jdk/blob/5cb1322f58a4c676aac59244dcb62d8b67f0ed93/src/hotspot/cpu/s390/continuationFreezeThaw_s390.inline.hpp#L302C1-L318C2, issue: 
> 
> In `BasicExt.java` testcase there are two subtests : 
> ```java 
>         new Continuation3Frames(TestCaseVariants.THROW_HANDLED_EXCEPTION).runTestCase(4, compPolicy);
>         new Continuation3Frames(TestCaseVariants.THROW_UNHANDLED_EXCEPTION).runTestCase(4, compPolicy);
> 
> 
> these two testcase were failing because we were overwriting the interpreter frame content as we have to make the native call which saves the register from r6 to r15. So at that time the workaround was necessary, but it turns out that using `top_frame_sp` to extend the frame will fix the overwriting issue.

This pull request has now been integrated.

Changeset: 50bb92a3
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50bb92a33b32778a96b1823ff995889892bef890
Stats:     37 lines in 2 files changed: 32 ins; 0 del; 5 mod

8370871: [s390x] consistently update top_frame_sp

Reviewed-by: rrich, lucy

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

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

From eosterlund at openjdk.org  Tue Nov  4 05:14:05 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 4 Nov 2025 05:14:05 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v14]
In-Reply-To: <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
 <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>
Message-ID: <Mk5bbH-TwIBNoJ05BedvJPgBJNXMZ_9XH9knqJbdMew=.77f2c317-0f4c-4e37-8724-dcb7f6ddfa2d@github.com>

On Tue, 4 Nov 2025 00:05:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The updated version looks good to me.

Thank you for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3483893308

From amitkumar at openjdk.org  Tue Nov  4 05:20:15 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 4 Nov 2025 05:20:15 GMT
Subject: RFR: 8371188: [s390x] Un-ProblemList TestUnreachableInnerLoop.java
Message-ID: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>

Trivial change,
After [JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981) delivery test is now passing on s390x. So It can be removed from the problemlist.

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

Commit messages:
 - remove

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

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

From sgehwolf at openjdk.org  Tue Nov  4 07:09:47 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Nov 2025 07:09:47 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <BghgrFW1h0BM6Ss32Yzjwgb17plt8WN7FM8jNxAczgY=.e09d0ca9-9056-4b59-ace8-228e9fe650b3@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
 <oCHtTEO1QOxzB_wco1VSn_gv2NkUSbl8nsOUlnyK6-Q=.1ca20a9c-3717-45df-8991-cb7e1074c6b1@github.com>
 <DkPhrXwWHHptnQ50THfxKiJatf5-c7WOa67JW1IbXt8=.57054308-bfb9-4161-b476-cb2fd700d0e4@github.com>
 <InCQThI0WDqMUyk9_be7xVI4b_01G-fqVF1kmL87fFQ=.da75341f-01b4-4330-bcf3-2f2ead79fe29@github.com>
 <9uVKpiWCXvxcxhyg6V1seeSxyLm14lHEdOL_I07uVQs=.de1b0ed8-d006-49d5-a982-27556759415e@github.com>
 <BghgrFW1h0BM6Ss32Yzjwgb17plt8WN7FM8jNxAczgY=.e09d0ca9-9056-4b59-ace8-228e9fe650b3@github.com>
Message-ID: <REF4gCsr9gTLAgAm06ipMmCQH_v9wYBldXnEhUOBkhM=.a915f9d9-7a9b-4889-861b-c219eb86448d@github.com>

On Mon, 27 Oct 2025 09:17:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > it wasn't because we wanted to figure out the color of the bike shed but rather how to write safer code that makes it less likely to accidentally introduce bugs because of type conflation.
> 
> This. A function that returns its value as a side effect on a reference parameter is (at best) a code smell.

Thanks for the comments. So what's the consensus then? As far as API surface is concerned I've modelled it after [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). It [introduces](https://github.com/openjdk/jdk/commit/d5d94db12a6d82a6fe9da18b5f8ce3733a6ee7e7) the side-effect/code smell issue. Do we want to re-open this discussion or proceed with this here. It's not clear to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3469549344

From duke at openjdk.org  Tue Nov  4 07:14:09 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 07:14:09 GMT
Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE
 [v2]
In-Reply-To: <1rP2ebDy2PFLeEq4lYTks0cHZsvBKJsZFPtVZPsbH_g=.8aa13828-9eb6-4607-821d-9bbc7bd286a1@github.com>
References: <VmD1YkLtZRxhBpF5lwqMltlfjtQk0D78hoHJsN-Zjrs=.63276c32-8f28-4e60-becd-55581c2b2c5d@github.com>
 <hEx-2kQxttKtQD4SKud4ceKGZq9uK2ZSSqKCXjGsOz0=.f6468cb9-c462-44a8-9da0-e2ff90876af3@github.com>
 <8nJUYG6FECEghybXRFfeIsA0R9paX_AFr5IgiGO6Trs=.a3f75a8f-421d-4da8-9c53-03064a397b2b@github.com>
 <1rP2ebDy2PFLeEq4lYTks0cHZsvBKJsZFPtVZPsbH_g=.8aa13828-9eb6-4607-821d-9bbc7bd286a1@github.com>
Message-ID: <bI074iufimEc9XTicBInuIU0AV7jlwLMsFAUE9WDdsw=.a2180d57-368a-42a8-a2ea-7416dde5dd84@github.com>

On Thu, 21 Aug 2025 08:13:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> You're right, it is a little inaccurate to use the Java API to determine what `cmpxchgptr` does. Although the original intent to remove the membar is still functionality correct.
>> 
>> Although looking into it more, it seems that `cmpxchgptr` can now be removed completely. The recent PR https://github.com/openjdk/jdk/pull/26594 removed two of its call sites, and the only other existing one is within `MacroAssembler::cmpxchg_obj_header` - a method which never gets called to.
>> 
>> So I propose:
>> - We close this pr
>> - Open new one which removes the methods `MacroAssembler::cmpxchg_obj_header`, `MacroAssembler::cmpxchgptr` and `MacroAssembler::cmpxchgw` completely since they are no longer called to from anywhere.
>
>> * We close this pr
>> 
>> * Open new one which removes the methods `MacroAssembler::cmpxchg_obj_header`, `MacroAssembler::cmpxchgptr` and `MacroAssembler::cmpxchgw` completely since they are no longer called to from anywhere.
> 
> If you like, although we can (and we should) tidy up as we go along.

Hi @theRealAph,
I've pushed changes to remove the unused cmpxchg* functions to https://github.com/openjdk/jdk/compare/master...ruben-arm:jdk:pr-8365799 as Samuel is currently not available. Once he is back, he can update this PR's branch.
However, as this is a different scope from the original JBS ticket https://bugs.openjdk.org/browse/JDK-8365799, should we create a new one?

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

PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3481358544

From ysuenaga at openjdk.org  Tue Nov  4 07:41:13 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 4 Nov 2025 07:41:13 GMT
Subject: RFR: 8371093: Assert "section header string table should be loaded"
 failed on debug VM
Message-ID: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>

When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))


Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [linux-vdso.so.1+0xe69]
[error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]

Retrying call stack printing without source information...

[error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]


When I checked back trace on GDB, it failed at `assert`.

#12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
    line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
    detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
#13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
#14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407



(gdb) f 13
#13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
536 assert(false, "section header string table should be loaded");


vDSO is not a regular ELF, so it should be skipped here.

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

Commit messages:
 - 8371093: Assert "section header string table should be loaded" failed on debug VM

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

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

From duke at openjdk.org  Tue Nov  4 08:34:34 2025
From: duke at openjdk.org (walkertest)
Date: Tue, 4 Nov 2025 08:34:34 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v12]
In-Reply-To: <-FOyxYPMnMfseoEVE0gqhuWFKT2s04ZLcKvyKF28zwE=.2c7eef23-1b9a-4339-89c6-58117a625848@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <KHZElWc7zraJIEXSHmNGmwzlXmN2USnrbqqHxPeMcCI=.81b68032-9200-49d7-bd45-e21c106122cc@github.com>
 <jmT-lvxKjcKsq0MSqzx6h5UXOxxvecrh5IeOtsl-6fA=.4eb24466-76ce-44a1-b644-53b0611be883@github.com>
 <-FOyxYPMnMfseoEVE0gqhuWFKT2s04ZLcKvyKF28zwE=.2c7eef23-1b9a-4339-89c6-58117a625848@github.com>
Message-ID: <DCiMHXzIax_cyp5HCtr1-UXOje79IpHezPDY-YwJwx4=.120c72fc-a30b-43c4-b3c4-cba79fab883c@github.com>

On Mon, 3 Nov 2025 18:51:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> > A truly useful enhancement! Just had a few questions / suggestions.
> 
> Thanks for the review Fred!

Hello, I have meet a simlar question as: [https://stackoverflow.com/questions/79808508/jdk24-tomcat-start-pinned-in-virtual-thead-env](https://stackoverflow.com/questions/79808508/jdk24-tomcat-start-pinned-in-virtual-thead-env)

I want to know if this quesiton is same as https://bugs.openjdk.org/browse/JDK-8369238 or not.
How to temporarily solve this problem?

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3484149341

From aph at openjdk.org  Tue Nov  4 09:22:01 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 4 Nov 2025 09:22:01 GMT
Subject: RFR: 8371188: [s390x] Un-ProblemList TestUnreachableInnerLoop.java
In-Reply-To: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
References: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
Message-ID: <e_tplEV3cV5xS_HTG8SKFEuydHkNnNPmnyGQTUsedUU=.c3063560-a990-45e2-91b9-0a5d2458fade@github.com>

On Tue, 4 Nov 2025 05:10:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Trivial change,
> After [JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981) delivery test is now passing on s390x. So It can be removed from the problemlist.

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28122#pullrequestreview-3415020771

From ayang at openjdk.org  Tue Nov  4 09:26:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 4 Nov 2025 09:26:36 GMT
Subject: RFR: 8370774: Merge ModRefBarrierSet into CardTableBarrierSet
In-Reply-To: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
References: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
Message-ID: <Js0atVjYVbfgN9SdWeELGHfii5WpzV-wpB6Fydp9QpA=.60fc1ca0-9518-4579-8722-e8c64580cb37@github.com>

On Tue, 28 Oct 2025 09:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Merge a class into its sole subclass.
> 
> Many files are changed in this PR, and they can be largely divided into two groups, moving content of `ModRefBarrierSet` into `CardTableBarrierSet` (`src/hotspot/share/gc/`) and platform specific moving content of `ModRefBarrierSetAssembler` into `CardTableBarrierSetAssembler` (`src/hotspot/cpu/`).
> 
> Test: tier1-5 for x64 and aarch64; GHA

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28013#issuecomment-3484837794

From ayang at openjdk.org  Tue Nov  4 09:26:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 4 Nov 2025 09:26:37 GMT
Subject: Integrated: 8370774: Merge ModRefBarrierSet into CardTableBarrierSet
In-Reply-To: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
References: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
Message-ID: <6lsApuc2eXuLS2Thbiu_udBzifrewj5V5UQ2w62HUDE=.525ec5e3-b206-4049-9f0f-f20dd6549442@github.com>

On Tue, 28 Oct 2025 09:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Merge a class into its sole subclass.
> 
> Many files are changed in this PR, and they can be largely divided into two groups, moving content of `ModRefBarrierSet` into `CardTableBarrierSet` (`src/hotspot/share/gc/`) and platform specific moving content of `ModRefBarrierSetAssembler` into `CardTableBarrierSetAssembler` (`src/hotspot/cpu/`).
> 
> Test: tier1-5 for x64 and aarch64; GHA

This pull request has now been integrated.

Changeset: 21f41c5f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21f41c5f49cd3c5e6e4f29ed38701a4d92c16098
Stats:     2066 lines in 60 files changed: 633 ins; 1368 del; 65 mod

8370774: Merge ModRefBarrierSet into CardTableBarrierSet

Reviewed-by: tschatzl, iwalulya

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

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

From aph at openjdk.org  Tue Nov  4 09:32:54 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 4 Nov 2025 09:32:54 GMT
Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE
 [v2]
In-Reply-To: <1rP2ebDy2PFLeEq4lYTks0cHZsvBKJsZFPtVZPsbH_g=.8aa13828-9eb6-4607-821d-9bbc7bd286a1@github.com>
References: <VmD1YkLtZRxhBpF5lwqMltlfjtQk0D78hoHJsN-Zjrs=.63276c32-8f28-4e60-becd-55581c2b2c5d@github.com>
 <hEx-2kQxttKtQD4SKud4ceKGZq9uK2ZSSqKCXjGsOz0=.f6468cb9-c462-44a8-9da0-e2ff90876af3@github.com>
 <8nJUYG6FECEghybXRFfeIsA0R9paX_AFr5IgiGO6Trs=.a3f75a8f-421d-4da8-9c53-03064a397b2b@github.com>
 <1rP2ebDy2PFLeEq4lYTks0cHZsvBKJsZFPtVZPsbH_g=.8aa13828-9eb6-4607-821d-9bbc7bd286a1@github.com>
Message-ID: <tii7qG3XHQdAuul4GFxMtAvzSDGPTl8eMSTpJE4Mb-E=.172fff18-d10e-439a-b1cd-d1a316213a27@github.com>

On Thu, 21 Aug 2025 08:13:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> You're right, it is a little inaccurate to use the Java API to determine what `cmpxchgptr` does. Although the original intent to remove the membar is still functionality correct.
>> 
>> Although looking into it more, it seems that `cmpxchgptr` can now be removed completely. The recent PR https://github.com/openjdk/jdk/pull/26594 removed two of its call sites, and the only other existing one is within `MacroAssembler::cmpxchg_obj_header` - a method which never gets called to.
>> 
>> So I propose:
>> - We close this pr
>> - Open new one which removes the methods `MacroAssembler::cmpxchg_obj_header`, `MacroAssembler::cmpxchgptr` and `MacroAssembler::cmpxchgw` completely since they are no longer called to from anywhere.
>
>> * We close this pr
>> 
>> * Open new one which removes the methods `MacroAssembler::cmpxchg_obj_header`, `MacroAssembler::cmpxchgptr` and `MacroAssembler::cmpxchgw` completely since they are no longer called to from anywhere.
> 
> If you like, although we can (and we should) tidy up as we go along.

> Hi @theRealAph, I've pushed changes to remove the unused cmpxchg* functions to [master...ruben-arm:jdk:pr-8365799](https://github.com/openjdk/jdk/compare/master...ruben-arm:jdk:pr-8365799) as Samuel is currently not available. Once he is back, he can update this PR's branch. However, as this is a different scope from the original JBS ticket https://bugs.openjdk.org/browse/JDK-8365799, should we create a new one?

Yes, do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3484873265

From epeter at openjdk.org  Tue Nov  4 09:42:02 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 4 Nov 2025 09:42:02 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v4]
In-Reply-To: <niJEvIg4tBY6ptD64Zevov7zGSPuk7D7DunyciWLc44=.a1c09d93-b308-4345-8143-f1a5ca7595ff@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
 <niJEvIg4tBY6ptD64Zevov7zGSPuk7D7DunyciWLc44=.a1c09d93-b308-4345-8143-f1a5ca7595ff@github.com>
Message-ID: <EIILp2ReS4S2tgKNkB893zYqzyRAj3HFW6284TzaTKY=.7e4b5acd-0bbf-4a70-8416-54db363d8100@github.com>

On Thu, 30 Oct 2025 00:24:26 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add assertion for the helper in CTPComparator
>   
>   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>

Still good :)

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27618#pullrequestreview-3415158637

From duke at openjdk.org  Tue Nov  4 09:48:20 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 09:48:20 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
Message-ID: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>

> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

 - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
 - Merge from the main branch
 - Address review comments and fix a mistype
 - Check for NOP and MOVK separately in NativePostCallNop
 - Test for deoptimization in virtual threads
   
   Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
 - Merge from the main branch
 - Address review comments
 - Address review comments
 - Address review comments
 - The patch is contributed by @TheRealMDoerr
 - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

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

Changes: https://git.openjdk.org/jdk/pull/26678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=09
  Stats: 569 lines in 41 files changed: 268 ins; 216 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/26678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678

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

From mdoerr at openjdk.org  Tue Nov  4 09:58:54 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 4 Nov 2025 09:58:54 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <cIK9mFn8sPtndcHItgUfNgF0prPHnG7wfcZoyd8VfWA=.6ea41aea-73f4-46a7-9cd1-187d29ad556e@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3415283652

From qamai at openjdk.org  Tue Nov  4 10:09:07 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Nov 2025 10:09:07 GMT
Subject: RFR: 8367341: C2: apply KnownBits and unsigned bounds to And / Or
 operations [v5]
In-Reply-To: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
References: <SqHEdFScmcQRe6wTaITLemzMzWD6jxGWCRWzHNepqjE=.ab7e7553-3a43-4b43-abc3-338d6493a35d@github.com>
Message-ID: <s9ctO-GO9dQP-0PSjb22B21KI7VdUnLvX9S7t0g5BxU=.422726d5-5e36-4c7b-81fe-8c05bb69baa9@github.com>

> Hi,
> 
> This PR improves the implementation of `AndNode/OrNode/XorNode::Value` by taking advantages of the additional information in `TypeInt`. The implementation is pretty straightforward. A clever trick is that by analyzing the negative and positive ranges of a `TypeInt` separately, we have better info for the leading bits. I also implement gtest unit tests to verify the correctness and monotonicity of the inference functions.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into andorxor
 - Add assertion for the helper in CTPComparator
   
   Co-authored-by: Emanuel Peter <emanuel.peter at oracle.com>
 - remove std::hash
 - remove unordered_map, add some comments for all_instances_size
 - Emanuel's reviews
 - Improve Value inferences of And, Or, Xor and implement gtest for general Value inferences

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

Changes: https://git.openjdk.org/jdk/pull/27618/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27618&range=04
  Stats: 964 lines in 9 files changed: 630 ins; 313 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27618/head:pull/27618

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

From jsjolen at openjdk.org  Tue Nov  4 10:57:47 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:47 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
Message-ID: <gaDkJcdQTKgBJeFtj604SkP0vjZdYq3VZU7phQv1hxQ=.35dd5839-54bb-4829-994c-94675dba651b@github.com>

On Wed, 8 Oct 2025 20:35:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> src/hotspot/share/classfile/classFileParser.cpp line 3342:
> 
>> 3340: 
>> 3341:     BSMAttributeEntry* entry = iter.reserve_new_entry(bootstrap_method_ref, num_bootstrap_arguments);
>> 3342:     guarantee_property(entry != nullptr, "Invalid BootstrapMethods num_bootstrap_methods. The total amount of space reserved for the BootstrapMethod attribute was not sufficient", CHECK);
> 
> Nit: This line is too big. It is a good idea to split the message. Also, would it better to move this guaranty for `nullptr` into the `reserve_new_entry()`?

I think it's best to keep this null check here so that we can have a specialized error message. In this case, we are reading a classfile, so we're parsing untrusted input. That's when we might get a null result when attempting to reserve a new entry.


In the other cases, we're working from trusted data and a presumed-to-be-correct algorithm. I've added assertions in these cases, as it shouldn't break.

> src/hotspot/share/oops/bsmAttribute.hpp line 97:
> 
>> 95:     int _cur_offset;
>> 96:     // Current unused offset into BSMAEs bsm-data array
>> 97:     int _cur_array;
> 
> Nit: The declarations at lines 95, 97 will be more readable if comments above declarations trail declarations. The comment should not start with capital.

Do you mean that you want this?

```c++
    int _cur_offset; // current unused offset into BSMAEs offset array

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489955815
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489948444

From jsjolen at openjdk.org  Tue Nov  4 10:57:50 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:50 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
Message-ID: <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>

On Tue, 23 Sep 2025 04:22:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>>  - Fix BSM naming
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 482:
> 
>> 480:     int basePos = offs.at(bsmIndex);
>> 481:     int argv = basePos + INDY_ARGV_OFFSET;
>> 482:     int argc = getBootstrapMethodArgsCount(bsmIndex);
> 
> Nit: Consider to make it shorter:
>   `getBootstrapMethods` => `getBSMs`
>   `getBootstrapMethodArgsCount` => `getBSMArgsCount`

I'm keeping it verbose, as that's the general style of this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489941288

From jsjolen at openjdk.org  Tue Nov  4 10:57:44 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:44 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v14]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <fDfZM9Sgvsb4dJjWGJG7DV3vJVBa66APA2gFeKMb03I=.00e3f6d4-a487-4d07-ab95-0b5c6ce459e0@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Serguei comments
 - Revert change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/5e72da4e..e3419823

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

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

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

From jsjolen at openjdk.org  Tue Nov  4 10:57:48 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:57:48 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <E5cp5rk8qtat-kiY3oBIQKp9CEk9jl43LBLn7PRg0OQ=.cd830d11-d7e0-4939-a63d-7787f9061e3e@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
 <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>
 <E5cp5rk8qtat-kiY3oBIQKp9CEk9jl43LBLn7PRg0OQ=.cd830d11-d7e0-4939-a63d-7787f9061e3e@github.com>
Message-ID: <QnsgxlHRJAdPmvnB_PluIUz12nAD_yefeN91pSNoLiA=.e35761f9-d8fd-497f-8a98-6f9410094536@github.com>

On Wed, 15 Oct 2025 17:58:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I believe that the style is to have an empty line between the code and the endif, so this is a style fix.
>
> The issue is this is the only fix in this file. Should we go and fix all style issues around?
> In fact, I'm okay with this tweak. :)

Ah, you're right. I responded to this in the 'Conversation' view and didn't see that this is the only change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2489892804

From phubner at openjdk.org  Tue Nov  4 10:59:07 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 10:59:07 GMT
Subject: RFR: 8371188: [s390x] Un-ProblemList TestUnreachableInnerLoop.java
In-Reply-To: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
References: <EfrE8Xz_4aPFgSHN2xGXPb9SJA8xrTOME9Fw8BpqWTA=.710094cc-d196-4eb8-ab53-8fdf497eb976@github.com>
Message-ID: <bJWEdMCaXO75dDRx-R53ve_qHf9-757Jfw9mXEzSygc=.72fbdaa8-84dc-4812-b533-03e71e7df225@github.com>

On Tue, 4 Nov 2025 05:10:04 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Trivial change,
> After [JDK-8288981](https://bugs.openjdk.org/browse/JDK-8288981) delivery test is now passing on s390x. So It can be removed from the problemlist.

Thanks!

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/28122#pullrequestreview-3415707571

From phubner at openjdk.org  Tue Nov  4 11:02:28 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 11:02:28 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

>From the manpage:
> The name of the vDSO varies across architectures.  It will often
       show up in things like glibc's [ldd(1)](https://man7.org/linux/man-pages/man1/ldd.1.html) output.  The exact name
       should not matter to any code, so do not hardcode it.
       
Just throwing an idea out there, since we are hardcoding the name, would it be worth to add an `else` clause to your `if`, in which we `assert` that `filepath` does not contain `vdso` or `linux-gate.so`?

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

PR Review: https://git.openjdk.org/jdk/pull/28102#pullrequestreview-3415738465

From duke at openjdk.org  Tue Nov  4 11:35:04 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 11:35:04 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <JohQnNOwaUXT_m459WOhFfXutn-U4SMQ6VFOjacecIU=.e427b201-abc7-44fc-938a-4c3d0d506406@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Thank you all for reviewing the PR and helping with testing.

A separate JBS issue has been opened for `SafeFetch`: https://bugs.openjdk.org/browse/JDK-8371204.

I plan to wait until tomorrow before issuing the `/integrate` request. Please let me know if you think this should wait longer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3485520456

From ysuenaga at openjdk.org  Tue Nov  4 12:21:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 4 Nov 2025 12:21:02 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>
Message-ID: <9q6sEvrBzhWLGSnGHWkfZrKcfFea-mQ3MZknTI4-RAU=.16b44786-4e12-4175-8963-196315f7cfba@github.com>

On Tue, 4 Nov 2025 11:00:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> would it be worth to add an else clause to your if, in which we assert that filepath does not contain vdso or linux-gate.so?

It would be false-positive if "vdso" is included unintended path like "libfoo-vdsoon.so" . `linux-gate.so` is for unsupported platform of OpenJDK e.g. IA64, SH.

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3485695366

From eosterlund at openjdk.org  Tue Nov  4 12:23:06 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 4 Nov 2025 12:23:06 GMT
Subject: RFR: 8367319: Add os interfaces to get machine and container
 values separately [v2]
In-Reply-To: <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
References: <gxXrAX2NGPyZnHuA4ttkfJ8MagiiELK-Wk700A2ZBgw=.00aaf9ab-976d-476a-ba4d-8a4063d96130@github.com>
 <YsSD07LmdasM7tN-4ULeMtGLTZzaWiWsxW-Zj6dtDe8=.5684f897-19b4-4293-8265-6929b6d3f5fd@github.com>
Message-ID: <Lydze3oNHRhrY3Y6Gw8S7kcH1b7Y2V_gXR5thf14U5M=.aabda48b-6a5a-4cc1-b5bd-35695d3f603e@github.com>

On Mon, 6 Oct 2025 14:48:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed print type

Looks good to me.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27646#pullrequestreview-3416160902

From phubner at openjdk.org  Tue Nov  4 12:50:36 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 12:50:36 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <9q6sEvrBzhWLGSnGHWkfZrKcfFea-mQ3MZknTI4-RAU=.16b44786-4e12-4175-8963-196315f7cfba@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>
 <9q6sEvrBzhWLGSnGHWkfZrKcfFea-mQ3MZknTI4-RAU=.16b44786-4e12-4175-8963-196315f7cfba@github.com>
Message-ID: <RMQFXYcczF2nYMrGfaMbAaJiI9LA1_9ONUylaZiraS4=.ce2c7cfe-8485-4f5f-9656-404bfce8dca2@github.com>

On Tue, 4 Nov 2025 12:18:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > would it be worth to add an else clause to your if, in which we assert that filepath does not contain vdso or linux-gate.so?
> 
> It would be false-positive if "vdso" is included unintended path like "libfoo-vdsoon.so" . `linux-gate.so` is for unsupported platform of OpenJDK e.g. IA64, SH.

Yes, it would be a false positive. If I understand correctly, right now we error due to an assertion. So after your patch, if someone (for whatever reason) has a different file name, we would error anyway in the same way we error now, via the same assertion right? If we error anyway, feel like it could be marginally more helpful to make the error location/message as precise as possible.

That said, I don't know this area nor vDSO very well, so I'm not sure if my proposal is very canonical. I'm just brainstorming from the perspective of someone who wants to make debugging as straightforward as possible. I'm happy to approve the change as-is. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3485834347

From shade at openjdk.org  Tue Nov  4 13:15:22 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Nov 2025 13:15:22 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v8]
In-Reply-To: <U1w03x1mKY-DAEiu_2Wch_yHdclbp3hwlU0Pxkkp9Eo=.0d5067a4-3c09-4390-a521-131dc7a79089@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <U1w03x1mKY-DAEiu_2Wch_yHdclbp3hwlU0Pxkkp9Eo=.0d5067a4-3c09-4390-a521-131dc7a79089@github.com>
Message-ID: <VAq7pyEoiVAdCdJzynMOxuligrTv1e6l7UiydRvPSLk=.991b670a-9143-43f7-a780-b7882ff042b7@github.com>

On Thu, 30 Oct 2025 11:46:11 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "Erase obsolete comments"
>    
>    This reverts commit 860b6ee6faeb6e56e292abef1c85faad456729e2.
>  - fix space
>  - Erase obsolete comments

Looks reasonable. A few questions/nits:

src/hotspot/share/utilities/elfFile.cpp line 730:

> 728:   // Assume ~3% of the .debug_aranges is DebugArangesSetHeader and the rest is made up of AddressDescriptors.
> 729:   const uintptr_t estimatedSetHeaderSize = _size_bytes / 32;
> 730:   const size_t initial_capacity = (_size_bytes - estimatedSetHeaderSize) / sizeof(AddressDescriptor);

Suggestion:

  const uintptr_t estimated_set_header_size = _size_bytes / 32;
  const size_t initial_capacity = (_size_bytes - estimated_set_header_size) / sizeof(AddressDescriptor);

src/hotspot/share/utilities/elfFile.cpp line 931:

> 929: bool DwarfFile::ArangesCache::add_entry(const AddressDescriptor& descriptor, uint32_t debug_info_offset) {
> 930:   if (_count >= _capacity && !grow()) {
> 931:     destroy(true);

Why it calls `destroy` here? Can you call destroy multiple times? I wonder if it would be cleaner to move `destroy` to caller, seeing how it already handles the similar failure.

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

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3416394946
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2490465475
PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2490464716

From egahlin at openjdk.org  Tue Nov  4 13:29:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 4 Nov 2025 13:29:59 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <SkZ1al6sgQVHfhN1vOTFUoLCbgxtKNnDQs5VduhJdRU=.2ce59627-8bfe-443a-a4ef-88d91bd5b1aa@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

> To answer your first question, we do have a diagnostic command (AOT.end_recording) and it would precede the AOT MXBean into mainline and its PR is here: #27965

Ah, I didn't know that. 

(I don?t have a strong opinion on this, but for consistency you might want the jcmd commands for AOT recording to use the same naming convention for starting, stopping, and checking the status of a recording as JFR: JFR.start, JFR.stop, JFR.check, JFR.dump and JFR.configure, where applicable. Initially, we had start_recording, but we later shortened it to start to avoid unnecessary typing)

> The longer goal for this MXBean is to provide additional methods that would aid in monitoring (isRecording, currentRecordingLength etc.), however we decided to reduce the scope of the MXBean for main line while we continue to test the monitoring functionality in leyden/premain
> 
> Historically the diagnostic command came after the MXBean in leyden/premain, however I decided to implement the diagnostic command with the necessary JVM hooks first to simplify review

Ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/28010#issuecomment-3486004039

From coleenp at openjdk.org  Tue Nov  4 13:44:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Nov 2025 13:44:54 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
Message-ID: <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>

On Tue, 4 Nov 2025 10:49:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 482:
>> 
>>> 480:     int basePos = offs.at(bsmIndex);
>>> 481:     int argv = basePos + INDY_ARGV_OFFSET;
>>> 482:     int argc = getBootstrapMethodArgsCount(bsmIndex);
>> 
>> Nit: Consider to make it shorter:
>>   `getBootstrapMethods` => `getBSMs`
>>   `getBootstrapMethodArgsCount` => `getBSMArgsCount`
>
> I'm keeping it verbose, as that's the general style of this file.

Yes please I like the full names if possible rather than abbreviations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2490567923

From duke at openjdk.org  Tue Nov  4 13:48:14 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 13:48:14 GMT
Subject: RFR: 8365799: AArch64: Remove trailing DMB from cmpxchgptr for LSE
 [v2]
In-Reply-To: <tii7qG3XHQdAuul4GFxMtAvzSDGPTl8eMSTpJE4Mb-E=.172fff18-d10e-439a-b1cd-d1a316213a27@github.com>
References: <VmD1YkLtZRxhBpF5lwqMltlfjtQk0D78hoHJsN-Zjrs=.63276c32-8f28-4e60-becd-55581c2b2c5d@github.com>
 <hEx-2kQxttKtQD4SKud4ceKGZq9uK2ZSSqKCXjGsOz0=.f6468cb9-c462-44a8-9da0-e2ff90876af3@github.com>
 <8nJUYG6FECEghybXRFfeIsA0R9paX_AFr5IgiGO6Trs=.a3f75a8f-421d-4da8-9c53-03064a397b2b@github.com>
 <1rP2ebDy2PFLeEq4lYTks0cHZsvBKJsZFPtVZPsbH_g=.8aa13828-9eb6-4607-821d-9bbc7bd286a1@github.com>
 <tii7qG3XHQdAuul4GFxMtAvzSDGPTl8eMSTpJE4Mb-E=.172fff18-d10e-439a-b1cd-d1a316213a27@github.com>
Message-ID: <2m6c5VL2EUrTuA3fqHTKxMa9CRPYSKsjvmxHzCcdFoM=.830507c6-be6b-4c4b-8a9e-41bfb38d5741@github.com>

On Tue, 4 Nov 2025 09:30:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>Yes, do that.

Opened the ticket and corresponding PR:
https://bugs.openjdk.org/browse/JDK-8371205
https://github.com/openjdk/jdk/pull/28131

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

PR Comment: https://git.openjdk.org/jdk/pull/26845#issuecomment-3486079877

From fbredberg at openjdk.org  Tue Nov  4 13:49:23 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 4 Nov 2025 13:49:23 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>
 <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
Message-ID: <HJ8Hu7SwYhkfmwa2vUVyoYzNa-nWOzJWFDC_C8T_A6w=.30ccf41d-efd0-4b16-90fb-1dd82e57c26b@github.com>

On Mon, 27 Oct 2025 00:04:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/runtime/abstract_vm_version.hpp line 195:
> 
>> 193: 
>> 194:   // Is recursive fast locking implemented for this platform?
>> 195:   constexpr static bool supports_recursive_fast_locking() { return false; }
> 
> Next cleanup: this is supported on all platforms now, so we can get rid of this migration aid.

Not sure we can do that, since I don't find any implementation of recursive fast locking on ARM32.
@bulasevich Any comment on this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2490583182

From ysuenaga at openjdk.org  Tue Nov  4 13:51:29 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 4 Nov 2025 13:51:29 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <RhJ6KZBhWqUvLDuixKqLBQBpHD1hm0J-ucKMaLaMaP0=.2ce8d608-ca8c-4ab4-b01b-7a26529862a8@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

vDSO is very special, it is a part of kernel, we can't find the .so file on lib directory (e.g. `/usr/lib64`).

The assertion mentioned this issue is caused by this behavior - `ElfDecorder` attemps to load souce information from ELF, but it wouldn't because vDSO file is not found. It should happen on vDSO because regular loaded ELFs should be located on file system (otherwise the process wouldn't load library of course).

vDSO name is specified in manpage, so we can skip vDSO only. Thus I think it does not need to add `else` for other files named with `vdso`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3486093770

From duke at openjdk.org  Tue Nov  4 13:52:01 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 4 Nov 2025 13:52:01 GMT
Subject: RFR: 8371205: AArch64: Remove unused cmpxchg* methods
Message-ID: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>

Since JDK-8364406, the AArch64 macroAssembler method cmpxchg_obj_header is no longer used. The method cmpxchgptr is used by cmpxchg_obj_header however is not used by any other method so can be removed alongside cmpxchgptr.
cmpxchgw is also unused and can be removed.

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

Commit messages:
 - 8371205: AArch64: Remove unused cmpxchg* methods

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

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

From jsjolen at openjdk.org  Tue Nov  4 14:27:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 14:27:57 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v15]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
 - Fix naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/e3419823..219ef346

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

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

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

From krk at openjdk.org  Tue Nov  4 14:47:18 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 4 Nov 2025 14:47:18 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v9]
In-Reply-To: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
Message-ID: <dLJUNuDnlKywjmdNLl3X8bxzrFNO9aj1JarBpT6Rtj4=.ecd7aae9-e33e-4130-8910-2f8dcc94b729@github.com>

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:

  move destroy and rename var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27337/files
  - new: https://git.openjdk.org/jdk/pull/27337/files/d94025da..ab20ce3b

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

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

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

From krk at openjdk.org  Tue Nov  4 14:47:21 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 4 Nov 2025 14:47:21 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v8]
In-Reply-To: <VAq7pyEoiVAdCdJzynMOxuligrTv1e6l7UiydRvPSLk=.991b670a-9143-43f7-a780-b7882ff042b7@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <U1w03x1mKY-DAEiu_2Wch_yHdclbp3hwlU0Pxkkp9Eo=.0d5067a4-3c09-4390-a521-131dc7a79089@github.com>
 <VAq7pyEoiVAdCdJzynMOxuligrTv1e6l7UiydRvPSLk=.991b670a-9143-43f7-a780-b7882ff042b7@github.com>
Message-ID: <D5tSudGbsVhLuLSPyTLLw32B6OxhaQNbbNahwEV32Nk=.c8f55c3b-3913-41f0-9458-d4ad936ada3d@github.com>

On Tue, 4 Nov 2025 13:09:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kerem Kat has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Revert "Erase obsolete comments"
>>    
>>    This reverts commit 860b6ee6faeb6e56e292abef1c85faad456729e2.
>>  - fix space
>>  - Erase obsolete comments
>
> src/hotspot/share/utilities/elfFile.cpp line 931:
> 
>> 929: bool DwarfFile::ArangesCache::add_entry(const AddressDescriptor& descriptor, uint32_t debug_info_offset) {
>> 930:   if (_count >= _capacity && !grow()) {
>> 931:     destroy(true);
> 
> Why it calls `destroy` here? Can you call destroy multiple times? I wonder if it would be cleaner to move `destroy` to caller, seeing how it already handles the similar failure.

If the cache cannot grow, it becomes unusable as we will not use a partial cache. So we destroy the cache and fall back to the linear scan for the dwarf file.

I am moving the `destroy` call into `ensure_cached` as all other destroy calls are in that method, thanks.

Destroying a cache multiple times is not an error, as the heap pointer in `ArangesCache::free` is checked for null.

On the other hand, when destroy is called, it is followed by a return in `DebugAranges::ensure_cached`. Did you have a particular scenario when `destroy` is called multiple times?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2490786974

From jvernee at openjdk.org  Tue Nov  4 15:43:47 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Nov 2025 15:43:47 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
Message-ID: <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>

On Mon, 3 Nov 2025 18:29:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> See the JBS issue for a problem description.
>> 
>> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
>> 
>> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
>> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
>> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
>> 3. Any other Java code that runs as part of the linking process.
>> 
>> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
>> 
>> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments Patricio

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3486638747

From jvernee at openjdk.org  Tue Nov  4 15:43:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Nov 2025 15:43:50 GMT
Subject: Integrated: 8370344: Arbitrary Java frames on stack during scoped
 access
In-Reply-To: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
Message-ID: <GNO4wS2ioX_SgkNAktGtzSaaSYJSXKPMPju2gIlHU88=.406e4e77-96eb-4342-85cd-8b479ba69eb2@github.com>

On Tue, 21 Oct 2025 16:00:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> See the JBS issue for a problem description.
> 
> This patch changes the shared scope closure handshake to be able to handle 'arbitrary' Java frames on the stack during a scoped memory access.
> 
> For the purposes of this change, we assume that 'arbitrary' is limited to the following: 
> 1. Frames added by calling the constructor of `InternalError` as a result of a faulting access to a truncated memory-mapped file (see `HandshakeState::handle_unsafe_access_error`). This is the only handshake operation (i.e. may be triggered during a scoped access) that calls back into Java.
> 2. Frames added by a JVMTI agent that calls back into Java code while handling a JVMTI event that happens during a scoped access.
> 3. Any other Java code that runs as part of the linking process.
> 
> For (1), we set a flag while we are create the `InternalError`. If a thread has that flag set, we know it is in the process of crashing already, so we don't have to inspect the stack at all. For (2), all bets are off, so we have to walk the entire stack. For (3), this patch switches the hard limit of 10 frames for the stack walk to instead bail out at the first frame outside of the `java.base` module. In most cases this speeds up the stack walk as well, if threads are running other code.
> 
> The test `TestSharedCloseJFR` is added for scenario (1), and the test `TestSharedCloseJvmti` is added for scenario (2). Existing tests already cover scenario (3).
> 
> Testing: tier 1-4

This pull request has now been integrated.

Changeset: a51a0bf5
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a51a0bf57feaae0862fd7f3dbf305883d49781a0
Stats:     550 lines in 9 files changed: 534 ins; 5 del; 11 mod

8370344: Arbitrary Java frames on stack during scoped access

Reviewed-by: pchilanomate, dholmes, liach

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

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

From pchilanomate at openjdk.org  Tue Nov  4 15:47:31 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:47:31 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

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

  fix to JvmtiHideSingleStepping

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27802/files
  - new: https://git.openjdk.org/jdk/pull/27802/files/4dff05a8..55c89ad0

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

  Stats: 182 lines in 4 files changed: 164 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From pchilanomate at openjdk.org  Tue Nov  4 15:47:33 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:47:33 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
Message-ID: <1m9Kbr2qq1hRl4Sc4YG39hxJ0WFS5aAx-BDmiAaZ_Xk=.d9ba0f21-f06d-46b3-8b08-cf5cc3520906@github.com>

On Mon, 3 Nov 2025 19:03:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested fix in macroAssembler_ppc.cpp

> Hello, I have meet a simlar question as: https://stackoverflow.com/questions/79808508/jdk24-tomcat-start-pinned-in-virtual-thead-env
> 
> I want to know if this quesiton is same as https://bugs.openjdk.org/browse/JDK-8369238 or not. How to temporarily solve this problem?
>
In the stacktrace posted, virtual thread #157 is pinned not because of the `static synchronized` but because there are native frames in the stack due to initializing class `CoyoteOutputStream`. This PR doesn?t address that pinning case. It addresses the case of virtual threads pinned waiting for a class to be initialized by another thread. Feel free to send any related questions to the loom-dev mailing list instead, it?s the best place to discuss this. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3486642618

From pchilanomate at openjdk.org  Tue Nov  4 15:48:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 15:48:00 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
Message-ID: <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>

On Mon, 3 Nov 2025 19:03:07 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested fix in macroAssembler_ppc.cpp

I pushed a small fix to `JvmtiHideSingleStepping` for an issue found during pre-integration testing where we hit this assert: https://github.com/openjdk/jdk/blob/50bb92a33b32778a96b1823ff995889892bef890/src/hotspot/share/prims/jvmtiThreadState.hpp#L337
The problem is that for a preempting vthread, the `JvmtiThreadState` of the current `JavaThread` has already been rebinded to the state of the carrier when executing `~JvmtiHideSingleStepping`. The fix is to remember the `JvmtiThreadState` used originally in the `JvmtiHideSingleStepping` constructor. The commit includes a new test that reproduces the issue. @sspitsyn maybe you could take a look at this please?

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3486666711

From duke at openjdk.org  Tue Nov  4 16:31:05 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 16:31:05 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v2]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <1azA71s8sFRamYweW9fbMEv1Drl2dNVUT7qZmUPeQeU=.c9bbf5eb-fede-44ae-b767-549a74a5dd75@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

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

 - Merge branch 'openjdk:master' into macos-vm-tagging
 - 1. Test improved to incorporate os/zgc allocation routines 2. Minor refactor to improve readability
 - remove extra whitespace
 - remove extra whitespace
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Covered ZGC direct mmap usage for JAVA tagging. Added unit test to validate changes
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/1144ca92..1c8b3818

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

  Stats: 73212 lines in 988 files changed: 39905 ins; 27282 del; 6025 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Tue Nov  4 16:46:28 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 16:46:28 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v3]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  clean whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/1c8b3818..72a6e5fb

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

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

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

From vpaprotski at openjdk.org  Tue Nov  4 16:46:36 2025
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Tue, 4 Nov 2025 16:46:36 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
Message-ID: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>

- New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
   - `SignatureBench.MLDSA` is 1.2x-2.2x faster
   - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
- AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
  - `SignatureBench.MLDSA` is upto 5% faster, never slower

Note on intrinsic:
- The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
- Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2

Tests and benchmarks:
- Added a fuzz test to ensure Java and intrinsic produces exactly same result
- Added benchmark to measure the performance of intrinsic itself

make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into avx2-ntt
 - add copyright, whitespace and test jtreg tags
 - Fixes and comments from Anas
 - AVX2 and AVX512 intrinsics for MLDSA

Changes: https://git.openjdk.org/jdk/pull/28136/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371259
  Stats: 2247 lines in 7 files changed: 1546 ins; 257 del; 444 mod
  Patch: https://git.openjdk.org/jdk/pull/28136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28136/head:pull/28136

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

From stefank at openjdk.org  Tue Nov  4 17:06:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Nov 2025 17:06:52 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v3]
In-Reply-To: <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>
Message-ID: <jUn0HlN35ZQXg6QtqRng3X9BPjq8K81b22qEYl0gEkA=.bd3339e1-f958-4a6e-9422-850f7c21ce15@github.com>

On Tue, 4 Nov 2025 16:46:28 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean whitespaces

EOD here but got notified about this change. A few quick comments:
1) Could you fix the whitespace issues GH is complaining about?
2) There's a significant amount of duplication of these conspicuous additions. Could you you create a constexpr function and use that instead?
3) It doesn't seem prudent to put the new testing code in our test_zForwarding.cpp file. Could this be in its own test file?

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3417654140

From duke at openjdk.org  Tue Nov  4 17:12:15 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 17:12:15 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v4]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <Fnnb6wAFEBUYDZekKd6vSxLTSylDGZA0WCjUnxuEiJ8=.baf637fb-b65f-46e2-a1a6-d966491a3cca@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  more whitespace cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/72a6e5fb..ab1a90d0

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

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

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

From shade at openjdk.org  Tue Nov  4 17:17:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Nov 2025 17:17:47 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v9]
In-Reply-To: <dLJUNuDnlKywjmdNLl3X8bxzrFNO9aj1JarBpT6Rtj4=.ecd7aae9-e33e-4130-8910-2f8dcc94b729@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <dLJUNuDnlKywjmdNLl3X8bxzrFNO9aj1JarBpT6Rtj4=.ecd7aae9-e33e-4130-8910-2f8dcc94b729@github.com>
Message-ID: <Xm4fr5DpOheRiQ9AK20Rb-j6Dmx2p9A_HeLrWd2M-Yo=.eebe8e2f-5d01-41b7-9479-8809410f06e1@github.com>

On Tue, 4 Nov 2025 14:47:18 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move destroy and rename var

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27337#pullrequestreview-3417718734

From shade at openjdk.org  Tue Nov  4 17:17:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 4 Nov 2025 17:17:49 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v8]
In-Reply-To: <D5tSudGbsVhLuLSPyTLLw32B6OxhaQNbbNahwEV32Nk=.c8f55c3b-3913-41f0-9458-d4ad936ada3d@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <U1w03x1mKY-DAEiu_2Wch_yHdclbp3hwlU0Pxkkp9Eo=.0d5067a4-3c09-4390-a521-131dc7a79089@github.com>
 <VAq7pyEoiVAdCdJzynMOxuligrTv1e6l7UiydRvPSLk=.991b670a-9143-43f7-a780-b7882ff042b7@github.com>
 <D5tSudGbsVhLuLSPyTLLw32B6OxhaQNbbNahwEV32Nk=.c8f55c3b-3913-41f0-9458-d4ad936ada3d@github.com>
Message-ID: <PnmZ7P1gJmdjzNVB4xcxeR5ivptlel_vv0NOOxm4D5E=.71a24f70-94d6-49eb-9d5f-b16dfbb7d1dd@github.com>

On Tue, 4 Nov 2025 14:41:10 GMT, Kerem Kat <krk at openjdk.org> wrote:

> Did you have a particular scenario when destroy is called multiple times?

No, just wondering. It was just suspicious that `add` manages global cache state (destroying it) somehow. With multiple `add`-s, one could have suspected it could destroy the cache multiple times.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2491385986

From duke at openjdk.org  Tue Nov  4 17:42:25 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Nov 2025 17:42:25 GMT
Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v9]
In-Reply-To: <dLJUNuDnlKywjmdNLl3X8bxzrFNO9aj1JarBpT6Rtj4=.ecd7aae9-e33e-4130-8910-2f8dcc94b729@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
 <dLJUNuDnlKywjmdNLl3X8bxzrFNO9aj1JarBpT6Rtj4=.ecd7aae9-e33e-4130-8910-2f8dcc94b729@github.com>
Message-ID: <AAgIGyrWkVJ3qUJqbz6DZLTIHb09xm3wrCH5S4x92Ik=.476fa8d6-d01b-45bb-8ec8-047e67f212cf@github.com>

On Tue, 4 Nov 2025 14:47:18 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
>> 
>> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
>> 
>> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move destroy and rename var

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27337#issuecomment-3487285662

From aph at openjdk.org  Tue Nov  4 17:49:58 2025
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 4 Nov 2025 17:49:58 GMT
Subject: RFR: 8371205: AArch64: Remove unused cmpxchg* methods
In-Reply-To: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
References: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
Message-ID: <0xHF1oB8jYPfooZZqjxPT7i6VTAt6o0KN2FVpnUhUyo=.21fbcc0d-fc23-42d1-99e3-0f35d7760b63@github.com>

On Tue, 4 Nov 2025 13:41:04 GMT, Ruben <duke at openjdk.org> wrote:

> Since JDK-8364406, the AArch64 macroAssembler method cmpxchg_obj_header is no longer used. The method cmpxchgptr is used by cmpxchg_obj_header however is not used by any other method so can be removed alongside cmpxchgptr.
> cmpxchgw is also unused and can be removed.

Trivial, obviously correct.

Marked as reviewed by aph (Reviewer).

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28131#pullrequestreview-3417917816
PR Review: https://git.openjdk.org/jdk/pull/28131#pullrequestreview-3417923671

From kbarrett at openjdk.org  Tue Nov  4 17:49:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Nov 2025 17:49:59 GMT
Subject: RFR: 8371205: AArch64: Remove unused cmpxchg* methods
In-Reply-To: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
References: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
Message-ID: <O7Ex9GYf8IS12dHpG8JK284mBb8BSSpVJOMeNPfbg5E=.dc8280f5-5d31-4d0f-ac7c-1341ec53fc9f@github.com>

On Tue, 4 Nov 2025 13:41:04 GMT, Ruben <duke at openjdk.org> wrote:

> Since JDK-8364406, the AArch64 macroAssembler method cmpxchg_obj_header is no longer used. The method cmpxchgptr is used by cmpxchg_obj_header however is not used by any other method so can be removed alongside cmpxchgptr.
> cmpxchgw is also unused and can be removed.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28131#pullrequestreview-3417927215

From duke at openjdk.org  Tue Nov  4 18:24:01 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 18:24:01 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v5]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <O4fmoZMVCIiQ1ERVR_tze14dkLZSrsif0Ce_51BVh1w=.503e2102-5cde-40f1-b323-8b731a8a17c1@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  move is_memory_tagged_as_java to common to reduce duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/ab1a90d0..2322badf

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

  Stats: 122 lines in 4 files changed: 43 ins; 74 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Tue Nov  4 19:07:32 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 19:07:32 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  minor refactoring to reduce code duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/2322badf..183927b0

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

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

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

From duke at openjdk.org  Tue Nov  4 19:07:33 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 19:07:33 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v3]
In-Reply-To: <jUn0HlN35ZQXg6QtqRng3X9BPjq8K81b22qEYl0gEkA=.bd3339e1-f958-4a6e-9422-850f7c21ce15@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>
 <jUn0HlN35ZQXg6QtqRng3X9BPjq8K81b22qEYl0gEkA=.bd3339e1-f958-4a6e-9422-850f7c21ce15@github.com>
Message-ID: <ig2LWccxlfmDTtghCPT1IKJSJzfPQ1c0_Gz_j9hYmXk=.e50e6fc5-3d03-485e-8d07-caeabf6c8429@github.com>

On Tue, 4 Nov 2025 17:03:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> EOD here but got notified about this change. A few quick comments:
> 
> 1. Could you fix the whitespace issues GH is complaining about?
Fixed
> 2. There's a significant amount of duplication of these conspicuous additions. Could you you create a constexpr function and use that instead?
Refactored code to remove duplication.
> 3. It doesn't seem prudent to put the new testing code in our test_zForwarding.cpp file. Could this be in its own test file?
I think the changes are minor to assert the tagging on allocation while we are doing that and do not require extra tests, please let me know if you still think otherwise.

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3487603064

From mdoerr at openjdk.org  Tue Nov  4 19:59:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 4 Nov 2025 19:59:30 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
Message-ID: <OgWp3USgtgltJFR7hidR1GZoyO1CtOKrn1BiE4nedAw=.d96d0251-e67a-4320-ac58-c9022b950120@github.com>

On Tue, 4 Nov 2025 15:39:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments Patricio
>
> Thanks for the reviews!

@JornVernee: The new test has failed on AIX:

[fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
[fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
[fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
[fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
[fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
[fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
[fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
[fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
[fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)

Should I file a new issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3487797511

From sspitsyn at openjdk.org  Tue Nov  4 20:45:37 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 20:45:37 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v13]
In-Reply-To: <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <mn6l7E2ogVa2XfrmNeGmWfmVAgs8icuQAmUd1Itb4bM=.60780117-f123-4457-b5a5-eea96227e386@github.com>
 <kLlUGHdyPCrCOqL-8WVRI9GahnH5HUnLJs7orQv3rms=.a485dd8f-b0f3-4b82-ad78-d63d678fbee2@github.com>
Message-ID: <0Z0x2IAQ1TayXTP7kAm9U3Yyx6A4rw88m7Kjgen6bAY=.15663b42-96db-444f-9e2d-2efcbe4dd94d@github.com>

On Tue, 4 Nov 2025 15:45:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> @sspitsyn maybe you could take a look at this please?

It looks good in general. I'm still looking at it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3487943741

From sspitsyn at openjdk.org  Tue Nov  4 20:49:19 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 20:49:19 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
Message-ID: <wPQlWFIZCeBMq589X81beQ-LNEwEBI0UHFATEarQXFI=.4bcd8d39-252c-4222-836e-5f7ec7d07fd3@github.com>

On Tue, 4 Nov 2025 15:47:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix to JvmtiHideSingleStepping

test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:

> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
> 37:            jmethodID method, jlocation location) {
> 38: }

Q: Would it make sense to verify that `SingleStep` events are posted or not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2491981248

From sspitsyn at openjdk.org  Tue Nov  4 21:12:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 21:12:51 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
Message-ID: <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>

On Tue, 4 Nov 2025 15:47:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix to JvmtiHideSingleStepping

I've reviewed the latest incremental SVC related update. It is good and nice to have in general. Thank you for adding the test!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3418644332

From fandreuzzi at openjdk.org  Tue Nov  4 21:27:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 4 Nov 2025 21:27:22 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v4]
In-Reply-To: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
Message-ID: <WgcXEQ5O4NHHKuvkOfRQrhlrTq9FfPbwiZXPZtwXlsk=.02793013-0aab-48a4-b031-feeb5751ba80@github.com>

> In this PR I introduce a new JFR event: `jdk.StringDeduplicationStatistics`
> 
> The new event is emitted every time a deduplication cycle happens.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - enable
 - bytes to size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/c3c9a8db..e8644c68

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

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

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

From pchilanomate at openjdk.org  Tue Nov  4 21:28:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 21:28:15 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
 <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
Message-ID: <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>

On Tue, 4 Nov 2025 21:10:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I've reviewed the latest incremental SVC related update. It is good and nice to have in general. Thank you for adding the test!
>
Great, thanks for the review Serguei!

> test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:
> 
>> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
>> 37:            jmethodID method, jlocation location) {
>> 38: }
> 
> Q: Would it make sense to verify that `SingleStep` events are posted or not?

Good idea, I added a check for it. Let me know if that works.

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3488063416
PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2492084640

From pchilanomate at openjdk.org  Tue Nov  4 21:28:14 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 21:28:14 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

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 22 commits:

 - Add check for SingleStep events
 - Merge branch 'master' into JDK-8369238
 - fix to JvmtiHideSingleStepping
 - Suggested fix in macroAssembler_ppc.cpp
 - Improve comment and assert msg
 - More fixes from David's comments
 - Merge branch 'master' into JDK-8369238
 - add const to references
 - Improve comment in anchor_mark_set_pd
 - More comments from Coleen
 - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

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

Changes: https://git.openjdk.org/jdk/pull/27802/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=14
  Stats: 2373 lines in 102 files changed: 1928 ins; 125 del; 320 mod
  Patch: https://git.openjdk.org/jdk/pull/27802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802

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

From fandreuzzi at openjdk.org  Tue Nov  4 21:34:45 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 4 Nov 2025 21:34:45 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
 <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
Message-ID: <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>

On Mon, 3 Nov 2025 16:59:55 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> We typically try to avoid using "Bytes" in field names, since that information is already available in the content type. Perhaps something else could be used, newSize?

Sure: 586f413571c7c0354e9663888c81113065d991bf

> It doesn't sound that bad, the event could probably be enabled by default. 

I re-enabled the event in `default.jfc`: e8644c683a4290f0ae112b7c63a8a1fc1c85b27e

> The elapsed fields, are they the total since the JVM started or from the last round?

All fields in `EventStringDeduplicationStatistics` contain the diff since the last round:

jdk.StringDeduplicationStatistics {
  startTime = 21:31:19.604 (2025-11-04)
  duration = 0.000020 ms
  inspected = 8424
  known = 2898
  shared = 1247
  newStrings = 4279
  newSize = 255.0 kB
  replaced = 0
  deleted = 0
  deduplicated = 3331
  deduplicatedSize = 102.4 kB
  skippedDead = 6
  skippedIncomplete = 0
  skippedShared = 0
  activeElapsed = 1.85 ms
  processElapsed = 1.85 ms
  idleElapsed = 191 ms
  resizeTableElapsed = 0 s
  cleanupTableElapsed = 0 s
}


jdk.StringDeduplicationStatistics {
  startTime = 21:31:19.604 (2025-11-04)
  duration = 0.000030 ms
  inspected = 1
  known = 0
  shared = 0
  newStrings = 1
  newSize = 24 bytes
  replaced = 0
  deleted = 0
  deduplicated = 0
  deduplicatedSize = 0 bytes
  skippedDead = 0
  skippedIncomplete = 0
  skippedShared = 0
  activeElapsed = 0.00124 ms
  processElapsed = 0.00100 ms
  idleElapsed = 0.000780 ms
  resizeTableElapsed = 0 s
  cleanupTableElapsed = 0 s
}

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

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3488086974

From sspitsyn at openjdk.org  Tue Nov  4 21:54:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 21:54:54 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
 <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>
Message-ID: <8Sx_Zy0yHDLxhRd-D9VdD4bsS2fnQmZd20RGlrCpsFg=.bf22f172-50de-4143-b6be-752ef899e4b8@github.com>

On Tue, 4 Nov 2025 13:42:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I'm keeping it verbose, as that's the general style of this file.
>
> Yes please I like the full names if possible rather than abbreviations.

> I'm keeping it verbose, as that's the general style of this file.

Okay. Local naming consistency is important too.

> Yes please I like the full names if possible rather than abbreviations.

Here the problem is not about full names vs abbreviations. It is about naming inconsistency with all these `BSM` related code. There are already many places with the `BSM` abbreviation. But I agree it is better to maintain the local style here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2492144260

From sspitsyn at openjdk.org  Tue Nov  4 22:02:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:02:52 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v15]
In-Reply-To: <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
Message-ID: <lJEW78VnaoodBYu5e6lSWHwaWmrKB0Xi1ggv2vxauHs=.e48d0c18-d48d-45ee-9c2e-c299af2e9494@github.com>

On Tue, 4 Nov 2025 14:27:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
>  - Fix naming

Thank you for the updates. This review became too long. I'm okay with the current state. The refactoring itself is nice to have.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3418770910

From jkratochvil at openjdk.org  Tue Nov  4 22:11:09 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 4 Nov 2025 22:11:09 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v3]
In-Reply-To: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
Message-ID: <xy7RDox0Pcz8mhy0TtuUqrgquQWps2L-HgoKCYwbQ60=.81f257e4-9408-4dcd-b2cd-c35d3b41b990@github.com>

> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
> 
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
>       |          (void*)
> 
> The patch follows the suggested fix.

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

 - Merge branch 'master' into clangmemset
 - Revert "8361288: Fix build of JTReg: wget exited with exit code 4"
   
   This reverts commit 6e6b8f6a26f8e555f1e70544546b92bbafcae6cc.
 - 8361288: Fix build of JTReg: wget exited with exit code 4
 - 8357579: Compilation error: first argument in call to 'memset' is a pointer to non-trivially copyable type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26098/files
  - new: https://git.openjdk.org/jdk/pull/26098/files/09a45c6d..3745a8af

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

  Stats: 422061 lines in 6258 files changed: 284237 ins; 95996 del; 41828 mod
  Patch: https://git.openjdk.org/jdk/pull/26098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26098/head:pull/26098

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

From sspitsyn at openjdk.org  Tue Nov  4 22:36:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:36:41 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v15]
In-Reply-To: <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <-MyLNt-M1uWjNPTzmizfSNSHZjqO-MFkxJK_Dn22MQs=.68e3b8cf-10da-4c8d-a891-11a0ecf516be@github.com>
Message-ID: <zGX18FsmvE9eyD7hw9Wmo944uX-z3bhZujuZrsanIkA=.a5ff48a4-160e-4638-915a-28a4dbf0b715@github.com>

On Tue, 4 Nov 2025 14:27:57 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
>  - Fix naming

I'd recommend to additionally run mach5 tier-6.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3488242701

From sspitsyn at openjdk.org  Tue Nov  4 22:41:18 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:41:18 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
Message-ID: <vR7s_qA4KIDxPjqxYFoDKmIAqenU_LILmD4Tr2pgwU8=.5716e1a8-1900-42d2-907c-d7f57e0708e2@github.com>

On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> 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 22 commits:
> 
>  - Add check for SingleStep events
>  - Merge branch 'master' into JDK-8369238
>  - fix to JvmtiHideSingleStepping
>  - Suggested fix in macroAssembler_ppc.cpp
>  - Improve comment and assert msg
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3418852425

From sspitsyn at openjdk.org  Tue Nov  4 22:41:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 4 Nov 2025 22:41:20 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v14]
In-Reply-To: <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <AobXZVV0x8-1GfnzdnY-D21GBDiLYc8Zy0ZmgakZV48=.175fef74-52ea-4fba-9f73-89680be21b4a@github.com>
 <LcEBInGRyZWU8cGPJ9UsY7e80Bt4iuPOVaqpDvQd6wY=.477b3511-517b-4d6a-a355-61ec65010018@github.com>
 <VG_RAxmnHcPnUVQI7EBYMIHKnvtU8r1t8INuNjpfKKY=.917a3276-95c0-4982-ae7a-380963b9495c@github.com>
Message-ID: <CyU-vZ-DK4lL1hzptQL8ISdjoNLqPGAozPFVgFNTRv4=.a6296035-c3b4-403c-a488-db6a63dca16a@github.com>

On Tue, 4 Nov 2025 21:23:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/SingleStepKlassInit/libSingleStepKlassInit.cpp line 38:
>> 
>>> 36: SingleStep(jvmtiEnv *jvmti, JNIEnv* jni, jthread thread,
>>> 37:            jmethodID method, jlocation location) {
>>> 38: }
>> 
>> Q: Would it make sense to verify that `SingleStep` events are posted or not?
>
> Good idea, I added a check for it. Let me know if that works.

Thanks! It is good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2492228658

From pchilanomate at openjdk.org  Tue Nov  4 23:35:55 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 23:35:55 GMT
Subject: RFR: 8369238: Allow virtual thread preemption on some common class
 initialization paths [v15]
In-Reply-To: <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
 <EwvkN1elIW-rTC-4dmZgwiVbA_gNFFLxb3QuDsoBgD4=.9a7ee2e4-20bd-4bf1-b9e4-00c26112a40d@github.com>
Message-ID: <lfcJgXrHP0jBeObaX7-9Aex071uKMQ6IIibSiBtcndg=.ba41e77c-9443-4baf-913f-ff9dbd6d28d0@github.com>

On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
>> 
>> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
>> 
>> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
>> 
>> ### Summary of implementation
>> 
>> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
>> 
>> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
>> 
>> ### Notes
>> 
>> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon...
>
> 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 22 commits:
> 
>  - Add check for SingleStep events
>  - Merge branch 'master' into JDK-8369238
>  - fix to JvmtiHideSingleStepping
>  - Suggested fix in macroAssembler_ppc.cpp
>  - Improve comment and assert msg
>  - More fixes from David's comments
>  - Merge branch 'master' into JDK-8369238
>  - add const to references
>  - Improve comment in anchor_mark_set_pd
>  - More comments from Coleen
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198

Thanks everyone for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3488372018

From pchilanomate at openjdk.org  Tue Nov  4 23:35:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 4 Nov 2025 23:35:58 GMT
Subject: Integrated: 8369238: Allow virtual thread preemption on some common
 class initialization paths
In-Reply-To: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
References: <Rd8wV59sD9o__8DuvXVSzJhdynFzx0Xz9perSQY_WWU=.90407bf8-30f2-4f25-bd89-a29133c872fc@github.com>
Message-ID: <uBoqZEVMoW7Qe0xjtksGNookxMDWSiNTxf0iIYJ7Ygo=.bc63a4b1-97df-4386-8610-617103f46ed2@github.com>

On Tue, 14 Oct 2025 13:42:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized.
> 
> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too.
> 
> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`.
> 
> ### Summary of implementation
> 
> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too.
> 
> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). 
> 
> ### Notes
> 
> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In...

This pull request has now been integrated.

Changeset: c6a88155
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6a88155b519a5d0b22f6009e75a0e6388601756
Stats:     2373 lines in 102 files changed: 1928 ins; 125 del; 320 mod

8369238: Allow virtual thread preemption on some common class initialization paths

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Reviewed-by: sspitsyn, dholmes, coleenp, fbredberg

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

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

From dlong at openjdk.org  Tue Nov  4 23:50:40 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 4 Nov 2025 23:50:40 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>
Message-ID: <J7HkbLBXiSv9CuCgEJQtVZ1oL0MJQZcQ_B0KbVW2DE0=.25f54aa1-8802-4487-a61b-bc115edaa98e@github.com>

On Mon, 3 Nov 2025 09:29:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue.
>> 
>> Tests:
>>  mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product}
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments and post-cond

src/hotspot/share/oops/klass.hpp line 525:

> 523:     // So use alternate form of negation to avoid warning.
> 524:     uint result = candidates & (~candidates + 1);
> 525:     assert(((result - 1) & result) == 0, "post-condition");

Maybe use "must be power of 2" instead of  "post-condition".  Also, this value is never going to change.  Can we make the function `constexpr`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2492344606

From qpzhang at openjdk.org  Wed Nov  5 03:52:01 2025
From: qpzhang at openjdk.org (Patrick Zhang)
Date: Wed, 5 Nov 2025 03:52:01 GMT
Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when
 UseBlockZeroing is false [v4]
In-Reply-To: <MGiMcmDMuGsTDuPdqrAc8hdMRbkxm7SwjHRCsLqh8dg=.b4700324-db76-4de3-988d-368a38234fc0@github.com>
References: <pSbTemGu8e1IiEiqk0ENZ_GgEVyi-NoA2U01iK_dMDM=.a8308160-ba13-4b39-9696-93e1e3e6f67f@github.com>
 <ojYKlYh3GgnfdImR6oA93RRs-0uc0a7ukpb9fi5ZXsQ=.2ae7f457-9b3a-4768-babc-e1c92b532fab@github.com>
 <bxtYdFD36_D9PtwWyKKPkC2z7hxC4ArDiovwWOKaMhc=.8c858f44-2d75-40b8-b91c-bdda2ff85745@github.com>
 <AWBsjcYr3xUS5h2Tu_tu-3-qnp345tRxR4S_RVARYtA=.4d34e726-6753-47cd-92ef-00dd4bea87d9@github.com>
 <HSGgYMh0eXTLkfvMKIYvASej2QLJ5hA70uVS5I-utc4=.2b296425-2eda-4bdc-9966-e19cee59f82f@github.com>
 <gAsbTJvZ9KSYNDpyKOX_6vctaFKxh6pw9K93H_Qiks0=.cb832560-8130-4391-8d4c-576a0fcbad5f@github.com>
 <eXl4qSdHNo2yrfVLa8stDuAyn8O7Yiuf33RvvPC91wU=.7953ac01-fc0e-492d-967a-a615698e2736@github.com>
 <5Q-u2mZQot1qUYvX2QuOi2jGTxy8kb79Hb2e6d4zHx4=.6f7af4f7-1f65-43ac-a76d-ae8a4145c3b8@github.com>
 <PKPR7zFxLRpUdWQB4cu6msm5jQVYn6y05kZJtFmMSfY=.44dc76f1-f903-4d2d-a50b-4ce6f6c5c115@github.com>
 <MGiMcmDMuGsTDuPdqrAc8hdMRbkxm7SwjHRCsLqh8dg=.b4700324-db76-4de3-988d-368a38234fc0@github.com>
Message-ID: <MeKTKN_lwitLZxSqOkMLjSebAIBs49gocJkx5wIPFe0=.a5b04031-0fc2-46bd-9b88-1e9f31ffd5e6@github.com>

On Tue, 28 Oct 2025 12:08:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> > I would like to reiterate that I have no objection to the functions when the `-XX:+UseBlockZeroing` option is set, everything can keep as is. My point is that `BlockZeroingLowLimit` serves literally/specifically as a switch to control whether DC ZVA instructions are generated for clearing instances under a specified bytes size limitation, rather than for deciding between unrolling and callout. Therefore, it should NOT affect the code-gen results any longer when `-XX:-UseBlockZeroing` is set, should it?
>>> 
>>> It does not. When `-XX:-UseBlockZeroing` is set, `BlockZeroingLowLimit` is ignored.
>> 
>> 
>> zero_words does not check `UseBlockZeroing`, it directly compares `cnt` and `BlockZeroingLowLimit / BytesPerWord`.
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L6198C1-L6204C16
>> 
>> 
>> address MacroAssembler::zero_words(Register base, uint64_t cnt)
>> {
>>   assert(wordSize <= BlockZeroingLowLimit,
>>             "increase BlockZeroingLowLimit");
>>   address result = nullptr;
>>   if (cnt <= (uint64_t)BlockZeroingLowLimit / BytesPerWord) {
>> #ifndef PRODUCT
>> 
>> 
>> In contrast, the inner stub function does so.
>> 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#L669
>> 
>>   address generate_zero_blocks() {
>>     Label done;
>>     Label base_aligned;
>> 
>>     Register base = r10, cnt = r11;
>> 
>>     __ align(CodeEntryAlignment);
>>     StubId stub_id = StubId::stubgen_zero_blocks_id;
>>     StubCodeMark mark(this, stub_id);
>>     address start = __ pc();
>> 
>>     if (UseBlockZeroing) {
>
>> > > I would like to reiterate that I have no objection to the functions when the `-XX:+UseBlockZeroing` option is set, everything can keep as is. My point is that `BlockZeroingLowLimit` serves literally/specifically as a switch to control whether DC ZVA instructions are generated for clearing instances under a specified bytes size limitation, rather than for deciding between unrolling and callout. Therefore, it should NOT affect the code-gen results any longer when `-XX:-UseBlockZeroing` is set, should it?
>> > 
>> > 
>> > It does not. When `-XX:-UseBlockZeroing` is set, `BlockZeroingLowLimit` is ignored.
>> 
>> zero_words does not check `UseBlockZeroing`, it directly compares `cnt` and `BlockZeroingLowLimit / BytesPerWord`.
> 
> It doesn't need to because
> 
> 
>   if (!UseBlockZeroing && !FLAG_IS_DEFAULT(BlockZeroingLowLimit)) {
>     warning("BlockZeroingLowLimit has been ignored because UseBlockZeroing is disabled");
>     FLAG_SET_DEFAULT(BlockZeroingLowLimit, is_zva_enabled() ? (4 * VM_Version::zva_length()) : 256);
>   }
> 
> 
> That is to say, if a user sets `BlockZeroingLowLimit` and `-XX:-UseBlockZeroing`, then the user's `BlockZeroingLowLimit` is, rightly, ignored.

Hi @theRealAph and @adinn, please let me know if you have any additional comments on this PR, or advice to improve it. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3489152280

From duke at openjdk.org  Wed Nov  5 05:08:57 2025
From: duke at openjdk.org (Zihao Lin)
Date: Wed, 5 Nov 2025 05:08:57 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v8]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <dA_grlnr1fuY2jKiJ6CMzN-vKet0TN5grHMXBuFUNkM=.58192610-6853-4ec5-a28b-7df1abbdd383@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> I have done more work which remove slice paramater from StoreNode::make.
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

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

 - fix assert
 - add more assert
 - rid of access.addr().type()
 - Merge branch 'openjdk:master' into 8344116
 - Merge branch 'openjdk:master' into 8344116
 - Merge branch 'openjdk:master' into 8344116
 - Fix build
 - Fix test failed
 - 8344116: C2: remove slice parameter from LoadNode::make

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24258/files
  - new: https://git.openjdk.org/jdk/pull/24258/files/ea83736e..6d122039

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

  Stats: 526337 lines in 7522 files changed: 349612 ins; 122587 del; 54138 mod
  Patch: https://git.openjdk.org/jdk/pull/24258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24258/head:pull/24258

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

From jsjolen at openjdk.org  Wed Nov  5 05:09:16 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Nov 2025 05:09:16 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
Message-ID: <Dg5ZqTZIs7F6FFD0xk5uDz2b7Tzn42tgUxV26lP7xXs=.503c6bc4-2d21-42fb-a5aa-43125d2d32c7@github.com>

On Tue, 4 Nov 2025 19:07:32 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring to reduce code duplication

Changes requested by jsjolen (Reviewer).

test/hotspot/gtest/runtime/test_os.cpp line 744:

> 742:     EXPECT_TRUE(GtestUtils::is_memory_tagged_as_java(p, 1 * M))
> 743:       << "JVM memory allocated via os::reserve_memory should be tagged with VM_MEMORY_JAVA on macOS";
> 744: #endif

Move all of these snippets into one separate test

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

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3419863275
PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2492971686

From duke at openjdk.org  Wed Nov  5 05:09:05 2025
From: duke at openjdk.org (Zihao Lin)
Date: Wed, 5 Nov 2025 05:09:05 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <F05XhIeM-2KYesDRQ4dtGv2iui5GvLh3hF_udP5IFjM=.8fd0ede3-df42-4d10-9aa9-85e6ea500d4a@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
 <F05XhIeM-2KYesDRQ4dtGv2iui5GvLh3hF_udP5IFjM=.8fd0ede3-df42-4d10-9aa9-85e6ea500d4a@github.com>
Message-ID: <xzuk2iJXY3XxK1LcXNJA_Xo9Q5anRUHbpiQzkyXwp_0=.bc54f82f-d7f3-4090-85bc-9735c045e8b6@github.com>

On Tue, 8 Apr 2025 13:04:12 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into 8344116
>>  - Fix build
>>  - Fix test failed
>>  - 8344116: C2: remove slice parameter from LoadNode::make
>
> src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 223:
> 
>> 221:     MergeMemNode* mm = opt_access.mem();
>> 222:     PhaseGVN& gvn = opt_access.gvn();
>> 223:     Node* mem = mm->memory_at(gvn.C->get_alias_index(access.addr().type()));
> 
> Can we get rid of all uses of `access.addr().type()`?

Get rid of all access.addr().type()

> src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp line 105:
> 
>> 103:     // stores.  In theory we could relax the load from ctrl() to
>> 104:     // no_ctrl, but that doesn't buy much latitude.
>> 105:     Node* card_val = __ load( __ ctrl(), card_adr, TypeInt::BYTE, T_BYTE);
> 
> We could asssert that `C->get_alias_index(kit->type(card_adr) == Compile::AliasIdxRaw`, that is that computed slice is the same as hardcoded slide. Similar asserts could be added for every location where a slice/address type is removed in this patch.

Sure, I add more assert for this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2484816831
PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2492987998

From krk at openjdk.org  Wed Nov  5 08:36:30 2025
From: krk at openjdk.org (Kerem Kat)
Date: Wed, 5 Nov 2025 08:36:30 GMT
Subject: Integrated: 8334866: Improve Speed of ElfDecoder source search
In-Reply-To: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
References: <Z9CQI2aDfYxYBIU5UWy8NaO8e2NleDY8MxvdNTGCE6Q=.09df3d49-1389-42d8-9403-7ca2fbe67087@github.com>
Message-ID: <j7VLNTkbz1fYNl6fI2xDy6KhcfaMoBPLo0NScd9S6qA=.902b0ca4-5ac1-44e1-a3b6-879b506f6438@github.com>

On Wed, 17 Sep 2025 10:14:09 GMT, Kerem Kat <krk at openjdk.org> wrote:

> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err.
> 
> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object.
> 
> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method.

This pull request has now been integrated.

Changeset: dddfcd03
Author:    Kerem Kat <krk at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dddfcd03aa30514d63eceff707d48bff35e93c56
Stats:     229 lines in 2 files changed: 216 ins; 4 del; 9 mod

8334866: Improve Speed of ElfDecoder source search

Reviewed-by: shade, chagedorn

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

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

From jsjolen at openjdk.org  Wed Nov  5 08:37:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Nov 2025 08:37:22 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v16]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len 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 31 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into operands-again
 - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
 - Fix naming
 - Serguei comments
 - Revert change
 - Some nits
 - Fix copyright
 - Move BSMAttribute BSMAttributeEntries to own header file
 - Merge remote-tracking branch 'origin/operands-again' into operands-again
 - Apply suggestions from code review
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - ... and 21 more: https://git.openjdk.org/jdk/compare/1e0cd337...57f0093e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/219ef346..57f0093e

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

  Stats: 278590 lines in 3431 files changed: 200223 ins; 55822 del; 22545 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From haosun at openjdk.org  Wed Nov  5 08:40:21 2025
From: haosun at openjdk.org (Hao Sun)
Date: Wed, 5 Nov 2025 08:40:21 GMT
Subject: RFR: 8371205: AArch64: Remove unused cmpxchg* methods
In-Reply-To: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
References: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
Message-ID: <0Z-2cj3w01eEKIJBZEMZ7FH3Hl2ECI0lCX_fv77fO_4=.ef49a25c-d70c-4dfb-9233-eec4b633d5d9@github.com>

On Tue, 4 Nov 2025 13:41:04 GMT, Ruben <duke at openjdk.org> wrote:

> Since JDK-8364406, the AArch64 macroAssembler method cmpxchg_obj_header is no longer used. The method cmpxchgptr is used by cmpxchg_obj_header however is not used by any other method so can be removed alongside cmpxchgptr.
> cmpxchgw is also unused and can be removed.

Marked as reviewed by haosun (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28131#pullrequestreview-3420572157

From jsikstro at openjdk.org  Wed Nov  5 09:32:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 5 Nov 2025 09:32:10 GMT
Subject: RFR: 8370813: Deprecate AggressiveHeap
Message-ID: <_tMyItJZEwt4YJq9EYQuDBVIs_1l4jFPXhncYIHy2TE=.337902e6-ed5d-46e5-8344-d858407acbee@github.com>

Hello,

This RFE deprecates the `AggressiveHeap` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behavior in the future.

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

Commit messages:
 - 8370813: Deprecate AggressiveHeap

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

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

From ayang at openjdk.org  Wed Nov  5 10:16:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Nov 2025 10:16:39 GMT
Subject: RFR: 8371321: Remove unused last arg of
 BarrierSetAssembler::arraycopy_epilogue
Message-ID: <YWeHOmD1oSnPtxDgRhA3MhhVKes91gBrB65csw6Ttz0=.5931ac68-c355-4f0c-9463-32e584593f8d@github.com>

Removing effectively dead code.

Test: tier1, GHA

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

Commit messages:
 - remove-barrier-arg

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

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

From jsikstro at openjdk.org  Wed Nov  5 10:25:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 5 Nov 2025 10:25:19 GMT
Subject: RFR: 8370843: Deprecate AlwaysActAsServerClassMachine and
 NeverActAsServerClassMachine
Message-ID: <gQx26_tvLu9cM2ssV3MMn6osKtDKLGmmWKUMxqnFu2Q=.32b46d51-9c5e-4769-96bc-86c6f66777d2@github.com>

Hello,

This RFE deprecates the `AlwaysActAsServerClassMachine` and `NeverActAsServrClassMachine` flags in JDK 26. Please see the CSR for specific details on why these flag are being deprecated.

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

Commit messages:
 - 8370843: Deprecate AlwaysActAsServerClassMachine and NeverActAsServerClassMachine

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

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

From fandreuzzi at openjdk.org  Wed Nov  5 10:33:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 5 Nov 2025 10:33:04 GMT
Subject: RFR: 8371321: Remove unused last arg of
 BarrierSetAssembler::arraycopy_epilogue
In-Reply-To: <YWeHOmD1oSnPtxDgRhA3MhhVKes91gBrB65csw6Ttz0=.5931ac68-c355-4f0c-9463-32e584593f8d@github.com>
References: <YWeHOmD1oSnPtxDgRhA3MhhVKes91gBrB65csw6Ttz0=.5931ac68-c355-4f0c-9463-32e584593f8d@github.com>
Message-ID: <_jy1EXbNvAcvuv1R0jwOUXuE7dQX1YSLjsnM5ijyBNM=.20d22624-f6ff-4de7-8701-7ff1536ffa5b@github.com>

On Wed, 5 Nov 2025 10:10:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing effectively dead code.
> 
> Test: tier1, GHA

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/28146#pullrequestreview-3421109827

From ayang at openjdk.org  Wed Nov  5 10:34:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Nov 2025 10:34:03 GMT
Subject: RFR: 8370843: Deprecate AlwaysActAsServerClassMachine and
 NeverActAsServerClassMachine
In-Reply-To: <gQx26_tvLu9cM2ssV3MMn6osKtDKLGmmWKUMxqnFu2Q=.32b46d51-9c5e-4769-96bc-86c6f66777d2@github.com>
References: <gQx26_tvLu9cM2ssV3MMn6osKtDKLGmmWKUMxqnFu2Q=.32b46d51-9c5e-4769-96bc-86c6f66777d2@github.com>
Message-ID: <T2WDfr_5Sh37_BVKFEqQJbZUrTtfKwiL_Ca1K86q7xc=.cf753f7e-bb9d-4a0b-8a82-a7aab830a6f0@github.com>

On Wed, 5 Nov 2025 10:16:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE deprecates the `AlwaysActAsServerClassMachine` and `NeverActAsServrClassMachine` flags in JDK 26. Please see the CSR for specific details on why these flag are being deprecated.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28148#pullrequestreview-3421115339

From ayang at openjdk.org  Wed Nov  5 10:35:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Nov 2025 10:35:04 GMT
Subject: RFR: 8370813: Deprecate AggressiveHeap
In-Reply-To: <_tMyItJZEwt4YJq9EYQuDBVIs_1l4jFPXhncYIHy2TE=.337902e6-ed5d-46e5-8344-d858407acbee@github.com>
References: <_tMyItJZEwt4YJq9EYQuDBVIs_1l4jFPXhncYIHy2TE=.337902e6-ed5d-46e5-8344-d858407acbee@github.com>
Message-ID: <rRR5u2oMWgKKwBYsXt67MDUOnR5kDxXdZtwOxrsCAFo=.1676e37c-f1e9-4244-aba9-6539dd7f018e@github.com>

On Wed, 5 Nov 2025 09:24:51 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE deprecates the `AggressiveHeap` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behavior in the future.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28144#pullrequestreview-3421117544

From duke at openjdk.org  Wed Nov  5 10:57:18 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 10:57:18 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <j7lqJEM_ZYzvt4DXkF1gPlV1tHCaPwN_KQAMsueuHxk=.1ab0ac81-b18a-4eff-bb26-9262c2426858@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

@ruben-arm 
Your change (at version 359c2f185c7add1cac98523f4325a7896e8bd3e0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3490519353

From duke at openjdk.org  Wed Nov  5 11:58:32 2025
From: duke at openjdk.org (Ruben)
Date: Wed, 5 Nov 2025 11:58:32 GMT
Subject: Integrated: 8365047: Remove exception handler stub code in C2
In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
Message-ID: <NlWZi6MCksCD41c16o6QfIm9vGv29jWy6zWj-inNkPE=.9bf73f8c-3b8d-4fc6-b537-ef2fced46d89@github.com>

On Thu, 7 Aug 2025 15:49:20 GMT, Ruben <duke at openjdk.org> wrote:

> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

This pull request has now been integrated.

Changeset: 3e3822ad
Author:    Ruben Ayrapetyan <ruben.ayrapetyan at arm.com>
Committer: Evgeny Astigeevich <eastigeevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e3822ad7eadbb3d86a3b94a6bd858f8c8ef9364
Stats:     569 lines in 41 files changed: 268 ins; 216 del; 85 mod

8365047: Remove exception handler stub code in C2

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, dlong, dfenacci, adinn, fyang, aph

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

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

From jvernee at openjdk.org  Wed Nov  5 12:17:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Nov 2025 12:17:32 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
Message-ID: <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>

On Tue, 4 Nov 2025 15:39:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments Patricio
>
> Thanks for the reviews!

> @JornVernee: The new test has failed on AIX:
> 
> ```
> [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
> [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
> [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
> ```
> 
> Should I file a new issue?

Please file a new issue. We haven't seen this failure in our CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3490884908

From coleenp at openjdk.org  Wed Nov  5 12:50:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 12:50:26 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v16]
In-Reply-To: <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <Q3LdlxN9FjB2wxrazQO6S2xqdU2RbdQ2eE_bOjTQ_IQ=.e5c542e1-8c91-4bd3-8937-150a618c45d2@github.com>
Message-ID: <N4u6yCmwx4e1kR7RDL9PBPku50w4urxw73iGk_bY7uo=.ad4721d3-7ea1-43c2-b5d8-000ec2c7c794@github.com>

On Wed, 5 Nov 2025 08:37:22 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len 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 31 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into operands-again
>  - It's fine to initialize the iterator with null, it's not fine to reserve an entry if it's null
>  - Fix naming
>  - Serguei comments
>  - Revert change
>  - Some nits
>  - Fix copyright
>  - Move BSMAttribute BSMAttributeEntries to own header file
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/edfdae41...57f0093e

This is excellent work!  I had a couple of small suggested changes, but am happy to approve it.

src/hotspot/share/oops/bsmAttribute.hpp line 28:

> 26: #define SHARE_OOPS_BSMATTRIBUTE_HPP
> 27: 
> 28: #include "classfile/classLoaderData.hpp"

I think you can forward declare ClassLoaderData rather than include the whole file here.

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3421758555
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494308893

From coleenp at openjdk.org  Wed Nov  5 12:50:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 12:50:30 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
Message-ID: <8WVVrT5cKKUY1wGnTvxzj-8FFM-dZnYtuActIQRXZUQ=.0f11587c-e06f-47ee-93e4-bd7a5e7fc16f@github.com>

On Wed, 8 Oct 2025 21:09:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> src/hotspot/share/oops/bsmAttribute.inline.hpp line 34:
> 
>> 32:       _cur_array + BSMAttributeEntry::u2s_required(argc) > insert_into->bootstrap_methods()->length()) {
>> 33:     return nullptr;
>> 34:   }
> 
> Nit: This check needs a comment. Also, I'd suggest to add a guarantee here instead of returning `nullptr`.

I agree with this comment - is returning null going to crash somewhere down the line?  Is this an overflow?

> src/hotspot/share/oops/constantPool.hpp line 94:
> 
>> 92:   InstanceKlass*       _pool_holder; // the corresponding class
>> 93: 
>> 94:   BSMAttributeEntries _bsmaentries;
> 
> Nit: Suggestion to rename: `_bsmaentries` => `_bsm_entries`.

This is a good suggestion for a minor change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494322202
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494323677

From coleenp at openjdk.org  Wed Nov  5 12:50:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 12:50:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <8Sx_Zy0yHDLxhRd-D9VdD4bsS2fnQmZd20RGlrCpsFg=.bf22f172-50de-4143-b6be-752ef899e4b8@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <B8YLEaCzbovLCdbC5yRomtpq3xKtk4aEPVjs_NtUDp4=.0aa4fa8f-5ae6-4e35-acfc-cc2df97c219e@github.com>
 <q1yO1HHO2QGynbP1uz7YfNpqqcneGPUiG3JxxGIrtwA=.4bb75050-10ee-469b-b3a3-3bcb2f56cc67@github.com>
 <8Sx_Zy0yHDLxhRd-D9VdD4bsS2fnQmZd20RGlrCpsFg=.bf22f172-50de-4143-b6be-752ef899e4b8@github.com>
Message-ID: <9KAeG5WWY5hMK4Yjl0i3G9tCWreCYe-b8y-BeHnXSdY=.6c742a39-87f8-40e9-8725-be05bb5f36f4@github.com>

On Tue, 4 Nov 2025 21:52:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Yes please I like the full names if possible rather than abbreviations.
>
>> I'm keeping it verbose, as that's the general style of this file.
> 
> Okay. Local naming consistency is important too.
> 
>> Yes please I like the full names if possible rather than abbreviations.
> 
> Here the problem is not about full names vs abbreviations. It is about naming inconsistency with all these `BSM` related code. There are already many places with the `BSM` abbreviation. But I agree it is better to maintain the local style here.

The abbreviation in the middle of the word makes me find it hard to say in English in this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2494315140

From roland at openjdk.org  Wed Nov  5 13:23:18 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 5 Nov 2025 13:23:18 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v8]
In-Reply-To: <dA_grlnr1fuY2jKiJ6CMzN-vKet0TN5grHMXBuFUNkM=.58192610-6853-4ec5-a28b-7df1abbdd383@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <dA_grlnr1fuY2jKiJ6CMzN-vKet0TN5grHMXBuFUNkM=.58192610-6853-4ec5-a28b-7df1abbdd383@github.com>
Message-ID: <Wm8EB4qNUykX-JeRghUfU7kHilCpI2T-CJ7B0jxxBoc=.0900073f-fa43-493b-956d-a2d6096aeef0@github.com>

On Wed, 5 Nov 2025 05:08:57 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> I have done more work which remove slice paramater from StoreNode::make.
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - fix assert
>  - add more assert
>  - rid of access.addr().type()
>  - Merge branch 'openjdk:master' into 8344116
>  - Merge branch 'openjdk:master' into 8344116
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

Can we remove `C2AccessValuePtr`  entirely and use:

Node* _addr;

where, currently, there's:

C2AccessValuePtr& _addr;

?

src/hotspot/share/opto/callnode.cpp line 1740:

> 1738:     Node* klass_node = in(AllocateNode::KlassNode);
> 1739:     Node* proto_adr = phase->transform(new AddPNode(klass_node, klass_node, phase->MakeConX(in_bytes(Klass::prototype_header_offset()))));
> 1740:     mark_node = LoadNode::make(*phase, control, mem, proto_adr, TypeX_X, TypeX_X->basic_type(), MemNode::unordered);

We could assert that C->get_alias_index(kit->type(card_adr) == Compile::AliasIdxRaw

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

PR Review: https://git.openjdk.org/jdk/pull/24258#pullrequestreview-3421940817
PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2494424924

From mdoerr at openjdk.org  Wed Nov  5 13:30:15 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 5 Nov 2025 13:30:15 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
 <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
Message-ID: <fRuhTAKiblYVhQ-OOIYwGQAbRcXJrm2pGomSaWxNZ-g=.ebd8170f-5842-4cdf-9834-4621080512b9@github.com>

On Wed, 5 Nov 2025 12:14:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > @JornVernee: The new test has failed on AIX:
> > ```
> > [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
> > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
> > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
> > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
> > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
> > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
> > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
> > [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
> > [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Should I file a new issue?
> 
> Please file a new issue. We haven't seen this failure in our CI.

Filed [JDK-8371340](https://bugs.openjdk.org/browse/JDK-8371340). Is the test supposed to work on platforms other than linux? It passes on linux PPC64 (both, big and little endian).

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3491224600

From duke at openjdk.org  Wed Nov  5 13:55:26 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 13:55:26 GMT
Subject: RFR: 8371205: AArch64: Remove unused cmpxchg* methods
In-Reply-To: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
References: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
Message-ID: <v1Takrmun4F2sbBWgDvxNy2ee-oaMaDp-AQy5_I8gtk=.410516fa-9c16-4508-8483-63a15a3c7028@github.com>

On Tue, 4 Nov 2025 13:41:04 GMT, Ruben <duke at openjdk.org> wrote:

> Since JDK-8364406, the AArch64 macroAssembler method cmpxchg_obj_header is no longer used. The method cmpxchgptr is used by cmpxchg_obj_header however is not used by any other method so can be removed alongside cmpxchgptr.
> cmpxchgw is also unused and can be removed.

@ruben-arm 
Your change (at version d87d96222c8918f982313e84e79d48c476aa7728) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28131#issuecomment-3491336974

From duke at openjdk.org  Wed Nov  5 13:59:58 2025
From: duke at openjdk.org (Ruben)
Date: Wed, 5 Nov 2025 13:59:58 GMT
Subject: Integrated: 8371205: AArch64: Remove unused cmpxchg* methods
In-Reply-To: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
References: <kWWdgZNFBOdMxEoVKOlQ1bmKp3wRoakWRtsBwtn-JQ8=.77ab9d18-9ef9-4dfd-a374-06bd0635424b@github.com>
Message-ID: <VA2ckzyzhnpzF7-OqOXuxM4svF050HChNez8MqTgk5Q=.b275f506-2265-420d-854e-9401ad106fcf@github.com>

On Tue, 4 Nov 2025 13:41:04 GMT, Ruben <duke at openjdk.org> wrote:

> Since JDK-8364406, the AArch64 macroAssembler method cmpxchg_obj_header is no longer used. The method cmpxchgptr is used by cmpxchg_obj_header however is not used by any other method so can be removed alongside cmpxchgptr.
> cmpxchgw is also unused and can be removed.

This pull request has now been integrated.

Changeset: c9a98169
Author:    Samuel Chee <samche01 at arm.com>
Committer: Fei Gao <fgao at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9a98169cb79df235316cb38a804d539044ea57e
Stats:     101 lines in 2 files changed: 0 ins; 101 del; 0 mod

8371205: AArch64: Remove unused cmpxchg* methods

Co-authored-by: Samuel Chee <samche01 at arm.com>
Reviewed-by: aph, kbarrett, haosun

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

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

From egahlin at openjdk.org  Wed Nov  5 14:18:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 5 Nov 2025 14:18:17 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
 <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
 <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU
 6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>
Message-ID: <XuUowo5n1fE1BP8RzyifQbT9wzt5aK73ssUGeGpVkOw=.d2f3da1a-b61a-435a-b7e1-9c29004e4ad6@github.com>

On Tue, 4 Nov 2025 21:32:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> > The elapsed fields, are they the total since the JVM started or from the last round?
> 
> All fields in `EventStringDeduplicationStatistics` contain the diff since the last round:
> 

Since the event has a duration, I wonder if the event should be called StringDeduplication, similar to Compilation or GarbageCollection? As I understand it, the event represents a round of deduplication. All other events called statistics are instantaneous events.

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

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3491455070

From coleenp at openjdk.org  Wed Nov  5 14:32:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Nov 2025 14:32:01 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v4]
In-Reply-To: <Cm-LtASdiao6yU339p7msFgrLRytiTXEQ7w_GFPUlu4=.efbf9c02-157f-45e6-905d-caf314c4589c@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <Cm-LtASdiao6yU339p7msFgrLRytiTXEQ7w_GFPUlu4=.efbf9c02-157f-45e6-905d-caf314c4589c@github.com>
Message-ID: <D0Ib2OwtClhWamHTNxArRD4ED-yImdvNvuVsKHtvLKM=.c74643cd-f891-4b31-9e0b-256fe4f40759@github.com>

On Mon, 3 Nov 2025 10:05:35 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Update two, after the review
>  - Update after review
>  - Small arm32 fix
>  - Small include line fix
>  - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

I believe you've addressed all of David's comments and mine, and we can have a new PR for moving and additional work we're going to do with the ObjectMonitorTable.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3422419032

From fbredberg at openjdk.org  Wed Nov  5 14:39:22 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 5 Nov 2025 14:39:22 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <_96H3JAsfT8uJ5oY7PEtsiX4tNZPy0VRgDRW6YjfBCo=.aa04fd8b-9520-463a-9677-a73a52244ef3@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>
 <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
 <_96H3JAsfT8uJ5oY7PEtsiX4tNZPy0VRgDRW6YjfBCo=.aa04fd8b-9520-463a-9677-a73a52244ef3@github.com>
Message-ID: <UN2hCH8ujb0ODGR4lBLzVGC9J6k6PeHFCTenEYvBg34=.8fcf5861-75ee-433b-8e94-1e632865d7ac@github.com>

On Fri, 31 Oct 2025 13:52:53 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 287:
>> 
>>> 285:   _last_async_deflation_time_ns = os::javaTimeNanos();
>>> 286: 
>>> 287:   ObjectSynchronizer::create_om_table();
>> 
>> The original code should effectively be inlined here:
>> 
>> if (UseObjectMonitorTable) {
>>   ObjectMonitorTable::create();
>> }
>
> Tried to do a quick fix for this, but `ObjectMonitorTable` is not known at this point, and forward declaring it turned out to be a mess. So, since we agreed to move out `ObjectMonitorTable` to a separate file, I think this can be postponed until that file has been created.

Created: [JDK-8371347](https://bugs.openjdk.org/browse/JDK-8371347) "Move the ObjectMonitorTable to a separate new file"

>> src/hotspot/share/runtime/synchronizer.cpp line 1838:
>> 
>>> 1836:   if (!UseObjectMonitorTable) {
>>> 1837:     return;
>>> 1838:   }
>> 
>> This should move to the caller and be replaced with an assertion at this level. Though you don't need to introduce this method at all as the caller can call `OMT::create` directly.
>
> Same as last answer, this is easily done once we have moved `ObjectMonitorTable` to a separate file, but not until then.

Created: [JDK-8371347](https://bugs.openjdk.org/browse/JDK-8371347) "Move the ObjectMonitorTable to a separate new file"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2494806413
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2494808134

From fbredberg at openjdk.org  Wed Nov  5 14:39:24 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 5 Nov 2025 14:39:24 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v4]
In-Reply-To: <WwyMZzIHAxiUCer6euFB5OzJk6iiFO4ysBAT4csfTlA=.97b29ebf-87ad-4cea-9896-495dd8140056@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
 <00xzxB3fxjSbmCZCQCu_ZEClnyxq2yfPfF-9SKJXoIc=.b45bec0f-164d-4604-87e2-d69ce072533b@github.com>
 <WbEr0-F2ZKolF2az6-MfdcG03WqKZ18kvk4axRvmjtk=.7ee9eb10-1b41-448d-a6b6-265a72eb0417@github.com>
 <WwyMZzIHAxiUCer6euFB5OzJk6iiFO4ysBAT4csfTlA=.97b29ebf-87ad-4cea-9896-495dd8140056@github.com>
Message-ID: <7ZEE720IklvXdhfxVI_Bxz2IwcY_CoOwPJHtk9PZ1bw=.deca3dd9-c7d6-4fbc-865d-470cd2cf96b9@github.com>

On Mon, 27 Oct 2025 12:47:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I agree on both counts: move it to a new file in a new PR.
>
> Follow-on cleanup would be fine for moving this.

Created: [JDK-8371347](https://bugs.openjdk.org/browse/JDK-8371347) "Move the ObjectMonitorTable to a separate new file"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2494797881

From stefank at openjdk.org  Wed Nov  5 14:46:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Nov 2025 14:46:54 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
Message-ID: <iRXfFqjf2iwzPIiSqGVsPpaljbSZ65nqrn5R2udX1Ks=.b6e8e8e7-4cf0-451e-8b63-625c5e6ff11e@github.com>

On Tue, 4 Nov 2025 19:07:32 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring to reduce code duplication

> I think the changes are minor to assert the tagging on allocation while we are doing that and do not require extra tests, please let me know if you still think otherwise.

I think otherwise. Please put the test somewhere else.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3422524897

From aboldtch at openjdk.org  Wed Nov  5 15:03:57 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 5 Nov 2025 15:03:57 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
Message-ID: <Jih2u7ZS3vtrXg31ea7_6tvvKQkoyW1Gc4vOu5ek7Bw=.2556609c-ef77-4f79-81be-6cc132ce1eda@github.com>

On Tue, 4 Nov 2025 19:07:32 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring to reduce code duplication

src/hotspot/os/bsd/os_bsd.hpp line 38:

> 36: // Shared constant for mmap file descriptor used across BSD OS implementations
> 37: static constexpr int bsd_mmap_fd =
> 38: #ifdef __APPLE__

Are these defines always available (present and future)? Or should they be guarded?
Suggestion:

#if defined(__APPLE__) && defined(VM_MAKE_TAG) && defined(VM_MEMORY_JAVA)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2494939644

From kvn at openjdk.org  Wed Nov  5 15:52:07 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 5 Nov 2025 15:52:07 GMT
Subject: RFR: 8370843: Deprecate AlwaysActAsServerClassMachine and
 NeverActAsServerClassMachine
In-Reply-To: <gQx26_tvLu9cM2ssV3MMn6osKtDKLGmmWKUMxqnFu2Q=.32b46d51-9c5e-4769-96bc-86c6f66777d2@github.com>
References: <gQx26_tvLu9cM2ssV3MMn6osKtDKLGmmWKUMxqnFu2Q=.32b46d51-9c5e-4769-96bc-86c6f66777d2@github.com>
Message-ID: <6hEjGUOSdQZLd59jx1J-HI5n0-54TlN469u5_2F5HBU=.00ea17df-a97f-457f-8040-fc2392d96075@github.com>

On Wed, 5 Nov 2025 10:16:40 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE deprecates the `AlwaysActAsServerClassMachine` and `NeverActAsServrClassMachine` flags in JDK 26. Please see the CSR for specific details on why these flag are being deprecated.

Good.

@jsikstro do we have any test which use these flags?

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28148#pullrequestreview-3422967622
PR Comment: https://git.openjdk.org/jdk/pull/28148#issuecomment-3492001894

From bulasevich at openjdk.org  Wed Nov  5 16:03:41 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 5 Nov 2025 16:03:41 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <HJ8Hu7SwYhkfmwa2vUVyoYzNa-nWOzJWFDC_C8T_A6w=.30ccf41d-efd0-4b16-90fb-1dd82e57c26b@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>
 <C7IeRg12yJal0kkhCoHs-uIs4p-rHoEk6K4Xrs9xDgA=.d43828e7-5de7-4375-90c3-2f5c25c6af0a@github.com>
 <HJ8Hu7SwYhkfmwa2vUVyoYzNa-nWOzJWFDC_C8T_A6w=.30ccf41d-efd0-4b16-90fb-1dd82e57c26b@github.com>
Message-ID: <aSavq-NVJPJv2UXn5NLmS-C5i-s8Hz_XTYP2Pg97zW4=.730b943f-a7b4-4b4d-b4a7-8dd2eae9ac3d@github.com>

On Tue, 4 Nov 2025 13:46:22 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/abstract_vm_version.hpp line 195:
>> 
>>> 193: 
>>> 194:   // Is recursive fast locking implemented for this platform?
>>> 195:   constexpr static bool supports_recursive_fast_locking() { return false; }
>> 
>> Next cleanup: this is supported on all platforms now, so we can get rid of this migration aid.
>
> Not sure we can do that, since I don't find any implementation of recursive fast locking on ARM32.
> @bulasevich Any comment on this?

Recursive lightweight locking (JDK-8319796) was implemented for x86, AArch64, PPC64LE, RISC-V64, and S390, but not for ARM32.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2495179254

From jvernee at openjdk.org  Wed Nov  5 16:11:14 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 5 Nov 2025 16:11:14 GMT
Subject: RFR: 8370344: Arbitrary Java frames on stack during scoped access
 [v6]
In-Reply-To: <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
References: <lg7iuOnzwsbWPAZ5yhqlSHaUz1hTJ2Tg3Jnk4--6LQs=.46f4fe02-ad29-4796-a51d-5495e048d05a@github.com>
 <DlsFz4kPrrOoKvV345RASaPMoXJH5ZCScwvK_V5afDY=.61cf3543-d25f-480f-9761-fdad7254343d@github.com>
 <-y-NiC9PnzyWtkppcs3ffnYGeWucnYSOqrtWOChOFNs=.904d1e0f-dfb0-4427-af71-c2fad0355aba@github.com>
 <qeWTOOJ8yRtbuu9hAPzcnA7YScnCUhEurFS-0nkLb80=.87815487-d39f-4131-b5ae-b25f73829c0c@github.com>
Message-ID: <zFkGU6kSxenXCj2kGPyjMxB0cOXADIDIbTww8FOA1FQ=.20ab2d90-0cdf-4c37-b6f3-ba84fbe517ea@github.com>

On Wed, 5 Nov 2025 12:14:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Thanks for the reviews!
>
>> @JornVernee: The new test has failed on AIX:
>> 
>> ```
>> [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
>> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
>> [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
>> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
>> [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
>> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
>> [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
>> [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
>> [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
>> ```
>> 
>> Should I file a new issue?
> 
> Please file a new issue. We haven't seen this failure in our CI.

> > > @JornVernee: The new test has failed on AIX:
> > > ```
> > > [fork] FATAL ERROR in native method: Wrong object class or methodID passed to JNI call
> > > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidStateRaw(java.base at 26-internal/MemorySessionImpl.java:206)
> > > [fork] 	at jdk.internal.foreign.MemorySessionImpl.checkValidState(java.base at 26-internal/MemorySessionImpl.java:215)
> > > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeInternal(java.base at 26-internal/SegmentFactories.java:189)
> > > [fork] 	at jdk.internal.foreign.SegmentFactories.allocateNativeSegment(java.base at 26-internal/SegmentFactories.java:181)
> > > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:56)
> > > [fork] 	at jdk.internal.foreign.ArenaImpl.allocate(java.base at 26-internal/ArenaImpl.java:31)
> > > [fork] 	at java.lang.foreign.SegmentAllocator.allocate(java.base at 26-internal/SegmentAllocator.java:644)
> > > [fork] 	at TestSharedCloseJvmti$EventDuringScopedAccessRunner.<clinit>(TestSharedCloseJvmti.java:75)
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > Should I file a new issue?
> > 
> > 
> > Please file a new issue. We haven't seen this failure in our CI.
> 
> Filed [JDK-8371340](https://bugs.openjdk.org/browse/JDK-8371340). Is the test supposed to work on platforms other than linux? It passes on linux PPC64 (both, big and little endian).

Yes, it is supposed to work on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/27919#issuecomment-3492077297

From fbredberg at openjdk.org  Wed Nov  5 17:35:16 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 5 Nov 2025 17:35:16 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v5]
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
 - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
 - Update two, after the review
 - Update after review
 - Small arm32 fix
 - Small include line fix
 - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

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

Changes: https://git.openjdk.org/jdk/pull/27915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=04
  Stats: 2981 lines in 80 files changed: 1263 ins; 1429 del; 289 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

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

From mullan at openjdk.org  Wed Nov  5 17:50:23 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 5 Nov 2025 17:50:23 GMT
Subject: RFR: 8371259: ML-DSA AVX2 and AVX512 intrinsics and improvements
In-Reply-To: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
References: <jBsJutj_t6Vi46rFkiQ9ZSOd32CgE2INtN6fdfnSHTQ=.6ee0f769-4a43-4aff-9830-48539aa1ded0@github.com>
Message-ID: <n9EWu15d7W_eVsHkCkT350i5tVZPIyA3XrjL6jxRVKc=.a801b517-06a4-46c1-a2d0-e813232505c1@github.com>

On Tue, 4 Nov 2025 16:38:49 GMT, Volodymyr Paprotski <vpaprotski at openjdk.org> wrote:

> - New AVX2 intrinsics are 1.6x-6.9x faster than Java baseline 
>    - `SignatureBench.MLDSA` is 1.2x-2.2x faster
>    - Note: there is no AVX2-SHA3 intrinsics yet (Being reviewed https://github.com/vpaprotsk/jdk/pull/7)
> - AVX512 intrinsic improvements are 1.24x-1.5x faster then current version 
>   - `SignatureBench.MLDSA` is upto 5% faster, never slower
> 
> Note on intrinsic:
> - The emitted (existing) AVX512 assembler was not "significantly" changed; mostly more efficient instruction selection and tighter register allocation, which allowed removal of NTT loop and stack spill.
> - Code was refactored to allow reuse of same assembler (as possible) for AVX512 and AVX2
> 
> Tests and benchmarks:
> - Added a fuzz test to ensure Java and intrinsic produces exactly same result
> - Added benchmark to measure the performance of intrinsic itself
> 
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java"
> make test TEST="test/jdk/sun/security/provider/acvp/Launcher.java test/jdk/sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java" JTREG="JAVA_OPTIONS=-XX:UseAVX=2"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:+UseDilithiumIntrinsics;FORK=1"
> make test TEST="micro:org.openjdk.bench.javax.crypto.full.SignatureBench.MLDSA" MICRO="JAVA_OPTIONS=-XX:+UnlockDiagnosticVMOptions -XX:-UseDilithiumIntrinsics;FORK=1"

Nice speedup. This improvement seems worthy of a release note.

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

PR Comment: https://git.openjdk.org/jdk/pull/28136#issuecomment-3492562302

From aboldtch at openjdk.org  Wed Nov  5 19:25:58 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 5 Nov 2025 19:25:58 GMT
Subject: RFR: 8371346: ZGC: Flexible heap base selection
Message-ID: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>

ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base.

Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties.

With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM.

This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base.

I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits.

The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that.

On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. 

There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. 

Performance testing show no significant differences.

Testing:
* GHA
* Running ZGC tier1-8 on Oracle supported platforms

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

Commit messages:
 - Initial Test Implementation
 - Initial implementation flexible heap base
 - Constrain ZAddressOffsetMax correctly when multi-partition fails
 - Log reserved size correctly when multi-partition fails
 - Cleanup headers
 - Consistent types zAddress

Changes: https://git.openjdk.org/jdk/pull/28161/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371346
  Stats: 1234 lines in 24 files changed: 907 ins; 290 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/28161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28161/head:pull/28161

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

From lmesnik at openjdk.org  Wed Nov  5 20:56:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 5 Nov 2025 20:56:13 GMT
Subject: RFR: 8371367: Replace remaining JvmtiJavaThreadEventTransition with
 JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK
Message-ID: <iQoCak0kAsd8lfJB2lWrsm_IYrq3FkxvXd5jICh-254=.d10528a2-f15d-4ade-b62e-229a6085b5e5@github.com>

The one JvmtiJavaThreadEventTransition mark should be replaced with macro.

Grepped that there are not JvmtiJavaThreadEventTransition and JvmtiThreadEventTransition mark are used except vm_death.

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

Commit messages:
 - 8371367: Replace remaining JvmtiJavaThreadEventTransition with JVMTI_JAVA_THREAD_EVENT_CALLBACK_BLOCK

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

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

From pchilanomate at openjdk.org  Wed Nov  5 21:05:11 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 5 Nov 2025 21:05:11 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v5]
In-Reply-To: <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
Message-ID: <KyupM4Q-0ERCwsb2jOuk-CfZjZ0Nc-9SecRSa2nXvoo=.00d5440c-c78a-4837-88f9-cb2f3501c298@github.com>

On Wed, 5 Nov 2025 17:35:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Update two, after the review
>  - Update after review
>  - Small arm32 fix
>  - Small include line fix
>  - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Looks good to me, thanks.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3424388594

From mr at openjdk.org  Wed Nov  5 21:55:02 2025
From: mr at openjdk.org (Mark Reinhold)
Date: Wed, 5 Nov 2025 21:55:02 GMT
Subject: RFR: 8369736 - Add management interface for AOT cache creation
 [v4]
In-Reply-To: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>
Message-ID: <RNZzi6MSztflQxxrsQaHlPmRGLtr85_bSsSlOCz7S9w=.a3c23612-b237-40a5-b033-c556c8c98a6c@github.com>

On Wed, 29 Oct 2025 21:07:51 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated test based on comments

Changes requested by mr (Lead).

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 78:

> 76:        *  specification of the corresponding JVM command-line options, please refer
> 77:        * to https://openjdk.org/jeps/483 and https://openjdk.org/jeps/514.
> 78:        *

Please don't use bare URLs. Change these to

... please refer to JEPs <a href="https://openjdk.org/jeps/483">483</a> and
<a href="https://openjdk.org/jeps/514">514</a>.

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

PR Review: https://git.openjdk.org/jdk/pull/28010#pullrequestreview-3424599728
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2496294936

From jrose at openjdk.org  Wed Nov  5 23:10:01 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 5 Nov 2025 23:10:01 GMT
Subject: RFR: 8371104: gtests should use wrappers for <limits> and
 <type_traits>
In-Reply-To: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
References: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
Message-ID: <ueKm0Zvn4UvMUbCLR2TcB4R8cf53nvdXdB3BHHtn1Nw=.971ace92-bc08-433b-a2c0-f7034e30406b@github.com>

On Mon, 3 Nov 2025 18:01:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change, updating HotSpot gtests to include the new
> cppstdlib/{limits,type_traits}.hpp wrappers instead of including the Standard
> Library headers directly.
> 
> Testing: mach5 tier1

Marked as reviewed by jrose (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28114#pullrequestreview-3424899657

From fandreuzzi at openjdk.org  Thu Nov  6 01:25:00 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 6 Nov 2025 01:25:00 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v5]
In-Reply-To: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
Message-ID: <FQ78Ajjh6pkAcuPL7lRGx84lWSiSDhfzoIMdQdMI3Ao=.cc85b432-40ae-4fad-9d06-e854ac4664e9@github.com>

> In this PR I introduce a new JFR event: `jdk.StringDeduplicationStatistics`
> 
> The new event is emitted every time a deduplication cycle happens.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  no start

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/e8644c68..3793befd

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

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

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

From fandreuzzi at openjdk.org  Thu Nov  6 01:59:41 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 6 Nov 2025 01:59:41 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v6]
In-Reply-To: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
Message-ID: <qBi2IqPdCJVfm__ynPaUGcn83hLkC33v2yTeGTMPFMg=.0537cbb1-3762-4d8d-8ea2-32dc171ca060@github.com>

> In this PR I introduce a new JFR event: `jdk.StringDeduplication`
> 
> The new event is emitted every time a deduplication cycle happens.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  rename. start/end time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/3793befd..090c02bc

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

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

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

From fandreuzzi at openjdk.org  Thu Nov  6 01:59:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 6 Nov 2025 01:59:42 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <XuUowo5n1fE1BP8RzyifQbT9wzt5aK73ssUGeGpVkOw=.d2f3da1a-b61a-435a-b7e1-9c29004e4ad6@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
 <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
 <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU
 6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>
 <XuUowo5n1fE1BP8RzyifQbT9wzt5aK73ssUGeGpVkOw=.d2f3da1a-b61a-435a-b7e1-9c29004e4ad6@github.com>
Message-ID: <9Ne0a7oeIyXjdA_VFbfbX52u7WRgTonCp_jI906V6DQ=.8e10796c-6160-4e08-9595-1b35491dcda0@github.com>

On Wed, 5 Nov 2025 14:15:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > > The elapsed fields, are they the total since the JVM started or from the last round?
> > 
> > 
> > All fields in `EventStringDeduplicationStatistics` contain the diff since the last round:
> 
> Since the event has a duration, I wonder if the event should be called StringDeduplication, similar to Compilation or GarbageCollection? As I understand it, the event represents a round of deduplications. All other events called statistics are instantaneous events.

Yeah this makes sense, thanks. See 090c02bce5ba79cff378bd48de0fc0849f532250

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

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3494458707

From jpai at openjdk.org  Thu Nov  6 07:03:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Nov 2025 07:03:01 GMT
Subject: RFR: 8371048: ImageFileReader::open fails to check return value of
 osSupport::map_memory
In-Reply-To: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
References: <tMiURM1fFzdKlQ3PLifstr4XjkRclx2CdCrkpD7wmFA=.32d24cfb-d4ff-433f-876c-ba8bdb0f4247@github.com>
Message-ID: <Har5mcp3Inx5L2GTgZREI0J59f5NU5--aWL1NehZ-ac=.0d3b6068-ad81-4fce-a168-581f3b35a0eb@github.com>

On Fri, 31 Oct 2025 14:00:38 GMT, Justin King <jcking at openjdk.org> wrote:

> Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing.

Hello Justin, `jimage` code is maintained in core-libs area. I have added now that label to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28087#issuecomment-3495396990

From tschatzl at openjdk.org  Thu Nov  6 08:07:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 6 Nov 2025 08:07:03 GMT
Subject: RFR: 8371104: gtests should use wrappers for <limits> and
 <type_traits>
In-Reply-To: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
References: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
Message-ID: <DUxrkTZKPwoR5Rxo22a0QxNCVc3faCOTFtck101U3og=.7a7e2479-abf6-4cfa-8a66-1bdd109eb604@github.com>

On Mon, 3 Nov 2025 18:01:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change, updating HotSpot gtests to include the new
> cppstdlib/{limits,type_traits}.hpp wrappers instead of including the Standard
> Library headers directly.
> 
> Testing: mach5 tier1

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28114#pullrequestreview-3426776962

From shade at openjdk.org  Thu Nov  6 09:51:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 6 Nov 2025 09:51:03 GMT
Subject: RFR: 8370813: Deprecate AggressiveHeap
In-Reply-To: <_tMyItJZEwt4YJq9EYQuDBVIs_1l4jFPXhncYIHy2TE=.337902e6-ed5d-46e5-8344-d858407acbee@github.com>
References: <_tMyItJZEwt4YJq9EYQuDBVIs_1l4jFPXhncYIHy2TE=.337902e6-ed5d-46e5-8344-d858407acbee@github.com>
Message-ID: <Qc0Xm_IBcm7XZyB_JtOTiQRbtflmVR2HSEYjwhU6My4=.d1e1dc88-61ce-4d40-b78f-9660de26bd56@github.com>

On Wed, 5 Nov 2025 09:24:51 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE deprecates the `AggressiveHeap` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behavior in the future.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28144#pullrequestreview-3427233045

From kbarrett at openjdk.org  Thu Nov  6 10:04:04 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 6 Nov 2025 10:04:04 GMT
Subject: RFR: 8371104: gtests should use wrappers for <limits> and
 <type_traits>
In-Reply-To: <ueKm0Zvn4UvMUbCLR2TcB4R8cf53nvdXdB3BHHtn1Nw=.971ace92-bc08-433b-a2c0-f7034e30406b@github.com>
References: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
 <ueKm0Zvn4UvMUbCLR2TcB4R8cf53nvdXdB3BHHtn1Nw=.971ace92-bc08-433b-a2c0-f7034e30406b@github.com>
Message-ID: <e3z7nBZE8AUIppQdDvUYAwPe5MbH56SX8k70cJRc5Ew=.dcbb686c-37ad-4bcb-b1e5-bf4b038127dc@github.com>

On Wed, 5 Nov 2025 23:07:48 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Please review this trivial change, updating HotSpot gtests to include the new
>> cppstdlib/{limits,type_traits}.hpp wrappers instead of including the Standard
>> Library headers directly.
>> 
>> Testing: mach5 tier1
>
> Marked as reviewed by jrose (Reviewer).

Thanks for reviews @rose00 and @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/28114#issuecomment-3496292862

From kbarrett at openjdk.org  Thu Nov  6 10:17:31 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 6 Nov 2025 10:17:31 GMT
Subject: Integrated: 8371104: gtests should use wrappers for <limits> and
 <type_traits>
In-Reply-To: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
References: <m110N1ERY3dTTRCQOrUOmzOuLB50xD4-50G_ZG_TvIU=.53b573a7-f17a-466a-9b29-58ff7527bea0@github.com>
Message-ID: <KQsxkEvwhQymCbWLaa3CuurkFg27TXWgSfu5Eb3Ltf4=.b34ae1fe-d2bd-400b-aea5-c4d680d3c74d@github.com>

On Mon, 3 Nov 2025 18:01:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change, updating HotSpot gtests to include the new
> cppstdlib/{limits,type_traits}.hpp wrappers instead of including the Standard
> Library headers directly.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: 913c973c
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/913c973ca0ffdc19171a56550e8a8f03ac7f4771
Stats:     31 lines in 9 files changed: 11 ins; 20 del; 0 mod

8371104: gtests should use wrappers for <limits> and <type_traits>

Reviewed-by: jrose, tschatzl

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

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

From eosterlund at openjdk.org  Thu Nov  6 11:38:35 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 6 Nov 2025 11:38:35 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v15]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <yYxT4X-RrbTIwIqBj6RbkYLjA35NaLV2tEZiY78hS34=.5564043f-10d1-4f5f-b02f-d8ffab7230a6@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Comment update
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - remove include
 - Interned string value word accounting
 - Dont load all objects when JVMTI CFLH is on
 - Remove duplicate string dedup disabling when dumping
 - Accept interned strings sharing value with another string
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - ... and 21 more: https://git.openjdk.org/jdk/compare/b0536f9c...afdb11ee

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

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=14
  Stats: 8721 lines in 106 files changed: 5943 ins; 2318 del; 460 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From azafari at openjdk.org  Thu Nov  6 12:09:06 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Nov 2025 12:09:06 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <Zvkwt1iR2wEHvg13gFQi6hfMlU9xeWNgndw0WYvbW-o=.84a9841c-3cf8-42cd-8c5b-5328309920a2@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>
 <Zvkwt1iR2wEHvg13gFQi6hfMlU9xeWNgndw0WYvbW-o=.84a9841c-3cf8-42cd-8c5b-5328309920a2@github.com>
Message-ID: <xgzmwU9GfpqvMGQ7WAqW1Lv0Oih4I8hEX4M79O_pwj8=.896e1f94-8d18-4ba0-b363-85e45a868571@github.com>

On Tue, 4 Nov 2025 04:19:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments and post-cond
>
> src/hotspot/share/oops/klass.hpp line 514:
> 
>> 512:   }
>> 513: 
>> 514:   // Find the right-most non-zero (e.g., ...1000) bit of the diff of array-of-boolean and array-of-byte layout helpers.
> 
> Callers don't care whether it's the rightmost bit, only that it's a single
> bit. (Some callers use log2_exact to get the bit position.) So a more
> pedantically correct description might be something like "Return a value
> containing a single set bit that is in the bitset difference between the
> layout helpers for array-of-boolean and array-of-byte."

Comment of the function is replaced with this one.

> src/hotspot/share/oops/klass.hpp line 525:
> 
>> 523:     // So use alternate form of negation to avoid warning.
>> 524:     uint result = candidates & (~candidates + 1);
>> 525:     assert(((result - 1) & result) == 0, "post-condition");
> 
> Use `power_of_2(result)`.  For completeness, also consider checking other post-conditions - result is set
> in zlh and clear in blh.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2498695917
PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2498696841

From azafari at openjdk.org  Thu Nov  6 12:09:08 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Nov 2025 12:09:08 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <CF0Zu9iLi22KTcWJ_D94efRgjoLrNkqw8ueI8EbwtEk=.9dd99110-4010-47b2-88c7-5c969fffb8c7@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <rX_0t2D2dF27V0h1fCxFEJPY66_aWjl3gxaOcKxLj8I=.cdcc1a01-2b1e-4ad3-91ed-7b87c56ae390@github.com>
 <CF0Zu9iLi22KTcWJ_D94efRgjoLrNkqw8ueI8EbwtEk=.9dd99110-4010-47b2-88c7-5c969fffb8c7@github.com>
Message-ID: <B9JC45cSqhCGNyvrHIhBIf_1I9AXFByr4O5KawLaWDI=.b96952b8-7931-4598-9c6f-1021bc26ab55@github.com>

On Tue, 4 Nov 2025 04:26:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/oops/klass.hpp line 518:
>> 
>>> 516:   static int layout_helper_boolean_diffbit() {
>>> 517:     uint zlh = checked_cast<uint>(array_layout_helper(T_BOOLEAN));
>>> 518:     uint blh = checked_cast<uint>(array_layout_helper(T_BYTE));
>> 
>> Use of check_cast is probably wrong. I think an alh is negative. Oops, my mistake. It probably doesn't fail currently because of [JDK-8314258](https://bugs.openjdk.org/browse/JDK-8314258).
>
> Note that by "my mistake" I meant it was a mistake to use `checked_cast` here.

static_cast is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2498695108

From azafari at openjdk.org  Thu Nov  6 12:09:11 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Nov 2025 12:09:11 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v4]
In-Reply-To: <J7HkbLBXiSv9CuCgEJQtVZ1oL0MJQZcQ_B0KbVW2DE0=.25f54aa1-8802-4487-a61b-bc115edaa98e@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <8F0nIHGwWbZ0Z6oRxP6rXYoS-GRQEh3-LuiCa2RGvfk=.553e56b9-93cb-4aac-b89e-4ebb2f1e2169@github.com>
 <J7HkbLBXiSv9CuCgEJQtVZ1oL0MJQZcQ_B0KbVW2DE0=.25f54aa1-8802-4487-a61b-bc115edaa98e@github.com>
Message-ID: <0Gv-2oiMM0k7lYJMZURyodUIa4wUTvzRAe361IqJOcc=.ddb98fce-788b-4d9e-88be-aed325f31f4a@github.com>

On Tue, 4 Nov 2025 23:47:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comments and post-cond
>
> src/hotspot/share/oops/klass.hpp line 525:
> 
>> 523:     // So use alternate form of negation to avoid warning.
>> 524:     uint result = candidates & (~candidates + 1);
>> 525:     assert(((result - 1) & result) == 0, "post-condition");
> 
> Maybe use "must be power of 2" instead of  "post-condition".  Also, this value is never going to change.  Can we make the function `constexpr`?

Assert's message updated.
`constexpr` cannot be used unless all the called functions (alh and its descendents) are also `constexpr`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2498708371

From fbredberg at openjdk.org  Thu Nov  6 12:19:20 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 6 Nov 2025 12:19:20 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v5]
In-Reply-To: <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <T7iVYdA9TdpvyzmkfUdxXXwLWp8H5lwQtw6eejgS4QI=.a48930f7-d4d5-4628-ab25-33ce15a6e8fd@github.com>
Message-ID: <0Bp5MHdJNB3D3XZhG85m_clr-urKBKJ4StjZifsDTRg=.1ecc9574-3493-4a3e-8d7f-4aba5b9495ef@github.com>

On Wed, 5 Nov 2025 17:35:16 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Fredrik Bredberg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Merge branch 'master' into 8367982_unify_object_and_lightweight_synchronizer
>  - Update two, after the review
>  - Update after review
>  - Small arm32 fix
>  - Small include line fix
>  - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Thank you for the reviews. Now let's...

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

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3496959325

From fbredberg at openjdk.org  Thu Nov  6 12:19:21 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 6 Nov 2025 12:19:21 GMT
Subject: Integrated: 8367982: Unify ObjectSynchronizer and
 LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <oNcbqD1fQv-fnS70SXCEvdZoHuqcvTc9uZa9BGtMiS8=.bcbca6ee-7f6b-465b-9b1a-b953e8c37f15@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

This pull request has now been integrated.

Changeset: 3930b1d4
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3930b1d4ddda9d56d0fb3626421283c72f4ad7f9
Stats:     2981 lines in 80 files changed: 1263 ins; 1429 del; 289 mod

8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Reviewed-by: pchilanomate, coleenp

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

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

From bulasevich at openjdk.org  Thu Nov  6 12:59:24 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 6 Nov 2025 12:59:24 GMT
Subject: RFR: 8359256: AArch64: Use SHA3 GPR intrinsic where it's faster
 [v2]
In-Reply-To: <U8S0BDmYB17PCq5i8Sd-idcGRKx1mJ7_pIsyKqsNT7w=.ff043375-5749-42c8-9330-134ebbc6fa79@github.com>
References: <9KmPqhIXB8_05Tu4NQP7TECtTqtQKs0ZvXWxI58C1TU=.5c488724-4d57-4d4f-aa2e-bdecab6a91af@github.com>
 <U8S0BDmYB17PCq5i8Sd-idcGRKx1mJ7_pIsyKqsNT7w=.ff043375-5749-42c8-9330-134ebbc6fa79@github.com>
Message-ID: <TOgamLTrNWjk7RwoEc0hVkXZ8F7I-7m2h0DYrQbZKF4=.0f11aff0-19e1-45ef-862b-f4b7ea8d6905@github.com>

On Thu, 30 Oct 2025 11:29:40 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> This change adjusts the default selection of SHA-3 intrinsics on AArch64 based on observed performance across CPUs. In our measurements, the SHA-3 SIMD path (using SHA3 instructions) is consistently faster on Apple silicon, while on Neoverse and several older cores the GPR implementation performs better. On CPUs without SHA-3 instructions, the GPR path is the only viable option and behaves as expected.
>> 
>> Accordingly, `UseSIMDForSHA3Intrinsic` now defaults to false globally. The SIMD variant is auto-enabled only on Apple silicon; elsewhere the default remains the GPR path.
>> 
>> _The attached raw data also includes observations about `UseFPUForSpilling`. Back in #27350 we discussed whether the option is entirely useless. While orthogonal to this change, the MessageDigests benchmark is a convenient probe of register-spilling behavior because the SHA-3 (Keccak) algorithm is highly register-hungry, which adds a significant number of spills to the generated assembly sequence. In the provided results, at least one CPU benefits from enabling UseFPUForSpilling, so the option seems worth keeping for now._
>> 
>> **Cortex-A53 (RPi3)**
>> 
>> $ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
>> Benchmark          (digesterName)  (length)   Cnt    Score   Error   Units
>> MessageDigests.digest    SHA3-512        64   150  345.010 ? 0.473  ops/ms
>> MessageDigests.digest    SHA3-512     16384   150    1.817 ? 0.001  ops/ms
>> 
>> $ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
>> MessageDigests.digest    SHA3-512        64   150  352.247 ? 0.279  ops/ms  +UseFPUForSpilling: +2%
>> MessageDigests.digest    SHA3-512     16384   150    1.855 ? 0.001  ops/ms  +UseFPUForSpilling: +2%
>> 
>> $ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics" 2>&1 | tail -n5
>> Benchmark                (digesterName)  (length)   Cnt    Score    Error   Units
>> MessageDigests.digest          SHA3-512        64    15  345.552 ?  0.291  ops/ms
>> MessageDigests.digest          SHA3-512     16384    15    1.818 ?  0.001  ops/ms
>> MessageDigests.getAndDigest    SHA3-512        64    15  265.744 ? 56.591  ops/ms
>> MessageD...
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor review corrections

thanks for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/27726#issuecomment-3497141039

From bulasevich at openjdk.org  Thu Nov  6 12:59:26 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 6 Nov 2025 12:59:26 GMT
Subject: Integrated: 8359256: AArch64: Use SHA3 GPR intrinsic where it's faster
In-Reply-To: <9KmPqhIXB8_05Tu4NQP7TECtTqtQKs0ZvXWxI58C1TU=.5c488724-4d57-4d4f-aa2e-bdecab6a91af@github.com>
References: <9KmPqhIXB8_05Tu4NQP7TECtTqtQKs0ZvXWxI58C1TU=.5c488724-4d57-4d4f-aa2e-bdecab6a91af@github.com>
Message-ID: <VIR2xy_xgfrBd1yfssEPCmAHaprC3FGr0bEwhCjfVKQ=.339e3609-3cd9-4d63-a028-bd2983b52136@github.com>

On Thu, 9 Oct 2025 13:26:51 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> This change adjusts the default selection of SHA-3 intrinsics on AArch64 based on observed performance across CPUs. In our measurements, the SHA-3 SIMD path (using SHA3 instructions) is consistently faster on Apple silicon, while on Neoverse and several older cores the GPR implementation performs better. On CPUs without SHA-3 instructions, the GPR path is the only viable option and behaves as expected.
> 
> Accordingly, `UseSIMDForSHA3Intrinsic` now defaults to false globally. The SIMD variant is auto-enabled only on Apple silicon; elsewhere the default remains the GPR path.
> 
> _The attached raw data also includes observations about `UseFPUForSpilling`. Back in #27350 we discussed whether the option is entirely useless. While orthogonal to this change, the MessageDigests benchmark is a convenient probe of register-spilling behavior because the SHA-3 (Keccak) algorithm is highly register-hungry, which adds a significant number of spills to the generated assembly sequence. In the provided results, at least one CPU benefits from enabling UseFPUForSpilling, so the option seems worth keeping for now._
> 
> **Cortex-A53 (RPi3)**
> 
> $ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
> Benchmark          (digesterName)  (length)   Cnt    Score   Error   Units
> MessageDigests.digest    SHA3-512        64   150  345.010 ? 0.473  ops/ms
> MessageDigests.digest    SHA3-512     16384   150    1.817 ? 0.001  ops/ms
> 
> $ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
> MessageDigests.digest    SHA3-512        64   150  352.247 ? 0.279  ops/ms  +UseFPUForSpilling: +2%
> MessageDigests.digest    SHA3-512     16384   150    1.855 ? 0.001  ops/ms  +UseFPUForSpilling: +2%
> 
> $ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics" 2>&1 | tail -n5
> Benchmark                (digesterName)  (length)   Cnt    Score    Error   Units
> MessageDigests.digest          SHA3-512        64    15  345.552 ?  0.291  ops/ms
> MessageDigests.digest          SHA3-512     16384    15    1.818 ?  0.001  ops/ms
> MessageDigests.getAndDigest    SHA3-512        64    15  265.744 ? 56.591  ops/ms
> MessageDigests.getAndDigest    SHA3-512     16384    1...

This pull request has now been integrated.

Changeset: c173d416
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c173d416f749348bee42e1a9436a999700d0f0e8
Stats:     19 lines in 2 files changed: 6 ins; 0 del; 13 mod

8359256: AArch64: Use SHA3 GPR intrinsic where it's faster

Reviewed-by: eastigeevich, phh

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

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

From azafari at openjdk.org  Thu Nov  6 13:06:41 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 6 Nov 2025 13:06:41 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v5]
In-Reply-To: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
Message-ID: <2tqtSNmhY0bGDrqu06wBvUWw_bpdv311BSM-ij5EEGY=.90ef7eb5-8d88-439c-b0df-f917f3543cc2@github.com>

> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue.
> 
> Tests:
>  mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product}

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

  review comments applied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27288/files
  - new: https://git.openjdk.org/jdk/pull/27288/files/8a3d6d13..cc3831fa

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

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

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

From eosterlund at openjdk.org  Thu Nov  6 13:33:04 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 6 Nov 2025 13:33:04 GMT
Subject: RFR: 8371346: ZGC: Flexible heap base selection
In-Reply-To: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
References: <g2sXoLZ6-rQ8TeHjA_C2Gi_gmrAW_uA-mQpe867xG-M=.5f135781-364a-4929-b6cb-79f2488b415c@github.com>
Message-ID: <XpFS_V_cCiwF92mqOaEP-mLSchAuZ3q2Lix2fk_TKt4=.07111eaa-7f2b-490f-9540-b69113eb660a@github.com>

On Wed, 5 Nov 2025 19:19:23 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base.
> 
> Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties.
> 
> With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM.
> 
> This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base.
> 
> I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits.
> 
> The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that.
> 
> On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. 
> 
> There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. 
> 
> Performance testing show no significant differences.
> 
> Testing:
> * GHA
> * Running ZGC tier1-8 on Oracle supported platforms

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28161#pullrequestreview-3428202976

From duke at openjdk.org  Thu Nov  6 13:43:33 2025
From: duke at openjdk.org (Zihao Lin)
Date: Thu, 6 Nov 2025 13:43:33 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v9]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <zFTPEfkseaypOaoPm5nhJpWh7JOvHfCUaT4wmeDYoBE=.643d7e26-7c8c-45b7-a5e5-79c454338427@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> I have done more work which remove slice paramater from StoreNode::make.
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

Zihao Lin has updated the pull request incrementally with one additional commit since the last revision:

  remove C2AccessValuePtr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24258/files
  - new: https://git.openjdk.org/jdk/pull/24258/files/6d122039..e89910c2

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

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

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

From duke at openjdk.org  Thu Nov  6 13:58:53 2025
From: duke at openjdk.org (Zihao Lin)
Date: Thu, 6 Nov 2025 13:58:53 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v10]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <1zyQq98OPsZ-2nzYz21X_5v2RgKhWaZrZaJQevDMzo4=.138599b1-4797-42b0-a48a-829a112dfbe7@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> I have done more work which remove slice paramater from StoreNode::make.
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

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

 - fix conflict
 - Merge master
 - remove C2AccessValuePtr
 - fix assert
 - add more assert
 - rid of access.addr().type()
 - Merge branch 'openjdk:master' into 8344116
 - Merge branch 'openjdk:master' into 8344116
 - Merge branch 'openjdk:master' into 8344116
 - Fix build
 - ... and 2 more: https://git.openjdk.org/jdk/compare/c173d416...36e024db

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

Changes: https://git.openjdk.org/jdk/pull/24258/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24258&range=09
  Stats: 230 lines in 18 files changed: 33 ins; 55 del; 142 mod
  Patch: https://git.openjdk.org/jdk/pull/24258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24258/head:pull/24258

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

From mablakatov at openjdk.org  Thu Nov  6 17:59:41 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 6 Nov 2025 17:59:41 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v8]
In-Reply-To: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
Message-ID: <t-pPphsu0nVINtYfJDwnE4sX3n-vqLF9GkHDBNdBe1Q=.83eccebe-1e11-423c-8415-6013b1960482@github.com>

> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee.
> 
> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls.
> 
> This has passed tier1-3 and jcstress testing on AArch64.

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

 - Merge commit 'f6f87bb6759c86d941453a1776e8abfdffc48183' into 8359359
 - the only trampoline in ArrayCopyStub is never shared
 - fixup: a shared trampoline must branch to a statically bound method
 - share static call trampolines generated by C1 as well
 - assert callee is nullptr for runtime calls
 - assert that call sites offsets aren't missing
 - cleanup: rephrase comments in macroAssembler_aarch64.hpp
 - Merge commit 'fd29677479797956e0d205b5ce6e7cb9ad407bd1' into 8359359
 - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
 - remove implementation-dependent logic from emit_shared_trampolines()
 - ... and 8 more: https://git.openjdk.org/jdk/compare/f6f87bb6...871903f4

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

Changes: https://git.openjdk.org/jdk/pull/25954/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25954&range=07
  Stats: 447 lines in 12 files changed: 320 ins; 114 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/25954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25954/head:pull/25954

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

From mablakatov at openjdk.org  Thu Nov  6 17:59:43 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 6 Nov 2025 17:59:43 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v7]
In-Reply-To: <HcdcqrQ4OvF_VqbYfkZuwGaWz7dTyFaifAv3ThNuil8=.1dca3c78-fe6f-4825-b11a-741f85aa8290@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <KbpPFEk7etIK0EjgmkOB6v48J57yUfTEsNCnb8Rq_vA=.e44b7f10-5279-4071-966e-2e5b1bde94d9@github.com>
 <HcdcqrQ4OvF_VqbYfkZuwGaWz7dTyFaifAv3ThNuil8=.1dca3c78-fe6f-4825-b11a-741f85aa8290@github.com>
Message-ID: <BwJwAFlZHXLei7WvI7zL96HzlFEfRoSlv7N0MmRuL14=.a073bd21-8e8b-4b21-9afb-6ab71cef48d9@github.com>

On Thu, 30 Oct 2025 13:11:27 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - share static call trampolines generated by C1 as well
>>  - assert callee is nullptr for runtime calls
>>  - assert that call sites offsets aren't missing
>>  - cleanup: rephrase comments in macroAssembler_aarch64.hpp
>>  - Merge commit 'fd29677479797956e0d205b5ce6e7cb9ad407bd1' into 8359359
>>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>>  - remove implementation-dependent logic from emit_shared_trampolines()
>>  - cleanup: update copyright headers
>>  - Make the value type of the dictionary a struct instead of Pair typedef
>>  - Remove share_rc_trampoline_for and share_sc_trampoline_for
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/fd296774...e3ad440b
>
> src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp line 336:
> 
>> 334:   Address resolve(SharedRuntime::get_resolve_static_call_stub(),
>> 335:                   relocInfo::static_call_type);
>> 336:   address call = __ trampoline_call(resolve, info()->method());
> 
> This does not save any space because it is one call in the stub.

reverted, please see https://github.com/openjdk/jdk/pull/25954/commits/a5c665520088ca7a3f282b684bb58701733af83e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2500160541

From mablakatov at openjdk.org  Thu Nov  6 17:59:45 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 6 Nov 2025 17:59:45 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v7]
In-Reply-To: <zaEmEO0VnXIqPCoWVR4oIYgdVm6ripUYCnlQECPGxMk=.e7e3792b-44da-4f19-bf2d-553129c810ef@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <KbpPFEk7etIK0EjgmkOB6v48J57yUfTEsNCnb8Rq_vA=.e44b7f10-5279-4071-966e-2e5b1bde94d9@github.com>
 <NzROiTFDP3zgM5a7aXbMC2YiELViwuA9dB0RUtM3nIo=.bbe259f3-fb2b-4886-b97e-d88cd53f810e@github.com>
 <FGQeOpCA59Hd2-viLCJP4-ucVi_WPjS6x0mBX0XrNjQ=.03327989-7cf0-41a7-ba64-1006eb493f51@github.com>
 <zaEmEO0VnXIqPCoWVR4oIYgdVm6ripUYCnlQECPGxMk=.e7e3792b-44da-4f19-bf2d-553129c810ef@github.com>
Message-ID: <y0gMzikKE7uF5BzYhZg_v6t10Mbeev9UJ4oHFazrBkQ=.1f17d271-dd8d-4592-827d-f6ba620a3ec2@github.com>

On Thu, 30 Oct 2025 17:38:19 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Would it be correct to use `op->method()->can_be_statically_bound()` instead, similarly to how it's done for static call stubs in https://github.com/openjdk/jdk/blob/ed36b9bb6f3d429db6accfb3b096e50e7f2217ff/src/hotspot/share/c1/c1_LIRAssembler.cpp#L456?
>
> `can_be_statically_bound()` should definitely work.

Fixed, please see https://github.com/openjdk/jdk/pull/25954/commits/ba317d4ca96af87fbc53155d1fcc33d88a6c2349

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2500161764

From mablakatov at openjdk.org  Thu Nov  6 17:59:46 2025
From: mablakatov at openjdk.org (Mikhail Ablakatov)
Date: Thu, 6 Nov 2025 17:59:46 GMT
Subject: RFR: 8359359: AArch64: share trampolines between static calls to
 the same method [v6]
In-Reply-To: <2pGRA1xI61iqh51Hi1HkJCT7uDR1j0i4r__ceZQGsYk=.903836e5-d3b3-4481-b48b-f1f3c4b0c148@github.com>
References: <3mB1bU-08ZvsJkR52D-nNFObwsaysNHxBkF1L42lmIY=.459e1ba8-118e-4a3a-8049-415765d25553@github.com>
 <UUKZKm2XxIp00wUaAx015JWOpAUuOvULukAMrxLmaIY=.75e298f2-ff06-4885-9559-c070850fd593@github.com>
 <zk-Zqk7gB94EVou3fghjr8L_4R27h0tdQRUCg2-7i7o=.276943fa-41a5-49ef-ab89-a2a60b4251e2@github.com>
 <SSzYBh9E8qTnmPjIMwqFKBckkss1wk1D4Iczzh-hPRY=.569f6520-1021-4547-b2a2-312f97390696@github.com>
 <BXFr-z1N5W3SNcz5tsk8CrEPmyqQ--8bUOnOAeyWpWA=.01e9e25c-5bc4-468e-8411-7c9ecc0de0d5@github.com>
 <9idT2wdo-uuG1seABSR_6Mr0S_ygFBmeAbL6hK2QwCg=.343f6868-486a-4407-ab43-f6236a504e37@github.com>
 <Hp6QSEOFv7waYk3jwFx3KG23xtjzuT2sAkaudjd529k=.22cd0b09-bcab-4083-bbeb-fd8e2da5af5b@github.com>
 <8_LF342KuV09coGe-_uebB5ZjIyS9GLzJ9u6Xac8o-I=.69ab3c54-dd12-40d6-9ff3-123615ba91ac@github.com>
 <VXSthKEd1LZWEeRFfFafvFAxOkAQgZ3McnJ7YQYiZcU=.0c75ba76-82de-4e95-8e38-317eea0163b5@github.com>
 <2pGRA1xI61iqh51Hi1HkJCT7uDR1j0i4r__ceZQGsYk=.903836e5-d3b3-4481-b48b-f1f3c4b0c148@github.com>
Message-ID: <0lC1c-0kf6Ea-_a4j-cjxD4LFvwLLFZtmAIwWxATwPA=.a196f9fd-27b9-463e-bd13-6953b49af174@github.com>

On Thu, 30 Oct 2025 15:38:54 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Are you sure this is OK in LIR_Assembler::call()?  Calls of type lir_dynamic_call use relocInfo::static_call_type, but can't they resolve to different targets depending on the call site info?  I don't think op->method() is unique for invokedynamic calls.  @iwanowww what do you think?
>
> Perhaps we should check if the callee method can be statically bound here using `op->method()->can_be_statically_bound()`?

> Are you sure this is OK in LIR_Assembler::call()?

Fixed, please see https://github.com/openjdk/jdk/pull/25954/commits/ba317d4ca96af87fbc53155d1fcc33d88a6c2349

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2500165019

From alanb at openjdk.org  Thu Nov  6 19:17:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Nov 2025 19:17:15 GMT
Subject: RFR: 8359256: AArch64: Use SHA3 GPR intrinsic where it's faster
 [v2]
In-Reply-To: <U8S0BDmYB17PCq5i8Sd-idcGRKx1mJ7_pIsyKqsNT7w=.ff043375-5749-42c8-9330-134ebbc6fa79@github.com>
References: <9KmPqhIXB8_05Tu4NQP7TECtTqtQKs0ZvXWxI58C1TU=.5c488724-4d57-4d4f-aa2e-bdecab6a91af@github.com>
 <U8S0BDmYB17PCq5i8Sd-idcGRKx1mJ7_pIsyKqsNT7w=.ff043375-5749-42c8-9330-134ebbc6fa79@github.com>
Message-ID: <sZuJPO17gQN75aI0fWauLvDXzQbgeGKk3epaYK5l-Q4=.9a5be437-846c-4b81-b82f-d15b88143a85@github.com>

On Thu, 30 Oct 2025 11:29:40 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> This change adjusts the default selection of SHA-3 intrinsics on AArch64 based on observed performance across CPUs. In our measurements, the SHA-3 SIMD path (using SHA3 instructions) is consistently faster on Apple silicon, while on Neoverse and several older cores the GPR implementation performs better. On CPUs without SHA-3 instructions, the GPR path is the only viable option and behaves as expected.
>> 
>> Accordingly, `UseSIMDForSHA3Intrinsic` now defaults to false globally. The SIMD variant is auto-enabled only on Apple silicon; elsewhere the default remains the GPR path.
>> 
>> _The attached raw data also includes observations about `UseFPUForSpilling`. Back in #27350 we discussed whether the option is entirely useless. While orthogonal to this change, the MessageDigests benchmark is a convenient probe of register-spilling behavior because the SHA-3 (Keccak) algorithm is highly register-hungry, which adds a significant number of spills to the generated assembly sequence. In the provided results, at least one CPU benefits from enabling UseFPUForSpilling, so the option seems worth keeping for now._
>> 
>> **Cortex-A53 (RPi3)**
>> 
>> $ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:-UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
>> Benchmark          (digesterName)  (length)   Cnt    Score   Error   Units
>> MessageDigests.digest    SHA3-512        64   150  345.010 ? 0.473  ops/ms
>> MessageDigests.digest    SHA3-512     16384   150    1.817 ? 0.001  ops/ms
>> 
>> $ ./jdk-25/bin/java -jar benchmarks.jar -p digesterName=SHA3-512 -jvmArgs "-XX:+UseFPUForSpilling -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics -XX:TieredStopAtLevel=4" MessageDigests.digest
>> MessageDigests.digest    SHA3-512        64   150  352.247 ? 0.279  ops/ms  +UseFPUForSpilling: +2%
>> MessageDigests.digest    SHA3-512     16384   150    1.855 ? 0.001  ops/ms  +UseFPUForSpilling: +2%
>> 
>> $ ./jdk-25/bin/java -jar benchmarks.jar MessageDigests -p digesterName=SHA3-512 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:-UseSHA3Intrinsics" 2>&1 | tail -n5
>> Benchmark                (digesterName)  (length)   Cnt    Score    Error   Units
>> MessageDigests.digest          SHA3-512        64    15  345.552 ?  0.291  ops/ms
>> MessageDigests.digest          SHA3-512     16384    15    1.818 ?  0.001  ops/ms
>> MessageDigests.getAndDigest    SHA3-512        64    15  265.744 ? 56.591  ops/ms
>> MessageD...
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor review corrections

There are 5 tests failing in tier2 on aarch64 that I assume are related to this change : [JDK-8371432](https://bugs.openjdk.org/browse/JDK-8371432)

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

PR Comment: https://git.openjdk.org/jdk/pull/27726#issuecomment-3499007823

From jkratochvil at openjdk.org  Thu Nov  6 19:37:49 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 6 Nov 2025 19:37:49 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v4]
In-Reply-To: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
Message-ID: <ufjLR-APUJe7-dr9Ut7R_qalaznhewluyK5DWLyS9ho=.2a789b40-70ef-4653-948b-dfa595098f53@github.com>

> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
> 
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
>       |          (void*)
> 
> The patch follows the suggested fix.

Jan Kratochvil 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:

 - Use padding fields for ResolvedFieldEntry and ResolvedMethodEntry
 - Merge branch 'master' into clangmemset
 - Merge branch 'master' into clangmemset
 - Revert "8361288: Fix build of JTReg: wget exited with exit code 4"
   
   This reverts commit 6e6b8f6a26f8e555f1e70544546b92bbafcae6cc.
 - 8361288: Fix build of JTReg: wget exited with exit code 4
 - 8357579: Compilation error: first argument in call to 'memset' is a pointer to non-trivially copyable type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26098/files
  - new: https://git.openjdk.org/jdk/pull/26098/files/3745a8af..3d4eccc1

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

  Stats: 14222 lines in 372 files changed: 8523 ins; 4457 del; 1242 mod
  Patch: https://git.openjdk.org/jdk/pull/26098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26098/head:pull/26098

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

From jkratochvil at openjdk.org  Thu Nov  6 19:47:40 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 6 Nov 2025 19:47:40 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v5]
In-Reply-To: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
Message-ID: <MYX2AQ8G6KmUZVxkVCzTEY6UcV7_rtmREPEPnzionIw=.62eff055-5bf8-44bc-abf1-e6f2275102c3@github.com>

> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
> 
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
>       |          (void*)
> 
> The patch follows the suggested fix.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Import some code from Ioi Lam's patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26098/files
  - new: https://git.openjdk.org/jdk/pull/26098/files/3d4eccc1..98bb03eb

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

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

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

From jkratochvil at openjdk.org  Thu Nov  6 19:52:17 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 6 Nov 2025 19:52:17 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v6]
In-Reply-To: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
Message-ID: <GbEzTucCsDdlt-CHcXx2cAfkc6sDGghO_Qx4aAh4VL4=.2cf5330e-f110-4d3b-bdb4-ea07e59b964d@github.com>

> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
> 
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
>       |          (void*)
> 
> The patch follows the suggested fix.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  More code improvements from Ioi Lam's patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26098/files
  - new: https://git.openjdk.org/jdk/pull/26098/files/98bb03eb..77814bf9

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

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

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

From lmesnik at openjdk.org  Thu Nov  6 21:33:38 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 6 Nov 2025 21:33:38 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
Message-ID: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>

The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.

The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.

The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.

Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
I am going to file separate RFE for this. 
Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

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

Commit messages:
 - 8371103: vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java failing

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

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

From amenkov at openjdk.org  Thu Nov  6 21:50:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Nov 2025 21:50:04 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
In-Reply-To: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
References: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
Message-ID: <KytOlhCQQxsW3wHpp4HemKJC7MPSKthk_xZxh-tbgA8=.13430f42-0dfd-457a-a566-a76b674b796f@github.com>

On Thu, 6 Nov 2025 21:26:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
> flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.
> 
> The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.
> 
> The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.
> 
> Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
> I am going to file separate RFE for this. 
> Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28184#pullrequestreview-3430693825

From sspitsyn at openjdk.org  Thu Nov  6 22:31:02 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 6 Nov 2025 22:31:02 GMT
Subject: RFR: 8371103:
 vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.java
 failing
In-Reply-To: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
References: <0TSSeNB540PtvusDCXFoYLc4TJm8GJMeBlExphuFDic=.5ff05b43-91c3-497f-b17a-1887c538c1ce@github.com>
Message-ID: <_-7XKb0c-O5l0FmUztsbDj2NAAXeHhANS25nZFviFHg=.fd1ac36a-9450-4121-8a05-88a4e3593753@github.com>

On Thu, 6 Nov 2025 21:26:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problem happens because jvmti events are posted while handling JvmtiThreadState_lock. The fix just to move 
> flushing out of lock like it is already done in `JvmtiEventController::set_user_enabled(..)` method.
> 
> The problem start reproducing after fix for https://bugs.openjdk.org/browse/JDK-8370732 that replaced GC triggering from slow and unreliable `ClassUnloader.eatMemory();` to fast and robust`WhiteBox.fullGC()`.
> 
> The jvmti events posting is not synchronized with  enabling/disabling events and setting callbacks. So even if there are new events appear in the jvmti tagmap after flushing it is not a bug to don't post them or use new callback handler.
> 
> Also, it might be makes sense to flush object events before vm_death and post all deferred events from SerrviceThread queue. 
> I am going to file separate RFE for this. 
> Also, I am going to file RFE to replace all GC provoking the `eatMemory()` calls with `WB.fullGC()` to improve test stability and reduce test execution time.

looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28184#pullrequestreview-3430797067

From jkratochvil at openjdk.org  Thu Nov  6 22:44:40 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 6 Nov 2025 22:44:40 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v7]
In-Reply-To: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
Message-ID: <MTra2bBiLQ3eDuK4Bz6cMO53dV6iHxeiLsOM5Harr8M=.53ce9700-43e2-492e-a10a-5216b9cd129e@github.com>

> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
> 
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>    49 |   memset(this, 0, sizeof(*this));
>       |          ^
>       |          (void*)
> 
> The patch follows the suggested fix.

Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:

  Fix 32-bit compilation error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26098/files
  - new: https://git.openjdk.org/jdk/pull/26098/files/77814bf9..b789941f

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

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

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

From dlong at openjdk.org  Fri Nov  7 00:01:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 7 Nov 2025 00:01:29 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <vxK28Vn6gG_zyIe_GwNOEt7bg2QTMeBLdUSh_E2hwOg=.6ee2b1a3-d5ba-4ab7-97e9-4bfddf06f5b6@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

We are seeing some new crashes ([JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388)) trying to access a PC that is just past the end of the nmethod and the page is unmapped because it also happens to be the last page of the CodeHeap.  Could it be related to the changes in this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3499890263

From duke at openjdk.org  Fri Nov  7 00:20:19 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 00:20:19 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <vxK28Vn6gG_zyIe_GwNOEt7bg2QTMeBLdUSh_E2hwOg=.6ee2b1a3-d5ba-4ab7-97e9-4bfddf06f5b6@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
 <vxK28Vn6gG_zyIe_GwNOEt7bg2QTMeBLdUSh_E2hwOg=.6ee2b1a3-d5ba-4ab7-97e9-4bfddf06f5b6@github.com>
Message-ID: <a3PldhvBpLPxAGLPBs-0tPMxSSBYxTXJBv2mRo2TIkM=.954278ed-ca1e-4e15-8a4f-2c0a8b6a3dfa@github.com>

On Thu, 6 Nov 2025 23:58:46 GMT, Dean Long <dlong at openjdk.org> wrote:

> We are seeing some new crashes ([JDK-8371388](https://bugs.openjdk.org/browse/JDK-8371388)) trying to access a PC that is just past the end of the nmethod and the page is unmapped because it also happens to be the last page of the CodeHeap. Could it be related to the changes in this PR?

Yes, I think it could be similar to the case fixed for AArch64 post-call NOP check earlier: https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/nativeInst_x86.hpp#L584 reads a 32-bit integer from the perceived call site. In case of the deoptimization handler, which is potentially located at the end of the code blob, the read would happen past the end of the code blob - which might cause the access to an unmapped page.

It could be replaced with the two-step comparison: first the comparison matching size of the `jmp` instruction (I believe that's 2 bytes), and if that's successful then comparison of the third byte as the second step. Alternatively, the specific deoptimization stub code could be extended by a `nop` in the `emit_deopt_handler`.

Would either of these options be suitable?

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3499929974

From duke at openjdk.org  Fri Nov  7 00:50:27 2025
From: duke at openjdk.org (Ruben)
Date: Fri, 7 Nov 2025 00:50:27 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <FshSmNkcxww-JYqCueDtTIRMAfmoTiD6i0wNdzUunJk=.0eb2187d-2a71-42a5-9894-cafc27a5212e@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Indeed, the `jmp` size is `2` - I had incorrectly assumed it is `5` as specified here https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/nativeInst_x86.hpp#L412 however that's for a different case. The `10` as size of the deopt handler stub code at https://github.com/openjdk/jdk/blob/e34a831814996be3e0a2df86b11b1718a76ea558/src/hotspot/cpu/x86/x86.ad#L2774 is not correct either - it should be `7`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3499993366

From iklam at openjdk.org  Fri Nov  7 04:44:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 7 Nov 2025 04:44:02 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v7]
In-Reply-To: <MTra2bBiLQ3eDuK4Bz6cMO53dV6iHxeiLsOM5Harr8M=.53ce9700-43e2-492e-a10a-5216b9cd129e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
 <MTra2bBiLQ3eDuK4Bz6cMO53dV6iHxeiLsOM5Harr8M=.53ce9700-43e2-492e-a10a-5216b9cd129e@github.com>
Message-ID: <DidmpzQ4owRiYcb81sXdWZc9SGlRQLONX6pBap7iuWw=.1ab45ae5-9d89-4156-9588-38b8e6ec1d83@github.com>

On Thu, 6 Nov 2025 22:44:40 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
>> 
>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>>       |          (void*)
>> 
>> The patch follows the suggested fix.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32-bit compilation error

Thanks for the update. I will run it through our CI to see if the deterministic CDS tests pass.

I think we should replace the memset with the following, per @kimbarrett 's comment on [JBS](https://bugs.openjdk.org/browse/JDK-8357579?focusedId=14831517&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14831517)


::new (this) ResolvedFieldEntry();


I tried it on Linux and it worked. I will test on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/26098#issuecomment-3500680077

From duke at openjdk.org  Fri Nov  7 04:57:52 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 04:57:52 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v7]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <Xp6vG0ftFLCh0p9FDvrcjnN7EgRVa08rKIPwO7LN_jY=.6ba29e32-ff57-4a6b-95fb-b69cd2125272@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  consolidate unit tests for vm memory tagging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/183927b0..59f4722c

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

  Stats: 53 lines in 3 files changed: 20 ins; 32 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Fri Nov  7 04:57:53 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 04:57:53 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <iRXfFqjf2iwzPIiSqGVsPpaljbSZ65nqrn5R2udX1Ks=.b6e8e8e7-4cf0-451e-8b63-625c5e6ff11e@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
 <iRXfFqjf2iwzPIiSqGVsPpaljbSZ65nqrn5R2udX1Ks=.b6e8e8e7-4cf0-451e-8b63-625c5e6ff11e@github.com>
Message-ID: <-_XVImRDDvjsMvf_7YNG_V-dFYfNqtdFC-xVrylQpPI=.8738f2f9-454e-4114-b7da-7c51667e580e@github.com>

On Wed, 5 Nov 2025 14:43:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I think the changes are minor to assert the tagging on allocation while we are doing that and do not require extra tests, please let me know if you still think otherwise.
> 
> I think otherwise. Please put the test somewhere else.

Done

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3500704669

From duke at openjdk.org  Fri Nov  7 05:02:22 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 05:02:22 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v8]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <t5LfL-ap58lMJ3_dL3W2xnMPyzL_UdrG2usSIjQZ6oM=.9330fa21-73b1-4c80-915b-e9ba89bf9ef7@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  remote testutils.hpp from test_zForwarding.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/59f4722c..0fbcdb09

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

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

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

From jsjolen at openjdk.org  Fri Nov  7 05:02:23 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 7 Nov 2025 05:02:23 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v7]
In-Reply-To: <Xp6vG0ftFLCh0p9FDvrcjnN7EgRVa08rKIPwO7LN_jY=.6ba29e32-ff57-4a6b-95fb-b69cd2125272@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <Xp6vG0ftFLCh0p9FDvrcjnN7EgRVa08rKIPwO7LN_jY=.6ba29e32-ff57-4a6b-95fb-b69cd2125272@github.com>
Message-ID: <TD5EffrJG3_ocxkze9CkiRrS4daas0XzIv85dJ_no48=.0167c6c8-66e7-4249-83ca-e4376d88f6dd@github.com>

On Fri, 7 Nov 2025 04:57:52 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   consolidate unit tests for vm memory tagging

Changes requested by jsjolen (Reviewer).

test/hotspot/gtest/runtime/test_os.cpp line 1133:

> 1131:   char* base = os::reserve_memory(size, mtTest, false);
> 1132:   ASSERT_NOT_NULL(base);
> 1133: 

Remove this change

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

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3431645714
PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2501685500

From iklam at openjdk.org  Fri Nov  7 05:04:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 7 Nov 2025 05:04:09 GMT
Subject: RFR: 8357579: Compilation error: first argument in call to
 'memset' is a pointer to non-trivially copyable type [v7]
In-Reply-To: <MTra2bBiLQ3eDuK4Bz6cMO53dV6iHxeiLsOM5Harr8M=.53ce9700-43e2-492e-a10a-5216b9cd129e@github.com>
References: <usuBa8J-nIYr2gQKaZSMzotyzY04TnuARKG5U_XelUM=.4b729adb-2ab8-4713-8f86-1ba8b4b4ba4e@github.com>
 <MTra2bBiLQ3eDuK4Bz6cMO53dV6iHxeiLsOM5Harr8M=.53ce9700-43e2-492e-a10a-5216b9cd129e@github.com>
Message-ID: <pc7NSq2t8KUUyvR5kcietH7ExnnSpl9vN5KIXhasyrk=.bcdad243-2948-42fa-aac8-c5cd24c75e76@github.com>

On Thu, 6 Nov 2025 22:44:40 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> With clang-20 using --with-toolchain-type=clang resolveFieldEntry.cpp and resolveMethodEntry.cpp break the build with similar warnings like:
>> 
>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedFieldEntry' [-Werror,-Wnontrivial-memcall]
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>> src/hotspot/share/oops/resolvedFieldEntry.cpp:49:10: note: explicitly cast the pointer to silence this warning
>>    49 |   memset(this, 0, sizeof(*this));
>>       |          ^
>>       |          (void*)
>> 
>> The patch follows the suggested fix.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32-bit compilation error

I think adding some manual paddings might be OK. I am hoping the following will work on all reasonable C++ compilers, so we don't need to hard code any size values.


STATIC_ASSERT(sizeof(ResolvedMethodEntryWithExtra) > sizeof(ResolvedMethodEntry));


In the worst case, we may have to add extra paddings for weird compilers

#ifdef _SOME_COMPILER
    u8 _more_paddings;
#endif

There should be no performance impact as the C++ compiler should be smart enough to combine the init/copy operations of the padding with the trailing "real" fields. E.g., the following can be compiled to a single 64-bit move:


    _get_code(0),
    _put_code(0)
#ifdef _LP64
    , _padding(0)
#endif


There's a trade off with my other proposal, https://github.com/openjdk/jdk/pull/28172, which is arguably more portable, but it's more verbose as you need to copy each field by hand, so it's less maintainable.

I will be fine with either approach, although if we can find a clean *and* portable solution that would be best, but we shouldn't lose our mind doing it :-)

src/hotspot/share/oops/resolvedMethodEntry.cpp line 43:

> 41: STATIC_ASSERT(sizeof(ResolvedMethodEntry) == 16);
> 42: # endif
> 43: #endif

I think this can be cleaned up as:


#ifdef _LP64
STATIC_ASSERT(sizeof(ResolvedMethodEntry) == DEBUG_ONLY(32) NOT_DEBUG(24));
#else
STATIC_ASSERT(sizeof(ResolvedMethodEntry) == DEBUG_ONLY(20) NOT_DEBUG(16));
#endif


But I think this will be better without the need to hard code numbers:


// There should be no more padding at the end of ResolvedMethodEntry
class ResolvedMethodEntryWithExtra : public ResolvedMethodEntry {
  u1 _extra_field;
};
STATIC_ASSERT(sizeof(ResolvedMethodEntryWithExtra) > sizeof(ResolvedMethodEntry));


I tested by changing `u4 _padding2` to `u4 _padding2` in `ResolvedMethodEntry` and the static assert fails.

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

PR Review: https://git.openjdk.org/jdk/pull/26098#pullrequestreview-3431620301
PR Review Comment: https://git.openjdk.org/jdk/pull/26098#discussion_r2501670635

From duke at openjdk.org  Fri Nov  7 05:08:20 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 05:08:20 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v9]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <sN6A_77iG1YR6_RuDHNWQ4t3Ftwr8hKY_hNBAmyNM4M=.358df287-e93e-4548-ba64-f208820ea0be@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  remove blanck line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/0fbcdb09..d8d09007

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

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

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

From duke at openjdk.org  Fri Nov  7 05:22:10 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 05:22:10 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v9]
In-Reply-To: <2yddz-oh3R_8sZlR6zagp-aoev24wvWTGw_7yFCL1yo=.9ad83098-76c8-41d5-9645-63335cb0b2a2@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <2yddz-oh3R_8sZlR6zagp-aoev24wvWTGw_7yFCL1yo=.9ad83098-76c8-41d5-9645-63335cb0b2a2@github.com>
Message-ID: <mFshQWvE96ZhWqV915bEzfYqvr7mQkfqjcvoJnr8g-w=.f71fcdda-c6bc-4f8c-9f77-9a3a60bf2cb4@github.com>

On Wed, 29 Oct 2025 17:41:35 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> The PR needs gtest/jtreg testing results. Also it needs to be checks the new code is covered by existing gtests or new tests are needed.

Done

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3500768402

From kbarrett at openjdk.org  Fri Nov  7 06:37:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 7 Nov 2025 06:37:02 GMT
Subject: RFR: 8358957: [ubsan]: The assert in
 layout_helper_boolean_diffbit() in klass.hpp needs UB to fail [v5]
In-Reply-To: <2tqtSNmhY0bGDrqu06wBvUWw_bpdv311BSM-ij5EEGY=.90ef7eb5-8d88-439c-b0df-f917f3543cc2@github.com>
References: <VWZqau4U-uxZGad1eXOsBNfT_OyYYrBxBhm3tTZANSo=.4ae71682-13fb-4f60-b22c-b2910c1e0368@github.com>
 <2tqtSNmhY0bGDrqu06wBvUWw_bpdv311BSM-ij5EEGY=.90ef7eb5-8d88-439c-b0df-f917f3543cc2@github.com>
Message-ID: <xczquQvh9Rb7_LAFc7RZwQ-8e4sJVgqt9UmdskGNk0g=.64453b5d-9961-43ba-aee9-98b2b8fa97dd@github.com>

On Thu, 6 Nov 2025 13:06:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue.
>> 
>> Tests:
>>  mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product}
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

I have no further comments or issues. Since it's still essentially the
implementation I proposed, I'll leave it to others to approve.

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

PR Review: https://git.openjdk.org/jdk/pull/27288#pullrequestreview-3431878809

From thartmann at openjdk.org  Fri Nov  7 07:43:41 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 07:43:41 GMT
Subject: RFR: 8371388: [BACKOUT] JDK-8365047: Remove exception handler stub
 code in C2
Message-ID: <pvN3zKNWzpT41DcbVd2_U07I1ZowzBjJ2a5QU-dIse0=.5f835c18-eef3-4f4d-b031-a32df7e6deed@github.com>

Clean backout of [JDK-8365047](https://bugs.openjdk.org/browse/JDK-8365047) due to massive failures with different tests in our CI (see JBS for details).

Thanks,
Tobias

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

Commit messages:
 - Revert "8365047: Remove exception handler stub code in C2"

Changes: https://git.openjdk.org/jdk/pull/28187/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28187&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371388
  Stats: 569 lines in 41 files changed: 216 ins; 268 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/28187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28187/head:pull/28187

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

From thartmann at openjdk.org  Fri Nov  7 07:45:28 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 07:45:28 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v10]
In-Reply-To: <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <TV_VDf4fRqXBtuvFZOYyD2NRzv10kxJ-j_jvVHgawfA=.7e96c1a6-f78c-49df-b017-a621704740e1@github.com>
Message-ID: <fjvYU_7dRq3NnQpBg2egiq7e2xK_fZVHrFXwY4Gsuec=.b7e410e5-ca00-4fc0-b9f9-f3f04cb6139a@github.com>

On Tue, 4 Nov 2025 09:48:20 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Rename deoptHandlerOffsetField -> deoptHandlerEntryOffsetField
>  - Merge from the main branch
>  - Address review comments and fix a mistype
>  - Check for NOP and MOVK separately in NativePostCallNop
>  - Test for deoptimization in virtual threads
>    
>    Change-Id: I9ef51b426d34e9b44a3891f6a45307232f900e5a
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1922c4fd...359c2f18

Backing out with https://github.com/openjdk/jdk/pull/28187.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3501135218