From dholmes at openjdk.org  Mon Mar  2 02:10:39 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Mar 2026 02:10:39 GMT
Subject: RFR: 8373128: Stack overflow handling for native stack overflows
In-Reply-To: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
References: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
Message-ID: <HR0XNIF0p-DkaWmaaSI6Jhu6o0CbwXHEzpLLoDPghXE=.b407fa2c-00a3-4bfe-b798-747b8be76bf7@github.com>

On Wed, 4 Feb 2026 07:19:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still Draft, pls ignore for now. Patch is not done yet.
> 
> This patch enables hs-err file generation for native out-of-stack cases. It is an optional analysis feature one can use when JVMs mysteriously vanish - typically, vanishing JVMs are either native stack overflows or OOM kills.
> 
> This was motivated by the analysis difficulties of bugs like https://bugs.openjdk.org/browse/JDK-8371630. There are many more examples.
> 
> ### Motivation
> 
> Today, when native stack overflows, the JVM dies immediately without an hs-err file. This is because C++-compiled code does not bang - if the stack is too small, we walk right into whatever caps the stack. That might be our own yellow/red guard pages, native guard pages placed by libc or kernel, or possibly unmapped area after the end of the stack. 
> 
> Since we don't have a stack left to run the signal handler on, we cannot produce the hs-err file. If one is very lucky, the libc writes a short "Stack overflow" to stderr. But usually not: if it is a JavaThread and we run into our own yellow/red pages, it counts as a simple segmentation fault from the OS's point of view, since the fault address is inside of what it thinks is a valid pthread stack. So, typically, you just see "Segmentation fault" on stderr.
> 
> ***Why do we need this patch? Don't we bang enough space for native code we call?***
> 
> We bang when entering a native function from Java. The maximum stack size we assume at that time might not be enough; moreover, the native code may be buggy or just too deeply or infinitely recursive. 
> 
> ***We could just increase `ShadowPages`, right?***
> 
> Sure, but the point is we have no hs-err file, so we don't even know it was a stack overflow. One would have to start debugging, which is work-intensive and may not even be possible in a customer scenario. And for buggy recursive code, any `ShadowPages` value might be too small. The code would need to be fixed.
> 
> ### Implementation
> 
> The patch uses alternative signal stacks. That is a simple, robust solution with few moving parts. It works out of the box for all cases: 
> - Stack overflows inside native JNI code from Java 
> - Stack overflows inside Hotspot-internal JavaThread children (e.g. CompilerThread, AttachListenerThread etc)
> - Stack overflows in non-Java threads (e.g. VMThread, ConcurrentGCThread)
> - Stack overflows in outside threads that are attached to the JVM, e.g. third-party JVMTI threads
> 
> The drawback of this simplicity is that it is not suitable for always-on production use. That is du...

Hi Thomas,

My main concern with this is that it is so hard to test and we will never know to what extent it is getting used. It's usefulness depends entirely on support organizations knowing about it and telling customers to enable this (in production - which they might balk at) to try and better diagnose mystery crashes.

I will run it through our testing - enabled by default - see if anything crops up - while I continue to think about it.

A few minor nits/comments below.

Thanks

src/hotspot/os/posix/threadAltSigStack_posix.cpp line 115:

> 113: 
> 114:   if (success) {
> 115:     step ++;

Suggestion:

    step++;

src/hotspot/os/posix/threadAltSigStack_posix.cpp line 120:

> 118: 
> 119:   if (success) {
> 120:     step ++;

Suggestion:

    step++;

src/hotspot/os/posix/threadAltSigStack_posix.cpp line 140:

> 138:   sigaltstack_and_log(&ss, &oss);
> 139: 
> 140:   // --- From here on, if we receive a signal, we'll run on the alternative stack ----

Only for SIGSEGV/BUS right?

src/hotspot/os/posix/threadAltSigStack_posix.cpp line 155:

> 153: 
> 154:   assert(this == Thread::current_or_null_safe(), "Only for current thread");
> 155:   assert(_altsigstack != nullptr, "Not enabled?");

This is redundant given you checked for null above.

src/hotspot/os/posix/threadAltSigStack_posix.cpp line 170:

> 168: 
> 169:   assert(oss.ss_sp == _altsigstack, "Different stack? " PTR_FORMAT " vs " PTR_FORMAT, p2i(oss.ss_sp), p2i(_altsigstack));
> 170:   assert(oss.ss_size == stacksize, "Different size?");

Please report the two sizes

src/hotspot/share/code/nmethod.cpp line 947:

> 945:       // Buffering to a stringStream, disable internal buffering so it's not done twice.
> 946:       method()->print_codes_on(&ss, 0, false);
> 947:     }

So we have lost some debugging information whenever alt-stacks are enabled. ??

src/hotspot/share/nmt/memTag.hpp line 62:

> 60:   f(mtObjectMonitor,  "Object Monitors")                                             \
> 61:   f(mtJNI,            "JNI")                                                         \
> 62:   f(mtAltStack,       "Alternate Stacks")                                            \

Suggestion:

  f(mtAltStack,       "Alternate Signal Stacks")                                            \

src/hotspot/share/runtime/globals.hpp line 2011:

> 2009:                                                                             \
> 2010:   product(bool, UseAltSigStacks, false, DIAGNOSTIC,                         \
> 2011:           "Enable the use of alternative signal stacks.")                   \

Should state it has no affect on Windows (or non-Posix).

src/hotspot/share/runtime/stackOverflow.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2026, Oracle and/or its affiliates. All rights reserved.

There are no changes in this file.

test/hotspot/jtreg/gtest/NativeStackOverflowGtest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.

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

PR Review: https://git.openjdk.org/jdk/pull/29559#pullrequestreview-3873717807
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870155311
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870155758
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870159957
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870162567
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870167765
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870172171
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870172810
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870175316
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870176469
PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870184900

From dholmes at openjdk.org  Mon Mar  2 02:16:23 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Mar 2026 02:16:23 GMT
Subject: RFR: 8373128: Stack overflow handling for native stack overflows
In-Reply-To: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
References: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
Message-ID: <cSBvmS8EkKi9KO_ZtwWRN54HzOh-pF7sWvTni3br8TY=.ada925d9-a339-4316-9994-44602ad88beb@github.com>

On Wed, 4 Feb 2026 07:19:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still Draft, pls ignore for now. Patch is not done yet.
> 
> This patch enables hs-err file generation for native out-of-stack cases. It is an optional analysis feature one can use when JVMs mysteriously vanish - typically, vanishing JVMs are either native stack overflows or OOM kills.
> 
> This was motivated by the analysis difficulties of bugs like https://bugs.openjdk.org/browse/JDK-8371630. There are many more examples.
> 
> ### Motivation
> 
> Today, when native stack overflows, the JVM dies immediately without an hs-err file. This is because C++-compiled code does not bang - if the stack is too small, we walk right into whatever caps the stack. That might be our own yellow/red guard pages, native guard pages placed by libc or kernel, or possibly unmapped area after the end of the stack. 
> 
> Since we don't have a stack left to run the signal handler on, we cannot produce the hs-err file. If one is very lucky, the libc writes a short "Stack overflow" to stderr. But usually not: if it is a JavaThread and we run into our own yellow/red pages, it counts as a simple segmentation fault from the OS's point of view, since the fault address is inside of what it thinks is a valid pthread stack. So, typically, you just see "Segmentation fault" on stderr.
> 
> ***Why do we need this patch? Don't we bang enough space for native code we call?***
> 
> We bang when entering a native function from Java. The maximum stack size we assume at that time might not be enough; moreover, the native code may be buggy or just too deeply or infinitely recursive. 
> 
> ***We could just increase `ShadowPages`, right?***
> 
> Sure, but the point is we have no hs-err file, so we don't even know it was a stack overflow. One would have to start debugging, which is work-intensive and may not even be possible in a customer scenario. And for buggy recursive code, any `ShadowPages` value might be too small. The code would need to be fixed.
> 
> ### Implementation
> 
> The patch uses alternative signal stacks. That is a simple, robust solution with few moving parts. It works out of the box for all cases: 
> - Stack overflows inside native JNI code from Java 
> - Stack overflows inside Hotspot-internal JavaThread children (e.g. CompilerThread, AttachListenerThread etc)
> - Stack overflows in non-Java threads (e.g. VMThread, ConcurrentGCThread)
> - Stack overflows in outside threads that are attached to the JVM, e.g. third-party JVMTI threads
> 
> The drawback of this simplicity is that it is not suitable for always-on production use. That is du...

PS. An updated bug synopsis and description might be good e.g. Add diagnostic alternate stack option for handling native stack overflows

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

PR Comment: https://git.openjdk.org/jdk/pull/29559#issuecomment-3981628362

From dholmes at openjdk.org  Mon Mar  2 02:34:18 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Mar 2026 02:34:18 GMT
Subject: RFR: 8378793: Add ResolvedFieldEntry is_valid assert [v4]
In-Reply-To: <18rnlPy-fi7-gnLsaub3EJF72vJb-kQsw3rQlVGcpWA=.729be923-0b2d-4a8b-9f04-777737311093@github.com>
References: <ZIGrXHMqJfJuPjOat24EevZwPCNluGt6E_hmzWv3kwI=.4e258392-e734-49f6-bad5-0de602749d8d@github.com>
 <18rnlPy-fi7-gnLsaub3EJF72vJb-kQsw3rQlVGcpWA=.729be923-0b2d-4a8b-9f04-777737311093@github.com>
Message-ID: <SChbB2e7Ov1wl56qFuv8uGFUuZh5es01bdNzetDtGhs=.bda04b2d-dc6c-4648-87fe-11889c6f0756@github.com>

On Fri, 27 Feb 2026 17:15:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this small change to add an assert for values in ResolvedFieldEntry, which was useful for debugging at one time.
>> Tested with tier1-3
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve assert message.

Updated version seems okay - thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29943#pullrequestreview-3873805063

From dholmes at openjdk.org  Mon Mar  2 02:42:21 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Mar 2026 02:42:21 GMT
Subject: RFR: 8378845: Add NoSafepointVerifier to CriticalSection classes
In-Reply-To: <adTF3pm5HCNV5Y9vCy4NnGTTsnsRSru1eqwUSRV2QmA=.8e76372b-b907-4210-ae9a-30ca46a6c00b@github.com>
References: <adTF3pm5HCNV5Y9vCy4NnGTTsnsRSru1eqwUSRV2QmA=.8e76372b-b907-4210-ae9a-30ca46a6c00b@github.com>
Message-ID: <4ENuBeQWUr5T89IIV30ha4Ecx1heYaFafLDOo_1xDx4=.f5da932d-f358-4229-bbfd-297433d80320@github.com>

On Fri, 27 Feb 2026 14:40:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that adds `NoSafepointVerifier`s into `GlobalCounter::CriticalSection` and `SingleWriterSynchronizer::CriticalSection` - any safepoint in a critical section of these kinds will deadlock the VM.
> 
> This relates to [JDK-8378820](https://bugs.openjdk.org/browse/JDK-8378820) that apparently shows the problem, and originally this change has been written to debug the other. However so far it did not help reproducing it, and it is worth having anyway. 
> 
> Testing: gha, tier1-5 run with that change did not show an issue, around 3k runs of the failing test in JDK-8378820 without failures
> 
> Thanks,
>   Thomas

Seems reasonable. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29958#pullrequestreview-3873817826

From ysuenaga at openjdk.org  Mon Mar  2 02:43:20 2026
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 2 Mar 2026 02:43:20 GMT
Subject: RFR: 8373128: Stack overflow handling for native stack overflows
In-Reply-To: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
References: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
Message-ID: <NdKcdrlh9p6q34H_8TyIaPOlQ1-sTB3_xFwuCJoVDM0=.5fafe8de-0e26-4f9e-be4b-9cc5ad0cfb11@github.com>

On Wed, 4 Feb 2026 07:19:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still Draft, pls ignore for now. Patch is not done yet.
> 
> This patch enables hs-err file generation for native out-of-stack cases. It is an optional analysis feature one can use when JVMs mysteriously vanish - typically, vanishing JVMs are either native stack overflows or OOM kills.
> 
> This was motivated by the analysis difficulties of bugs like https://bugs.openjdk.org/browse/JDK-8371630. There are many more examples.
> 
> ### Motivation
> 
> Today, when native stack overflows, the JVM dies immediately without an hs-err file. This is because C++-compiled code does not bang - if the stack is too small, we walk right into whatever caps the stack. That might be our own yellow/red guard pages, native guard pages placed by libc or kernel, or possibly unmapped area after the end of the stack. 
> 
> Since we don't have a stack left to run the signal handler on, we cannot produce the hs-err file. If one is very lucky, the libc writes a short "Stack overflow" to stderr. But usually not: if it is a JavaThread and we run into our own yellow/red pages, it counts as a simple segmentation fault from the OS's point of view, since the fault address is inside of what it thinks is a valid pthread stack. So, typically, you just see "Segmentation fault" on stderr.
> 
> ***Why do we need this patch? Don't we bang enough space for native code we call?***
> 
> We bang when entering a native function from Java. The maximum stack size we assume at that time might not be enough; moreover, the native code may be buggy or just too deeply or infinitely recursive. 
> 
> ***We could just increase `ShadowPages`, right?***
> 
> Sure, but the point is we have no hs-err file, so we don't even know it was a stack overflow. One would have to start debugging, which is work-intensive and may not even be possible in a customer scenario. And for buggy recursive code, any `ShadowPages` value might be too small. The code would need to be fixed.
> 
> ### Implementation
> 
> The patch uses alternative signal stacks. That is a simple, robust solution with few moving parts. It works out of the box for all cases: 
> - Stack overflows inside native JNI code from Java 
> - Stack overflows inside Hotspot-internal JavaThread children (e.g. CompilerThread, AttachListenerThread etc)
> - Stack overflows in non-Java threads (e.g. VMThread, ConcurrentGCThread)
> - Stack overflows in outside threads that are attached to the JVM, e.g. third-party JVMTI threads
> 
> The drawback of this simplicity is that it is not suitable for always-on production use. That is du...

We discussed about using `sigaltstack`: https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2011-August/002370.html

I remember `sigaltstack()` has security bug on older Linux Kernel, but it it is fixed in later 2.6.
Older JDK (maybe 6?) implemented to use `sigaltstack()`, but I heard it removed due to this bug.

This PR uses `sigaltstack()`, so I concern we need to consider for older Linux Kernel. (it is better not to consider older environment, of course...)

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

PR Comment: https://git.openjdk.org/jdk/pull/29559#issuecomment-3981691736

From dholmes at openjdk.org  Mon Mar  2 03:17:19 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Mar 2026 03:17:19 GMT
Subject: RFR: 8373128: Stack overflow handling for native stack overflows
In-Reply-To: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
References: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
Message-ID: <_Xx76MQhXuKfmZi6Gv3qoxt1QxgZFbLKnqXnJfoitLg=.2e87a7b7-21eb-4dca-8017-ce55684cfe1c@github.com>

On Wed, 4 Feb 2026 07:19:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still Draft, pls ignore for now. Patch is not done yet.
> 
> This patch enables hs-err file generation for native out-of-stack cases. It is an optional analysis feature one can use when JVMs mysteriously vanish - typically, vanishing JVMs are either native stack overflows or OOM kills.
> 
> This was motivated by the analysis difficulties of bugs like https://bugs.openjdk.org/browse/JDK-8371630. There are many more examples.
> 
> ### Motivation
> 
> Today, when native stack overflows, the JVM dies immediately without an hs-err file. This is because C++-compiled code does not bang - if the stack is too small, we walk right into whatever caps the stack. That might be our own yellow/red guard pages, native guard pages placed by libc or kernel, or possibly unmapped area after the end of the stack. 
> 
> Since we don't have a stack left to run the signal handler on, we cannot produce the hs-err file. If one is very lucky, the libc writes a short "Stack overflow" to stderr. But usually not: if it is a JavaThread and we run into our own yellow/red pages, it counts as a simple segmentation fault from the OS's point of view, since the fault address is inside of what it thinks is a valid pthread stack. So, typically, you just see "Segmentation fault" on stderr.
> 
> ***Why do we need this patch? Don't we bang enough space for native code we call?***
> 
> We bang when entering a native function from Java. The maximum stack size we assume at that time might not be enough; moreover, the native code may be buggy or just too deeply or infinitely recursive. 
> 
> ***We could just increase `ShadowPages`, right?***
> 
> Sure, but the point is we have no hs-err file, so we don't even know it was a stack overflow. One would have to start debugging, which is work-intensive and may not even be possible in a customer scenario. And for buggy recursive code, any `ShadowPages` value might be too small. The code would need to be fixed.
> 
> ### Implementation
> 
> The patch uses alternative signal stacks. That is a simple, robust solution with few moving parts. It works out of the box for all cases: 
> - Stack overflows inside native JNI code from Java 
> - Stack overflows inside Hotspot-internal JavaThread children (e.g. CompilerThread, AttachListenerThread etc)
> - Stack overflows in non-Java threads (e.g. VMThread, ConcurrentGCThread)
> - Stack overflows in outside threads that are attached to the JVM, e.g. third-party JVMTI threads
> 
> The drawback of this simplicity is that it is not suitable for always-on production use. That is du...

src/hotspot/share/code/nmethod.cpp line 943:

> 941:     // nmethod::continuation_for_implicit_exception runs in a signal handler, and
> 942:     // Method::print_codes_on implicitly assumes (see methodHandle::methodHandle)
> 943:     // that we run on the same stack as the faulting code.

I assume you are referring to:

// Constructor for metadata handles
#define DEF_METADATA_HANDLE_FN(name, type) \
inline name##Handle::name##Handle(Thread* thread, type* obj) : _value(obj), _thread(thread) { \
  if (obj != nullptr) {                                                   \
    assert(((Metadata*)obj)->is_valid(), "obj is valid");              \
    assert(_thread == Thread::current(), "thread must be current");    \
    assert(_thread->is_in_live_stack((address)this), "not on stack?"); \   <===== HERE
    _thread->metadata_handles()->push((Metadata*)obj);                 \
  }                                                                    \
}                                                                      \

but this code means we can't create any metadata handle whilst executing on the alt-stack. I triggered it by running the test `runtime/ErrorHandling/MachCodeFramesInErrorFile.java`. I'd suggest disabling the assert for UseAltSigStacks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29559#discussion_r2870316016

From qamai at openjdk.org  Mon Mar  2 04:33:19 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Mar 2026 04:33:19 GMT
Subject: RFR: 8278857: C2: optimize (x << 2) & -4 to x (and similar
 patterns) -> KnownBits for LShift [v2]
In-Reply-To: <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
References: <oFSgX82fpKQHUxFm084V1UVZNypugYpGar8KBsEArlI=.cb358b68-fc66-4427-8415-112c690e95f3@github.com>
 <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
Message-ID: <aIUSuPEqDNo-9m17igd71BRer7IoA2Ui84-1veuQ6TA=.ec8890a9-97f2-4b63-8ee1-c4aad9c064fa@github.com>

On Fri, 27 Feb 2026 19:43:03 GMT, Ashay Rane <duke at openjdk.org> wrote:

>> This PR contains the first of the two changes necessary to resolve
>> JDK-8278857.
>> 
>> The commit message, pasted below, has additional details.
>> 
>>> Augment `RangeInference` with information about left shifts
>>> 
>>> Add `RangeInference::infer_lshift()` to compute type information for
>>> left shift operations.  This method tracks known zero bits in the low
>>> positions (the bottom `shift` bits are always zero after a left shift)
>>> and computes signed and unsigned range bounds when the shift does not
>>> cause overflow.
>>> 
>>> This is the first of the two changes necessary to resolve JDK-8278857.
>>> The second change will build on top of these changes to enable AND nodes
>>> to be optimized away when the bits that would have been cleared by the
>>> AND operation were already known to be zero.
>
> Ashay Rane has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments
>   
>   1. Elided redundant check when type is known to not be `Type::BOTTOM`.
>   
>   2. Used `RangerInference` to AND the shift amount with 31 or 63 (based
>      on the basic type) to match the Java shift semantics so that we have
>      a higher chance of triggering the optimization.
>   
>   3. Added a `type_width()` function that can work with `uintn_t<N>`
>      types, in addition to other unsigned types like `juint` and `julong`.
>   
>   4. Updated `RangeInference::infer_lshift()` to now accept masked shift,
>      which works correctly because the caller (`LShiftINode::Ideal()`)
>      ANDs the shift amount with 31 or 63.

test/hotspot/gtest/opto/test_rangeinference.cpp line 672:

> 670:   test_lshift_for_type<TypeIntMirror<intn_t<1>, uintn_t<1>>>();
> 671:   test_lshift_for_type<TypeIntMirror<intn_t<2>, uintn_t<2>>>();
> 672:   test_lshift_for_type<TypeIntMirror<intn_t<3>, uintn_t<3>>>();

I see you only have the exhaustive tests for 1,2,3-bit integers, it would be better to have some tests for `jint` and `jlong`, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29898#discussion_r2870442725

From qamai at openjdk.org  Mon Mar  2 04:42:21 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Mar 2026 04:42:21 GMT
Subject: RFR: 8278857: C2: optimize (x << 2) & -4 to x (and similar
 patterns) -> KnownBits for LShift [v2]
In-Reply-To: <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
References: <oFSgX82fpKQHUxFm084V1UVZNypugYpGar8KBsEArlI=.cb358b68-fc66-4427-8415-112c690e95f3@github.com>
 <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
Message-ID: <hLDYqyRV70uytC6x9noPp0Fm6HyHOygxOpjHtp7eLIg=.f96f6b8e-ea98-4e04-a7d7-a8c47c34662a@github.com>

On Fri, 27 Feb 2026 19:43:03 GMT, Ashay Rane <duke at openjdk.org> wrote:

>> This PR contains the first of the two changes necessary to resolve
>> JDK-8278857.
>> 
>> The commit message, pasted below, has additional details.
>> 
>>> Augment `RangeInference` with information about left shifts
>>> 
>>> Add `RangeInference::infer_lshift()` to compute type information for
>>> left shift operations.  This method tracks known zero bits in the low
>>> positions (the bottom `shift` bits are always zero after a left shift)
>>> and computes signed and unsigned range bounds when the shift does not
>>> cause overflow.
>>> 
>>> This is the first of the two changes necessary to resolve JDK-8278857.
>>> The second change will build on top of these changes to enable AND nodes
>>> to be optimized away when the bits that would have been cleared by the
>>> AND operation were already known to be zero.
>
> Ashay Rane has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments
>   
>   1. Elided redundant check when type is known to not be `Type::BOTTOM`.
>   
>   2. Used `RangerInference` to AND the shift amount with 31 or 63 (based
>      on the basic type) to match the Java shift semantics so that we have
>      a higher chance of triggering the optimization.
>   
>   3. Added a `type_width()` function that can work with `uintn_t<N>`
>      types, in addition to other unsigned types like `juint` and `julong`.
>   
>   4. Updated `RangeInference::infer_lshift()` to now accept masked shift,
>      which works correctly because the caller (`LShiftINode::Ideal()`)
>      ANDs the shift amount with 31 or 63.

src/hotspot/share/utilities/intn_t.hpp line 181:

> 179:   // of the underlying storage rather than the logical type width.  So we
> 180:   // instead compute the number of 1s in the maximum value.
> 181:   static_assert(!std::is_signed<T>::value, "type_width requires an unsigned type");

`std::is_signed` is `false` for `intn_t`, you need to manually check that `T(-1) > T(0)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29898#discussion_r2870459963

From qamai at openjdk.org  Mon Mar  2 04:45:22 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Mar 2026 04:45:22 GMT
Subject: RFR: 8278857: C2: optimize (x << 2) & -4 to x (and similar
 patterns) -> KnownBits for LShift [v2]
In-Reply-To: <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
References: <oFSgX82fpKQHUxFm084V1UVZNypugYpGar8KBsEArlI=.cb358b68-fc66-4427-8415-112c690e95f3@github.com>
 <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
Message-ID: <XmEitbe3Qa9hKbKR1mVJXom8FVSMHQUtkV8i-_DYRzU=.3b2fd90c-a06f-4b87-be05-d168e8915d72@github.com>

On Fri, 27 Feb 2026 19:43:03 GMT, Ashay Rane <duke at openjdk.org> wrote:

>> This PR contains the first of the two changes necessary to resolve
>> JDK-8278857.
>> 
>> The commit message, pasted below, has additional details.
>> 
>>> Augment `RangeInference` with information about left shifts
>>> 
>>> Add `RangeInference::infer_lshift()` to compute type information for
>>> left shift operations.  This method tracks known zero bits in the low
>>> positions (the bottom `shift` bits are always zero after a left shift)
>>> and computes signed and unsigned range bounds when the shift does not
>>> cause overflow.
>>> 
>>> This is the first of the two changes necessary to resolve JDK-8278857.
>>> The second change will build on top of these changes to enable AND nodes
>>> to be optimized away when the bits that would have been cleared by the
>>> AND operation were already known to be zero.
>
> Ashay Rane has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments
>   
>   1. Elided redundant check when type is known to not be `Type::BOTTOM`.
>   
>   2. Used `RangerInference` to AND the shift amount with 31 or 63 (based
>      on the basic type) to match the Java shift semantics so that we have
>      a higher chance of triggering the optimization.
>   
>   3. Added a `type_width()` function that can work with `uintn_t<N>`
>      types, in addition to other unsigned types like `juint` and `julong`.
>   
>   4. Updated `RangeInference::infer_lshift()` to now accept masked shift,
>      which works correctly because the caller (`LShiftINode::Ideal()`)
>      ANDs the shift amount with 31 or 63.

LGTM otherwise, I submitted testing.

src/hotspot/share/utilities/intn_t.hpp line 167:

> 165: }
> 166: 
> 167: template <typename T>

Can you move this into a class, maybe `HotspotNumerics` is a good name, it helps hide this private implementation, too.

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

PR Review: https://git.openjdk.org/jdk/pull/29898#pullrequestreview-3874027327
PR Review Comment: https://git.openjdk.org/jdk/pull/29898#discussion_r2870467903

From qamai at openjdk.org  Mon Mar  2 04:51:21 2026
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 2 Mar 2026 04:51:21 GMT
Subject: RFR: 8278857: C2: optimize (x << 2) & -4 to x (and similar
 patterns) -> KnownBits for LShift [v2]
In-Reply-To: <hLDYqyRV70uytC6x9noPp0Fm6HyHOygxOpjHtp7eLIg=.f96f6b8e-ea98-4e04-a7d7-a8c47c34662a@github.com>
References: <oFSgX82fpKQHUxFm084V1UVZNypugYpGar8KBsEArlI=.cb358b68-fc66-4427-8415-112c690e95f3@github.com>
 <DpedRNpn-n0ElpO3zzV7piIQOp_DKsXPvGMg_gbRm9Q=.aef130d9-643d-42cb-98d8-a393dbdf644b@github.com>
 <hLDYqyRV70uytC6x9noPp0Fm6HyHOygxOpjHtp7eLIg=.f96f6b8e-ea98-4e04-a7d7-a8c47c34662a@github.com>
Message-ID: <nZP_LDRsoHAlFa8X9ylb-g7BTJrjtVLgSh4Qz0BNsro=.4a45d3a9-6811-4040-b2ed-6cd652820e46@github.com>

On Mon, 2 Mar 2026 04:39:34 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Ashay Rane has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>>   
>>   1. Elided redundant check when type is known to not be `Type::BOTTOM`.
>>   
>>   2. Used `RangerInference` to AND the shift amount with 31 or 63 (based
>>      on the basic type) to match the Java shift semantics so that we have
>>      a higher chance of triggering the optimization.
>>   
>>   3. Added a `type_width()` function that can work with `uintn_t<N>`
>>      types, in addition to other unsigned types like `juint` and `julong`.
>>   
>>   4. Updated `RangeInference::infer_lshift()` to now accept masked shift,
>>      which works correctly because the caller (`LShiftINode::Ideal()`)
>>      ANDs the shift amount with 31 or 63.
>
> src/hotspot/share/utilities/intn_t.hpp line 181:
> 
>> 179:   // of the underlying storage rather than the logical type width.  So we
>> 180:   // instead compute the number of 1s in the maximum value.
>> 181:   static_assert(!std::is_signed<T>::value, "type_width requires an unsigned type");
> 
> `std::is_signed` is `false` for `intn_t`, you need to manually check that `T(-1) > T(0)`.

Adding a template `HotSpotNumerics::is_signed` is a good idea, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29898#discussion_r2870481515

From dholmes at openjdk.org  Mon Mar  2 05:40:19 2026
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Mar 2026 05:40:19 GMT
Subject: RFR: 8373128: Stack overflow handling for native stack overflows
In-Reply-To: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
References: <OQC08BN93UrMrTCc-9mmeSIXhVKFdJk4kFkKSVe-eQQ=.8bda1cf3-e6db-443f-8492-3c9bb8cac600@github.com>
Message-ID: <5rIvxlrVDm4foQqD5AacnstLHTtk9Oc1fsdsFP4_0Xo=.c329bd97-2bda-4119-a5d4-520f27bc8932@github.com>

On Wed, 4 Feb 2026 07:19:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still Draft, pls ignore for now. Patch is not done yet.
> 
> This patch enables hs-err file generation for native out-of-stack cases. It is an optional analysis feature one can use when JVMs mysteriously vanish - typically, vanishing JVMs are either native stack overflows or OOM kills.
> 
> This was motivated by the analysis difficulties of bugs like https://bugs.openjdk.org/browse/JDK-8371630. There are many more examples.
> 
> ### Motivation
> 
> Today, when native stack overflows, the JVM dies immediately without an hs-err file. This is because C++-compiled code does not bang - if the stack is too small, we walk right into whatever caps the stack. That might be our own yellow/red guard pages, native guard pages placed by libc or kernel, or possibly unmapped area after the end of the stack. 
> 
> Since we don't have a stack left to run the signal handler on, we cannot produce the hs-err file. If one is very lucky, the libc writes a short "Stack overflow" to stderr. But usually not: if it is a JavaThread and we run into our own yellow/red pages, it counts as a simple segmentation fault from the OS's point of view, since the fault address is inside of what it thinks is a valid pthread stack. So, typically, you just see "Segmentation fault" on stderr.
> 
> ***Why do we need this patch? Don't we bang enough space for native code we call?***
> 
> We bang when entering a native function from Java. The maximum stack size we assume at that time might not be enough; moreover, the native code may be buggy or just too deeply or infinitely recursive. 
> 
> ***We could just increase `ShadowPages`, right?***
> 
> Sure, but the point is we have no hs-err file, so we don't even know it was a stack overflow. One would have to start debugging, which is work-intensive and may not even be possible in a customer scenario. And for buggy recursive code, any `ShadowPages` value might be too small. The code would need to be fixed.
> 
> ### Implementation
> 
> The patch uses alternative signal stacks. That is a simple, robust solution with few moving parts. It works out of the box for all cases: 
> - Stack overflows inside native JNI code from Java 
> - Stack overflows inside Hotspot-internal JavaThread children (e.g. CompilerThread, AttachListenerThread etc)
> - Stack overflows in non-Java threads (e.g. VMThread, ConcurrentGCThread)
> - Stack overflows in outside threads that are attached to the JVM, e.g. third-party JVMTI threads
> 
> The drawback of this simplicity is that it is not suitable for always-on production use. That is du...

This also seems to break the SA core dump analysis when used. The main thread (that triggers the crash for core dump analysis) gives:

sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntegerRegisterSet(BsdDebuggerLocal.java:472)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:68)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdCDebugger.topFrameForThread(BsdCDebugger.java:88)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:103)

And if we do trigger a crash whilst on the alt-stack, we can't report it properly:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S104193/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c9064ba7-6869-444d-8711-6d351e4aef68/runs/13a2783a-fcf1-4587-9b41-fa976ba25ed0/workspace/open/src/hotspot/share/runtime/thread.hpp:469), pid=61163, tid=25603
#  assert(stack_base() > limit && limit >= stack_end()) failed: limit is outside of stack
#
...
---------------  T H R E A D  ---------------

Current thread (0x000000013d057e10):  
[error occurred during error reporting (printing current thread), id 0xe0000000, Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/da1065b5-7b94-4f0d-85e9-a3a252b9a32e-S104193/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c9064ba7-6869-444d-8711-6d351e4aef68/runs/13a2783a-fcf1-4587-9b41-fa976ba25ed0/workspace/open/src/hotspot/share/runtime/thread.hpp:469)]
Stack: [0x000000016ce30000,0x000000016ceb3000],  sp=0x0000000105d89920 **OUTSIDE STACK**.
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x1250500]  VMError::report(outputStream*, bool)+0x1d1c  (thread.hpp:469)

Interestingly a few tests seem to fail only on macOS.

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

PR Comment: https://git.openjdk.org/jdk/pull/29559#issuecomment-3982244026
PR Comment: https://git.openjdk.org/jdk/pull/29559#issuecomment-3982248264

From duke at openjdk.org  Mon Mar  2 08:39:22 2026
From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=)
Date: Mon, 2 Mar 2026 08:39:22 GMT
Subject: RFR: 8377777: Improve logging when rejecting assets from the AOT
 archive [v10]
In-Reply-To: <p9C6EdymCHkl9RaH5ATEyqp0Cc47B5IB45BY5K39oZs=.6c12dda9-1549-4631-bf19-ece33cf8c484@github.com>
References: <p9C6EdymCHkl9RaH5ATEyqp0Cc47B5IB45BY5K39oZs=.6c12dda9-1549-4631-bf19-ece33cf8c484@github.com>
Message-ID: <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>

> Restored the check `if (resolved)` when printing if a CP entry is rejected or archived. If it is not resolved, we shouldn't even bother with it.
> 
> Also, added log messages (mostly based on surrounding comments) on `ConstantPoolCache::can_archive_resolved_method` to add information about why a method gets rejected.
> 
> All the log messages have the same format to be able to parse them easily:
> 
> ` log.print("%s can't be archived because $REASON.",
>                 pool_holder->name()->as_C_string());`

Mar?a Arias de Reyna Dom?nguez 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 15 additional commits since the last revision:

 - Negative test: make sure nothing is rejected on this test
 - Using LogStream
 - Update src/hotspot/share/oops/cpCache.cpp
   
   Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
 - Update src/hotspot/share/oops/cpCache.cpp
   
   Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
 - cleanup and fix tests
 - fixing compiling errors
 - simplify logging and drag reason outside can_archive_resolved_method()
 - Reorganize log prints
 - Adding index on CPPool for better tracking
 - Adding explanation for indy and fields
 - ... and 5 more: https://git.openjdk.org/jdk/compare/dc65d0d6...fb5777ce

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29690/files
  - new: https://git.openjdk.org/jdk/pull/29690/files/c7124748..fb5777ce

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

  Stats: 509372 lines in 1194 files changed: 256807 ins; 242594 del; 9971 mod
  Patch: https://git.openjdk.org/jdk/pull/29690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29690/head:pull/29690

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

From stuefe at openjdk.org  Mon Mar  2 08:39:22 2026
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 2 Mar 2026 08:39:22 GMT
Subject: RFR: 8377777: Improve logging when rejecting assets from the AOT
 archive [v10]
In-Reply-To: <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>
References: <p9C6EdymCHkl9RaH5ATEyqp0Cc47B5IB45BY5K39oZs=.6c12dda9-1549-4631-bf19-ece33cf8c484@github.com>
 <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>
Message-ID: <vdM2lO5Ots-_-Ewaz1cE1d_fBsX64IxTthrSnRgEwl4=.a51a371e-fdf9-4c98-b467-ccf9c3b4a4b4@github.com>

On Mon, 2 Mar 2026 08:35:57 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

>> Restored the check `if (resolved)` when printing if a CP entry is rejected or archived. If it is not resolved, we shouldn't even bother with it.
>> 
>> Also, added log messages (mostly based on surrounding comments) on `ConstantPoolCache::can_archive_resolved_method` to add information about why a method gets rejected.
>> 
>> All the log messages have the same format to be able to parse them easily:
>> 
>> ` log.print("%s can't be archived because $REASON.",
>>                 pool_holder->name()->as_C_string());`
>
> Mar?a Arias de Reyna Dom?nguez 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 15 additional commits since the last revision:
> 
>  - Negative test: make sure nothing is rejected on this test
>  - Using LogStream
>  - Update src/hotspot/share/oops/cpCache.cpp
>    
>    Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
>  - Update src/hotspot/share/oops/cpCache.cpp
>    
>    Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
>  - cleanup and fix tests
>  - fixing compiling errors
>  - simplify logging and drag reason outside can_archive_resolved_method()
>  - Reorganize log prints
>  - Adding index on CPPool for better tracking
>  - Adding explanation for indy and fields
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/dc65d0d6...fb5777ce

Looks good to me.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29690#pullrequestreview-3867913494

From aartemov at openjdk.org  Mon Mar  2 08:55:54 2026
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 2 Mar 2026 08:55:54 GMT
Subject: RFR: 8302745: sp > unextended_sp for interpreted to interpreted
 calls going through method handle linker [v2]
In-Reply-To: <nOyg_oGIrwX4aOAXKe28FjjPoMLmhyJMy_uK5qIHqIs=.50e4d58c-bfa6-4587-b395-97d5b64a9aab@github.com>
References: <FgBoOXw7VzY5HcCMUP9fk2XNqA4nyC7VP5bjux3ityw=.6e309f6d-402e-4e89-a1bb-6827d136a0af@github.com>
 <YkrRP3aHUUkMv6AMqBX6NlIOtw09vKhVkcrJXahu9uA=.ddae107f-4402-49af-8ef6-cfbc5f76c703@github.com>
 <nOyg_oGIrwX4aOAXKe28FjjPoMLmhyJMy_uK5qIHqIs=.50e4d58c-bfa6-4587-b395-97d5b64a9aab@github.com>
Message-ID: <c7y9Qiq6HsPjmPaz-ECa_U0idszRhjppXPeQFEtt8wI=.257a0fba-e0ab-4604-91da-f0a44edc9a93@github.com>

On Thu, 26 Feb 2026 08:39:20 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8302745: Don't touch ARM code.
>>  - 8302745: Addressed reviewer's comments.
>
> Hi Anton.  Sorry, maybe I'm missing something, but this looks wrong.  My understanding is that the aarch64 interpreter frame goes through the following stages:
> 1. new frame, sp includes max_stack and 16 byte alignment, sp <= esp
> 2. call to interpreter, r19=sp snapshot, sp bumped to esp - extra_locals
>     Depending on size of caller max_stack and callee extra_locals, adjusted sp can now be either less or greater than
>     r19, so we can't reliably assert any relationship between the two
> 3. method handle invoke, esp += 1 for membername
> As far as I can tell, this PR changes the meaning of unextended_sp be an aligned version of esp.
> Using this value on method return means SP no longer includes worst case stack size based on max_stack,
> so growing esp can now exceed SP.  But we should have asserts for that, so I probably got something wrong.

@dean-long 
> Hi Anton. Sorry, maybe I'm missing something, but this looks wrong. My understanding is that the aarch64 interpreter frame goes through the following stages:

Hi Dean, thanks for taking a look. You point n2 is related to [8294152](https://bugs.openjdk.org/browse/JDK-8294152), and indeed, with `r19` keeping a snapshot of `sp`, one can't say anything about relation of that snapshot value and the adjusted `sp`.

With  `r19` keeping an aligned version of `esp ` a relationship can be established, but as you mention in point 3, it looks like `esp` can now exceed the `sp`. I did not find any asserts for that, but now added a few myself in the assembly code, and yes, a few tests in tier1 hit them. So this fix is not correct. I will put it back to draft for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/29744#issuecomment-3983005303

From kevinw at openjdk.org  Mon Mar  2 09:09:28 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 2 Mar 2026 09:09:28 GMT
Subject: RFR: 8378110: Add -XX: prefix to settings-file flags in
 RuntimeMXBean.getInputArguments() [v4]
In-Reply-To: <aPKjHQN_gH6nu0FiU1Ihlyn03OgkccGWUFdwxZ80csE=.bd47a539-a378-45b5-9a2a-98d2e8d067d8@github.com>
References: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>
 <xGi6Y6XZ97rMjmR_3cJwd0Lo_Me_VYRA1m2QulCWANQ=.c29ff07e-c280-44aa-b7d2-7f69dbfe7a65@github.com>
 <aPKjHQN_gH6nu0FiU1Ihlyn03OgkccGWUFdwxZ80csE=.bd47a539-a378-45b5-9a2a-98d2e8d067d8@github.com>
Message-ID: <2CAD_wi1JUqFoPWoSvvLvVDKUve5X05l9FAEjC2zf0o=.16b3a3ac-8e1f-4b95-bf99-afb5308fbbe0@github.com>

On Fri, 27 Feb 2026 15:10:13 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   D'oh
>
>> OpenJDK 64-Bit Server VM warning: .hotspotrc file is present but has been ignored.  Run with -XX:Flags=.hotspotrc to load the file.
> 
> Oh, didn't realise that. Perfect!

@olivergillespie IIRC how it works, this will need /integrate again before a /sponsor works

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

PR Comment: https://git.openjdk.org/jdk/pull/29793#issuecomment-3983066966

From ogillespie at openjdk.org  Mon Mar  2 09:14:23 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 2 Mar 2026 09:14:23 GMT
Subject: RFR: 8378110: Add -XX: prefix to settings-file flags in
 RuntimeMXBean.getInputArguments() [v5]
In-Reply-To: <KrNlDUL0Nvhai7omUrwbXDsOy9SgdXcv1e1uYmnDYtc=.99c2ae3d-001c-40d9-9b80-e17594539f9c@github.com>
References: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>
 <KrNlDUL0Nvhai7omUrwbXDsOy9SgdXcv1e1uYmnDYtc=.99c2ae3d-001c-40d9-9b80-e17594539f9c@github.com>
Message-ID: <tbtKUgqkANJusf9rVdz5B48RnvLlrXeE4XG0rLQyslE=.c593c6a9-44e8-4c79-a53d-194c15b5cfca@github.com>

On Fri, 27 Feb 2026 15:11:02 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Flags passed via a settings file (`.hotspotrc`, or `-XX:Flags=my-file`) do not have the `-XX:` prefix like they would have if passed as command-line args. `JVM_GetVmArguments` then prints these flags also without the prefix, along with command-line flags that _are_ prefixed.
>> 
>> However, users of `JVM_GetVmArguments` expect the arguments to be in a format that they can pass as command-line args, for example [in CDS static_dump](https://github.com/openjdk/jdk/blob/63f00fff921ed4ac0f595a0a013d399700433a2c/src/java.base/share/classes/jdk/internal/misc/CDS.java#L329-L338) - CDS static_dump currently *does not work* if the main VM uses flags from a settings file.
>> 
>> So, always add the `-XX:` prefix to flags from settings files in `JVM_GetVmArguments`. Updated existing test to cover this behaviour.
>> 
>> I looked for existing users of `JVM_GetVmArguments` and they either seem like they'll benefit from this change (CDS, JMH via `RuntimeMXBean.getInputArguments()`) or they won't care.
>> 
>> **Testing**
>> 
>> * Updated the existing InputArgument test with a case that verifies the new behaviour.
>> * Confirmed that CDS static_dump and JMH now work on a VM with flags from a file.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy 'no args' handling

Yeah thanks, I was just giving Alan/David time to comment since they already looked earlier.

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

PR Comment: https://git.openjdk.org/jdk/pull/29793#issuecomment-3983088511

From duke at openjdk.org  Mon Mar  2 09:14:24 2026
From: duke at openjdk.org (duke)
Date: Mon, 2 Mar 2026 09:14:24 GMT
Subject: RFR: 8378110: Add -XX: prefix to settings-file flags in
 RuntimeMXBean.getInputArguments() [v5]
In-Reply-To: <KrNlDUL0Nvhai7omUrwbXDsOy9SgdXcv1e1uYmnDYtc=.99c2ae3d-001c-40d9-9b80-e17594539f9c@github.com>
References: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>
 <KrNlDUL0Nvhai7omUrwbXDsOy9SgdXcv1e1uYmnDYtc=.99c2ae3d-001c-40d9-9b80-e17594539f9c@github.com>
Message-ID: <F6dIJUxpcGM7e2NzubrRXkFJAIRySO4zD9DWGvTlC0U=.d4e2caf6-2c82-48cb-a4ee-3d85a0b68603@github.com>

On Fri, 27 Feb 2026 15:11:02 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Flags passed via a settings file (`.hotspotrc`, or `-XX:Flags=my-file`) do not have the `-XX:` prefix like they would have if passed as command-line args. `JVM_GetVmArguments` then prints these flags also without the prefix, along with command-line flags that _are_ prefixed.
>> 
>> However, users of `JVM_GetVmArguments` expect the arguments to be in a format that they can pass as command-line args, for example [in CDS static_dump](https://github.com/openjdk/jdk/blob/63f00fff921ed4ac0f595a0a013d399700433a2c/src/java.base/share/classes/jdk/internal/misc/CDS.java#L329-L338) - CDS static_dump currently *does not work* if the main VM uses flags from a settings file.
>> 
>> So, always add the `-XX:` prefix to flags from settings files in `JVM_GetVmArguments`. Updated existing test to cover this behaviour.
>> 
>> I looked for existing users of `JVM_GetVmArguments` and they either seem like they'll benefit from this change (CDS, JMH via `RuntimeMXBean.getInputArguments()`) or they won't care.
>> 
>> **Testing**
>> 
>> * Updated the existing InputArgument test with a case that verifies the new behaviour.
>> * Confirmed that CDS static_dump and JMH now work on a VM with flags from a file.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy 'no args' handling

@olivergillespie 
Your change (at version 8625c484a20af799f48f06bca7aac0ac9bfd830b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/29793#issuecomment-3983091736

From dbriemann at openjdk.org  Mon Mar  2 10:08:41 2026
From: dbriemann at openjdk.org (David Briemann)
Date: Mon, 2 Mar 2026 10:08:41 GMT
Subject: RFR: 8378675: PPC64: increase instruction cache line size [v4]
In-Reply-To: <qn25MvIi2Bm8Ynk6Yn_gW9xMMjq1RQsgBL5n78uoHq4=.5fac95ac-d1a0-40ff-8d1d-9aff1e97c0bc@github.com>
References: <qn25MvIi2Bm8Ynk6Yn_gW9xMMjq1RQsgBL5n78uoHq4=.5fac95ac-d1a0-40ff-8d1d-9aff1e97c0bc@github.com>
Message-ID: <w-Np4kucr5UXHA6s_wmFl4SfVeh5EGNwah7d6Wf8dPg=.6def3256-f907-4298-ac08-60da480a5d4d@github.com>

> Set the instruction cache line size for Power to 128 bytes.
> 
> Add functions to retrieve the data cache line size and instruction cache line size from the system (AIX & Linux).

David Briemann has updated the pull request incrementally with three additional commits since the last revision:

 - fix calculation
 - revert copyright header updates
 - refactor get cache methods from os into vm_version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29918/files
  - new: https://git.openjdk.org/jdk/pull/29918/files/dfa4bbf9..24019515

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

  Stats: 119 lines in 10 files changed: 80 ins; 31 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29918.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29918/head:pull/29918

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

From aph at openjdk.org  Mon Mar  2 10:14:34 2026
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Mar 2026 10:14:34 GMT
Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1
 volatile field loads [v4]
In-Reply-To: <OkHKlqM2pModc4m-E2IeDf6SFqPGU9KgZQMKi3Zkkn8=.ed0f7381-b821-4039-8a87-61e8d69b2718@github.com>
References: <p7XaTTrJZA65XAB3EoXH_cI34eOKXcSaPozylNiWMss=.4b218507-adbd-4351-996f-88f1c38f5f18@github.com>
 <nkJYB7G_xrlgKde7zSJzCo5cxgzed1mBSlw2ie_15qQ=.20fb92b7-f694-4225-8602-4a63674234a3@github.com>
 <lDfhN5sB1Jct8Iji13Z_K7vKhlxAJLW_Jfoeb6ObVb4=.4782603e-d2a9-40fd-ab1e-84b5af260188@github.com>
 <OkHKlqM2pModc4m-E2IeDf6SFqPGU9KgZQMKi3Zkkn8=.ed0f7381-b821-4039-8a87-61e8d69b2718@github.com>
Message-ID: <m01NgOWIdshkcmHBTbvm7nDjHVLMdxzR9ZO8pOp8NTA=.a120c7b3-6d42-466d-97b1-4d825395a1a1@github.com>

On Fri, 27 Feb 2026 23:25:32 GMT, Ruben <duke at openjdk.org> wrote:

> This would add the `membar_acquire` where in case of `needs_atomic && !is_volatile` in `BarrierSetC1::load_at_resolved` it would have been skipped.

The only circumstances in which this is possible ls a `long` field on a 32-bit system. If a `membar_acquire` in such circumstances is a problem, we can hadle it separately.

 To mitigate this would it be suitable to add a `needs_acquire` parameter to `volatile_field_load`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26748#discussion_r2871556894

From kevinw at openjdk.org  Mon Mar  2 10:19:49 2026
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 2 Mar 2026 10:19:49 GMT
Subject: RFR: 8378110: Add -XX: prefix to settings-file flags in
 RuntimeMXBean.getInputArguments() [v5]
In-Reply-To: <KrNlDUL0Nvhai7omUrwbXDsOy9SgdXcv1e1uYmnDYtc=.99c2ae3d-001c-40d9-9b80-e17594539f9c@github.com>
References: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>
 <KrNlDUL0Nvhai7omUrwbXDsOy9SgdXcv1e1uYmnDYtc=.99c2ae3d-001c-40d9-9b80-e17594539f9c@github.com>
Message-ID: <aKLUaWdt0u9P3mSMAnzohvD4iY95VzmD7fQTFZpY4CM=.26c6157a-ea9a-487f-bcd3-186bacd746a7@github.com>

On Fri, 27 Feb 2026 15:11:02 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Flags passed via a settings file (`.hotspotrc`, or `-XX:Flags=my-file`) do not have the `-XX:` prefix like they would have if passed as command-line args. `JVM_GetVmArguments` then prints these flags also without the prefix, along with command-line flags that _are_ prefixed.
>> 
>> However, users of `JVM_GetVmArguments` expect the arguments to be in a format that they can pass as command-line args, for example [in CDS static_dump](https://github.com/openjdk/jdk/blob/63f00fff921ed4ac0f595a0a013d399700433a2c/src/java.base/share/classes/jdk/internal/misc/CDS.java#L329-L338) - CDS static_dump currently *does not work* if the main VM uses flags from a settings file.
>> 
>> So, always add the `-XX:` prefix to flags from settings files in `JVM_GetVmArguments`. Updated existing test to cover this behaviour.
>> 
>> I looked for existing users of `JVM_GetVmArguments` and they either seem like they'll benefit from this change (CDS, JMH via `RuntimeMXBean.getInputArguments()`) or they won't care.
>> 
>> **Testing**
>> 
>> * Updated the existing InputArgument test with a case that verifies the new behaviour.
>> * Confirmed that CDS static_dump and JMH now work on a VM with flags from a file.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidy 'no args' handling

Thanks for waiting!

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

PR Comment: https://git.openjdk.org/jdk/pull/29793#issuecomment-3983432280

From ogillespie at openjdk.org  Mon Mar  2 10:19:50 2026
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Mon, 2 Mar 2026 10:19:50 GMT
Subject: Integrated: 8378110: Add -XX: prefix to settings-file flags in
 RuntimeMXBean.getInputArguments()
In-Reply-To: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>
References: <syyAUnwjy7bmrSvCNN9HjWDw20xNofCGLSI6ZaKLZPg=.e0eb1c44-0e14-4028-815b-9457ebf115b4@github.com>
Message-ID: <f_jnY7xvDbxSG32s53smJC-73k6qFhQX2XMVH2cu8OY=.0f684b9a-be49-4546-9a62-ff769b495e89@github.com>

On Wed, 18 Feb 2026 15:34:02 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

> Flags passed via a settings file (`.hotspotrc`, or `-XX:Flags=my-file`) do not have the `-XX:` prefix like they would have if passed as command-line args. `JVM_GetVmArguments` then prints these flags also without the prefix, along with command-line flags that _are_ prefixed.
> 
> However, users of `JVM_GetVmArguments` expect the arguments to be in a format that they can pass as command-line args, for example [in CDS static_dump](https://github.com/openjdk/jdk/blob/63f00fff921ed4ac0f595a0a013d399700433a2c/src/java.base/share/classes/jdk/internal/misc/CDS.java#L329-L338) - CDS static_dump currently *does not work* if the main VM uses flags from a settings file.
> 
> So, always add the `-XX:` prefix to flags from settings files in `JVM_GetVmArguments`. Updated existing test to cover this behaviour.
> 
> I looked for existing users of `JVM_GetVmArguments` and they either seem like they'll benefit from this change (CDS, JMH via `RuntimeMXBean.getInputArguments()`) or they won't care.
> 
> **Testing**
> 
> * Updated the existing InputArgument test with a case that verifies the new behaviour.
> * Confirmed that CDS static_dump and JMH now work on a VM with flags from a file.

This pull request has now been integrated.

Changeset: b12daa41
Author:    Oli Gillespie <ogillespie at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b12daa41e23eaac2777a8f89ef279963d0e6f7a0
Stats:     49 lines in 2 files changed: 31 ins; 10 del; 8 mod

8378110: Add -XX: prefix to settings-file flags in RuntimeMXBean.getInputArguments()

Reviewed-by: kevinw, dholmes

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

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

From adinn at openjdk.org  Mon Mar  2 10:25:09 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 2 Mar 2026 10:25:09 GMT
Subject: RFR: 8377777: Improve logging when rejecting assets from the AOT
 archive [v10]
In-Reply-To: <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>
References: <p9C6EdymCHkl9RaH5ATEyqp0Cc47B5IB45BY5K39oZs=.6c12dda9-1549-4631-bf19-ece33cf8c484@github.com>
 <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>
Message-ID: <mJB2n63GKwAw13Hx0kj7ZKqq0LjgGTaBLVdtSnCsPUA=.08eacfda-9345-4b28-a19f-4809a4b101bc@github.com>

On Mon, 2 Mar 2026 08:39:22 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

>> Restored the check `if (resolved)` when printing if a CP entry is rejected or archived. If it is not resolved, we shouldn't even bother with it.
>> 
>> Also, added log messages (mostly based on surrounding comments) on `ConstantPoolCache::can_archive_resolved_method` to add information about why a method gets rejected.
>> 
>> All the log messages have the same format to be able to parse them easily:
>> 
>> ` log.print("%s can't be archived because $REASON.",
>>                 pool_holder->name()->as_C_string());`
>
> Mar?a Arias de Reyna Dom?nguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Negative test: make sure nothing is rejected on this test
>  - Using LogStream
>  - Update src/hotspot/share/oops/cpCache.cpp
>    
>    Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
>  - Update src/hotspot/share/oops/cpCache.cpp
>    
>    Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
>  - cleanup and fix tests
>  - fixing compiling errors
>  - simplify logging and drag reason outside can_archive_resolved_method()
>  - Reorganize log prints
>  - Adding index on CPPool for better tracking
>  - Adding explanation for indy and fields
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8b805630...fb5777ce

Looks good

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29690#pullrequestreview-3875252574

From ayang at openjdk.org  Mon Mar  2 10:25:24 2026
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Mar 2026 10:25:24 GMT
Subject: RFR: 8378948: Remove unused local variable in RunnerGSInserterThread
Message-ID: <_iqdJhnPsezyFlImzSFVljTkbIjcJEhbJOR0pbKzDmg=.a443f4ec-fad3-4ef3-9d86-d078684cad59@github.com>

Trivial removing dead code.

Test: GHA

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

Commit messages:
 - gtest-trivial-unused-local-var

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

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

From aph at openjdk.org  Mon Mar  2 10:30:05 2026
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Mar 2026 10:30:05 GMT
Subject: RFR: 8366441: AArch64: Support WFET in OnSpinWait [v4]
In-Reply-To: <xeE7IHhHZc84SLgfO9k3CJwf1LrbZNb1VvlwNwl6-A4=.11efa377-9f90-4266-8496-81d33216e30e@github.com>
References: <pCQ3UJd__52UsHCs4O0oLcLZTXN602dBEP8zmRvU-H4=.aff34c5d-0a53-4e9a-8107-b6fadc7d9cca@github.com>
 <xeE7IHhHZc84SLgfO9k3CJwf1LrbZNb1VvlwNwl6-A4=.11efa377-9f90-4266-8496-81d33216e30e@github.com>
Message-ID: <a-tni-K9mkGAAD5Pf2u20dxmt4TMyoP8BQPJiKXeGSI=.742a8495-8fd9-4a1d-93ab-94a85db8a2bf@github.com>

On Fri, 27 Feb 2026 23:32:45 GMT, Ruben <duke at openjdk.org> wrote:

>> Implement OnSpinWait based on WFET - wait for event with timeout:
>>  - introduce OnSpinWaitDelay - the OnSpinWait time in nanoseconds;
>>  - the OnSpinWaitInstCount is expected to be 1 when WFET is used;
>>  - the waiting loop is followed by SB - to ensure following instructions aren't speculated until wait is finished;
>>  - the timer register is read via the self-synchronized view CNTVCTSS_EL0 to prevent the read being hoisted out of the loop.
>> 
>> The WFET and CNTVCTSS_EL0 read are added to aarch64-asmtest.py as hex values - using the instruction mnemonics would require support of -march=armv9-2.a, and consequently, the binutils 2.36+.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fix handling platform-specific default values of OnSpinWaitInstCount
>  - Set default OnSpinWaitDelay to 40 and clarify it is the minimal delay
>  - Merge from mainline
>  - Set default OnSpinWaitDelay to 100
>  - Address review comments
>  - Apply PR review "Suggested changes" from @theRealAph
>  - Merge from mainline
>  - Fix bsd_aarch64 build
>  - Update
>    
>    - Address review comments
>    - Fix test
>    - Mark the support experimental
>    - Remove changes in src/hotspot/os_cpu/bsd_aarch64
>  - Merge from mainline
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4e15a4ad...da95b197

With that small change, we're good to go.

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 127:

> 125:           range(1, 99)                                                  \
> 126:   product(uint, OnSpinWaitDelay, 40, EXPERIMENTAL,                      \
> 127:           "The minimal delay (in nanoseconds) of the OnSpinWait loop."  \

Suggestion:

          "The minimum delay (in nanoseconds) of the OnSpinWait loop."  \

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

PR Review: https://git.openjdk.org/jdk/pull/27030#pullrequestreview-3875278792
PR Review Comment: https://git.openjdk.org/jdk/pull/27030#discussion_r2871617770

From adinn at openjdk.org  Mon Mar  2 11:24:48 2026
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 2 Mar 2026 11:24:48 GMT
Subject: RFR: 8372617: Save and restore stubgen stubs when using an AOT
 code cache [v16]
In-Reply-To: <Go54Gywh42CRwyklMujtDmvPuZ78orCsyekS0vmZ68I=.7cda3e62-209f-494b-9c89-b59653232813@github.com>
References: <Go54Gywh42CRwyklMujtDmvPuZ78orCsyekS0vmZ68I=.7cda3e62-209f-494b-9c89-b59653232813@github.com>
Message-ID: <-pdWKbtpbiughrb0N0jG6FYDLRfNfy8LYdEwYeaE2uE=.67b17e3d-b536-4a86-932d-2cab5db3fd0c@github.com>

> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes.
> 
> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints:
> 1. the first declared entry of every stub starts at the first instruction in the stub code range
> 2. all data/code cross-references from one stub to another target a declared stub entry

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

 - merge
 - add AOT logging for C strings
 - fix PrintStubs when loading AOT stubs
 - add missing ZGC external
 - add missing reloc for some stub calls
 - fix klass encode/decode for AOT code
 - merge
 - ensure C1 treats ThreadIdentifier::unsafe_offset() as an external address
 - configure low heap size to exercise more stub code
 - Run AOTCodeFlags test with multiple GCs
 - ... and 39 more: https://git.openjdk.org/jdk/compare/ae4df28b...96c30b31

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

Changes: https://git.openjdk.org/jdk/pull/28433/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28433&range=15
  Stats: 5704 lines in 63 files changed: 4663 ins; 444 del; 597 mod
  Patch: https://git.openjdk.org/jdk/pull/28433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28433/head:pull/28433

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

From syan at openjdk.org  Mon Mar  2 13:31:32 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 2 Mar 2026 13:31:32 GMT
Subject: RFR: 8378948: Remove unused local variable in
 RunnerGSInserterThread
In-Reply-To: <_iqdJhnPsezyFlImzSFVljTkbIjcJEhbJOR0pbKzDmg=.a443f4ec-fad3-4ef3-9d86-d078684cad59@github.com>
References: <_iqdJhnPsezyFlImzSFVljTkbIjcJEhbJOR0pbKzDmg=.a443f4ec-fad3-4ef3-9d86-d078684cad59@github.com>
Message-ID: <eZ5yJVvPhHolR8VMf3YMZAx1oTvo78IY0Gf9UGyp8YM=.b4a74277-8b10-42b0-a5c6-60f62baa1ab7@github.com>

On Mon, 2 Mar 2026 10:16:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: GHA

LGTM.

The unused-variable compiler waning was disabled both by gcc and clang
https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/CompileJvm.gmk#L103 cause the warings was depressed

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/29992#pullrequestreview-3876222609

From jiefu at openjdk.org  Mon Mar  2 13:41:36 2026
From: jiefu at openjdk.org (Jie Fu)
Date: Mon, 2 Mar 2026 13:41:36 GMT
Subject: RFR: 8378948: Remove unused local variable in
 RunnerGSInserterThread
In-Reply-To: <_iqdJhnPsezyFlImzSFVljTkbIjcJEhbJOR0pbKzDmg=.a443f4ec-fad3-4ef3-9d86-d078684cad59@github.com>
References: <_iqdJhnPsezyFlImzSFVljTkbIjcJEhbJOR0pbKzDmg=.a443f4ec-fad3-4ef3-9d86-d078684cad59@github.com>
Message-ID: <PbEbklDAZevoukpeJdePJcFWofPaw9B05Cb838qovQY=.b5d223b5-ee6a-49ca-b020-a9e330b886e7@github.com>

On Mon, 2 Mar 2026 10:16:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: GHA

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29992#pullrequestreview-3876281442

From coleenp at openjdk.org  Mon Mar  2 13:43:04 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Mar 2026 13:43:04 GMT
Subject: RFR: 8378793: Add ResolvedFieldEntry is_valid assert [v4]
In-Reply-To: <18rnlPy-fi7-gnLsaub3EJF72vJb-kQsw3rQlVGcpWA=.729be923-0b2d-4a8b-9f04-777737311093@github.com>
References: <ZIGrXHMqJfJuPjOat24EevZwPCNluGt6E_hmzWv3kwI=.4e258392-e734-49f6-bad5-0de602749d8d@github.com>
 <18rnlPy-fi7-gnLsaub3EJF72vJb-kQsw3rQlVGcpWA=.729be923-0b2d-4a8b-9f04-777737311093@github.com>
Message-ID: <yqw6wXt2xH-2OHcVSUZtcCXTqvQp8uedDX9Fq8mby9o=.11d1cac9-5fed-4ded-b814-e43bd5ea9acd@github.com>

On Fri, 27 Feb 2026 17:15:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this small change to add an assert for values in ResolvedFieldEntry, which was useful for debugging at one time.
>> Tested with tier1-3
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve assert message.

Thanks for reviewing and discussion, David Simms, Matias and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/29943#issuecomment-3984461304

From coleenp at openjdk.org  Mon Mar  2 13:43:05 2026
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Mar 2026 13:43:05 GMT
Subject: Integrated: 8378793: Add ResolvedFieldEntry is_valid assert
In-Reply-To: <ZIGrXHMqJfJuPjOat24EevZwPCNluGt6E_hmzWv3kwI=.4e258392-e734-49f6-bad5-0de602749d8d@github.com>
References: <ZIGrXHMqJfJuPjOat24EevZwPCNluGt6E_hmzWv3kwI=.4e258392-e734-49f6-bad5-0de602749d8d@github.com>
Message-ID: <oGZ8Y3vyKfiyd_m9bohESvc9-3GzIhjP3klSh17yqt0=.fbba3b21-e05d-4f4f-afc4-851751bb4566@github.com>

On Thu, 26 Feb 2026 20:32:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this small change to add an assert for values in ResolvedFieldEntry, which was useful for debugging at one time.
> Tested with tier1-3

This pull request has now been integrated.

Changeset: 29a40c3c
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29a40c3c6821da3d40c3aa45a0650e8d0ad5255d
Stats:     63 lines in 3 files changed: 40 ins; 16 del; 7 mod

8378793: Add ResolvedFieldEntry is_valid assert

Reviewed-by: dholmes, dsimms, matsaave

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

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

From krk at openjdk.org  Mon Mar  2 14:14:26 2026
From: krk at openjdk.org (Kerem Kat)
Date: Mon, 2 Mar 2026 14:14:26 GMT
Subject: RFR: 8366117: Shenandoah: Notify barrier nodes when transitive
 inputs change during IGVN [v4]
In-Reply-To: <MQYcmgafWmpKyf-Z8QcUPAqc4vMQYVYbPhwgPc--caA=.bc91a025-c346-42f8-9dc3-79e6b5ca3f63@github.com>
References: <MQYcmgafWmpKyf-Z8QcUPAqc4vMQYVYbPhwgPc--caA=.bc91a025-c346-42f8-9dc3-79e6b5ca3f63@github.com>
Message-ID: <sK_gaiEtoYFSwHgP7DFKgJaLW2KmTqqGv-BAkRUbJrQ=.c88a487f-3232-4760-8aa8-0d4d22c564c2@github.com>

> `ShenandoahLoadReferenceBarrierNode::Identity()` determines if a barrier can be eliminated by traversing through intermediate nodes (`Phi`, `DecodeN`, `CastPP`, etc.) via `needs_barrier_impl()`. When these intermediate nodes change during IGVN, the barrier is not re-evaluated because IGVN only notifies direct users. This causes `TestVerifyIterativeGVN` to fail with Shenandoah, reporting missed optimization opportunities.
> 
> This fix adds a `BarrierSetC2::enqueue_dependent_gc_barriers()` virtual method that Shenandoah overrides to traverse outputs through the same node types and enqueue dependent barriers for re-evaluation.
> 
> There are more barrier eliminations enabled with this, e.g. in the arbitrarily chosen scrabble of renaissance benchmarks:
> 
> 
> java -XX:+UseShenandoahGC -Xbatch -Xcomp -XX:-TieredCompilation -jar ~/.cache/stress/renaissance-gpl-0.16.1.jar scrabble -r 1 |& tee /dev/stderr | grep "optimize barrier" | sort | uniq -c | sort -rn
> 
> # with fix
> 236 optimize barrier on call
>      75 optimize barrier on alloc
>      35 optimize barrier on barrier
>      23 optimize barrier on parm
>      15 optimize barrier on const
>       1 optimize barrier on barrier
>       1 optimize barrier on null
> TOTAL = 386
> 
> # without fix
> 193 optimize barrier on call
>      72 optimize barrier on alloc
>      32 optimize barrier on barrier
>      23 optimize barrier on parm
>       1 optimize barrier on barrier
>       1 optimize barrier on null
>       1 optimize barrier on const
> TOTAL = 323
> 
> 
> This requires uncommenting prints with `optimize barrier` in `c2/shenandoahSupport.cpp`.
> 
> Also tested with `make test CONF=linux-x86_64-server-fastdebug TEST=compiler/c2/TestVerifyIterativeGVN.java JTREG="VM_OPTIONS=-XX:+UseShenandoahGC -Xcomp -Xbatch -XX:-TieredCompilation"` which passes with the fix and fails without.

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

 - Merge branch 'master' into shenbarrier-optmore-8366117
 - Merge branch 'master' into shenbarrier-optmore-8366117
 - Use a stack instead of recursion
 - Merge branch 'master' into shenbarrier-optmore-8366117
 - 8366117: Shenandoah: Notify barrier nodes when transitive inputs change during IGVN

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29491/files
  - new: https://git.openjdk.org/jdk/pull/29491/files/63606a00..515f788e

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

  Stats: 107213 lines in 1012 files changed: 48108 ins; 39635 del; 19470 mod
  Patch: https://git.openjdk.org/jdk/pull/29491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29491/head:pull/29491

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

From krk at openjdk.org  Mon Mar  2 14:14:29 2026
From: krk at openjdk.org (Kerem Kat)
Date: Mon, 2 Mar 2026 14:14:29 GMT
Subject: RFR: 8366117: Shenandoah: Notify barrier nodes when transitive
 inputs change during IGVN [v3]
In-Reply-To: <5ziCRP8gm2MoAQuKsHY7Q-e5fy_YpNbzUfiwtvDY6TY=.768b9c6c-61a8-471e-aba3-32292e8c4cda@github.com>
References: <MQYcmgafWmpKyf-Z8QcUPAqc4vMQYVYbPhwgPc--caA=.bc91a025-c346-42f8-9dc3-79e6b5ca3f63@github.com>
 <5ziCRP8gm2MoAQuKsHY7Q-e5fy_YpNbzUfiwtvDY6TY=.768b9c6c-61a8-471e-aba3-32292e8c4cda@github.com>
Message-ID: <xCjQRxBP53NYfU1fpROUDZAwRPVgzF19I1JoibieU98=.9a833b23-35a9-47c8-b253-b8821a46bb92@github.com>

On Tue, 17 Feb 2026 18:01:03 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> `ShenandoahLoadReferenceBarrierNode::Identity()` determines if a barrier can be eliminated by traversing through intermediate nodes (`Phi`, `DecodeN`, `CastPP`, etc.) via `needs_barrier_impl()`. When these intermediate nodes change during IGVN, the barrier is not re-evaluated because IGVN only notifies direct users. This causes `TestVerifyIterativeGVN` to fail with Shenandoah, reporting missed optimization opportunities.
>> 
>> This fix adds a `BarrierSetC2::enqueue_dependent_gc_barriers()` virtual method that Shenandoah overrides to traverse outputs through the same node types and enqueue dependent barriers for re-evaluation.
>> 
>> There are more barrier eliminations enabled with this, e.g. in the arbitrarily chosen scrabble of renaissance benchmarks:
>> 
>> 
>> java -XX:+UseShenandoahGC -Xbatch -Xcomp -XX:-TieredCompilation -jar ~/.cache/stress/renaissance-gpl-0.16.1.jar scrabble -r 1 |& tee /dev/stderr | grep "optimize barrier" | sort | uniq -c | sort -rn
>> 
>> # with fix
>> 236 optimize barrier on call
>>      75 optimize barrier on alloc
>>      35 optimize barrier on barrier
>>      23 optimize barrier on parm
>>      15 optimize barrier on const
>>       1 optimize barrier on barrier
>>       1 optimize barrier on null
>> TOTAL = 386
>> 
>> # without fix
>> 193 optimize barrier on call
>>      72 optimize barrier on alloc
>>      32 optimize barrier on barrier
>>      23 optimize barrier on parm
>>       1 optimize barrier on barrier
>>       1 optimize barrier on null
>>       1 optimize barrier on const
>> TOTAL = 323
>> 
>> 
>> This requires uncommenting prints with `optimize barrier` in `c2/shenandoahSupport.cpp`.
>> 
>> Also tested with `make test CONF=linux-x86_64-server-fastdebug TEST=compiler/c2/TestVerifyIterativeGVN.java JTREG="VM_OPTIONS=-XX:+UseShenandoahGC -Xcomp -Xbatch -XX:-TieredCompilation"` which passes with the fix and fails without.
>
> Kerem Kat 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 shenbarrier-optmore-8366117
>  - Use a stack instead of recursion
>  - Merge branch 'master' into shenbarrier-optmore-8366117
>  - 8366117: Shenandoah: Notify barrier nodes when transitive inputs change during IGVN

Hi! Could I get a review on this one?

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

PR Comment: https://git.openjdk.org/jdk/pull/29491#issuecomment-3984640660

From eastigeevich at openjdk.org  Mon Mar  2 14:15:19 2026
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Mar 2026 14:15:19 GMT
Subject: RFR: 8370947: Mitigate Neoverse-N1 erratum 1542419 negative impact
 on GCs and JIT performance [v28]
In-Reply-To: <MQLvg_AKu3XIrdDRxVspjFQLTEJradRtJXevBnpHkKQ=.a4513c3b-518d-47c8-82df-7ab604e7c014@github.com>
References: <hnnk8tkj0iLZkM4Ha_PZyiRXD6YkaDiOiy1SphJkUuU=.c233fcaf-472b-4589-8fc6-8ec3a42a1cba@github.com>
 <pHXJLQVPHdVq6YJfYQW5IHo9Qpvz72wb8jEiH_V6jCE=.dc28f0e8-1941-4bcf-909e-f2f36dd6deab@github.com>
 <iekU5Cc7PyHtV1SPPW9FR9surZ-G4F-41FZmllo1KoA=.d2f6ad0c-d82f-442f-ac99-21a022feebb9@github.com>
 <MQLvg_AKu3XIrdDRxVspjFQLTEJradRtJXevBnpHkKQ=.a4513c3b-518d-47c8-82df-7ab604e7c014@github.com>
Message-ID: <6Qn_rbqGN9x87GEoiDhCIA0MS7pnU6D-WB0RQnWS_2U=.43a8e847-e82c-475a-aedc-0a9e831fdea6@github.com>

On Thu, 26 Feb 2026 10:14:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/share/code/relocInfo.cpp line 621:
>> 
>>> 619: 
>>> 620: 
>>> 621: bool metadata_Relocation::fix_metadata_relocation() {
>> 
>> I understand we return the status here, so that we avoid invalidation when there is no real patching work was done. Granted, it likely matches the behavior we have. But I wonder how much this buys us? If we are doing the deferred invalidation in a very broad scope, it stands to reason we would _almost definitely_ have to invalidate, and all this tracking would _nearly always_ give us the same answer, "Do invalidate"?
>> 
>> IOW, this might be an unnecessary complication of the interface.
>> 
>> _Dropping_ this change would also be more robust, in cases something somewhere _forgets_ to announce the code cache was changed? If we don't trust the downstream code about this and just summarily invalidate, it feels safer.
>
>> @shipilev
>> 
>> > But I wonder how much this buys us?
>> 
>> SPECjvm crypto.aes is the case for this change. When I ran it on Graviton 2, 64 cores I got the following scores:
>>
>>     * Baseline: 1047(min), 1058(max), 1052(geomean)
>> 
>>     * PR: 1058(min), 1078(max), 1069(geomean), +1.6% improvement
> 
> This improvement is almost in the noise. What's the average SPECjvm improvement?
> 
>> **OPTION 1**: If we don't track code modification in `fix_oop_relocations` and assume any call of `fix_oop_relocations` requires icache invalidation, results are the following:
>> 
>>     * 1032(min), 1057(max), 1045(geomean), -0.7% regression
> 
> So, Options 1 and 2 are actually worse than doing nothing?

@theRealAph 

> > SPECjvm crypto.aes is the case for this change. When I ran it on Graviton 2, 64 cores I got the following scores:
> > ```
> > * Baseline: 1047(min), 1058(max), 1052(geomean)
> > 
> > * PR: 1058(min), 1078(max), 1069(geomean), +1.6% improvement
> > ```
> 
> This improvement is almost in the noise. What's the average SPECjvm improvement?

I ran it 58 times with `-i 3 -ict -it 120 -wt 90`. The plan was to run 100 times but it would be taking a lot of time.

Baseline:

                    Mean
                     ?
 ops/min        Frequency
 [1025,1030) ?                              0
 [1030,1035) ? ??                           2
 [1035,1040) ? ????                         4
 [1040,1045) ? ????????                     8
 [1045,1050) ? ????????                     8
 [1050,1055) ? ?????????                    9
 [1055,1060) ? ?????????????               13  ? mode
 [1060,1065) ? ?????                        5
 [1065,1070) ? ???                          3
 [1070,1075) ? ??                           2
 [1075,1080) ? ??                           2
 [1080,1085) ?                              0
 [1085,1090) ? ??                           2
 [1090,1095) ?                              0
              ???????????????????????????
              Mean = 1054.53    n = 58


Fix:

                      Mean
                       ?
 ops/min        Frequency
 [1025,1030) ? ?                            1
 [1030,1035) ?                              0
 [1035,1040) ? ?                            1
 [1040,1045) ? ????                         4
 [1045,1050) ? ??????                       6
 [1050,1055) ? ??????????                  10
 [1055,1060) ? ????????                     8
 [1060,1065) ? ????????                     8
 [1065,1070) ? ??????????                  10  ? mode (tied)
 [1070,1075) ? ???????                      7
 [1075,1080) ? ?                            1
 [1080,1085) ?                              0
 [1085,1090) ? ?                            1
 [1090,1095) ? ?                            1
              ???????????????????????????
              Mean = 1059.45    n = 58


Statistical tests, 4 out of 5 tests agree (p < 0.05) that the fix produces a statistically significant, small ~0.5% but consistent performance improvement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28328#discussion_r2872671390

From duke at openjdk.org  Mon Mar  2 15:25:56 2026
From: duke at openjdk.org (duke)
Date: Mon, 2 Mar 2026 15:25:56 GMT
Subject: RFR: 8377777: Improve logging when rejecting assets from the AOT
 archive [v10]
In-Reply-To: <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>
References: <p9C6EdymCHkl9RaH5ATEyqp0Cc47B5IB45BY5K39oZs=.6c12dda9-1549-4631-bf19-ece33cf8c484@github.com>
 <oIwSQ-NzQ47bzRt3JRChSBUl6Fh4eY_CwxBwFOqSje4=.53b5017c-9f1d-47dc-999f-84826e75271d@github.com>
Message-ID: <2dk5a2MusfTyTC3hp_kgxAWaPHlLIjUL4mgVesGj9sI=.181576cf-4207-44ff-b0cf-c34de157fae0@github.com>

On Mon, 2 Mar 2026 08:39:22 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

>> Restored the check `if (resolved)` when printing if a CP entry is rejected or archived. If it is not resolved, we shouldn't even bother with it.
>> 
>> Also, added log messages (mostly based on surrounding comments) on `ConstantPoolCache::can_archive_resolved_method` to add information about why a method gets rejected.
>> 
>> All the log messages have the same format to be able to parse them easily:
>> 
>> ` log.print("%s can't be archived because $REASON.",
>>                 pool_holder->name()->as_C_string());`
>
> Mar?a Arias de Reyna Dom?nguez has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Negative test: make sure nothing is rejected on this test
>  - Using LogStream
>  - Update src/hotspot/share/oops/cpCache.cpp
>    
>    Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
>  - Update src/hotspot/share/oops/cpCache.cpp
>    
>    Co-authored-by: Thomas Stuefe <thomas.stuefe at gmail.com>
>  - cleanup and fix tests
>  - fixing compiling errors
>  - simplify logging and drag reason outside can_archive_resolved_method()
>  - Reorganize log prints
>  - Adding index on CPPool for better tracking
>  - Adding explanation for indy and fields
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8b805630...fb5777ce

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

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

PR Comment: https://git.openjdk.org/jdk/pull/29690#issuecomment-3985054434

From ghan at openjdk.org  Mon Mar  2 15:43:46 2026
From: ghan at openjdk.org (Guanqiang Han)
Date: Mon, 2 Mar 2026 15:43:46 GMT
Subject: RFR: 8374789: C2: refactor GraphKit code that create AddP nodes
 for raw memory to use helper method [v9]
In-Reply-To: <hf2CJysV3ykhBp1PJF_eCtOUQOtwzmMV-Zj3Dx38H8g=.1963f03e-608b-4694-9749-faed7d3e6342@github.com>
References: <hf2CJysV3ykhBp1PJF_eCtOUQOtwzmMV-Zj3Dx38H8g=.1963f03e-608b-4694-9749-faed7d3e6342@github.com>
Message-ID: <LBmBTvJ3Jq3gzEny7cZrHTgIVoq89d8BwjxWW9WzM9s=.53a15410-795d-4eb7-96a6-3c0d9c6af19a@github.com>

> This PR refactors GraphKit code that creates AddP nodes for raw memory to use a dedicated helper method. This avoids passing top() explicitly at call sites and improves readability.
> 
> Please review this change. Thanks!
> 
> **Test:** GHA

Guanqiang Han 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 remote-tracking branch 'upstream/master' into 8374789
 - Merge remote-tracking branch 'upstream/master' into 8374789
 - Merge two lines into one
 - Adjust code style again
 - Adjust code style
 - Merge remote-tracking branch 'upstream/master' into 8374789
 - adjust code style
 - adjust code style
 - Merge remote-tracking branch 'upstream/master' into 8374789
 - Align properly
 - ... and 6 more: https://git.openjdk.org/jdk/compare/a6483255...3e99bfac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/29666/files
  - new: https://git.openjdk.org/jdk/pull/29666/files/3d07f2fe..3e99bfac

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

  Stats: 23817 lines in 750 files changed: 13317 ins; 4289 del; 6211 mod
  Patch: https://git.openjdk.org/jdk/pull/29666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29666/head:pull/29666

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

From aph at openjdk.org  Mon Mar  2 16:01:57 2026
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Mar 2026 16:01:57 GMT
Subject: RFR: 8372701: Randomized profile counters [v14]
In-Reply-To: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
References: <jKjmIONZcytzVjS4absOwOLv_QOF9qhIJifYhN6JyP4=.dceced94-bc29-43e6-9062-8dc77c2a6133@github.com>
Message-ID: <lx-iGCCu6-pk7hoNFiVaYTN5OI_bam4vr5gw-ar5QPE=.f3143d63-0df7-411a-814d-351320d745dd@github.com>

> Please use [this link](https://github.com/openjdk/jdk/pull/28541/changes?w=1) to view the files changed.
> 
> Profile counters scale very badly.
> 
> The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly.
> 
> For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads:
> 
> 
> Benchmark (randomized) Mode Cnt Score Error Units
> InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ? 2.631 ns/op
> InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ? 6.329 ns/op
> 
> 
> This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts.
> 
> This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing.
> 
> One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in
> 
> 
> Benchmark                        (randomized)  Mode  Cnt   Score   Error  Units
> InterfaceCalls.test2ndInt5Types         false  avgt    4  80.147 ? 9.991  ns/op
> 
> 
> The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64.

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

 - Merge from 903b3fe19596adaeac7cfb0d749b6e83f668f52f
 - Cleanup
 - Cleanup
 - Nice cleanup
 - Checkpoint
 - Checkpoint
 - Merge branch 'JDK-8134940' of https://github.com/theRealAph/jdk into JDK-8134940
 - Checkpoint
 - Seems to work
 - Checkpoint
 - ... and 64 more: https://git.openjdk.org/jdk/compare/903b3fe1...e6090d85

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

Changes: https://git.openjdk.org/jdk/pull/28541/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=13
  Stats: 1269 lines in 45 files changed: 1136 ins; 23 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/28541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541

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