From syan at openjdk.org Sat Nov 1 02:08:19 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 1 Nov 2025 02:08:19 GMT Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc for nsk/jvmti tests [v9] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 03:04:48 GMT, SendaoYan wrote: >> Hi all, >> >> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory. >> >> Change has been verified locally, test-fix only, no risk. >> >> >> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add log.display("Provoking GC"); Thanks for the suggestions and reviews @https://github.com/lmesnik @https://github.com/plummercj @https://github.com/sspitsyn ------------- PR Comment: https://git.openjdk.org/jdk/pull/28011#issuecomment-3475438561 From syan at openjdk.org Sat Nov 1 02:08:20 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 1 Nov 2025 02:08:20 GMT Subject: Integrated: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc for nsk/jvmti tests In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 06:22:14 GMT, SendaoYan wrote: > Hi all, > > This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory. > > Change has been verified locally, test-fix only, no risk. > > > grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status This pull request has now been integrated. Changeset: 54fe5021 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/54fe50210efe9ae6fad225b815cfdeb16c868115 Stats: 299 lines in 27 files changed: 33 ins; 234 del; 32 mod 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc for nsk/jvmti tests Reviewed-by: cjplummer, lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28011 From kdnilsen at openjdk.org Sat Nov 1 05:40:56 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 1 Nov 2025 05:40:56 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v4] In-Reply-To: References: Message-ID: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: fix bugs in implementation of weakly referenced object handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/80198abe..e16ea231 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=02-03 Stats: 9 lines in 2 files changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From fandreuzzi at openjdk.org Sat Nov 1 09:54:05 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Sat, 1 Nov 2025 09:54:05 GMT Subject: RFR: 8371018: Remove unused CollectedHeap::fill_with_object In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 09:31:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: GHA Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28082#pullrequestreview-3407189256 From kdnilsen at openjdk.org Sat Nov 1 19:12:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 1 Nov 2025 19:12:22 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v5] In-Reply-To: References: Message-ID: <276WbU_gLrJZkxJ6SGxIBBrDdg3NprzZSsnwqSGMpPw=.b3a1a4cc-daae-4cdc-a677-4833f5f6169d@github.com> > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge remote-tracking branch 'jdk/master' into finish-block-start - fix bugs in implementation of weakly referenced object handling - Fixup handling of weakly marked objects in remembered set - fix idiosyncratic formatting - cleanup code for review - Fix order of include files - fix white space - disable for debug build, alphabetic order for includes - add explicit typecast to avoid compiler warning message - Remove troublesome assert that assumes lock is held - ... and 19 more: https://git.openjdk.org/jdk/compare/13b3d2fc...d341522e ------------- Changes: https://git.openjdk.org/jdk/pull/27353/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=04 Stats: 871 lines in 11 files changed: 831 ins; 6 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From tschatzl at openjdk.org Mon Nov 3 07:27:08 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 3 Nov 2025 07:27:08 GMT Subject: RFR: 8371018: Remove unused CollectedHeap::fill_with_object In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 09:31:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: GHA Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28082#pullrequestreview-3409718791 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: References: Message-ID: > 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: References: Message-ID: > 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 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: References: Message-ID: On Mon, 3 Nov 2025 07:31:37 GMT, Thomas Schatzl 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 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: References: Message-ID: On Mon, 27 Oct 2025 11:38:17 GMT, Albert Mingkun Yang 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: References: Message-ID: On Wed, 22 Oct 2025 08:56:22 GMT, Joel Sikstr?m 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 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 ayang at openjdk.org Mon Nov 3 09:43:33 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Nov 2025 09:43:33 GMT Subject: RFR: 8371018: Remove unused CollectedHeap::fill_with_object In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 09:31:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: GHA Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28082#issuecomment-3479651288 From ayang at openjdk.org Mon Nov 3 09:43:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Nov 2025 09:43:34 GMT Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask [v2] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 12:46:47 GMT, Albert Mingkun Yang wrote: >> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context. >> >> Test: tier1-5 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-adjust-root > - pgc-adjust-root Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27822#issuecomment-3479648422 From ayang at openjdk.org Mon Nov 3 09:43:34 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Nov 2025 09:43:34 GMT Subject: Integrated: 8371018: Remove unused CollectedHeap::fill_with_object In-Reply-To: References: Message-ID: <1yM3A2nm2BeN5dzrzO6K7nvAfGMs2j2CExhUPf8hVCE=.83060028-9c61-4765-8a0c-5d74202e4ca3@github.com> On Fri, 31 Oct 2025 09:31:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: GHA This pull request has now been integrated. Changeset: 89b492f4 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/89b492f41bae6f3b9935093b07c9b4f78a97641e Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8371018: Remove unused CollectedHeap::fill_with_object Reviewed-by: iwalulya, fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28082 From ayang at openjdk.org Mon Nov 3 09:43:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Nov 2025 09:43:35 GMT Subject: Integrated: 8369913: Parallel: Refactor PSAdjustTask In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 13:31:06 GMT, Albert Mingkun Yang wrote: > Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context. > > Test: tier1-5 This pull request has now been integrated. Changeset: 400f51f7 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/400f51f7ab19c2dc6a4195f78f9f815d03dd4434 Stats: 42 lines in 1 file changed: 21 ins; 14 del; 7 mod 8369913: Parallel: Refactor PSAdjustTask Reviewed-by: fandreuzzi, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/27822 From jsikstro at openjdk.org Mon Nov 3 09:57:38 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 3 Nov 2025 09:57:38 GMT Subject: RFR: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods Message-ID: Hello, The last usage of the the Thread parameter that is passed to `CollectedHeap::{tlab_capacity, tlab_used, unsafe_max_tlab_alloc}` was removed in [JDK-8370345](https://bugs.openjdk.org/browse/JDK-8370345). Following this we should remove the Thread parameter completely from CollectedHeap and all GCs that derive from it. Testing: * Running through tier1-2 ------------- Commit messages: - 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods Changes: https://git.openjdk.org/jdk/pull/28107/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28107&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371131 Stats: 65 lines in 20 files changed: 0 ins; 2 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/28107.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28107/head:pull/28107 PR: https://git.openjdk.org/jdk/pull/28107 From jsikstro at openjdk.org Mon Nov 3 09:57:39 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 3 Nov 2025 09:57:39 GMT Subject: RFR: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 09:49:02 GMT, Joel Sikstr?m wrote: > Hello, > > The last usage of the the Thread parameter that is passed to `CollectedHeap::{tlab_capacity, tlab_used, unsafe_max_tlab_alloc}` was removed in [JDK-8370345](https://bugs.openjdk.org/browse/JDK-8370345). Following this we should remove the Thread parameter completely from CollectedHeap and all GCs that derive from it. > > Testing: > * Running through tier1-2 src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp line 57: > 55: // Compute the size for the new TLAB. > 56: // The "last" tlab may be smaller to reduce fragmentation. > 57: // unsafe_max_tlab_alloc is just a hint. I suggest we remove this comment as it is misleading since not all GCs take the `available_size` calculated here as a hint, but an unconditional size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28107#discussion_r2485894298 From ayang at openjdk.org Mon Nov 3 10:02:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Nov 2025 10:02:04 GMT Subject: RFR: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 09:49:02 GMT, Joel Sikstr?m wrote: > Hello, > > The last usage of the the Thread parameter that is passed to `CollectedHeap::{tlab_capacity, tlab_used, unsafe_max_tlab_alloc}` was removed in [JDK-8370345](https://bugs.openjdk.org/browse/JDK-8370345). Following this we should remove the Thread parameter completely from CollectedHeap and all GCs that derive from it. > > Testing: > * Running through tier1-2 Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28107#pullrequestreview-3410254336 From tschatzl at openjdk.org Mon Nov 3 12:09:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 3 Nov 2025 12:09:23 GMT Subject: RFR: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods In-Reply-To: References: Message-ID: <88fRRh2O2B2STEwKyd27MN-c6akGhu6JIRd5IWXDzXo=.2d643739-44c4-4f3b-83b7-6def71ff28a4@github.com> On Mon, 3 Nov 2025 09:49:02 GMT, Joel Sikstr?m wrote: > Hello, > > The last usage of the the Thread parameter that is passed to `CollectedHeap::{tlab_capacity, tlab_used, unsafe_max_tlab_alloc}` was removed in [JDK-8370345](https://bugs.openjdk.org/browse/JDK-8370345). Following this we should remove the Thread parameter completely from CollectedHeap and all GCs that derive from it. > > Testing: > * Oracle's tier1-2 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28107#pullrequestreview-3410714487 From iwalulya at openjdk.org Mon Nov 3 12:32:56 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 3 Nov 2025 12:32:56 GMT Subject: RFR: 8370682: G1: Survivor regions not in young gen cset group In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 09:55:11 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to fix the inconsistency of survivor regions having a reference to the young gen cardset group, but the cardset group not containing these regions. That also causes some hack in full gc to remove that link separately during GC. > > Basically the fix is to avoid adding the survivor regions to the young gen cardset group during gc (where at the end we would remove that link when resetting the young gen cardset), but only add them at the end after clearing the young gen cardset group. Since we already track survivor regions separately during GC for similar purposes, there is no extra complication with that. > > This is made possible by GC not using the young gen cardset during evacuation for determining the need for remembered set tracking, but uses the region attribute table only (apart from some asserts that are now handled separately). > > (Fwiw, so to make any newly allocated region start tracking remembered sets, just set that flag in the region attribute table; one can decide at the end of GC what to do with these regions wrt to remembered set maintenance) > > Testing: gha, tier1-3 > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28056#pullrequestreview-3410810296 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: References: Message-ID: On Mon, 3 Nov 2025 09:26:49 GMT, Ivan Walulya 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: References: Message-ID: On Tue, 14 Oct 2025 08:58:43 GMT, Thomas Schatzl 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 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 ayang at openjdk.org Mon Nov 3 15:13:19 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 3 Nov 2025 15:13:19 GMT Subject: RFR: 8370682: G1: Survivor regions not in young gen cset group In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 09:55:11 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to fix the inconsistency of survivor regions having a reference to the young gen cardset group, but the cardset group not containing these regions. That also causes some hack in full gc to remove that link separately during GC. > > Basically the fix is to avoid adding the survivor regions to the young gen cardset group during gc (where at the end we would remove that link when resetting the young gen cardset), but only add them at the end after clearing the young gen cardset group. Since we already track survivor regions separately during GC for similar purposes, there is no extra complication with that. > > This is made possible by GC not using the young gen cardset during evacuation for determining the need for remembered set tracking, but uses the region attribute table only (apart from some asserts that are now handled separately). > > (Fwiw, so to make any newly allocated region start tracking remembered sets, just set that flag in the region attribute table; one can decide at the end of GC what to do with these regions wrt to remembered set maintenance) > > Testing: gha, tier1-3 > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28056#pullrequestreview-3411486454 From iwalulya at openjdk.org Mon Nov 3 15:35:20 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 3 Nov 2025 15:35:20 GMT Subject: RFR: 8370494: G1: NewSize not bounded by InitialHeapSize or MaxHeapSize Message-ID: Hi, Please review this change to ensure that NewSize and MaxNewSize values specified on the command line are validated and adjusted to remain within the valid heap size range. Previously, G1 did not check for inconsistencies between` -XX:NewSize / -XX:MaxNewSize` and the `-XX:InitialHeapSize / -XX:MaxHeapSize`. As a result, users could configure `NewSize` or `MaxNewSize` values larger than the `MaxHeapSize` without receiving any warnings. The change mirrors how Parallel GC already handles this scenario. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into newsize_branch - Merge remote-tracking branch 'upstream/master' into newsize_branch - here Changes: https://git.openjdk.org/jdk/pull/28111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370494 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28111/head:pull/28111 PR: https://git.openjdk.org/jdk/pull/28111 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: On Tue, 28 Oct 2025 09:20:46 GMT, Albert Mingkun Yang 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 jsikstro at openjdk.org Mon Nov 3 16:17:01 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 3 Nov 2025 16:17:01 GMT Subject: RFR: 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v5] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 06:49:39 GMT, Axel Boldt-Christmas wrote: >> ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow. >> >> In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve. >> >> Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap). Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step. > > Axel Boldt-Christmas 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 tag 'jdk-26+21' into JDK-8367317 > > Added tag jdk-26+21 for changeset 3e20a939 > - Merge tag 'jdk-26+19' into JDK-8367317 > > Added tag jdk-26+19 for changeset b37a1a33 > - Merge tag 'jdk-26+18' into JDK-8367317 > > Added tag jdk-26+18 for changeset 5251405c > - Merge tag 'jdk-26+17' into JDK-8367317 > > Added tag jdk-26+17 for changeset 2aafda19 > - 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow Seems reasonable. ------------- Marked as reviewed by jsikstro (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27207#pullrequestreview-3411802916 From wkemper at openjdk.org Mon Nov 3 18:01:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 3 Nov 2025 18:01:31 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: References: Message-ID: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> > When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. > > # Background > When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots - Flush SATB buffers upon entering degenerated cycle when old marking is in progress This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier. - Fix typo in comment - Remove duplicate satb flush closure - Only flush satb once during degenerated cycle - Cleanup and comments - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots - Fix assertion - Oops, move inline definition out of ifdef ASSERT - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de ------------- Changes: https://git.openjdk.org/jdk/pull/27983/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27983&range=02 Stats: 309 lines in 11 files changed: 98 ins; 188 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27983/head:pull/27983 PR: https://git.openjdk.org/jdk/pull/27983 From tschatzl at openjdk.org Tue Nov 4 08:51:45 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 4 Nov 2025 08:51:45 GMT Subject: RFR: 8370682: G1: Survivor regions not in young gen cset group In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 15:10:38 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change to fix the inconsistency of survivor regions having a reference to the young gen cardset group, but the cardset group not containing these regions. That also causes some hack in full gc to remove that link separately during GC. >> >> Basically the fix is to avoid adding the survivor regions to the young gen cardset group during gc (where at the end we would remove that link when resetting the young gen cardset), but only add them at the end after clearing the young gen cardset group. Since we already track survivor regions separately during GC for similar purposes, there is no extra complication with that. >> >> This is made possible by GC not using the young gen cardset during evacuation for determining the need for remembered set tracking, but uses the region attribute table only (apart from some asserts that are now handled separately). >> >> (Fwiw, so to make any newly allocated region start tracking remembered sets, just set that flag in the region attribute table; one can decide at the end of GC what to do with these regions wrt to remembered set maintenance) >> >> Testing: gha, tier1-3 >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28056#issuecomment-3484637210 From tschatzl at openjdk.org Tue Nov 4 08:51:46 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 4 Nov 2025 08:51:46 GMT Subject: Integrated: 8370682: G1: Survivor regions not in young gen cset group In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 09:55:11 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to fix the inconsistency of survivor regions having a reference to the young gen cardset group, but the cardset group not containing these regions. That also causes some hack in full gc to remove that link separately during GC. > > Basically the fix is to avoid adding the survivor regions to the young gen cardset group during gc (where at the end we would remove that link when resetting the young gen cardset), but only add them at the end after clearing the young gen cardset group. Since we already track survivor regions separately during GC for similar purposes, there is no extra complication with that. > > This is made possible by GC not using the young gen cardset during evacuation for determining the need for remembered set tracking, but uses the region attribute table only (apart from some asserts that are now handled separately). > > (Fwiw, so to make any newly allocated region start tracking remembered sets, just set that flag in the region attribute table; one can decide at the end of GC what to do with these regions wrt to remembered set maintenance) > > Testing: gha, tier1-3 > > Thanks, > Thomas This pull request has now been integrated. Changeset: e4aed95c Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e4aed95cac343f1339b9bc87721561bdc4c2f5ad Stats: 42 lines in 4 files changed: 22 ins; 10 del; 10 mod 8370682: G1: Survivor regions not in young gen cset group Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/28056 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: On Tue, 28 Oct 2025 09:20:46 GMT, Albert Mingkun Yang 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 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 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 ayang at openjdk.org Tue Nov 4 09:33:06 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 4 Nov 2025 09:33:06 GMT Subject: RFR: 8371197: G1: Use void for return type of G1RegionsOnNodes::add Message-ID: Remove unused returns and update return-type. Test: tier1-3 ------------- Commit messages: - g1-void-return Changes: https://git.openjdk.org/jdk/pull/28126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371197 Stats: 11 lines in 5 files changed: 0 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28126.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28126/head:pull/28126 PR: https://git.openjdk.org/jdk/pull/28126 From jsikstro at openjdk.org Tue Nov 4 09:39:52 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 4 Nov 2025 09:39:52 GMT Subject: RFR: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 09:59:39 GMT, Albert Mingkun Yang wrote: >> Hello, >> >> The last usage of the the Thread parameter that is passed to `CollectedHeap::{tlab_capacity, tlab_used, unsafe_max_tlab_alloc}` was removed in [JDK-8370345](https://bugs.openjdk.org/browse/JDK-8370345). Following this we should remove the Thread parameter completely from CollectedHeap and all GCs that derive from it. >> >> Testing: >> * Oracle's tier1-2 > > Marked as reviewed by ayang (Reviewer). Thank you for the reviews! @albertnetymk @tschatzl Nice to get this cleanup in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28107#issuecomment-3484890434 From jsikstro at openjdk.org Tue Nov 4 09:39:54 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Tue, 4 Nov 2025 09:39:54 GMT Subject: Integrated: 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods In-Reply-To: References: Message-ID: <5BDwGukXMsP_RV8oGiVADupc5T2gZRhcVe_GGXYRhJE=.a3b3714e-f322-4d13-9d22-f583e45d74ea@github.com> On Mon, 3 Nov 2025 09:49:02 GMT, Joel Sikstr?m wrote: > Hello, > > The last usage of the the Thread parameter that is passed to `CollectedHeap::{tlab_capacity, tlab_used, unsafe_max_tlab_alloc}` was removed in [JDK-8370345](https://bugs.openjdk.org/browse/JDK-8370345). Following this we should remove the Thread parameter completely from CollectedHeap and all GCs that derive from it. > > Testing: > * Oracle's tier1-2 This pull request has now been integrated. Changeset: 19cca0a2 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/19cca0a2a829396291fa4140b2082ef518425518 Stats: 65 lines in 20 files changed: 0 ins; 2 del; 63 mod 8371131: Cleanup Thread parameter in CollectedHeap TLAB methods Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28107 From tschatzl at openjdk.org Tue Nov 4 10:05:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 4 Nov 2025 10:05:09 GMT Subject: RFR: 8371197: G1: Use void for return type of G1RegionsOnNodes::add In-Reply-To: References: Message-ID: <7Y8uTS1EclWiVwGjafFe1m2gnZwAwAYoOZOCB91zDwk=.56ba3ff9-b9a6-4135-9e55-dfc6dcd0a594@github.com> On Tue, 4 Nov 2025 09:25:55 GMT, Albert Mingkun Yang wrote: > Remove unused returns and update return-type. > > Test: tier1-3 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28126#pullrequestreview-3415325755 From iwalulya at openjdk.org Tue Nov 4 10:19:37 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 4 Nov 2025 10:19:37 GMT Subject: RFR: 8370494: G1: NewSize not bounded by InitialHeapSize or MaxHeapSize In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 14:04:34 GMT, Ivan Walulya wrote: > Hi, > > Please review this change to ensure that NewSize and MaxNewSize values specified on the command line are validated and adjusted to remain within the valid heap size range. Previously, G1 did not check for inconsistencies between` -XX:NewSize / -XX:MaxNewSize` and the `-XX:InitialHeapSize / -XX:MaxHeapSize`. As a result, users could configure `NewSize` or `MaxNewSize` values larger than the `MaxHeapSize` without receiving any warnings. > > The change mirrors how Parallel GC already handles this scenario. Ongoing work is addressing the inconsistent use of `FLAG_IS_CMDLINE` and `FLAG_IS_DEFAULT` in HotSpot. This issue will be resolved as part of that effort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28111#issuecomment-3485099743 From iwalulya at openjdk.org Tue Nov 4 10:19:38 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 4 Nov 2025 10:19:38 GMT Subject: Withdrawn: 8370494: G1: NewSize not bounded by InitialHeapSize or MaxHeapSize In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 14:04:34 GMT, Ivan Walulya wrote: > Hi, > > Please review this change to ensure that NewSize and MaxNewSize values specified on the command line are validated and adjusted to remain within the valid heap size range. Previously, G1 did not check for inconsistencies between` -XX:NewSize / -XX:MaxNewSize` and the `-XX:InitialHeapSize / -XX:MaxHeapSize`. As a result, users could configure `NewSize` or `MaxNewSize` values larger than the `MaxHeapSize` without receiving any warnings. > > The change mirrors how Parallel GC already handles this scenario. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28111 From iwalulya at openjdk.org Tue Nov 4 12:17:55 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 4 Nov 2025 12:17:55 GMT Subject: RFR: 8371197: G1: Use void for return type of G1RegionsOnNodes::add In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:25:55 GMT, Albert Mingkun Yang wrote: > Remove unused returns and update return-type. > > Test: tier1-3 Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28126#pullrequestreview-3416128728 From fandreuzzi at openjdk.org Tue Nov 4 15:45:33 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 4 Nov 2025 15:45:33 GMT Subject: RFR: 8371197: G1: Use void for return type of G1RegionsOnNodes::add In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:25:55 GMT, Albert Mingkun Yang wrote: > Remove unused returns and update return-type. > > Test: tier1-3 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28126#pullrequestreview-3417186806 From xpeng at openjdk.org Tue Nov 4 16:47:20 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Nov 2025 16:47:20 GMT Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration [v3] In-Reply-To: References: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com> Message-ID: On Fri, 31 Oct 2025 21:00:46 GMT, Xiaolong Peng wrote: >> The young and old collector reserves both have `FREE` regions, but we need to make sure we don't exceed the reserves for one or the other. > > I have added the can_allocate_in_new_region check back, it should have same behavior now. I have removed can_allocate_in_new_region again after merging @kdnilsen's change unifying accountings, since we don't have consistency in accountings anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2491266912 From duke at openjdk.org Tue Nov 4 17:39:37 2025 From: duke at openjdk.org (Nityanand Rai) Date: Tue, 4 Nov 2025 17:39:37 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: References: Message-ID: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> > Fix typos in debug log messages and comments in Concurrent.java Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27810/files - new: https://git.openjdk.org/jdk/pull/27810/files/349f1c2f..0b8c9a71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27810&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27810&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27810.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27810/head:pull/27810 PR: https://git.openjdk.org/jdk/pull/27810 From duke at openjdk.org Tue Nov 4 17:42:21 2025 From: duke at openjdk.org (Nityanand Rai) Date: Tue, 4 Nov 2025 17:42:21 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:13:40 GMT, Leonid Mesnik wrote: > The fix looks good, please update copyright years. Updated ------------- PR Comment: https://git.openjdk.org/jdk/pull/27810#issuecomment-3487284837 From kdnilsen at openjdk.org Tue Nov 4 17:47:33 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 4 Nov 2025 17:47:33 GMT Subject: RFR: 8371141: Shenandoah: Many test timeouts with -XX:-UseTLAB Message-ID: Problem list no-tlab versions of tests that fail after integration of https://github.com/openjdk/jdk/pull/26867 We expect the small regression (increase) in time spent holding the global heap log will be counterbalanced by resolution of https://bugs.openjdk.org/browse/JDK-8361099, which performs shared (no-tlab) allocations without acquiring the global heap lock. ------------- Commit messages: - Problem list no-tlab versions of TestSieve and TestRetain Changes: https://git.openjdk.org/jdk/pull/28133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371141 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28133/head:pull/28133 PR: https://git.openjdk.org/jdk/pull/28133 From xpeng at openjdk.org Tue Nov 4 17:47:34 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 4 Nov 2025 17:47:34 GMT Subject: RFR: 8371141: Shenandoah: Many test timeouts with -XX:-UseTLAB In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 15:24:18 GMT, Kelvin Nilsen wrote: > Problem list no-tlab versions of tests that fail after integration of https://github.com/openjdk/jdk/pull/26867 > > We expect the small regression (increase) in time spent holding the global heap log will be counterbalanced by resolution of https://bugs.openjdk.org/browse/JDK-8361099, which performs shared (no-tlab) allocations without acquiring the global heap lock. Looks good to me, I'll test and revert this after the CAS allocator PR. ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/28133#pullrequestreview-3417404129 From ysr at openjdk.org Tue Nov 4 17:47:35 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 4 Nov 2025 17:47:35 GMT Subject: RFR: 8371141: Shenandoah: Many test timeouts with -XX:-UseTLAB In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 15:24:18 GMT, Kelvin Nilsen wrote: > Problem list no-tlab versions of tests that fail after integration of https://github.com/openjdk/jdk/pull/26867 > > We expect the small regression (increase) in time spent holding the global heap log will be counterbalanced by resolution of https://bugs.openjdk.org/browse/JDK-8361099, which performs shared (no-tlab) allocations without acquiring the global heap lock. Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28133#pullrequestreview-3417869139 From wkemper at openjdk.org Tue Nov 4 18:06:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Nov 2025 18:06:52 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> References: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> Message-ID: On Tue, 4 Nov 2025 17:39:37 GMT, Nityanand Rai wrote: >> Fix typos in debug log messages and comments in Concurrent.java > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years Looks good. Thank you! ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3418012359 From lmesnik at openjdk.org Tue Nov 4 18:06:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Nov 2025 18:06:54 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> References: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> Message-ID: <9q6EGmDjbgzV4id0IUx3Esn07104lCe9DfI0RWQI3nI=.3668ccdd-4f94-47a5-87a7-5fd800a8fec2@github.com> On Tue, 4 Nov 2025 17:39:37 GMT, Nityanand Rai wrote: >> Fix typos in debug log messages and comments in Concurrent.java > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3418017029 From wkemper at openjdk.org Tue Nov 4 18:24:22 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Nov 2025 18:24:22 GMT Subject: RFR: 8371141: Shenandoah: Many test timeouts with -XX:-UseTLAB In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 15:24:18 GMT, Kelvin Nilsen wrote: > Problem list no-tlab versions of tests that fail after integration of https://github.com/openjdk/jdk/pull/26867 > > We expect the small regression (increase) in time spent holding the global heap log will be counterbalanced by resolution of https://bugs.openjdk.org/browse/JDK-8361099, which performs shared (no-tlab) allocations without acquiring the global heap lock. Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28133#pullrequestreview-3418085231 From wkemper at openjdk.org Tue Nov 4 22:27:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Nov 2025 22:27:52 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> References: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> Message-ID: <7kzHfoGKxHS3U5xhG81AuWhzghnHr-iWKuMyDZe-o6Q=.0e08f7b0-7ced-42df-9e39-d3134a095b73@github.com> On Mon, 3 Nov 2025 18:01:31 GMT, William Kemper wrote: >> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. >> >> # Background >> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Flush SATB buffers upon entering degenerated cycle when old marking is in progress > > This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier. > - Fix typo in comment > - Remove duplicate satb flush closure > - Only flush satb once during degenerated cycle > - Cleanup and comments > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Fix assertion > - Oops, move inline definition out of ifdef ASSERT > - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de I've run more tests and confirmed that critical and max `jops` are 3% improved on a variety of heap sizes and configurations. Additionally, after running more tests with `extremem`, the apparent regression at `p100` has evaporated: genshen/extremem/control Category | Count | Total | GeoMean | Average | Trim 0.1 | StdDev | Minimum | Maximum sales_transaction_p100 | 23 | 38817.000 | 1685.651 | 1687.696 | 1690.158 | 84.299 | 1539.000 | 1823.000 browsing_history_p100 | 23 | 32145.000 | 1391.269 | 1397.609 | 1382.211 | 139.779 | 1175.000 | 1769.000 customer_replacement_p100 | 23 | 107141.000 | 4652.940 | 4658.304 | 4664.211 | 227.279 | 4093.000 | 5053.000 product_replacement_p100 | 23 | 58315.000 | 2526.181 | 2535.435 | 2523.737 | 223.834 | 2203.000 | 3041.000 customer_preparation_p100 | 23 | 142953.000 | 5442.520 | 6215.348 | 6064.000 | 3132.333 | 2502.000 | 11547.000 customer_purchase_p100 | 23 | 491201.000 | 18622.792 | 21356.565 | 20385.263 | 11424.057 | 6582.000 | 48274.000 customer_save_for_later_p100 | 23 | 880105.000 | 36675.774 | 38265.435 | 37248.895 | 11777.757 | 23023.000 | 65591.000 customer_abandonment_p100 | 23 | 701197.000 | 28578.563 | 30486.826 | 29311.105 | 11521.080 | 16390.000 | 59179.000 genshen/extremem/experiment Category | Count | Total | GeoMean | Average | Trim 0.1 | StdDev | Minimum | Maximum sales_transaction_p100 | 23 | 40007.000 | 1730.529 | 1739.435 | 1711.947 | 193.896 | 1528.000 | 2490.000 browsing_history_p100 | 23 | 33032.000 | 1425.803 | 1436.174 | 1436.316 | 175.753 | 1123.000 | 1729.000 customer_replacement_p100 | 23 | 107516.000 | 4653.546 | 4674.609 | 4599.579 | 488.862 | 4072.000 | 6579.000 product_replacement_p100 | 23 | 56647.000 | 2451.855 | 2462.913 | 2469.789 | 235.896 | 1968.000 | 2903.000 customer_preparation_p100 | 23 | 136482.000 | 5224.974 | 5934.000 | 5766.684 | 3027.151 | 2924.000 | 10652.000 customer_purchase_p100 | 23 | 464888.000 | 17675.074 | 20212.522 | 18641.263 | 11355.233 | 7921.000 | 55420.000 customer_save_for_later_p100 | 23 | 854932.000 | 35744.969 | 37170.957 | 35660.579 | 11323.562 | 24370.000 | 71376.000 customer_abandonment_p100 | 23 | 686923.000 | 28261.963 | 29866.217 | 28589.737 | 10907.943 | 17791.000 | 65329.000 Indeed, the _experiment_ looks slightly better in some cases (slightly worse in others). The results also show the expected reduction in safepoint times as we are no longer flushing SATB buffers during `final_update_refs` or `init_mark`: -133.33% extremem/shenandoahfinalupdaterefs_stopped_max p=0.00000 (Welch's T-Test) Control: 1.103 (+/- 0.14 ) 23 Test: 0.473 (+/- 0.06 ) 23 The effect is more pronounced on `specjbb2015`: -216.54% specjbb2015/shenandoahfinalupdaterefs_stopped_max p=0.00000 (Mann-Whitney) Control: 2.217 (+/- 0.09 ) 22 Test: 0.700 (+/- 0.19 ) 22 -791.43% specjbb2015/shenandoahinitmark_stopped_max p=0.00173 (Mann-Whitney) Control: 3.408 (+/- 3.12 ) 22 Test: 0.382 (+/- 0.07 ) 22 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27983#issuecomment-3488220025 From wkemper at openjdk.org Tue Nov 4 23:10:34 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 4 Nov 2025 23:10:34 GMT Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration [v3] In-Reply-To: References: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com> Message-ID: On Tue, 4 Nov 2025 16:43:58 GMT, Xiaolong Peng wrote: >> I have added the can_allocate_in_new_region check back, it should have same behavior now. > > I have removed can_allocate_in_new_region again after merging @kdnilsen's change unifying accountings, since we don't have consistency in accountings anymore. We still need to enforce that requests for a young evacuation don't take memory that was reserved for old evacuations. `can_allocate_in_new_region` isn't about consistency between freeset and generation accounting, it's used to maintain old/young collector reserves. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2492277440 From kdnilsen at openjdk.org Wed Nov 5 00:28:26 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 5 Nov 2025 00:28:26 GMT Subject: Integrated: 8371141: Shenandoah: Many test timeouts with -XX:-UseTLAB In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 15:24:18 GMT, Kelvin Nilsen wrote: > Problem list no-tlab versions of tests that fail after integration of https://github.com/openjdk/jdk/pull/26867 > > We expect the small regression (increase) in time spent holding the global heap log will be counterbalanced by resolution of https://bugs.openjdk.org/browse/JDK-8361099, which performs shared (no-tlab) allocations without acquiring the global heap lock. This pull request has now been integrated. Changeset: 87c2091c Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/87c2091cd08e58304d0909ffaf9402ca2f0c3b7f Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8371141: Shenandoah: Many test timeouts with -XX:-UseTLAB Reviewed-by: xpeng, ysr, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/28133 From kdnilsen at openjdk.org Wed Nov 5 02:24:11 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 5 Nov 2025 02:24:11 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v6] In-Reply-To: References: Message-ID: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Revert "Fixup handling of weakly marked objects in remembered set" This reverts commit 80198abe5d06c3532d9a43a53691376e990ed45f. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/d341522e..643cdfd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=04-05 Stats: 28 lines in 1 file changed: 0 ins; 16 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From ayang at openjdk.org Wed Nov 5 10:16:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 5 Nov 2025 10:16:15 GMT Subject: RFR: 8371197: G1: Use void for return type of G1RegionsOnNodes::add In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:25:55 GMT, Albert Mingkun Yang wrote: > Remove unused returns and update return-type. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28126#issuecomment-3490323334 From ayang at openjdk.org Wed Nov 5 10:16:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 5 Nov 2025 10:16:15 GMT Subject: Integrated: 8371197: G1: Use void for return type of G1RegionsOnNodes::add In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 09:25:55 GMT, Albert Mingkun Yang wrote: > Remove unused returns and update return-type. > > Test: tier1-3 This pull request has now been integrated. Changeset: 6a51b51b Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/6a51b51ba13167a15a637507a7fa5d6f988a39e7 Stats: 11 lines in 5 files changed: 0 ins; 3 del; 8 mod 8371197: G1: Use void for return type of G1RegionsOnNodes::add Reviewed-by: tschatzl, iwalulya, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/28126 From mbaesken at openjdk.org Wed Nov 5 10:19:13 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Nov 2025 10:19:13 GMT Subject: RFR: 8371316: Adjust assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print Message-ID: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> it has been observed that the assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print cuts off the printed values, this should be adjusted to see the real values in error situations. The current assert prints misleading messages like this (see [JDK-8370063](https://bugs.openjdk.org/browse/JDK-8370063)) : # Internal Error (d:\priv\jenkins\ci2\client-home\workspace\openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\share\gc\g1\g1GCPhaseTimes.cpp:571), pid=8976, tid=24744 # assert(_gc_pause_time_ms >= accounted_ms) failed: GC pause time(0.001ms) cannot be smaller than the sum of each phase(0.001ms). ------------- Commit messages: - JDK-8371316 Changes: https://git.openjdk.org/jdk/pull/28147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371316 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28147/head:pull/28147 PR: https://git.openjdk.org/jdk/pull/28147 From ayang at openjdk.org Wed Nov 5 10:40:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 5 Nov 2025 10:40:32 GMT Subject: RFR: 8371316: Adjust assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print In-Reply-To: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> References: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> Message-ID: On Wed, 5 Nov 2025 10:11:42 GMT, Matthias Baesken wrote: > it has been observed that the assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print cuts off the printed values, this should be adjusted to see the real values in error situations. > The current assert prints misleading messages like this (see [JDK-8370063](https://bugs.openjdk.org/browse/JDK-8370063)) : > > > # Internal Error (d:\priv\jenkins\ci2\client-home\workspace\openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\share\gc\g1\g1GCPhaseTimes.cpp:571), pid=8976, tid=24744 > # assert(_gc_pause_time_ms >= accounted_ms) failed: GC pause time(0.001ms) cannot be smaller than the sum of each phase(0.001ms). Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28147#pullrequestreview-3421146643 From shade at openjdk.org Wed Nov 5 11:01:16 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 5 Nov 2025 11:01:16 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> References: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> Message-ID: On Tue, 4 Nov 2025 17:39:37 GMT, Nityanand Rai wrote: >> Fix typos in debug log messages and comments in Concurrent.java > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years Looks fine. I think you can integrate. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3421260591 From tschatzl at openjdk.org Wed Nov 5 17:02:22 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 5 Nov 2025 17:02:22 GMT Subject: RFR: 8371316: Adjust assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print In-Reply-To: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> References: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> Message-ID: <66jF0hWHOOI9TEaYpx3mZQqEb_kwfzad9tTfcSJhivI=.eed54062-3b98-4a56-a01b-4acf45817409@github.com> On Wed, 5 Nov 2025 10:11:42 GMT, Matthias Baesken wrote: > it has been observed that the assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print cuts off the printed values, this should be adjusted to see the real values in error situations. > The current assert prints misleading messages like this (see [JDK-8370063](https://bugs.openjdk.org/browse/JDK-8370063)) : > > > # Internal Error (d:\priv\jenkins\ci2\client-home\workspace\openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\share\gc\g1\g1GCPhaseTimes.cpp:571), pid=8976, tid=24744 > # assert(_gc_pause_time_ms >= accounted_ms) failed: GC pause time(0.001ms) cannot be smaller than the sum of each phase(0.001ms). Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28147#pullrequestreview-3423309557 From kdnilsen at openjdk.org Wed Nov 5 18:20:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 5 Nov 2025 18:20:45 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> References: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> Message-ID: On Mon, 3 Nov 2025 18:01:31 GMT, William Kemper wrote: >> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. >> >> # Background >> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Flush SATB buffers upon entering degenerated cycle when old marking is in progress > > This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier. > - Fix typo in comment > - Remove duplicate satb flush closure > - Only flush satb once during degenerated cycle > - Cleanup and comments > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Fix assertion > - Oops, move inline definition out of ifdef ASSERT > - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de Thank you for bringing this to closure... ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/27983#pullrequestreview-3423680188 From aboldtch at openjdk.org Wed Nov 5 19:05:59 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 5 Nov 2025 19:05:59 GMT Subject: RFR: 8371343: ZGC: Remove dependency on test execution order for gtests Message-ID: We currently have a few gtests which are run with the TEST_F macro and use `ZGlobalsPointers::initialize();` which on some platforms may end up doing GC precious logging, which requires the VM (mutexes) to be setup in order to work. Currently the `GTestWrapper.java` succeeds with running these test because we will have run other tests which have setup the VM. If a filter is used or the tests are shuffled we can observe that these tests may crash. Proposed change is to use the `ZTest` unittest base fixture and run these test with `TEST_VM_F` Testing * GHA * gtests with and without filter and shuffled test order ------------- Commit messages: - Fix ZGC gtests with dependency on test execution order Changes: https://git.openjdk.org/jdk/pull/28160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371343 Stats: 11 lines in 3 files changed: 0 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28160/head:pull/28160 PR: https://git.openjdk.org/jdk/pull/28160 From aboldtch at openjdk.org Wed Nov 5 19:09:36 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 5 Nov 2025 19:09:36 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) Message-ID: A few ZGC gtest reservers memory in valid ZAddress address ranges to mock and test different sub systems. When running in instrumented builds such as ASAN the address space we try to may be unavailable. This will cause a couple of our tests to fail. I propose we change all out gtests to do what `test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp` does. Namely uses our `ZVirtualMemoryManager` to reserve the address space and skip the test incase we are not able to reserve an adequate address range to use for the test. * Testing * GHA * gtest with and without ASAN, including artificially induced reservation clash with ASAN ------------- Commit messages: - Improve ZGC gtest interoperability with instrumented builds (ASAN) Changes: https://git.openjdk.org/jdk/pull/28159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371341 Stats: 138 lines in 5 files changed: 72 ins; 37 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/28159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28159/head:pull/28159 PR: https://git.openjdk.org/jdk/pull/28159 From ayang at openjdk.org Wed Nov 5 19:35:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 5 Nov 2025 19:35:42 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate Message-ID: Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. Test: tie1-5 ------------- Commit messages: - pgc-expand-assert Changes: https://git.openjdk.org/jdk/pull/28162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371369 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28162/head:pull/28162 PR: https://git.openjdk.org/jdk/pull/28162 From eosterlund at openjdk.org Wed Nov 5 19:43:34 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 5 Nov 2025 19:43:34 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate In-Reply-To: References: Message-ID: <8wJjVXcoQliHov4r_EJQagHrccI1mbh1izKX5JlrF98=.e48366f2-560b-45db-8b98-058f4aecbe11@github.com> On Wed, 5 Nov 2025 19:29:13 GMT, Albert Mingkun Yang wrote: > Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. > > Test: tie1-5 Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28162#pullrequestreview-3424003359 From kdnilsen at openjdk.org Wed Nov 5 22:31:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 5 Nov 2025 22:31:22 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 21:59:35 GMT, Xiaolong Peng wrote: >> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: >> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). >> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. >> * If mutator thread fails after trying 3 directly allocatable regions, it will: >> * Take heap lock >> * Try to retire the directly allocatable regions which are ready to retire. >> * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. >> * Satisfy mutator allocation request if possible. >> >> >> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: >> >> 1. Dacapo lusearch test on EC2 host with 96 CPU cores: >> Openjdk TIP: >> >> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" >> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== >> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== >> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 ... > > Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: > > - Merge branch 'openjdk:master' into cas-alloc-1 > - Merge branch 'openjdk:master' into cas-alloc-1 > - format > - Merge branch 'openjdk:master' into cas-alloc-1 > - Merge branch 'openjdk:master' into cas-alloc-1 > - Merge branch 'master' into cas-alloc-1 > - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp > - Merge branch 'openjdk:master' into cas-alloc-1 > - Fix errors caused by renaming ofAtomic to AtomicAccess > - Merge branch 'openjdk:master' into cas-alloc-1 > - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05 src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 762: > 760: #endif > 761: > 762: PaddedEnd* ShenandoahDirectlyAllocatableRegionAffinity::_affinity = nullptr; IIUC, each of the DirectlyAllocatableRegions has an affinity to a particular thread. If some other thread randomly selects to allocate from this region, we change the region's affinity. Now, if the original thread tries another allocation, it will be redirected to a different randomly selected region. It feels to me like this introduces more churn than necessary. It should be ok for multiple threads to have affinity to the same directly allocatable region so they can preserve "locality". The locality to be preserved is the value of region->top() and region->end(), in local caches. Sometimes, the multiple threads that are affiliated with a particular region will be running on the same core, which helps improve cache performance. If they are on different cores, that's now worse than the current implementation. So my thinking is that each thread should maintain an affinity to a particular index within the directly allocatable region array. It should reaffiliate with a different region only if that region entry becomes nullptr, or in case its attempt to CAS allocate fails more than twice in a row (because of heavy contention on the value of top for that region). Please clarify if I've misunderstood. Please explain rationale if there is good reason for preferring the design as it is currently implemented. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 848: > 846: HeapWord* ShenandoahFreeSet::allocate_with_affiliation(Iter& iterator, ShenandoahAffiliation affiliation, ShenandoahAllocRequest& req, bool& in_new_region) { > 847: for (idx_t idx = iterator.current(); iterator.has_next(); idx = iterator.next()) { > 848: ShenandoahHeapRegion* r = _heap->get_region(idx); I wonder if we could refine this a little bit. When the region is moved into the "directly allocatable" set, wouldn't we remove it from its partition? Then, we wouldn't have to test for !r->reserved_for_direct_allocation() here because the iterator wouldn't produce it. We could maybe replace this test with an assert that !r->reserved_for_direct_allocation(). src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1268: > 1266: // If region is not completely free, the current [beg; end] is useless, and we may fast-forward. If we can extend > 1267: // the existing range, we can exploit that certain regions are already known to be in the Mutator free set. > 1268: ShenandoahHeapRegion* region = _heap->get_region(end); Here also, if we remove the region from the partition when we make it directly allocatable, we would not need to rewrite this loop. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2070: > 2068: // retired, the sum of used and capacities within regions that are still in the Mutator free partition may not match > 2069: // my internally tracked values of used() and free(). > 2070: //TODO remove assert, it is not possible to mach since mutators may allocate on region w/o acquiring lock It seems that if we are properly adjusting used() when we make a region directly allocatable, then this assert would still be valid. Why not? src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2197: > 2195: // Intentionally not using AtomicAccess::load, if a mutator see a stale region it will fail to allocate anyway. > 2196: if ((r = shared_region._address) != nullptr && r->reserved_for_direct_allocation()) { > 2197: obj = cas_allocate_in_for_mutator(r, req, in_new_region); There are multiple things that can go wrong here, and it's not clear how we distinguish between them: 1. Region r may be retirable and not have enough memory to satisfy req. 2. Region r may not be retirable and not have enough memory to satisfy req. 3. Region r may have sufficient memory to satisfy r but we experience heavy contention (multiple CAS failures) while we attempt to allocate r. In my mental model, I think I might be inclined to behave as follows: 1. Inside case_allocate_in_for_mutator(), if we satisfy our allocation request, but only after "too many" (more than 2) CAS retries, do not update my thread-local _index variable. Leave it at its previously selected value. Otherwise, on successful allocation, update _index to represent current slot. (might have to pass current slot in as an argument) 2. If cas_allocate_in_for_mutator() returns nullptr, ask the question "is this region retirable?" If so, increment a local count of retirable_regions. If the incremented count of retirable_regions exceeds some threshold value (DirectlyAllocatableRegionCount / 4?) (and there may be more than this number of retirable regions, but we've seen at least this many), grab the heap lock to retire and replenish all retirable regions. Then restart this loop with i = 0; src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2204: > 2202: i++; > 2203: } > 2204: return obj; I think obj always equals nullptr at this point. Seems the code would be easier to understand (and would depend less on effective compiler optimization) if we just made that explicit. Can we just say: return nullptr? src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2206: > 2204: return obj; > 2205: } > 2206: template space above this line? src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2219: > 2217: const uint max_probes = ShenandoahDirectAllocationMaxProbes; > 2218: for (;;) { > 2219: HeapWord* obj = nullptr; This is written as an infinite loop, but I'm not sure it intends to iterate? It looks like there's no way for the loop body to get to a second iteration. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2235: > 2233: start_idx = next_start_index; > 2234: } else { > 2235: // try to steal from other directly allocatable regions Why not just let the enclosing infinite loop (for(;;)) iterate, which will call cas_allocate_single_for_mutator()? You could overwrite start_idx with a new value if you want. I'm not sure I agree with choosing start_idx + max_probes. It seems a more likely new value would be next_start_index. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2256: > 2254: } > 2255: > 2256: // Explicit specializations I'm sorry. I don't understand what is happening here with "explicit specializations". Maybe a comment to explain this less common C++ syntax would help here. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2280: > 2278: } > 2279: > 2280: class DirectAllocatableRegionRefillClosure final : public ShenandoahHeapRegionIterationClosure { I don't think we want to subclass ShenandoahHeapRegionIterationClosure here. That iterates over all 2000 regions. We only want to iterate over the 13 Directly allocatable regions. Maybe we don't even need/want a closure iterator here. We could just write a loop. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2347: > 2345: } > 2346: > 2347: bool heap_region_do(ShenandoahHeapRegion *r) { Need a comment to explain what heap_region_do() is doing. I think it is doing: 1. Returns true if there is no need to iterate over additional regions, otherwise returns false 2. If we've already found a region to hold the requested allocation and there are no more regions to retire, we return true. 3. If the region is trash or is free and we're not doing concurrent_weak_roots, we try to recycle it, setting its affiliation to young. (I'm not understanding how this works. What if the region had been placed in the Collector or OldCollector partitions?) 4. If the requested object has not yet been allocated and this region has sufficient memory to represent the object, allocate it here. (We do all this while holding the heap lock, so we can check available memory at entry to the function, and use the available memory further below within the function.) 5. If this region has more than min_tlab_size memory (after allocating _obj) and there's another region to be retired, we use replace the next retirable region with this region. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2383: > 2381: ShenandoahDirectAllocationRegion& shared_region = _direct_allocation_regions[_next_retire_eligible_region]; > 2382: assert(AtomicAccess::load(&shared_region._address) == nullptr, "Must have been released."); > 2383: r->reserve_for_direct_allocation(); Here also, I wonder if we can simplify the protocol for assigning this region into the directly allocatable array. Maybe the key idea could be to introduce a new volatile variable into ShenandoahHeapRegion known as top_for_cas. cas allocations allocate by incrementing top_for_cas. Before removing a region from the directly allocatable set, we use cas to increase top_for_cas to end(). Before placing a region into the directly allocatable set (and while holding the heap lock), we copy top() to top_for_cas. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2418: > 2416: iterate_regions_for_alloc(&cl, false); > 2417: if (cl._next_region_with_sufficient_mem != ShenandoahDirectlyAllocatableRegionCount && obj == nullptr) { > 2418: new_start_index = cl._next_region_with_sufficient_mem; I think an accessor method is preferred over direct access to a "private" variable. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 263: > 261: _capacity[int(which_partition)] = value; > 262: _available[int(which_partition)] = value - _used[int(which_partition)]; > 263: AtomicAccess::store(_capacity + int(which_partition), value); Shouldn't require AtomicAccess here, because we hold heap lock. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 271: > 269: _used[int(which_partition)] = value; > 270: _available[int(which_partition)] = _capacity[int(which_partition)] - value; > 271: AtomicAccess::store(_used + int(which_partition), value); Also here, should not require AtomicAccess. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 464: > 462: HeapWord* cas_allocate_in_for_mutator(ShenandoahHeapRegion* region, ShenandoahAllocRequest &req, bool &in_new_region); > 463: > 464: bool try_allocate_directly_allocatable_regions(uint start_index, Can we have a block comment description of what this function does, including its impact on var parameters. src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 363: > 361: } > 362: > 363: void ShenandoahHeapRegion::reset_alloc_metadata() { Do we need to make these atomic because we now increment asynchronously from within mutator CAS allocations? Before, they were only adjusted while holding heap lock? I'm wondering if add-with-fetch() or CAS() would be more/less efficient than AtomicAccess::stores. Can we test the tradeoffs? src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 131: > 129: } > 130: > 131: HeapWord* ShenandoahHeapRegion::allocate_atomic(size_t size, const ShenandoahAllocRequest& req) { As mentioned above, this is maybe where we would want to set the thread-local _index variable, and this is also where we might want to count how many times we retry the try_allocate() request before we succeed. The point is that if we have multiple try_allocate() CAS failures, that means this region is heavily contended, and we don't want to make this our new "starting index". src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 559: > 557: range(1, 128) \ > 558: \ > 559: product(uintx, ShenandoahDirectAllocationMaxProbes, 3, EXPERIMENTAL, \ I think we found that setting DirectAllocationMaxProbes to equal ShenandoahDirectlyAlloctableRegionCount works "best". I'm inclined to remove this parameter entirely as it somewhat simplifies the implementation. If you think we want to keep it, can you explain the rationale? Would we change the default value? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495713187 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495759091 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495768272 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495789372 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495974976 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495837037 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495793783 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496020674 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496020913 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496084186 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496124916 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496344767 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496359448 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496109695 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496045832 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496047006 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496050940 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496384148 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496395761 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496399061 From kdnilsen at openjdk.org Wed Nov 5 22:31:23 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 5 Nov 2025 22:31:23 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: References: Message-ID: <5YSA3F88CmDDv09M2KOm_EFNDh_09LPO2WMrgETfupI=.cc658dc9-829e-41a5-ad76-393d3eb0f75a@github.com> On Wed, 5 Nov 2025 19:00:03 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - format >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix errors caused by renaming ofAtomic to AtomicAccess >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05 > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 848: > >> 846: HeapWord* ShenandoahFreeSet::allocate_with_affiliation(Iter& iterator, ShenandoahAffiliation affiliation, ShenandoahAllocRequest& req, bool& in_new_region) { >> 847: for (idx_t idx = iterator.current(); iterator.has_next(); idx = iterator.next()) { >> 848: ShenandoahHeapRegion* r = _heap->get_region(idx); > > I wonder if we could refine this a little bit. When the region is moved into the "directly allocatable" set, wouldn't we remove it from its partition? Then, we wouldn't have to test for !r->reserved_for_direct_allocation() here because the iterator wouldn't produce it. > > We could maybe replace this test with an assert that !r->reserved_for_direct_allocation(). Same issue in other uses of the allocation iterator. > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2280: > >> 2278: } >> 2279: >> 2280: class DirectAllocatableRegionRefillClosure final : public ShenandoahHeapRegionIterationClosure { > > I don't think we want to subclass ShenandoahHeapRegionIterationClosure here. That iterates over all 2000 regions. We only want to iterate over the 13 Directly allocatable regions. Maybe we don't even need/want a closure iterator here. We could just write a loop. I think we should be borrowing from this code when replenishing the regions that are ready to be retired: if (_partitions.alloc_from_left_bias(ShenandoahFreeSetPartitionId::Mutator)) { // Allocate from low to high memory. This keeps the range of fully empty regions more tightly packed. // Note that the most recently allocated regions tend not to be evacuated in a given GC cycle. So this // tends to accumulate "fragmented" uncollected regions in high memory. ShenandoahLeftRightIterator iterator(&_partitions, ShenandoahFreeSetPartitionId::Mutator); return allocate_from_regions(iterator, req, in_new_region); } // Allocate from high to low memory. This preserves low memory for humongous allocations. ShenandoahRightLeftIterator iterator(&_partitions, ShenandoahFreeSetPartitionId::Mutator); return allocate_from_regions(iterator, req, in_new_region); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2495761580 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2496372013 From duke at openjdk.org Thu Nov 6 00:29:26 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 00:29:26 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space Message-ID: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m, so GenShen isn't worse. The reported GenShen failure observation probably came from the Random. public class TestLargeObjectAlignmentDeterministic { static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); static final int NODE_COUNT = Integer.getInteger("nodes", 10000); static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); static Object[] objects; public static void main(String[] args) throws Exception { objects = new Object[SLABS_COUNT]; for (int i = 0; i < SLABS_COUNT; i++) { objects[i] = createSome(); } } public static Object createSome() { List result = new ArrayList(); for (int c = 0; c < NODE_COUNT; c++) { result.add(new Integer(c)); } return result; } } ------------- Commit messages: - 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space Changes: https://git.openjdk.org/jdk/pull/28167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361339 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28167/head:pull/28167 PR: https://git.openjdk.org/jdk/pull/28167 From fandreuzzi at openjdk.org Thu Nov 6 00:42:01 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 6 Nov 2025 00:42:01 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 19:29:13 GMT, Albert Mingkun Yang wrote: > Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. > > Test: tie1-5 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28162#pullrequestreview-3425155624 From ysr at openjdk.org Thu Nov 6 01:25:11 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 6 Nov 2025 01:25:11 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> References: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> Message-ID: On Mon, 3 Nov 2025 18:01:31 GMT, William Kemper wrote: >> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. >> >> # Background >> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Flush SATB buffers upon entering degenerated cycle when old marking is in progress > > This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier. > - Fix typo in comment > - Remove duplicate satb flush closure > - Only flush satb once during degenerated cycle > - Cleanup and comments > - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots > - Fix assertion > - Oops, move inline definition out of ifdef ASSERT > - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de Changes look ok. I found some of the comments confusing -- I have left some remarks at those places, please have a look to see if they can be made clearer. The improvement in performance looks good. Do we track the number of SATB pointers processed by the old marking (to compare between before and after your changes here)? src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1143: > 1141: // be in the collection set. If this happens, the pointer will be preserved, essentially > 1142: // becoming part of the old snapshot. > 1143: // 2. The region is allocated during evacuation of old. This is also not a concern because One related question. In both these cases, I assume the reference will look "marked" because it's above TAMS for the purposes of the old marking? src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 234: > 232: // marking phase. In some cases, this can cause a write to a perfectly > 233: // reachable oop to enqueue a pointer that later becomes garbage (because > 234: // it points at an object that is later chosen for the collection set). There are > ``` > // ... In some cases, this can cause a write to a perfectly > // reachable oop to enqueue a pointer that later becomes garbage (because > // it points at an object that is later chosen for the collection set). > ``` I don't understand this statement. The SATB is supposed to be pointers to objects that we will preserve because they were reachable when the snapshot (marking) was started. Can you elaborate what you mean here? Did you mean that the filtering of the SATB didn't filter a (sometime) young reference which was then processed by the old marking? src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 237: > 235: // also cases where the referent of a weak reference ends up in the SATB > 236: // and is later collected. In these cases the oop in the SATB buffer becomes > 237: // invalid and the _next_ cycle will crash during its marking phase. To Again I don't understand the concept of an SATB pointer to an object that was later collected? Are we talking about young objects that are subsequently processed by old marking because they weren't filtered out when they should be? I think that is probably the case here, but it would be good to clean up these comments to avoid this confusion. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27983#pullrequestreview-3425195561 PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2496682448 PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2496698952 PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2496702500 From duke at openjdk.org Thu Nov 6 01:45:26 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 01:45:26 GMT Subject: RFR: 8261743: Shenandoah: enable String deduplication with compact heuristics Message-ID: Enable `UseStringDeduplication` when using compact heuristics. Testing: ./build/macosx-aarch64-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact -XX:+PrintFlagsFinal --version | grep UseStringDeduplication bool UseStringDeduplication = true {product} {default} Note: The label should be `{product} {ergonomic}` in theory. Pending on a separate issue: [JDK-8371381](https://bugs.openjdk.org/browse/JDK-8371381) ------------- Commit messages: - 8261743: Shenandoah: enable String deduplication with compact heuristics Changes: https://git.openjdk.org/jdk/pull/28170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8261743 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28170/head:pull/28170 PR: https://git.openjdk.org/jdk/pull/28170 From mbaesken at openjdk.org Thu Nov 6 08:09:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 08:09:15 GMT Subject: RFR: 8371316: Adjust assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print In-Reply-To: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> References: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> Message-ID: On Wed, 5 Nov 2025 10:11:42 GMT, Matthias Baesken wrote: > it has been observed that the assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print cuts off the printed values, this should be adjusted to see the real values in error situations. > The current assert prints misleading messages like this (see [JDK-8370063](https://bugs.openjdk.org/browse/JDK-8370063)) : > > > # Internal Error (d:\priv\jenkins\ci2\client-home\workspace\openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\share\gc\g1\g1GCPhaseTimes.cpp:571), pid=8976, tid=24744 > # assert(_gc_pause_time_ms >= accounted_ms) failed: GC pause time(0.001ms) cannot be smaller than the sum of each phase(0.001ms). Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28147#issuecomment-3495707692 From mbaesken at openjdk.org Thu Nov 6 08:09:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 08:09:15 GMT Subject: Integrated: 8371316: Adjust assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print In-Reply-To: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> References: <38hJPT8a4cDYO8W2ZxsPzxIX_613Soo58snARHAt-9s=.fa3afed1-740a-4645-93b7-052277cbe2f5@github.com> Message-ID: On Wed, 5 Nov 2025 10:11:42 GMT, Matthias Baesken wrote: > it has been observed that the assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print cuts off the printed values, this should be adjusted to see the real values in error situations. > The current assert prints misleading messages like this (see [JDK-8370063](https://bugs.openjdk.org/browse/JDK-8370063)) : > > > # Internal Error (d:\priv\jenkins\ci2\client-home\workspace\openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\share\gc\g1\g1GCPhaseTimes.cpp:571), pid=8976, tid=24744 > # assert(_gc_pause_time_ms >= accounted_ms) failed: GC pause time(0.001ms) cannot be smaller than the sum of each phase(0.001ms). This pull request has now been integrated. Changeset: db76479a Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/db76479a105cda383f38f5f9857a8642ccf50cfd Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8371316: Adjust assertion (GC pause time cannot be smaller than the sum of each phase) in G1GCPhaseTimes::print Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28147 From stefank at openjdk.org Thu Nov 6 09:22:02 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 6 Nov 2025 09:22:02 GMT Subject: RFR: 8371343: ZGC: Remove dependency on test execution order for gtests In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:58:56 GMT, Axel Boldt-Christmas wrote: > We currently have a few gtests which are run with the TEST_F macro and use `ZGlobalsPointers::initialize();` which on some platforms may end up doing GC precious logging, which requires the VM (mutexes) to be setup in order to work. Currently the `GTestWrapper.java` succeeds with running these test because we will have run other tests which have setup the VM. > > If a filter is used or the tests are shuffled we can observe that these tests may crash. > > Proposed change is to use the `ZTest` unittest base fixture and run these test with `TEST_VM_F` > > Testing > * GHA > * gtests with and without filter and shuffled test order Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28160#pullrequestreview-3427111121 From stefank at openjdk.org Thu Nov 6 09:25:04 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 6 Nov 2025 09:25:04 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:58:30 GMT, Axel Boldt-Christmas wrote: > A few ZGC gtest reservers memory in valid ZAddress address ranges to mock and test different sub systems. When running in instrumented builds such as ASAN the address space we try to may be unavailable. This will cause a couple of our tests to fail. > > I propose we change all out gtests to do what `test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp` does. Namely uses our `ZVirtualMemoryManager` to reserve the address space and skip the test incase we are not able to reserve an adequate address range to use for the test. > > * Testing > * GHA > * gtest with and without ASAN, including artificially induced reservation clash with ASAN Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28159#pullrequestreview-3427127585 From shade at openjdk.org Thu Nov 6 09:39:10 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Nov 2025 09:39:10 GMT Subject: RFR: 8261743: Shenandoah: enable String deduplication with compact heuristics In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:38:36 GMT, Rui Li wrote: > Enable `UseStringDeduplication` when using compact heuristics. > > Testing: > > ./build/macosx-aarch64-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact -XX:+PrintFlagsFinal --version | grep UseStringDeduplication > bool UseStringDeduplication = true {product} {default} > > > Note: The labels should be `{product} {ergonomic}` ideally. Pending on a separate issue: [JDK-8371381](https://bugs.openjdk.org/browse/JDK-8371381) Looks good. Have you measured any impact on pauses / GC durations in testing? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28170#pullrequestreview-3427178962 From shade at openjdk.org Thu Nov 6 09:47:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 6 Nov 2025 09:47:04 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Thu, 6 Nov 2025 00:21:55 GMT, Rui Li wrote: > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } Right. One node is basically an `Integer` and the reference array slot. So about 20 bytes, give or take. There are 10K nodes per slab, meaning there is 200KB per slab. There are 10K slabs, meaning they take 2GB memory. So bumping the limit to 3G makes sense. I think you want to override `Xmx`, though -- that is the decisive factor for sizing heap regions. Sticking with `Xmx` means the test runs in the same conditions everywhere, helping reproducibility. Unless there is a strong reason to explore different heap regions sizes, which I think there is none: the test was about testing `ObjectAlignmentInBytes` first and foremost. ------------- PR Review: https://git.openjdk.org/jdk/pull/28167#pullrequestreview-3427215034 From tschatzl at openjdk.org Thu Nov 6 10:41:46 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 6 Nov 2025 10:41:46 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate Message-ID: Hi all, please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. Testing: tier1-3, GHA Thomas ------------- Commit messages: - 8274178 Changes: https://git.openjdk.org/jdk/pull/28175/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8274178 Stats: 95 lines in 7 files changed: 42 ins; 30 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From syan at openjdk.org Thu Nov 6 11:20:02 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 6 Nov 2025 11:20:02 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Thu, 6 Nov 2025 00:21:55 GMT, Rui Li wrote: > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } test/hotspot/jtreg/gc/shenandoah/TestLargeObjectAlignment.java line 34: > 32: * @library /test/lib > 33: * > 34: * @run main/othervm -Xms3g -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ObjectAlignmentInBytes=16 -Xint TestLargeObjectAlignment Since the initial heap memory set to 3G, maybe we should add '@requires os.maxMemory > 4g' to skip this test when the physical memory of test machine is less than 4g. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28167#discussion_r2498564622 From eosterlund at openjdk.org Thu Nov 6 11:43:37 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 11:43:37 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race Message-ID: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. If the guard check is performed before the handshake, then the JIT-compiled code will continue to execute past the code that assumes the object has been "recently" allocated, before it replies to the handshake. This means that the promotion barriers never race with the relaxed C2 code. Therefore, the promotion barriers are monotonically coloring in null pointers, such that they become bad pointers when relocate start arrives. This way, the store barriers after relocate start are guaranteed to not lose remembered set entries. ------------- Commit messages: - 8371200: ZGC: C2 allocation deopt race Changes: https://git.openjdk.org/jdk/pull/28176/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371200 Stats: 102 lines in 5 files changed: 52 ins; 40 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28176/head:pull/28176 PR: https://git.openjdk.org/jdk/pull/28176 From eosterlund at openjdk.org Thu Nov 6 13:13:08 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 13:13:08 GMT Subject: RFR: 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v5] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 06:49:39 GMT, Axel Boldt-Christmas wrote: >> ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow. >> >> In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve. >> >> Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap). Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step. > > Axel Boldt-Christmas 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 tag 'jdk-26+21' into JDK-8367317 > > Added tag jdk-26+21 for changeset 3e20a939 > - Merge tag 'jdk-26+19' into JDK-8367317 > > Added tag jdk-26+19 for changeset b37a1a33 > - Merge tag 'jdk-26+18' into JDK-8367317 > > Added tag jdk-26+18 for changeset 5251405c > - Merge tag 'jdk-26+17' into JDK-8367317 > > Added tag jdk-26+17 for changeset 2aafda19 > - 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27207#pullrequestreview-3428123931 From eosterlund at openjdk.org Thu Nov 6 13:34:08 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 13:34:08 GMT Subject: RFR: 8371343: ZGC: Remove dependency on test execution order for gtests In-Reply-To: References: Message-ID: <60q6NAaw5EdpUvasO4Z62XZ-IBy6ywjgbL7D2XFQ6xs=.4f830947-82ab-4370-ad41-0c222871154e@github.com> On Wed, 5 Nov 2025 18:58:56 GMT, Axel Boldt-Christmas wrote: > We currently have a few gtests which are run with the TEST_F macro and use `ZGlobalsPointers::initialize();` which on some platforms may end up doing GC precious logging, which requires the VM (mutexes) to be setup in order to work. Currently the `GTestWrapper.java` succeeds with running these test because we will have run other tests which have setup the VM. > > If a filter is used or the tests are shuffled we can observe that these tests may crash. > > Proposed change is to use the `ZTest` unittest base fixture and run these test with `TEST_VM_F` > > Testing > * GHA > * gtests with and without filter and shuffled test order Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28160#pullrequestreview-3428207028 From eosterlund at openjdk.org Thu Nov 6 13:36:10 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 13:36:10 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: <2qfYb3JYTMm0OVtNtKc-QTw8-7dmAvgQKJ4I4xSFYUc=.ad86217a-2e64-4c24-8e79-053d9595bba2@github.com> On Wed, 5 Nov 2025 18:58:30 GMT, Axel Boldt-Christmas wrote: > A few ZGC gtest reservers memory in valid ZAddress address ranges to mock and test different sub systems. When running in instrumented builds such as ASAN the address space we try to may be unavailable. This will cause a couple of our tests to fail. > > I propose we change all out gtests to do what `test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp` does. Namely uses our `ZVirtualMemoryManager` to reserve the address space and skip the test incase we are not able to reserve an adequate address range to use for the test. > > * Testing > * GHA > * gtest with and without ASAN, including artificially induced reservation clash with ASAN Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28159#pullrequestreview-3428215256 From stefank at openjdk.org Thu Nov 6 13:58:16 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 6 Nov 2025 13:58:16 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race In-Reply-To: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> Message-ID: On Thu, 6 Nov 2025 11:35:50 GMT, Erik ?sterlund wrote: > C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. > > When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. > > ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. > > Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. > > However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. > > This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. > > If the guard check is performed before the handshake, then the JIT-compiled code will continue to execute past the code that as... Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28176#pullrequestreview-3428308369 From kdnilsen at openjdk.org Thu Nov 6 14:22:16 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 6 Nov 2025 14:22:16 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v6] In-Reply-To: References: Message-ID: <6QqmpWAvag906JW5UZj7T1tnWsDKuNNgVArEYv2pQ5g=.69b21a94-afc3-4812-ba9b-7217df4b6704@github.com> On Mon, 29 Sep 2025 16:40:51 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Fixup handling of weakly marked objects in remembered set" >> >> This reverts commit 80198abe5d06c3532d9a43a53691376e990ed45f. > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 132: > >> 130: >> 131: // Search for last one in the range [l_index, r_index). Return r_index if not found. >> 132: inline idx_t get_prev_one_offset (idx_t l_index, idx_t r_index) const; > > Nit: Some idiosyncratic formatting here (space before opening parenthesis). Thanks for catching this. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2499139532 From kvn at openjdk.org Thu Nov 6 16:48:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 6 Nov 2025 16:48:56 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race In-Reply-To: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> Message-ID: On Thu, 6 Nov 2025 11:35:50 GMT, Erik ?sterlund wrote: > C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. > > When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. > > ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. > > Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. > > However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. > > This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. > > If the guard check is performed before the handshake, then the JIT-compiled code will continue to execute past the code that as... Passing-by comment to confirm what @fisk is saying. On any return from runtime call back to compiled code there is check for safepoint request and process it: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/interfaceSupport.inline.hpp#L113C27-L113C63 During safepoint any generational GC may move objects to old gen AFAIU. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28176#issuecomment-3498294841 From wkemper at openjdk.org Thu Nov 6 17:04:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 17:04:58 GMT Subject: RFR: 8261743: Shenandoah: enable String deduplication with compact heuristics In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:38:36 GMT, Rui Li wrote: > Enable `UseStringDeduplication` when using compact heuristics. > > Testing: > > ./build/macosx-aarch64-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact -XX:+PrintFlagsFinal --version | grep UseStringDeduplication > bool UseStringDeduplication = true {product} {default} > > > Note: The labels should be `{product} {ergonomic}` ideally. Pending on a separate issue: [JDK-8371381](https://bugs.openjdk.org/browse/JDK-8371381) Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28170#pullrequestreview-3429408699 From phh at openjdk.org Thu Nov 6 17:12:35 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 6 Nov 2025 17:12:35 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> References: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> Message-ID: <1NQsJmJ_Rr-dIdfeq3kxfqkjNOlCjRurMJ9_QQ_2AeI=.f7da35bd-c80a-4076-b154-7c7a9f53c476@github.com> On Tue, 4 Nov 2025 17:39:37 GMT, Nityanand Rai wrote: >> Fix typos in debug log messages and comments in Concurrent.java > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3429444956 From duke at openjdk.org Thu Nov 6 17:17:32 2025 From: duke at openjdk.org (duke) Date: Thu, 6 Nov 2025 17:17:32 GMT Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java [v2] In-Reply-To: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> References: <_ub2OY-yzjgkFgeH-AcJhqULGO1L7v3hy9uByG2INZc=.aeceb6fd-5be4-41d4-9318-0e730ee430c5@github.com> Message-ID: On Tue, 4 Nov 2025 17:39:37 GMT, Nityanand Rai wrote: >> Fix typos in debug log messages and comments in Concurrent.java > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > update copyright years @nityarai08 Your change (at version 0b8c9a71f983a6d298a608ae8444655d70b2b690) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27810#issuecomment-3498440406 From eosterlund at openjdk.org Thu Nov 6 17:20:22 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 17:20:22 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race In-Reply-To: References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> Message-ID: <5yghbX6g3S-KGFT0G_W7r3brn-g66ropbLjSr3Zqdbg=.ecca0b48-e767-4dce-a251-d79bbb72d6f6@github.com> On Thu, 6 Nov 2025 16:45:52 GMT, Vladimir Kozlov wrote: > Passing-by comment to confirm what @fisk is saying. On any return from runtime call back to compiled code there is check for safepoint request and process it: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/interfaceSupport.inline.hpp#L113C27-L113C63 > > > > During safepoint any generational GC may move objects to old gen AFAIU. That is very true. Most GCs clobber some cards after the transition if the object gets promoted to the old generation to counteract the cheating with barriers. With ZGC, we deopt the frame instead and rely on not cheating with barriers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28176#issuecomment-3498453051 From xpeng at openjdk.org Thu Nov 6 17:27:34 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Nov 2025 17:27:34 GMT Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration [v3] In-Reply-To: References: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com> Message-ID: On Tue, 4 Nov 2025 23:08:11 GMT, William Kemper wrote: >> I have removed can_allocate_in_new_region again after merging @kdnilsen's change unifying accountings, since we don't have consistency in accountings anymore. > > We still need to enforce that requests for a young evacuation don't take memory that was reserved for old evacuations. `can_allocate_in_new_region` isn't about consistency between freeset and generation accounting, it's used to maintain old/young collector reserves. I am confused again. My understanding is: we won't, that is is done by the partition, for young evacuation we will only look for regions in the Collector partition, if a region is FREE and reserved for old evacuations, the region will be in OldCollector partition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2500016821 From duke at openjdk.org Thu Nov 6 17:28:35 2025 From: duke at openjdk.org (Nityanand Rai) Date: Thu, 6 Nov 2025 17:28:35 GMT Subject: Integrated: 8369323: Fix typos in vmTestbase/.../Concurrent.java In-Reply-To: References: Message-ID: <1FcoKTQKP1PqEoZoR4XWSNvxuaQiGntL98_IJksh2U4=.32e60dce-2785-4f21-a2f3-6cae9a4ded72@github.com> On Tue, 14 Oct 2025 21:54:19 GMT, Nityanand Rai wrote: > Fix typos in debug log messages and comments in Concurrent.java This pull request has now been integrated. Changeset: 4445a8e3 Author: Nityanand Rai Committer: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/4445a8e3f5cac6738b7984716c867dcf9780fe0a Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod 8369323: Fix typos in vmTestbase/.../Concurrent.java Reviewed-by: wkemper, phh, lmesnik, shade, syan ------------- PR: https://git.openjdk.org/jdk/pull/27810 From wkemper at openjdk.org Thu Nov 6 17:43:52 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 17:43:52 GMT Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration [v3] In-Reply-To: References: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com> Message-ID: On Thu, 6 Nov 2025 17:24:21 GMT, Xiaolong Peng wrote: >> We still need to enforce that requests for a young evacuation don't take memory that was reserved for old evacuations. `can_allocate_in_new_region` isn't about consistency between freeset and generation accounting, it's used to maintain old/young collector reserves. > > I am confused again. My understanding is: we won't, that is is done by the partition, for young evacuation we will only look for regions in the Collector partition, if a region is FREE and reserved for old evacuations, the region will be in OldCollector partition. My apologies, you're right. The `FREE` region we remember when looking for the region with the same affiliation as the request does come from the same partition as the second loop would have searched. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2500097577 From wkemper at openjdk.org Thu Nov 6 17:47:42 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 17:47:42 GMT Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration [v3] In-Reply-To: References: Message-ID: <2wIxZ0sslT7_GkFAr5yccBB7zSzfUOZAeaOsf9Ljnqg=.851fb239-04f8-4a85-adf0-42879d646722@github.com> On Fri, 31 Oct 2025 22:09:18 GMT, Xiaolong Peng wrote: >> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice: >> 1. fast path: traverse regions between left most and right most in the partition, and try to allocate in an affiliated region in the partition; >> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region. >> >> 2 can be saved if we also remember the first FREE region seem in 1. >> >> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) >> >> >> Test: >> - [x] hotspot_gc_shenandoah > > Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Remove can_allocate_in_new_region > - Merge remote-tracking branch 'origin/master' into collector-allocation > - Remove condition check for trash region > - Address the PR review comments > - Merge branch 'openjdk:master' into collector-allocation > - Touch up > - Remove test 'req.is_old()' when steal an empty region from the mutator view > - Update comment > - Fix wrong condition when steal an empty region from the mutator view > - Fix potential failure in young evac > - ... and 3 more: https://git.openjdk.org/jdk/compare/ec059c0e...8e01d691 Looks good, sorry for the mix up. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28036#pullrequestreview-3429628956 From wkemper at openjdk.org Thu Nov 6 17:53:12 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 17:53:12 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: References: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> Message-ID: <5J3gg2vmNAxe3JuZb88sM_CYm6DPwk9z8-o3ml3_l28=.38cf585c-c2ab-44da-9321-b448da98b4a7@github.com> On Thu, 6 Nov 2025 01:04:04 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots >> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots >> - Flush SATB buffers upon entering degenerated cycle when old marking is in progress >> >> This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier. >> - Fix typo in comment >> - Remove duplicate satb flush closure >> - Only flush satb once during degenerated cycle >> - Cleanup and comments >> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots >> - Fix assertion >> - Oops, move inline definition out of ifdef ASSERT >> - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1143: > >> 1141: // be in the collection set. If this happens, the pointer will be preserved, essentially >> 1142: // becoming part of the old snapshot. >> 1143: // 2. The region is allocated during evacuation of old. This is also not a concern because > > One related question. In both these cases, I assume the reference will look "marked" because it's above TAMS for the purposes of the old marking? In the first case (in-place promotion) the pointer wouldn't necessarily be above TAMS. In this case, we would leave the object in the 'complete' buffer and it would become marked by the old marking threads (it becomes part of the old snapshot). The second case is not an issue because none of the cset regions will become trash until _after_ `final-update-refs` (so no regions could become old until after we filter the SATB buffers). For regions that are already old, then the TAMS and mark bit map work as usual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2500141016 From wkemper at openjdk.org Thu Nov 6 18:06:03 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 18:06:03 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: References: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> Message-ID: On Thu, 6 Nov 2025 01:18:52 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots >> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots >> - Flush SATB buffers upon entering degenerated cycle when old marking is in progress >> >> This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier. >> - Fix typo in comment >> - Remove duplicate satb flush closure >> - Only flush satb once during degenerated cycle >> - Cleanup and comments >> - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots >> - Fix assertion >> - Oops, move inline definition out of ifdef ASSERT >> - ... and 11 more: https://git.openjdk.org/jdk/compare/1922c4fd...4bd602de > > src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 237: > >> 235: // also cases where the referent of a weak reference ends up in the SATB >> 236: // and is later collected. In these cases the oop in the SATB buffer becomes >> 237: // invalid and the _next_ cycle will crash during its marking phase. To > > Again I don't understand the concept of an SATB pointer to an object that was later collected? Are we talking about young objects that are subsequently processed by old marking because they weren't filtered out when they should be? > > I think that is probably the case here, but it would be good to clean up these comments to avoid this confusion. Suppose we have a young collection running while the SATB barrier is active for old marking. The barrier will be enabled for the entirety of the young collection. Now, suppose we have a situation like this: +--Young, CSet------+ +--Young, Regular----+ | | | | | | | | | A <--------------------+ B | | | | | | | | | | | | | | | | | | | | | +-------------------+ +--------------------+ If a mutator overwrites the pointer in `B`, the SATB barrier will enqueue object `A`. These are the objects we need to filter out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2500196026 From wkemper at openjdk.org Thu Nov 6 18:36:48 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 18:36:48 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v4] In-Reply-To: References: Message-ID: > When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. > > # Background > When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Improve comment describing the need for a method to filter SATB buffers for degenerated cycles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27983/files - new: https://git.openjdk.org/jdk/pull/27983/files/4bd602de..c741bf6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27983&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27983&range=02-03 Stats: 24 lines in 1 file changed: 6 ins; 6 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27983/head:pull/27983 PR: https://git.openjdk.org/jdk/pull/27983 From wkemper at openjdk.org Thu Nov 6 18:38:08 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 18:38:08 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v6] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 02:24:11 GMT, Kelvin Nilsen wrote: >> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. >> >> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Fixup handling of weakly marked objects in remembered set" > > This reverts commit 80198abe5d06c3532d9a43a53691376e990ed45f. Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27353#pullrequestreview-3429901677 From ysr at openjdk.org Thu Nov 6 18:57:04 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 6 Nov 2025 18:57:04 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v4] In-Reply-To: References: Message-ID: <3fNre-PPou9riBh4OJnCKeMgVIisuncArHrA44Ao4GQ=.4785a481-4280-414e-8a29-b9f7c654accb@github.com> On Thu, 6 Nov 2025 18:36:48 GMT, William Kemper wrote: >> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. >> >> # Background >> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment describing the need for a method to filter SATB buffers for degenerated cycles I approved this, but will follow up with you offline to more properly understand this. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27983#pullrequestreview-3430002460 From ysr at openjdk.org Thu Nov 6 18:57:08 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 6 Nov 2025 18:57:08 GMT Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old [v3] In-Reply-To: <5J3gg2vmNAxe3JuZb88sM_CYm6DPwk9z8-o3ml3_l28=.38cf585c-c2ab-44da-9321-b448da98b4a7@github.com> References: <-MlfBVpHD57gSd_4_0iIDHI0Cv6HIpTj9H9mX-UHS7g=.54423f43-32dd-49c4-8e7e-705dbbc8c825@github.com> <5J3gg2vmNAxe3JuZb88sM_CYm6DPwk9z8-o3ml3_l28=.38cf585c-c2ab-44da-9321-b448da98b4a7@github.com> Message-ID: On Thu, 6 Nov 2025 17:50:50 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1143: >> >>> 1141: // be in the collection set. If this happens, the pointer will be preserved, essentially >>> 1142: // becoming part of the old snapshot. >>> 1143: // 2. The region is allocated during evacuation of old. This is also not a concern because >> >> One related question. In both these cases, I assume the reference will look "marked" because it's above TAMS for the purposes of the old marking? > > In the first case (in-place promotion) the pointer wouldn't necessarily be above TAMS. In this case, we would leave the object in the 'complete' buffer and it would become marked by the old marking threads (it becomes part of the old snapshot). > > The second case is not an issue because none of the cset regions will become trash until _after_ `final-update-refs` (so no regions could become old until after we filter the SATB buffers). For regions that are already old, then the TAMS and mark bit map work as usual. Shouldn't promoted objects look black to the old collection, because that's what SATB marking would want? (In other words, the TAMS for the region should be bottom for that promoted in place region for the purposes of old gen marking.) I'll follow up off-line with you so I understand what's happening here better. Meanwhile, I'm going to re-approve this PR because I don't want to hold it hostage to my misunderstanding at this time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2500408183 From xpeng at openjdk.org Thu Nov 6 19:01:22 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Nov 2025 19:01:22 GMT Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration [v3] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 22:09:18 GMT, Xiaolong Peng wrote: >> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice: >> 1. fast path: traverse regions between left most and right most in the partition, and try to allocate in an affiliated region in the partition; >> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region. >> >> 2 can be saved if we also remember the first FREE region seem in 1. >> >> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) >> >> >> Test: >> - [x] hotspot_gc_shenandoah > > Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Remove can_allocate_in_new_region > - Merge remote-tracking branch 'origin/master' into collector-allocation > - Remove condition check for trash region > - Address the PR review comments > - Merge branch 'openjdk:master' into collector-allocation > - Touch up > - Remove test 'req.is_old()' when steal an empty region from the mutator view > - Update comment > - Fix wrong condition when steal an empty region from the mutator view > - Fix potential failure in young evac > - ... and 3 more: https://git.openjdk.org/jdk/compare/ec059c0e...8e01d691 Thanks a lot for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28036#issuecomment-3498932713 From xpeng at openjdk.org Thu Nov 6 19:01:23 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Nov 2025 19:01:23 GMT Subject: Integrated: 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 05:29:14 GMT, Xiaolong Peng wrote: > To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice: > 1. fast path: traverse regions between left most and right most in the partition, and try to allocate in an affiliated region in the partition; > 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region. > > 2 can be saved if we also remember the first FREE region seem in 1. > > The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) > > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 9cc542eb Author: Xiaolong Peng URL: https://git.openjdk.org/jdk/commit/9cc542ebcb81552fe8c32a8cc3c63332853e5127 Stats: 77 lines in 2 files changed: 18 ins; 45 del; 14 mod 8370850: Shenandoah: Simplify collector allocation to save unnecessary region iteration Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/28036 From azeller at openjdk.org Thu Nov 6 19:36:06 2025 From: azeller at openjdk.org (Arno Zeller) Date: Thu, 6 Nov 2025 19:36:06 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space In-Reply-To: References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Thu, 6 Nov 2025 11:17:01 GMT, SendaoYan wrote: >> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. >> >> Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. >> >> Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. >> >> >> >> public class TestLargeObjectAlignmentDeterministic { >> >> static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); >> static final int NODE_COUNT = Integer.getInteger("nodes", 10000); >> static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); >> >> static Object[] objects; >> >> public static void main(String[] args) throws Exception { >> objects = new Object[SLABS_COUNT]; >> >> for (int i = 0; i < SLABS_COUNT; i++) { >> objects[i] = createSome(); >> } >> } >> >> public static Object createSome() { >> List result = new ArrayList(); >> for (int c = 0; c < NODE_COUNT; c++) { >> result.add(new Integer(c)); >> } >> return result; >> } >> >> } > > test/hotspot/jtreg/gc/shenandoah/TestLargeObjectAlignment.java line 34: > >> 32: * @library /test/lib >> 33: * >> 34: * @run main/othervm -Xms3g -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ObjectAlignmentInBytes=16 -Xint TestLargeObjectAlignment > > Since the initial heap memory set to 3G, maybe we should add '@requires os.maxMemory > 4g' to skip this test when the physical memory of test machine is less than 4g. I suggest to also set -Xmx3g - otherwise the test will fail in case an -Xmx value of less than 3GB is set by a jtreg -vmoption. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28167#discussion_r2500542446 From wkemper at openjdk.org Thu Nov 6 19:40:14 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 19:40:14 GMT Subject: Integrated: 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 21:00:40 GMT, William Kemper wrote: > When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'. > > # Background > When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things. This pull request has now been integrated. Changeset: cad73d39 Author: William Kemper URL: https://git.openjdk.org/jdk/commit/cad73d39762974776dd6fda5efe4e2a271d69f14 Stats: 331 lines in 11 files changed: 108 ins; 198 del; 25 mod 8370041: GenShen: Filter young pointers from thread local SATB buffers when only marking old Reviewed-by: ysr, kdnilsen ------------- PR: https://git.openjdk.org/jdk/pull/27983 From duke at openjdk.org Thu Nov 6 20:46:13 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 20:46:13 GMT Subject: RFR: 8261743: Shenandoah: enable String deduplication with compact heuristics In-Reply-To: References: Message-ID: <2pqCwlRDMHj8qRBGXssro17pUf9sGnMLaeb4J_mY_iQ=.99c31242-76e5-4f08-b818-e7dfd0a38ed1@github.com> On Thu, 6 Nov 2025 09:36:06 GMT, Aleksey Shipilev wrote: > Looks good. Have you measured any impact on pauses / GC durations in testing? Yeah. Had a simple benchmark below (credit to [here](https://muratakkan.medium.com/understanding-string-deduplication-in-java-how-it-works-and-when-to-use-it-fbda71711435)): @Benchmark public void testMethod(Blackhole bh) { // This is a demo/sample template for building your JMH benchmarks. Edit as needed. // Put your benchmark code here. String[] strings = new String[1000000]; for (int i = 0; i < strings.length; i++) { strings[i] = "This is a test string"; } bh.consume(strings); } Results: ######## java -jar target/benchmarks.jar --jvmArgs "-XX:-UseStringDeduplication -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact" -prof gc ######## Benchmark Mode Cnt Score Error Units MyBenchmark.testMethod thrpt 3 3181.651 ? 248.835 ops/s MyBenchmark.testMethod:gc.alloc.rate thrpt 3 12136.888 ? 949.185 MB/sec MyBenchmark.testMethod:gc.alloc.rate.norm thrpt 3 4000016.188 ? 0.016 B/op MyBenchmark.testMethod:gc.count thrpt 3 1568.000 counts MyBenchmark.testMethod:gc.time thrpt 3 1882.000 ms ######## java -jar target/benchmarks.jar --jvmArgs "-XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact" -prof gc ######## Benchmark Mode Cnt Score Error Units MyBenchmark.testMethod thrpt 3 3155.961 ? 365.174 ops/s # throuput decreased by 0.8% MyBenchmark.testMethod:gc.alloc.rate thrpt 3 12038.882 ? 1394.186 MB/sec # decreased by 0.8% MyBenchmark.testMethod:gc.alloc.rate.norm thrpt 3 4000016.190 ? 0.022 B/op # same MyBenchmark.testMethod:gc.count thrpt 3 1172.000 counts # decreased by 25% MyBenchmark.testMethod:gc.time thrpt 3 726.000 ms # decreased by 38.6% The alloc rate / throughput didn't change much, but the gc count and gc time reduced by 25% and 38.6%. Not that familiar with string deduplication, but according to https://openjdk.org/jeps/192, the results seem to match the implementation - does not dedup at allocation time, but dedup the string internal char array at gc time and gc would be more efficient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28170#issuecomment-3499316594 From wkemper at openjdk.org Thu Nov 6 21:00:34 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 6 Nov 2025 21:00:34 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements Message-ID: When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. ------------- Commit messages: - More simplification of arraycopy mark barrier - Merge remote-tracking branch 'jdk/master' into satb-fixes - Merge remote-tracking branch 'jdk/master' into satb-fixes - Why does this break? - Simplify arraycopy barrier case for marking - Merge remote-tracking branch 'jdk/master' into satb-fixes - Do not unconditionally enqueue old objects during marking Changes: https://git.openjdk.org/jdk/pull/28183/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370039 Stats: 53 lines in 2 files changed: 0 ins; 46 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28183/head:pull/28183 PR: https://git.openjdk.org/jdk/pull/28183 From ysr at openjdk.org Thu Nov 6 21:12:03 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 6 Nov 2025 21:12:03 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v6] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 02:24:11 GMT, Kelvin Nilsen wrote: >> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. >> >> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Fixup handling of weakly marked objects in remembered set" > > This reverts commit 80198abe5d06c3532d9a43a53691376e990ed45f. It looks like a few older comments had not been published previously. I am flushing those and will take a fresh look at the review. ------------- PR Review: https://git.openjdk.org/jdk/pull/27353#pullrequestreview-3300762300 From ysr at openjdk.org Thu Nov 6 21:12:12 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 6 Nov 2025 21:12:12 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v2] In-Reply-To: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: On Fri, 3 Oct 2025 00:21:11 GMT, Kelvin Nilsen wrote: >> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. >> >> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > fix idiosyncratic formatting src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 129: > 127: inline idx_t get_prev_bit_impl(idx_t l_index, idx_t r_index) const; > 128: > 129: inline idx_t get_next_one_offset(idx_t l_index, idx_t r_index) const; Please document analogous to line 131. src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 131: > 129: inline idx_t get_next_one_offset(idx_t l_index, idx_t r_index) const; > 130: > 131: // Search for last one in the range [l_index, r_index). Return r_index if not found. Symmetry arguments wrt spec for `get_next_one_offset` may have preferred range `(l_index, r_index]`, returning `l_index` if none found. May be its (transitive) usage prefers this shape? (See similar comment at line 180.) src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 134: > 132: inline idx_t get_prev_one_offset(idx_t l_index, idx_t r_index) const; > 133: > 134: void clear_large_range(idx_t beg, idx_t end); documentation comment. src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 180: > 178: const HeapWord* limit) const; > 179: > 180: // Return the last marked address in the range [limit, addr], or addr+1 if none found. Symmetry would have preferred `(limit, addr]` as the range with `limit` if none found. However, may be usage of this method prefers the present shape? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 251: > 249: // if marking context is valid and we are below tams, we use the marking bit map to find the first marked object that > 250: // intersects with this card, and if no such object exists, we return null > 251: if ((ctx != nullptr) && (left < tams)) { It seems like the caller should check if `left >= tams` and short-circuit rather than have this method do that work. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 663: > 661: // we expect that the marking context isn't available and the crossing maps are valid. > 662: // Note that crossing maps may be invalid following class unloading and before dead > 663: // or unloaded objects have been coalesced and filled (updating the crossing maps). Good comment! What's still not clear is why `tams` and `last_relevant_card_index` are passed here. Does it reduce the work in the caller? I'd expect this to just return the first object on the card index or null if no such object exists. I realize `ctx` is used when one must consult the marking context in preference to the "crossing maps". The relevance of the last 2 arguments isn't clear from this documentation comment. May be I'll see why these are passed in when I look at the method definition, but I suspect there may be some leakage of abstraction & functionality here between caller and callee. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 177: > 175: // common. > 176: assert(ctx != nullptr || heap->old_generation()->is_parsable(), "Error"); > 177: HeapWord* p = _scc->first_object_start(dirty_l, ctx, tams, dirty_r); Passing `ctx`, `tams`, and `dirty_r` into this method seems interesting. Let's see how they are used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403250259 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403253570 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403255239 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403247074 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403311952 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403309508 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2403300158 From duke at openjdk.org Thu Nov 6 21:54:00 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 21:54:00 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Thu, 6 Nov 2025 00:21:55 GMT, Rui Li wrote: > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } Will set Xmx to 3g instead and add `@requires os.maxMemory > 3g` Initially set Xms to 3g was purely to satisfy the "minimal heap size needed" condition for the test. `@requires os.maxMemory` is apparently more close to what I was thinking and I didn't think about reproducibility. Thanks for the suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28167#issuecomment-3499525127 From duke at openjdk.org Thu Nov 6 22:25:32 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 22:25:32 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v2] In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } Rui Li has updated the pull request incrementally with one additional commit since the last revision: Set Xmx to 3g ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28167/files - new: https://git.openjdk.org/jdk/pull/28167/files/31e4adfc..6c442aa0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=00-01 Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28167/head:pull/28167 PR: https://git.openjdk.org/jdk/pull/28167 From duke at openjdk.org Thu Nov 6 22:35:09 2025 From: duke at openjdk.org (duke) Date: Thu, 6 Nov 2025 22:35:09 GMT Subject: RFR: 8261743: Shenandoah: enable String deduplication with compact heuristics In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 01:38:36 GMT, Rui Li wrote: > Enable `UseStringDeduplication` when using compact heuristics. > > Testing: > > ./build/macosx-aarch64-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact -XX:+PrintFlagsFinal --version | grep UseStringDeduplication > bool UseStringDeduplication = true {product} {default} > > > Note: The labels should be `{product} {ergonomic}` ideally. Pending on a separate issue: [JDK-8371381](https://bugs.openjdk.org/browse/JDK-8371381) > > > ------- > > Edit: add benchmark results: > > Had a simple benchmark below (credit to [here](https://muratakkan.medium.com/understanding-string-deduplication-in-java-how-it-works-and-when-to-use-it-fbda71711435)): > > > > @Benchmark > public void testMethod(Blackhole bh) { > String[] strings = new String[1000000]; > for (int i = 0; i < strings.length; i++) { > strings[i] = "This is a test string"; > } > bh.consume(strings); > } > > > Results: > > ######## > java -jar target/benchmarks.jar --jvmArgs "-XX:-UseStringDeduplication -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact" -prof gc > ######## > Benchmark Mode Cnt Score Error Units > MyBenchmark.testMethod thrpt 3 3181.651 ? 248.835 ops/s > MyBenchmark.testMethod:gc.alloc.rate thrpt 3 12136.888 ? 949.185 MB/sec > MyBenchmark.testMethod:gc.alloc.rate.norm thrpt 3 4000016.188 ? 0.016 B/op > MyBenchmark.testMethod:gc.count thrpt 3 1568.000 counts > MyBenchmark.testMethod:gc.time thrpt 3 1882.000 ms > > ######## > java -jar target/benchmarks.jar --jvmArgs "-XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact" -prof gc > ######## > Benchmark Mode Cnt Score Error Units > MyBenchmark.testMethod thrpt 3 3155.961 ? 365.174 ops/s # throuput decreased by 0.8% > MyBenchmark.testMethod:gc.alloc.rate thrpt 3 12038.882 ? 1394.186 MB/sec # decreased by 0.8% > MyBenchmark.testMethod:gc.alloc.rate.norm thrpt 3 4000016.190 ? 0.022 B/op # same > MyBenchmark.testMethod:gc.count thrpt 3 1172.000 counts # decreased by 25% > MyBenchmark.testMethod:gc.time thrpt 3 726.000 ms # decrea... @rgithubli Your change (at version 2407976e137e42f3f831690c14501b0e338a4c4e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28170#issuecomment-3499636944 From duke at openjdk.org Thu Nov 6 22:41:20 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 22:41:20 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v3] In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: <8F4jfHS1_VpRu9qzZdgO85PMEZRvL3FVMHMQDdmr7MU=.da7b2e1c-282b-47d1-9c46-aa684520acbb@github.com> > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } Rui Li has updated the pull request incrementally with one additional commit since the last revision: Adjust tag order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28167/files - new: https://git.openjdk.org/jdk/pull/28167/files/6c442aa0..3dbe9a10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28167/head:pull/28167 PR: https://git.openjdk.org/jdk/pull/28167 From duke at openjdk.org Thu Nov 6 22:52:13 2025 From: duke at openjdk.org (duke) Date: Thu, 6 Nov 2025 22:52:13 GMT Subject: Withdrawn: 8366065: ZGC: Differentiate Young Collection type strings in statistics In-Reply-To: References: Message-ID: <85JJMt-C2wSVGEUiktMXG4XTiuB_C4kdquyJC93EpSw=.d89a5f7b-fc64-4883-a1a5-bd03580114ca@github.com> On Thu, 28 Aug 2025 12:21:46 GMT, Joel Sikstr?m wrote: > Hello, > > Currently, two different Young Collection (YC) types print identical strings in the GC statistics at the end of `-Xlog:gc*`. This makes it difficult to distinguish statistics for specific YC types when analyzing logs for performance issues. This PR updates the strings to match the `ZYoungType` enum names, improving traceability and making logs clearer. > > Relevant enum for reference: > ```c++ > enum class ZYoungType { > minor, > major_full_preclean, > major_full_roots, > major_partial_roots, > none > }; > > > Testing: > * GHA This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26986 From xpeng at openjdk.org Thu Nov 6 23:16:23 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Nov 2025 23:16:23 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v6] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 138 commits: - Add assert back - Address test failures after merging the change from master which unify the accounting in FreeSet and ShenandoahGeneration - Merge remote-tracking branch 'origin/master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - format - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'master' into cas-alloc-1 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp - ... and 128 more: https://git.openjdk.org/jdk/compare/ec059c0e...dfb9c415 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=05 Stats: 780 lines in 17 files changed: 690 ins; 23 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Thu Nov 6 23:29:10 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 6 Nov 2025 23:29:10 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 22:28:06 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - format >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix errors caused by renaming ofAtomic to AtomicAccess >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05 > > src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 559: > >> 557: range(1, 128) \ >> 558: \ >> 559: product(uintx, ShenandoahDirectAllocationMaxProbes, 3, EXPERIMENTAL, \ > > I think we found that setting DirectAllocationMaxProbes to equal ShenandoahDirectlyAlloctableRegionCount works "best". I'm inclined to remove this parameter entirely as it somewhat simplifies the implementation. If you think we want to keep it, can you explain the rationale? Would we change the default value? I just fixed all the test failures after merging your changes from tip. Totally agreed, I do plan to remove DirectAllocationMaxProbes, we don't need to keep it based on the test result, I'll update the PR to remove it shortly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2501197258 From duke at openjdk.org Thu Nov 6 23:50:13 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 6 Nov 2025 23:50:13 GMT Subject: Integrated: 8261743: Shenandoah: enable String deduplication with compact heuristics In-Reply-To: References: Message-ID: <3KIq-OuvFuL4npIJZcS5IonVljwX8UMjOCfZNv4Pl-I=.ec7ead22-0fae-4993-ac22-6fa0b3a2c824@github.com> On Thu, 6 Nov 2025 01:38:36 GMT, Rui Li wrote: > Enable `UseStringDeduplication` when using compact heuristics. > > Testing: > > ./build/macosx-aarch64-server-release/images/jdk/bin/java -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact -XX:+PrintFlagsFinal --version | grep UseStringDeduplication > bool UseStringDeduplication = true {product} {default} > > > Note: The labels should be `{product} {ergonomic}` ideally. Pending on a separate issue: [JDK-8371381](https://bugs.openjdk.org/browse/JDK-8371381) > > > ------- > > Edit: add benchmark results: > > Had a simple benchmark below (credit to [here](https://muratakkan.medium.com/understanding-string-deduplication-in-java-how-it-works-and-when-to-use-it-fbda71711435)): > > > > @Benchmark > public void testMethod(Blackhole bh) { > String[] strings = new String[1000000]; > for (int i = 0; i < strings.length; i++) { > strings[i] = "This is a test string"; > } > bh.consume(strings); > } > > > Results: > > ######## > java -jar target/benchmarks.jar --jvmArgs "-XX:-UseStringDeduplication -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact" -prof gc > ######## > Benchmark Mode Cnt Score Error Units > MyBenchmark.testMethod thrpt 3 3181.651 ? 248.835 ops/s > MyBenchmark.testMethod:gc.alloc.rate thrpt 3 12136.888 ? 949.185 MB/sec > MyBenchmark.testMethod:gc.alloc.rate.norm thrpt 3 4000016.188 ? 0.016 B/op > MyBenchmark.testMethod:gc.count thrpt 3 1568.000 counts > MyBenchmark.testMethod:gc.time thrpt 3 1882.000 ms > > ######## > java -jar target/benchmarks.jar --jvmArgs "-XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=compact" -prof gc > ######## > Benchmark Mode Cnt Score Error Units > MyBenchmark.testMethod thrpt 3 3155.961 ? 365.174 ops/s # throuput decreased by 0.8% > MyBenchmark.testMethod:gc.alloc.rate thrpt 3 12038.882 ? 1394.186 MB/sec # decreased by 0.8% > MyBenchmark.testMethod:gc.alloc.rate.norm thrpt 3 4000016.190 ? 0.022 B/op # same > MyBenchmark.testMethod:gc.count thrpt 3 1172.000 counts # decreased by 25% > MyBenchmark.testMethod:gc.time thrpt 3 726.000 ms # decrea... This pull request has now been integrated. Changeset: e34a8318 Author: Rui Li Committer: Xiaolong Peng URL: https://git.openjdk.org/jdk/commit/e34a831814996be3e0a2df86b11b1718a76ea558 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8261743: Shenandoah: enable String deduplication with compact heuristics Reviewed-by: shade, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/28170 From kdnilsen at openjdk.org Thu Nov 6 23:52:05 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 6 Nov 2025 23:52:05 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: On Fri, 3 Oct 2025 20:47:16 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 663: > >> 661: // we expect that the marking context isn't available and the crossing maps are valid. >> 662: // Note that crossing maps may be invalid following class unloading and before dead >> 663: // or unloaded objects have been coalesced and filled (updating the crossing maps). > > Good comment! > > What's still not clear is why `tams` and `last_relevant_card_index` are passed here. Does it reduce the work in the caller? I'd expect this to just return the first object on the card index or null if no such object exists. I realize `ctx` is used when one must consult the marking context in preference to the "crossing maps". The relevance of the last 2 arguments isn't clear from this documentation comment. > > May be I'll see why these are passed in when I look at the method definition, but I suspect there may be some leakage of abstraction & functionality here between caller and callee. Thanks for identifying this "confusion". I'm making an attempt to improve documentation for this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2501237330 From xpeng at openjdk.org Fri Nov 7 00:12:25 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 00:12:25 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v7] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Set region back to empty and unaffiliated when release a directly allocatable region(may happen in full GC) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/dfb9c415..3fdb0bc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=05-06 Stats: 12 lines in 2 files changed: 10 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Nov 7 00:49:53 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 00:49:53 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v8] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request incrementally with three additional commits since the last revision: - Remove unnecessary fences - tidy up - Remove ShenandoahDirectAllocationMaxProbes, simplifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/3fdb0bc0..68b4673a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=06-07 Stats: 55 lines in 3 files changed: 12 ins; 34 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Nov 7 01:07:51 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 01:07:51 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v9] In-Reply-To: References: Message-ID: <_31UGErPvJMV2V7F92kffihoUTtJ7L3HrX-SGgTXj_M=.030a9b2a-8ef0-4d23-a2dd-69ad70e17656@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 143 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - Remove unnecessary fences - tidy up - Remove ShenandoahDirectAllocationMaxProbes, simplifications - Set region back to empty and unaffiliated when release a directly allocatable region(may happen in full GC) - Add assert back - Address test failures after merging the change from master which unify the accounting in FreeSet and ShenandoahGeneration - Merge remote-tracking branch 'origin/master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - ... and 133 more: https://git.openjdk.org/jdk/compare/e34a8318...e65457f6 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=08 Stats: 767 lines in 17 files changed: 677 ins; 23 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From syan at openjdk.org Fri Nov 7 02:12:06 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 7 Nov 2025 02:12:06 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v3] In-Reply-To: <8F4jfHS1_VpRu9qzZdgO85PMEZRvL3FVMHMQDdmr7MU=.da7b2e1c-282b-47d1-9c46-aa684520acbb@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> <8F4jfHS1_VpRu9qzZdgO85PMEZRvL3FVMHMQDdmr7MU=.da7b2e1c-282b-47d1-9c46-aa684520acbb@github.com> Message-ID: On Thu, 6 Nov 2025 22:41:20 GMT, Rui Li wrote: >> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. >> >> Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. >> >> Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. >> >> >> >> public class TestLargeObjectAlignmentDeterministic { >> >> static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); >> static final int NODE_COUNT = Integer.getInteger("nodes", 10000); >> static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); >> >> static Object[] objects; >> >> public static void main(String[] args) throws Exception { >> objects = new Object[SLABS_COUNT]; >> >> for (int i = 0; i < SLABS_COUNT; i++) { >> objects[i] = createSome(); >> } >> } >> >> public static Object createSome() { >> List result = new ArrayList(); >> for (int c = 0; c < NODE_COUNT; c++) { >> result.add(new Integer(c)); >> } >> return result; >> } >> >> } > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Adjust tag order test/hotspot/jtreg/gc/shenandoah/TestLargeObjectAlignment.java line 32: > 30: * @requires vm.gc.Shenandoah > 31: * @requires vm.bits == "64" > 32: * @requires os.maxMemory > 3G I think os.maxMemory should slightly large than max heap memory size, since heap memory is not the only memory in jvm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28167#discussion_r2501446720 From kdnilsen at openjdk.org Fri Nov 7 06:14:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 7 Nov 2025 06:14:45 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v7] In-Reply-To: References: Message-ID: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: fix up comments and simplify API for ShenandoahScanRemembered::first_object_start() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/643cdfd6..637c1775 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=05-06 Stats: 43 lines in 3 files changed: 19 ins; 13 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From aboldtch at openjdk.org Fri Nov 7 07:15:03 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 7 Nov 2025 07:15:03 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 19:29:13 GMT, Albert Mingkun Yang wrote: > Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. > > Test: tie1-5 We currently also need to hold `PSOldGenExpand_lock` to do expansion in old gen (when not doing it from a safepoint, or is just `Thread::current()->is_VM_thread()` right now, maybe a bit scary). I cannot really see that we take it in the`!!is_init_completed()` path. Think we also need to either take this lock or loosen the invariant to only require the lock when `is_init_completed() && !Thread::current()->is_VM_thread()` See `MutableSpace::needs_expand` and `PSOldGen::expand`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28162#issuecomment-3501053430 From aboldtch at openjdk.org Fri Nov 7 07:21:01 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 7 Nov 2025 07:21:01 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 19:29:13 GMT, Albert Mingkun Yang wrote: > Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. > > Test: tie1-5 src/hotspot/share/gc/parallel/psOldGen.cpp line 121: > 119: > 120: HeapWord* PSOldGen::expand_and_allocate(size_t word_size) { > 121: assert(Heap_lock->is_locked(), "precondition"); Are these methods fine to call from a non safepoint after we have started the GC? If they are not. We should not loosen the precondition this much. Suggestion: precond(Heap_lock->is_locked()); precond(!is_init_completed() || SafepointSynchronize::is_at_safepoint()); precond(!is_init_completed() || Thread::current()->is_VM_thread()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28162#discussion_r2501948145 From aboldtch at openjdk.org Fri Nov 7 07:49:01 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 7 Nov 2025 07:49:01 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race In-Reply-To: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> Message-ID: On Thu, 6 Nov 2025 11:35:50 GMT, Erik ?sterlund wrote: > C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. > > When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. > > ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. > > Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. > > However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. > > This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. > > If the guard check is performed before the handshake, then the JIT-compiled code will continue to execute past the code that as... Looks good. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28176#pullrequestreview-3432103152 From eosterlund at openjdk.org Fri Nov 7 10:06:07 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 10:06:07 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate In-Reply-To: References: Message-ID: <0vZkNbNauyjyK-izAJVSuCuUf4JHKxvC6f1AV0Tn7l8=.07818bbd-b4f8-4f38-b672-555156941b67@github.com> On Fri, 7 Nov 2025 07:18:42 GMT, Axel Boldt-Christmas wrote: >> Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. >> >> Test: tie1-5 > > src/hotspot/share/gc/parallel/psOldGen.cpp line 121: > >> 119: >> 120: HeapWord* PSOldGen::expand_and_allocate(size_t word_size) { >> 121: assert(Heap_lock->is_locked(), "precondition"); > > Are these methods fine to call from a non safepoint after we have started the GC? If they are not. We should not loosen the precondition this much. > > Suggestion: > > precond(Heap_lock->is_locked()); > precond(!is_init_completed() || SafepointSynchronize::is_at_safepoint()); > precond(!is_init_completed() || Thread::current()->is_VM_thread()); While it's true the assert is more loose than it needs to be, if we want the tighter assert here, then we should probably use that tighter assert in all the other places that were loosened too. If we want to do that, could we do that in a follow-up PR instead? I have done pre-integration testing with the object streaming JEP with the changes here, and if we poke around at the asserts again, I'm gonna have to re-run the tests again before integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28162#discussion_r2502517823 From ayang at openjdk.org Fri Nov 7 10:24:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 7 Nov 2025 10:24:37 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate [v2] In-Reply-To: References: Message-ID: > Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. > > Edit: > Additionally, the call `needs_expand` is updated to accommodate two different paths where it can't be invoked. > > Test: tie1-5 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28162/files - new: https://git.openjdk.org/jdk/pull/28162/files/c0f6ff5c..0cfb105c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28162&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28162&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28162/head:pull/28162 PR: https://git.openjdk.org/jdk/pull/28162 From eosterlund at openjdk.org Fri Nov 7 10:24:37 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 10:24:37 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate [v2] In-Reply-To: References: Message-ID: <1se7AdJ0ocPaDpaDN8l5SIR1Hcq-W2eK1u-Y00kfx8M=.2acac0b8-dd2f-4a6e-8453-5798082d21f6@github.com> On Fri, 7 Nov 2025 10:21:10 GMT, Albert Mingkun Yang wrote: >> Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. >> >> Edit: >> Additionally, the call `needs_expand` is updated to accommodate two different paths where it can't be invoked. >> >> Test: tie1-5 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28162#pullrequestreview-3432835520 From ayang at openjdk.org Fri Nov 7 10:24:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 7 Nov 2025 10:24:39 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate [v2] In-Reply-To: <0vZkNbNauyjyK-izAJVSuCuUf4JHKxvC6f1AV0Tn7l8=.07818bbd-b4f8-4f38-b672-555156941b67@github.com> References: <0vZkNbNauyjyK-izAJVSuCuUf4JHKxvC6f1AV0Tn7l8=.07818bbd-b4f8-4f38-b672-555156941b67@github.com> Message-ID: <7vPF8ELrfoolxnOjrn-iVWQVEowwQ44W4NyPAtaKfEw=.9457751c-c834-471e-8fd6-e7f1da73aaae@github.com> On Fri, 7 Nov 2025 10:03:01 GMT, Erik ?sterlund wrote: > If we want to do that, could we do that in a follow-up PR instead? Created a followup ticket: https://bugs.openjdk.org/browse/JDK-8371465 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28162#discussion_r2502576573 From fandreuzzi at openjdk.org Fri Nov 7 10:36:02 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 7 Nov 2025 10:36:02 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 10:24:37 GMT, Albert Mingkun Yang wrote: >> Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. >> >> Edit: >> Additionally, the call `needs_expand` is updated to accommodate two different paths where it can't be invoked. >> >> Test: tie1-5 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28162#pullrequestreview-3432933729 From ayang at openjdk.org Fri Nov 7 10:51:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 7 Nov 2025 10:51:12 GMT Subject: RFR: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 10:24:37 GMT, Albert Mingkun Yang wrote: >> Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. >> >> Edit: >> Additionally, the call `needs_expand` is updated to accommodate two different paths where it can't be invoked. >> >> Test: tie1-5 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28162#issuecomment-3501827232 From ayang at openjdk.org Fri Nov 7 10:51:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 7 Nov 2025 10:51:13 GMT Subject: Integrated: 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate In-Reply-To: References: Message-ID: <8WQkqM_bUIxDVkZl-YC5ngz-kbwl9lhmmcvbsbxqpXw=.9049c800-195e-42a1-a4ac-a5923569835e@github.com> On Wed, 5 Nov 2025 19:29:13 GMT, Albert Mingkun Yang wrote: > Use more precise precondition for heap/old-gen expansion; the same precondition is also used in its sole caller. > > Edit: > Additionally, the call `needs_expand` is updated to accommodate two different paths where it can't be invoked. > > Test: tie1-5 This pull request has now been integrated. Changeset: 167c952b Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/167c952bb0fefb5acc9782f4f4474d92097c93f8 Stats: 8 lines in 2 files changed: 0 ins; 1 del; 7 mod 8371369: Parallel: Relax precondition of PSOldGen::expand_and_allocate Reviewed-by: eosterlund, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/28162 From ayang at openjdk.org Fri Nov 7 12:04:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 7 Nov 2025 12:04:14 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 10:33:46 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 357: > 355: return humongous_obj_size_in_regions(allocation_word_size) * G1HeapRegion::GrainBytes; > 356: } else { > 357: return allocation_word_size; Shouldn't this be converted to bytes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2503117680 From tschatzl at openjdk.org Fri Nov 7 14:32:38 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 7 Nov 2025 14:32:38 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang review, missing conversion of word size to byte size ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28175/files - new: https://git.openjdk.org/jdk/pull/28175/files/9eea555d..5b00c3a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From kdnilsen at openjdk.org Fri Nov 7 18:25:37 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 7 Nov 2025 18:25:37 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v8] In-Reply-To: References: Message-ID: <6QHIbCuNkwTlUX2e3kjvaQF0G6WjJSQbP0bmqLtoYXQ=.1b42521a-eff2-4eab-834b-97c9dc537f2b@github.com> > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: consider last_relevant_card in determining right-most address ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/637c1775..0e2120b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From xpeng at openjdk.org Fri Nov 7 19:42:31 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 19:42:31 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v10] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 144 commits: - Merge branch 'openjdk:master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - Remove unnecessary fences - tidy up - Remove ShenandoahDirectAllocationMaxProbes, simplifications - Set region back to empty and unaffiliated when release a directly allocatable region(may happen in full GC) - Add assert back - Address test failures after merging the change from master which unify the accounting in FreeSet and ShenandoahGeneration - Merge remote-tracking branch 'origin/master' into cas-alloc-1 - Merge branch 'openjdk:master' into cas-alloc-1 - ... and 134 more: https://git.openjdk.org/jdk/compare/2c3c4707...69aec972 ------------- Changes: https://git.openjdk.org/jdk/pull/26171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=09 Stats: 767 lines in 17 files changed: 677 ins; 23 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From xpeng at openjdk.org Fri Nov 7 19:42:31 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 19:42:31 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: <5YSA3F88CmDDv09M2KOm_EFNDh_09LPO2WMrgETfupI=.cc658dc9-829e-41a5-ad76-393d3eb0f75a@github.com> References: <5YSA3F88CmDDv09M2KOm_EFNDh_09LPO2WMrgETfupI=.cc658dc9-829e-41a5-ad76-393d3eb0f75a@github.com> Message-ID: On Wed, 5 Nov 2025 19:00:37 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 848: >> >>> 846: HeapWord* ShenandoahFreeSet::allocate_with_affiliation(Iter& iterator, ShenandoahAffiliation affiliation, ShenandoahAllocRequest& req, bool& in_new_region) { >>> 847: for (idx_t idx = iterator.current(); iterator.has_next(); idx = iterator.next()) { >>> 848: ShenandoahHeapRegion* r = _heap->get_region(idx); >> >> I wonder if we could refine this a little bit. When the region is moved into the "directly allocatable" set, wouldn't we remove it from its partition? Then, we wouldn't have to test for !r->reserved_for_direct_allocation() here because the iterator wouldn't produce it. >> >> We could maybe replace this test with an assert that !r->reserved_for_direct_allocation(). > > Same issue in other uses of the allocation iterator. You are right, allocate_with_affiliation is only called from collector, it won't see any regions from Mutator partition, we don't even need to the assert here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2505191139 From xpeng at openjdk.org Fri Nov 7 19:48:13 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 19:48:13 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 19:02:59 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - format >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Merge branch 'master' into cas-alloc-1 >> - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Fix errors caused by renaming ofAtomic to AtomicAccess >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05 > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1268: > >> 1266: // If region is not completely free, the current [beg; end] is useless, and we may fast-forward. If we can extend >> 1267: // the existing range, we can exploit that certain regions are already known to be in the Mutator free set. >> 1268: ShenandoahHeapRegion* region = _heap->get_region(end); > > Here also, if we remove the region from the partition when we make it directly allocatable, we would not need to rewrite this loop. Yes, same as your comment above. Mutator thread shouldn't see any region which has been made directly allocatable in the Mutator partition here. > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2204: > >> 2202: i++; >> 2203: } >> 2204: return obj; > > I think obj always equals nullptr at this point. Seems the code would be easier to understand (and would depend less on effective compiler optimization) if we just made that explicit. Can we just say: > > return nullptr? Yes, it is always `nullptr`, `return nullptr` will make the code more readable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2505212589 PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2505221448 From duke at openjdk.org Fri Nov 7 21:02:34 2025 From: duke at openjdk.org (Nityanand Rai) Date: Fri, 7 Nov 2025 21:02:34 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking Message-ID: Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. ------------- Commit messages: - clean whitespace - minor cleanup - Merge branch 'openjdk:master' into 8371284 - exclude young-yong, old-old and honor UseCondCardMark in dirty card marking Changes: https://git.openjdk.org/jdk/pull/28204/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371284 Stats: 21 lines in 1 file changed: 20 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28204/head:pull/28204 PR: https://git.openjdk.org/jdk/pull/28204 From xpeng at openjdk.org Fri Nov 7 21:06:28 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 7 Nov 2025 21:06:28 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v11] In-Reply-To: References: Message-ID: <6pTKMOkjQwuamgBRyOItAlgwlNQD18aupF0ykkYN3GA=.690dc564-2ce0-4684-9a25-0c7162857167@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request incrementally with four additional commits since the last revision: - Fix wrong asserts - Remove unnecessary test for directly allocable region - Merge branch 'cas-alloc-1' of https://github.com/pengxiaolong/jdk into cas-alloc-1 - tidy up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/69aec972..b1c3b90f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=09-10 Stats: 11 lines in 1 file changed: 1 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From wkemper at openjdk.org Fri Nov 7 21:44:01 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 7 Nov 2025 21:44:01 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 20:42:25 GMT, Nityanand Rai wrote: > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. Let's make sure we don't mark cards for null objects. src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 200: > 198: // Exclude old-old > 199: T heap_oop = RawAccess<>::oop_load(field); > 200: if (!CompressedOops::is_null(heap_oop)) { We can return early if `CompressedOops::is_null` (we don't need to remember old pointers that are null). ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3436538439 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2505630257 From duke at openjdk.org Fri Nov 7 21:51:22 2025 From: duke at openjdk.org (Rui Li) Date: Fri, 7 Nov 2025 21:51:22 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v4] In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } Rui Li has updated the pull request incrementally with one additional commit since the last revision: Bump maxMem to 4g ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28167/files - new: https://git.openjdk.org/jdk/pull/28167/files/3dbe9a10..142d00e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28167&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28167/head:pull/28167 PR: https://git.openjdk.org/jdk/pull/28167 From duke at openjdk.org Fri Nov 7 23:09:47 2025 From: duke at openjdk.org (Nityanand Rai) Date: Fri, 7 Nov 2025 23:09:47 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v2] In-Reply-To: References: Message-ID: > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: early return of oop is null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28204/files - new: https://git.openjdk.org/jdk/pull/28204/files/09ad25ab..59f7a0d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=00-01 Stats: 8 lines in 1 file changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28204/head:pull/28204 PR: https://git.openjdk.org/jdk/pull/28204 From duke at openjdk.org Fri Nov 7 23:09:48 2025 From: duke at openjdk.org (Nityanand Rai) Date: Fri, 7 Nov 2025 23:09:48 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 21:40:38 GMT, William Kemper wrote: >> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: >> >> early return of oop is null > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 200: > >> 198: // Exclude old-old >> 199: T heap_oop = RawAccess<>::oop_load(field); >> 200: if (!CompressedOops::is_null(heap_oop)) { > > We can return early if `CompressedOops::is_null` (we don't need to remember old pointers that are null). Good point, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2505799473 From syan at openjdk.org Sat Nov 8 02:31:03 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 8 Nov 2025 02:31:03 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v4] In-Reply-To: References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Fri, 7 Nov 2025 21:51:22 GMT, Rui Li wrote: >> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. >> >> Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. >> >> Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. >> >> >> >> public class TestLargeObjectAlignmentDeterministic { >> >> static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); >> static final int NODE_COUNT = Integer.getInteger("nodes", 10000); >> static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); >> >> static Object[] objects; >> >> public static void main(String[] args) throws Exception { >> objects = new Object[SLABS_COUNT]; >> >> for (int i = 0; i < SLABS_COUNT; i++) { >> objects[i] = createSome(); >> } >> } >> >> public static Object createSome() { >> List result = new ArrayList(); >> for (int c = 0; c < NODE_COUNT; c++) { >> result.add(new Integer(c)); >> } >> return result; >> } >> >> } > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Bump maxMem to 4g Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28167#pullrequestreview-3437094158 From kdnilsen at openjdk.org Sat Nov 8 19:54:44 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 8 Nov 2025 19:54:44 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v9] In-Reply-To: References: Message-ID: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Refinements and debugging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/0e2120b8..29f5d42c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=07-08 Stats: 46 lines in 4 files changed: 27 ins; 4 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From kdnilsen at openjdk.org Sun Nov 9 16:11:46 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 9 Nov 2025 16:11:46 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v10] In-Reply-To: References: Message-ID: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: fix multiple errors introduced by minor refactoring of API ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/29f5d42c..cee16f88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=08-09 Stats: 16 lines in 4 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From kdnilsen at openjdk.org Sun Nov 9 16:16:25 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sun, 9 Nov 2025 16:16:25 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v11] In-Reply-To: References: Message-ID: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove debug instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/cee16f88..9f629a2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=09-10 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From aboldtch at openjdk.org Mon Nov 10 05:56:12 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 10 Nov 2025 05:56:12 GMT Subject: RFR: 8371343: ZGC: Remove dependency on test execution order for gtests In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:58:56 GMT, Axel Boldt-Christmas wrote: > We currently have a few gtests which are run with the TEST_F macro and use `ZGlobalsPointers::initialize();` which on some platforms may end up doing GC precious logging, which requires the VM (mutexes) to be setup in order to work. Currently the `GTestWrapper.java` succeeds with running these test because we will have run other tests which have setup the VM. > > If a filter is used or the tests are shuffled we can observe that these tests may crash. > > Proposed change is to use the `ZTest` unittest base fixture and run these test with `TEST_VM_F` > > Testing > * GHA > * gtests with and without filter and shuffled test order Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28160#issuecomment-3509535874 From aboldtch at openjdk.org Mon Nov 10 05:56:13 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 10 Nov 2025 05:56:13 GMT Subject: Integrated: 8371343: ZGC: Remove dependency on test execution order for gtests In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:58:56 GMT, Axel Boldt-Christmas wrote: > We currently have a few gtests which are run with the TEST_F macro and use `ZGlobalsPointers::initialize();` which on some platforms may end up doing GC precious logging, which requires the VM (mutexes) to be setup in order to work. Currently the `GTestWrapper.java` succeeds with running these test because we will have run other tests which have setup the VM. > > If a filter is used or the tests are shuffled we can observe that these tests may crash. > > Proposed change is to use the `ZTest` unittest base fixture and run these test with `TEST_VM_F` > > Testing > * GHA > * gtests with and without filter and shuffled test order This pull request has now been integrated. Changeset: 66e5a68a Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/66e5a68a33dcd6b23c73c892d51b3efed162b8f8 Stats: 11 lines in 3 files changed: 0 ins; 4 del; 7 mod 8371343: ZGC: Remove dependency on test execution order for gtests Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/28160 From aboldtch at openjdk.org Mon Nov 10 05:57:13 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 10 Nov 2025 05:57:13 GMT Subject: RFR: 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v5] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 06:49:39 GMT, Axel Boldt-Christmas wrote: >> ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow. >> >> In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve. >> >> Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap). Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step. > > Axel Boldt-Christmas 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 tag 'jdk-26+21' into JDK-8367317 > > Added tag jdk-26+21 for changeset 3e20a939 > - Merge tag 'jdk-26+19' into JDK-8367317 > > Added tag jdk-26+19 for changeset b37a1a33 > - Merge tag 'jdk-26+18' into JDK-8367317 > > Added tag jdk-26+18 for changeset 5251405c > - Merge tag 'jdk-26+17' into JDK-8367317 > > Added tag jdk-26+17 for changeset 2aafda19 > - 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27207#issuecomment-3509534916 From aboldtch at openjdk.org Mon Nov 10 05:57:14 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 10 Nov 2025 05:57:14 GMT Subject: Integrated: 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:12:42 GMT, Axel Boldt-Christmas wrote: > ZVirtualMemoryReserver::force_reserve_discontiguous is a debug only API used to simulate and test a discontinuous heap. The loop variable `end` is incorrectly checked which may lead to an underflow. > > In our normal testing we never observe this as the address space is always available. We observed this issue when running a hardened build (like ASAN) which had already mmapped the address space we tried to reserve. > > Rather than always jump two reserve sizes in its search, it searches every reserve size, moving an extra reserve size every time it succeeds with a reservation (so that there always is a gap). Searching in reserve sized steps is not really a requirement here, we could have just used a granule sized step. This pull request has now been integrated. Changeset: a8b35bf5 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/a8b35bf5a60c26e8975a468d4ebe6aac557e4d85 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8367317: ZGC: ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow Reviewed-by: jsikstro, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/27207 From aboldtch at openjdk.org Mon Nov 10 05:58:16 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 10 Nov 2025 05:58:16 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:58:30 GMT, Axel Boldt-Christmas wrote: > A few ZGC gtest reservers memory in valid ZAddress address ranges to mock and test different sub systems. When running in instrumented builds such as ASAN the address space we try to may be unavailable. This will cause a couple of our tests to fail. > > I propose we change all out gtests to do what `test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp` does. Namely uses our `ZVirtualMemoryManager` to reserve the address space and skip the test incase we are not able to reserve an adequate address range to use for the test. > > * Testing > * GHA > * gtest with and without ASAN, including artificially induced reservation clash with ASAN Thanks for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28159#issuecomment-3509539139 From aboldtch at openjdk.org Mon Nov 10 05:58:17 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 10 Nov 2025 05:58:17 GMT Subject: Integrated: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:58:30 GMT, Axel Boldt-Christmas wrote: > A few ZGC gtest reservers memory in valid ZAddress address ranges to mock and test different sub systems. When running in instrumented builds such as ASAN the address space we try to may be unavailable. This will cause a couple of our tests to fail. > > I propose we change all out gtests to do what `test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp` does. Namely uses our `ZVirtualMemoryManager` to reserve the address space and skip the test incase we are not able to reserve an adequate address range to use for the test. > > * Testing > * GHA > * gtest with and without ASAN, including artificially induced reservation clash with ASAN This pull request has now been integrated. Changeset: 4e4cced7 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/4e4cced710a8e4cd5bb8f49b08798c87b21e8b78 Stats: 138 lines in 5 files changed: 72 ins; 37 del; 29 mod 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/28159 From shade at openjdk.org Mon Nov 10 09:12:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 10 Nov 2025 09:12:04 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v4] In-Reply-To: References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Fri, 7 Nov 2025 21:51:22 GMT, Rui Li wrote: >> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. >> >> Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. >> >> Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. >> >> >> >> public class TestLargeObjectAlignmentDeterministic { >> >> static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); >> static final int NODE_COUNT = Integer.getInteger("nodes", 10000); >> static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); >> >> static Object[] objects; >> >> public static void main(String[] args) throws Exception { >> objects = new Object[SLABS_COUNT]; >> >> for (int i = 0; i < SLABS_COUNT; i++) { >> objects[i] = createSome(); >> } >> } >> >> public static Object createSome() { >> List result = new ArrayList(); >> for (int c = 0; c < NODE_COUNT; c++) { >> result.add(new Integer(c)); >> } >> return result; >> } >> >> } > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Bump maxMem to 4g Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28167#pullrequestreview-3441786698 From sjohanss at openjdk.org Mon Nov 10 10:32:37 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 10 Nov 2025 10:32:37 GMT Subject: RFR: 8371019: G1: Support heap expansion during startup Message-ID: Please review this change to allow G1 to expand the initial heap during startup **Summary** Currently G1 shuts down during startup if we allocate more memory than what's available in the initial young generation. The reason is that we can't allow GCs during initialization. To allow G1 to work in situations requiring additional memory during initialization, this change enables G1 to expand the initial young generation size all the way up the maximum heap size. When initialization is complete mutator allocations will no longer expand the heap. **Testing** * Mach 5 tier1-5 * Manual testing requiring additional allocations during startup ------------- Commit messages: - Thomas feedback - 8371019: G1: Support heap expansion during startup Changes: https://git.openjdk.org/jdk/pull/28213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371019 Stats: 24 lines in 3 files changed: 17 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28213/head:pull/28213 PR: https://git.openjdk.org/jdk/pull/28213 From eosterlund at openjdk.org Mon Nov 10 10:32:38 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 10 Nov 2025 10:32:38 GMT Subject: RFR: 8371019: G1: Support heap expansion during startup In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 09:32:32 GMT, Stefan Johansson wrote: > Please review this change to allow G1 to expand the initial heap during startup > > **Summary** > Currently G1 shuts down during startup if we allocate more memory than what's available in the initial young generation. The reason is that we can't allow GCs during initialization. To allow G1 to work in situations requiring additional memory during initialization, this change enables G1 to expand the initial young generation size all the way up the maximum heap size. When initialization is complete mutator allocations will no longer expand the heap. > > **Testing** > * Mach 5 tier1-5 > * Manual testing requiring additional allocations during startup Thanks for fixing this Stefan! Might have found an assert issue. I see now how the assert works: it only checks for the VM thread if not owning the heap lock, so I think it won't be an issue. Looks good. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3107: > 3105: G1HeapRegion* new_alloc_region = new_region(word_size, > 3106: G1HeapRegionType::Eden, > 3107: policy()->should_expand_on_mutator_allocation() /* do_expand */, On line 3102 above, there is an assert looking like this: ```assert_heap_locked_or_at_safepoint(true /* should_be_vm_thread */);``` The assumption seems to be that this is the VM thread. That won't be the case when exapnding from a mutator, right? ------------- Changes requested by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28213#pullrequestreview-3442142270 Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28213#pullrequestreview-3442232032 PR Review Comment: https://git.openjdk.org/jdk/pull/28213#discussion_r2509693488 From shade at openjdk.org Mon Nov 10 11:43:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 10 Nov 2025 11:43:04 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 23:09:47 GMT, Nityanand Rai wrote: >> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > early return of oop is null Generally looks fine, just tighten up the comments. src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 197: > 195: if (_heap->is_in_young(field)) { > 196: return; > 197: } Suggestion: if (_heap->is_in_young(field)) { // Young field stores do not require card mark. return; } src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 206: > 204: if (!_heap->is_in_young(obj)) { > 205: return; > 206: } Suggestion: if (!_heap->is_in_young(obj)) { // Young object -> old field stores do not require card mark. return; } src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 207: > 205: return; > 206: } > 207: // Honor UseCondCardMark: check if card is already dirty before writing Suggestion: ------------- PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3442710354 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2510147860 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2510152910 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2510153202 From tschatzl at openjdk.org Mon Nov 10 13:40:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 10 Nov 2025 13:40:10 GMT Subject: RFR: 8371019: G1: Support heap expansion during startup In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 09:32:32 GMT, Stefan Johansson wrote: > Please review this change to allow G1 to expand the initial heap during startup > > **Summary** > Currently G1 shuts down during startup if we allocate more memory than what's available in the initial young generation. The reason is that we can't allow GCs during initialization. To allow G1 to work in situations requiring additional memory during initialization, this change enables G1 to expand the initial young generation size all the way up the maximum heap size. When initialization is complete mutator allocations will no longer expand the heap. > > **Testing** > * Mach 5 tier1-5 > * Manual testing requiring additional allocations during startup Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28213#pullrequestreview-3443301903 From tschatzl at openjdk.org Mon Nov 10 13:47:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 10 Nov 2025 13:47:20 GMT Subject: RFR: 8371321: Remove unused last arg of BarrierSetAssembler::arraycopy_epilogue In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 10:10:02 GMT, Albert Mingkun Yang wrote: > Removing effectively dead code. > > Test: tier1, GHA Looks good. Thanks for cleaning this up. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28146#pullrequestreview-3443342641 From ayang at openjdk.org Mon Nov 10 14:29:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 10 Nov 2025 14:29:56 GMT Subject: RFR: 8371321: Remove unused last arg of BarrierSetAssembler::arraycopy_epilogue In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 10:10:02 GMT, Albert Mingkun Yang wrote: > Removing effectively dead code. > > Test: tier1, GHA Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28146#issuecomment-3512011561 From kdnilsen at openjdk.org Mon Nov 10 14:31:08 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 14:31:08 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: On Fri, 3 Oct 2025 20:49:01 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 251: > >> 249: // if marking context is valid and we are below tams, we use the marking bit map to find the first marked object that >> 250: // intersects with this card, and if no such object exists, we return null >> 251: if ((ctx != nullptr) && (left < tams)) { > > It seems like the caller should check if `left >= tams` and short-circuit rather than have this method do that work. That comment is wrong, which is what caused you to request the alternative semantics for this function. Your comments and questions motivated me to rewrite the comments describing the behavior of this function. Rewriting the comments helped me realize the API was a bit ill-defined. I made some improvements to the behavior so that the definition could be more clearly defined. The new implementation now passes all tests again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2510782671 From ayang at openjdk.org Mon Nov 10 14:32:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 10 Nov 2025 14:32:20 GMT Subject: Integrated: 8371321: Remove unused last arg of BarrierSetAssembler::arraycopy_epilogue In-Reply-To: References: Message-ID: <3MvmZGPFXA7cqYhLs44MVY_P3BFyuUh4y5mlSWbGUxA=.d2d98f00-d991-43cd-8dd1-7d5d96c4031c@github.com> On Wed, 5 Nov 2025 10:10:02 GMT, Albert Mingkun Yang wrote: > Removing effectively dead code. > > Test: tier1, GHA This pull request has now been integrated. Changeset: 9d2fa8fe Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/9d2fa8fe22652cbf1c70b953247bd154b363b383 Stats: 38 lines in 16 files changed: 0 ins; 6 del; 32 mod 8371321: Remove unused last arg of BarrierSetAssembler::arraycopy_epilogue Reviewed-by: fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28146 From kdnilsen at openjdk.org Mon Nov 10 14:39:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 14:39:09 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v13] In-Reply-To: References: Message-ID: > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: - Fix mistaken merge resolution - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates The resulting fastdebug build has 64 failures. I need to debug these. Probably introduced by improper resolution of merge conflicts - fix error in merge conflict resolution - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates - rework CompressedClassSpaceSizeinJmapHeap.java - fix errors in CompressedClassSpaceSizeInJmapHeap.java - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java - fix two indexing bugs - add an assert to detect suspected bug - Remove debug scaffolding - ... and 48 more: https://git.openjdk.org/jdk/compare/c272aca8...16cd6f8a ------------- Changes: https://git.openjdk.org/jdk/pull/24319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=12 Stats: 284 lines in 31 files changed: 115 ins; 30 del; 139 mod Patch: https://git.openjdk.org/jdk/pull/24319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319 PR: https://git.openjdk.org/jdk/pull/24319 From kdnilsen at openjdk.org Mon Nov 10 14:39:12 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 14:39:12 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v12] In-Reply-To: <2yyHGosCQCiu03jYG7lG82_2WrppAZqVQgDATo8bcfQ=.9c8bed3d-980f-499f-a467-a5cd1d90b6b8@github.com> References: <2yyHGosCQCiu03jYG7lG82_2WrppAZqVQgDATo8bcfQ=.9c8bed3d-980f-499f-a467-a5cd1d90b6b8@github.com> Message-ID: On Mon, 13 Oct 2025 22:18:38 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits: > > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - remove _mixed_candidate_garbage_words from ShenandoahHeapRegion > - reviewer feedback to reduce code duplication > - Fix compilation errors after merge > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - Fix uninitialized variable > - Remove deprecation conditional compiles > - Adjust candidate live memory for each mixed evac > - Refactor for better abstraction > - Fix set_live() after full gc > - ... and 35 more: https://git.openjdk.org/jdk/compare/92f2ab2e...24322e75 I'm going to place this in draft while I experiment with the code to diagnose apparent regressions with traditional shenandoah mode. I have placed instrumentation into the code to confirm that the live_data reported by ShenandoahHeapRegion is the same before and after this PR for traditional Shenandoah mode. So the regressions are either "signal noise", or perhaps inefficiencies introduced regarding how we compute the live_data. After refactoring the code to perform better in the "tight" rebuild free-set and build-collection set loops, the Shenandoah results show very slight improvement (rather than regression) on specjbb2015. Here is the performance regression that we saw before commit https://github.com/openjdk/jdk/pull/24319/commits/ecdec6363ee9e0a27f4207350cf0b51f8c99bab5 image Here are comparisons (in a slightly different environment) after that same commit: image ------------- PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3401760959 PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3416424293 PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3453055680 From kdnilsen at openjdk.org Mon Nov 10 15:37:59 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 15:37:59 GMT Subject: RFR: 8371573: Shenandoah: Fix style of include directive Message-ID: Fix style of include directive for improved consistency and compatibility with GraalVM conventions. ------------- Commit messages: - Fix style of include directive Changes: https://git.openjdk.org/jdk/pull/28219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28219&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371573 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28219/head:pull/28219 PR: https://git.openjdk.org/jdk/pull/28219 From wkemper at openjdk.org Mon Nov 10 15:45:55 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 10 Nov 2025 15:45:55 GMT Subject: RFR: 8371573: Shenandoah: Fix style of include directive In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 15:32:03 GMT, Kelvin Nilsen wrote: > Fix style of include directive for improved consistency and compatibility with GraalVM conventions. This include looks vestigial. Can we just delete it? ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28219#pullrequestreview-3443924743 From kdnilsen at openjdk.org Mon Nov 10 15:55:12 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 15:55:12 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v2] In-Reply-To: References: Message-ID: <_3OuNx5vGJMp_kP0hRZgLvkJgOUXuKVpJZ8ores0H-8=.3ca53897-5f22-4d1c-b3e6-a8e71422612a@github.com> On Sat, 31 May 2025 02:53:52 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision: >> >> - respond to reviewer feedback >> - Keep gc cycle times with heuristics for the relevant generation > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 183: > >> 181: } >> 182: >> 183: heap->young_generation()->set_evacuation_reserve((size_t) (young_evac_bytes * ShenandoahEvacWaste)); > > So we are using the amount to be evacuated out of young (suitably marked up to account for waste) from the collection set of a specific cycle to predict the same for the next cycle? And similarly for the promotion bytes. > > This seems reasonable, but how does that compare with using the live data identified in the most recent marking cycle instead? I can imagine that the former is more accurate under steady state assumptions and the latter is an overestimate to the extent that not all live data will be evacuated because it's in mostly live, i.e. densely live regions. However, it would be interesting to see how they compare and which tracks reality better. Since this is in the nature of a prediction/estimate, once can consider a control algorithm that tries to move the estimate closer based on minimizing some historical deviation between marked vs evacuated. > > This need not be done here, but can be considered a future enhancement/experiment. These reserves are applied to the current cycle, as we are about to begin evacuation and we need to know how much memory will be consumed in old and young during this cycle. The promo budget helps assure that overly aggressive promotions do not cause mixed evacuations to fail (by consuming memory that should have been set aside to hold the mixed evacuations). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2511095501 From kdnilsen at openjdk.org Mon Nov 10 16:02:53 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 16:02:53 GMT Subject: RFR: 8371573: Shenandoah: Fix style of include directive [v2] In-Reply-To: References: Message-ID: > Fix style of include directive for improved consistency and compatibility with GraalVM conventions. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28219/files - new: https://git.openjdk.org/jdk/pull/28219/files/2d926fb9..5c95f64e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28219&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28219&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28219/head:pull/28219 PR: https://git.openjdk.org/jdk/pull/28219 From kdnilsen at openjdk.org Mon Nov 10 16:02:55 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 16:02:55 GMT Subject: RFR: 8371573: Shenandoah: Fix style of include directive [v2] In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 15:42:48 GMT, William Kemper wrote: > This include looks vestigial. Can we just delete it? Good catch. I'll make that change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28219#issuecomment-3512565592 From shade at openjdk.org Mon Nov 10 16:14:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 10 Nov 2025 16:14:52 GMT Subject: RFR: 8371573: Shenandoah: Fix style of include directive [v2] In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 16:02:53 GMT, Kelvin Nilsen wrote: >> Fix style of include directive for improved consistency and compatibility with GraalVM conventions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded include This looks fine, but I adjusted the bug title, so PR title also needs adjustments to match it. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28219#pullrequestreview-3444057242 From shade at openjdk.org Mon Nov 10 16:17:59 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 10 Nov 2025 16:17:59 GMT Subject: RFR: 8371573: Shenandoah: Fix style of include directive [v2] In-Reply-To: References: Message-ID: <-l0j28TqIU6ZzR3kr2cWYz4fudPVzcDof9FW5pG0QWg=.864b9f00-8bbc-4aee-a6f0-14a8a7fe74ec@github.com> On Mon, 10 Nov 2025 16:02:53 GMT, Kelvin Nilsen wrote: >> Fix style of include directive for improved consistency and compatibility with GraalVM conventions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded include I also think it is trivial, so you can integrate as soon as testing is green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28219#issuecomment-3512640187 From wkemper at openjdk.org Mon Nov 10 18:38:29 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 10 Nov 2025 18:38:29 GMT Subject: RFR: 8371573: Shenandoah: Remove unnecessary include after JDK-8351091 [v2] In-Reply-To: References: Message-ID: <-LZ5OLqGd10veGNlWuFRxHOPcRWvmW1KtEwSolAs-pI=.b6870b16-2c58-4ee8-bdae-9be8d64ddb35@github.com> On Mon, 10 Nov 2025 16:02:53 GMT, Kelvin Nilsen wrote: >> Fix style of include directive for improved consistency and compatibility with GraalVM conventions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded include Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28219#pullrequestreview-3444620341 From kdnilsen at openjdk.org Mon Nov 10 18:54:44 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 18:54:44 GMT Subject: Integrated: 8371573: Shenandoah: Remove unnecessary include after JDK-8351091 In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 15:32:03 GMT, Kelvin Nilsen wrote: > Fix style of include directive for improved consistency and compatibility with GraalVM conventions. This pull request has now been integrated. Changeset: 43afce54 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/43afce54a7ecbd124f68f1f32d718f08b24ca61a Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8371573: Shenandoah: Remove unnecessary include after JDK-8351091 Reviewed-by: wkemper, shade ------------- PR: https://git.openjdk.org/jdk/pull/28219 From duke at openjdk.org Mon Nov 10 19:10:46 2025 From: duke at openjdk.org (duke) Date: Mon, 10 Nov 2025 19:10:46 GMT Subject: RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space [v4] In-Reply-To: References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Fri, 7 Nov 2025 21:51:22 GMT, Rui Li wrote: >> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. >> >> Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. >> >> Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. >> >> >> >> public class TestLargeObjectAlignmentDeterministic { >> >> static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); >> static final int NODE_COUNT = Integer.getInteger("nodes", 10000); >> static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); >> >> static Object[] objects; >> >> public static void main(String[] args) throws Exception { >> objects = new Object[SLABS_COUNT]; >> >> for (int i = 0; i < SLABS_COUNT; i++) { >> objects[i] = createSome(); >> } >> } >> >> public static Object createSome() { >> List result = new ArrayList(); >> for (int c = 0; c < NODE_COUNT; c++) { >> result.add(new Integer(c)); >> } >> return result; >> } >> >> } > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Bump maxMem to 4g @rgithubli Your change (at version 142d00e2d5a0f4ea61348551971272aa756b6727) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28167#issuecomment-3513472725 From wkemper at openjdk.org Mon Nov 10 21:57:11 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 10 Nov 2025 21:57:11 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v13] In-Reply-To: References: Message-ID: <7ReicCCT86J3wPR8FzTdOfaKOvxYbj1dhXNkbDNvduU=.b178f2f0-a241-46a2-a201-cc5394706621@github.com> On Mon, 10 Nov 2025 14:39:09 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: > > - Fix mistaken merge resolution > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > > The resulting fastdebug build has 64 failures. I need to debug these. > Probably introduced by improper resolution of merge conflicts > - fix error in merge conflict resolution > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - rework CompressedClassSpaceSizeinJmapHeap.java > - fix errors in CompressedClassSpaceSizeInJmapHeap.java > - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java > - fix two indexing bugs > - add an assert to detect suspected bug > - Remove debug scaffolding > - ... and 48 more: https://git.openjdk.org/jdk/compare/c272aca8...16cd6f8a Changes requested by wkemper (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 165: > 163: } > 164: > 165: inline size_t ShenandoahHeapRegion::get_live_data_words(ShenandoahMarkingContext* ctx, size_t index) const { Why do we want to change this signature? If `index` is always `this->_index` why go through the trouble to pass a member field to a member function on the same instance? I have a similar sentiment about passing `ShenandoahMarkingContext` through the function. Should we have a member `ShenandoahMarkingContext* _marking_context`? Changing this signature creates a lot of noise on the PR and it's not clear to me why we would do this. ------------- PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3445303571 PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2512084103 From kdnilsen at openjdk.org Mon Nov 10 21:58:02 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 21:58:02 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 20:52:11 GMT, William Kemper wrote: > When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 413: > 411: } > 412: shenandoah_assert_forwarded_except(elem_ptr, obj, _heap->cancelled_gc()); > 413: ShenandoahHeap::atomic_update_oop(fwd, elem_ptr, o); Is the comment at the start of arraycopy_work() still relevant? The description of the PR suggests that we will no longer call arraycopy_work() twice, but I'm not sure I fully understand the context of that statement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28183#discussion_r2512087213 From xpeng at openjdk.org Mon Nov 10 22:11:04 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 10 Nov 2025 22:11:04 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v12] In-Reply-To: References: Message-ID: <_eaC5_CJvs4AFnvs2M71p2oc6z-qUAXDZTcIFRR0o60=.5e6cb939-5422-46e2-89ff-f18ea51c1504@github.com> > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Remove ShenandoahDirectlyAllocatableRegionAffinity and simply use thread local instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/b1c3b90f..f3fa45c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=10-11 Stats: 75 lines in 2 files changed: 8 ins; 65 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From wkemper at openjdk.org Mon Nov 10 23:20:03 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 10 Nov 2025 23:20:03 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements In-Reply-To: References: Message-ID: <3QMYD6Upsc5-r4-RGS320hbSFc250n5p-YJRAgOOktQ=.5e440d61-3da8-42ff-9e7c-e3d57bbcc426@github.com> On Mon, 10 Nov 2025 21:55:37 GMT, Kelvin Nilsen wrote: >> When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 413: > >> 411: } >> 412: shenandoah_assert_forwarded_except(elem_ptr, obj, _heap->cancelled_gc()); >> 413: ShenandoahHeap::atomic_update_oop(fwd, elem_ptr, o); > > Is the comment at the start of arraycopy_work() still relevant? The description of the PR suggests that we will no longer call arraycopy_work() twice, but I'm not sure I fully understand the context of that statement. We used to call this twice (as `arraycopy_marking` _for each object_ if young and old marking were both in progress.. The comment at the start is trying to explain how the `arraycopy_work` could be called with different template parameters depending on the `gc_state`. It is confusingly worded, but I believe the comment is correct and the code is wrong here. The way the code is in the PR, it would effectively turn off the old SATB during young evacuation and young update-refs, which is not what we want. Good catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28183#discussion_r2512294938 From kdnilsen at openjdk.org Mon Nov 10 23:20:06 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 23:20:06 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: <6Z8jobEfFtS_xAGN4C_C0dtjfHvwFbmgbp2pDKyGewY=.c5964096-3c8b-42cb-b121-9cbe54fa30da@github.com> On Fri, 3 Oct 2025 20:15:16 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 180: > >> 178: const HeapWord* limit) const; >> 179: >> 180: // Return the last marked address in the range [limit, addr], or addr+1 if none found. > > Symmetry would have preferred `(limit, addr]` as the range with `limit` if none found. > However, may be usage of this method prefers the present shape? Yeah. The reason for the asymmetry is that forward-looking limit may not be a legitimate address (may be end of heap), whereas backward looking limit is a legitimate address. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512294911 From kdnilsen at openjdk.org Mon Nov 10 23:33:07 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 23:33:07 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: On Fri, 3 Oct 2025 20:16:50 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 129: > >> 127: inline idx_t get_prev_bit_impl(idx_t l_index, idx_t r_index) const; >> 128: >> 129: inline idx_t get_next_one_offset(idx_t l_index, idx_t r_index) const; > > Please document analogous to line 131. Sorry. I overlooked this request in prior response. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512315966 From duke at openjdk.org Mon Nov 10 23:33:21 2025 From: duke at openjdk.org (Nityanand Rai) Date: Mon, 10 Nov 2025 23:33:21 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v3] In-Reply-To: References: Message-ID: <-0iMsHeZnk_Ld_6D9zCBNFVcXi9rIq9S0NmmYEgqb0I=.ffb1591a-83a7-47be-86ff-a5646b51e3e1@github.com> > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Aleksey Shipil?v ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28204/files - new: https://git.openjdk.org/jdk/pull/28204/files/59f7a0d0..1c85da72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28204/head:pull/28204 PR: https://git.openjdk.org/jdk/pull/28204 From kdnilsen at openjdk.org Mon Nov 10 23:45:39 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 23:45:39 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v12] In-Reply-To: References: Message-ID: <3LPIbWVGQhvFzoPWfZEVXdj8N-6bm_x3rqat4nZfKxY=.fd6e8854-3da1-4e6e-a7b8-2fdc4e8b1bb6@github.com> > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Add two comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/9f629a2a..2dc7e98d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=10-11 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From kdnilsen at openjdk.org Mon Nov 10 23:45:41 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 10 Nov 2025 23:45:41 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: <6EUEYLYHG_8Ha50jFIm1KfbEE-hSCfyMRyC8BhlfLmM=.b1407843-9d56-4dad-9693-8937d814fa51@github.com> On Fri, 3 Oct 2025 20:18:46 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 131: > >> 129: inline idx_t get_next_one_offset(idx_t l_index, idx_t r_index) const; >> 130: >> 131: // Search for last one in the range [l_index, r_index). Return r_index if not found. > > Symmetry arguments wrt spec for `get_next_one_offset` may have preferred range `(l_index, r_index]`, returning `l_index` if none found. May be its (transitive) usage prefers this shape? (See similar comment at line 180.) See comment above regarding asymmetry. It is by design, due to shape of the data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512329320 From wkemper at openjdk.org Mon Nov 10 23:59:33 2025 From: wkemper at openjdk.org (William Kemper) Date: Mon, 10 Nov 2025 23:59:33 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v2] In-Reply-To: References: Message-ID: > When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. William Kemper has updated the pull request incrementally with two additional commits since the last revision: - SATB barrier for old must be independent of young collection gc state - We can also filter out old when striclty marking young ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28183/files - new: https://git.openjdk.org/jdk/pull/28183/files/3086fd30..ddd3d6d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28183&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28183&range=00-01 Stats: 67 lines in 5 files changed: 43 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/28183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28183/head:pull/28183 PR: https://git.openjdk.org/jdk/pull/28183 From wkemper at openjdk.org Tue Nov 11 00:33:36 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 11 Nov 2025 00:33:36 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: References: Message-ID: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> > When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Revert "We can also filter out old when striclty marking young" This reverts commit c53c4f23f4401785e1049494b6c4e4b92f9a5701. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28183/files - new: https://git.openjdk.org/jdk/pull/28183/files/ddd3d6d9..ba71462d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28183&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28183&range=01-02 Stats: 49 lines in 3 files changed: 0 ins; 34 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/28183.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28183/head:pull/28183 PR: https://git.openjdk.org/jdk/pull/28183 From xpeng at openjdk.org Tue Nov 11 00:58:47 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 11 Nov 2025 00:58:47 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v13] In-Reply-To: References: Message-ID: > Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works: > * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array). > * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive directly allocatable regions in the array storing directly allocatable region. > * If mutator thread fails after trying 3 directly allocatable regions, it will: > * Take heap lock > * Try to retire the directly allocatable regions which are ready to retire. > * Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired. > * Satisfy mutator allocation request if possible. > > > I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them: > > 1. Dacapo lusearch test on EC2 host with 96 CPU cores: > Openjdk TIP: > > [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar -n 10 lusearch | grep "metered full smoothing" > ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events ===== > ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Renaming directly allocatable region to alloc region ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26171/files - new: https://git.openjdk.org/jdk/pull/26171/files/f3fa45c6..67414bba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=11-12 Stats: 74 lines in 12 files changed: 0 ins; 0 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/26171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171 PR: https://git.openjdk.org/jdk/pull/26171 From duke at openjdk.org Tue Nov 11 03:38:11 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 11 Nov 2025 03:38:11 GMT Subject: Integrated: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space In-Reply-To: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> References: <4hAMzlEVTLb91k4l8Hd2ysUFx7FEe2erCAB_ReeHU2E=.9cae38e5-261a-499f-aee9-770775c02708@github.com> Message-ID: On Thu, 6 Nov 2025 00:21:55 GMT, Rui Li wrote: > Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had. > > Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise. > > Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random. > > > > public class TestLargeObjectAlignmentDeterministic { > > static final int SLABS_COUNT = Integer.getInteger("slabs", 10000); > static final int NODE_COUNT = Integer.getInteger("nodes", 10000); > static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000); > > static Object[] objects; > > public static void main(String[] args) throws Exception { > objects = new Object[SLABS_COUNT]; > > for (int i = 0; i < SLABS_COUNT; i++) { > objects[i] = createSome(); > } > } > > public static Object createSome() { > List result = new ArrayList(); > for (int c = 0; c < NODE_COUNT; c++) { > result.add(new Integer(c)); > } > return result; > } > > } This pull request has now been integrated. Changeset: e1c95260 Author: Rui Li Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/e1c952608d61c6c74c3fa4d00789390f3a789de4 Stats: 11 lines in 1 file changed: 2 ins; 1 del; 8 mod 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space Reviewed-by: shade, syan ------------- PR: https://git.openjdk.org/jdk/pull/28167 From lmesnik at openjdk.org Tue Nov 11 03:58:21 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 03:58:21 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence Message-ID: Please review following fix that move GC shutdown start after VM Death and agent's unloading. The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. ------------- Commit messages: - 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence Changes: https://git.openjdk.org/jdk/pull/28227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367902 Stats: 148 lines in 3 files changed: 145 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28227/head:pull/28227 PR: https://git.openjdk.org/jdk/pull/28227 From shade at openjdk.org Tue Nov 11 09:41:03 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 11 Nov 2025 09:41:03 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v3] In-Reply-To: <-0iMsHeZnk_Ld_6D9zCBNFVcXi9rIq9S0NmmYEgqb0I=.ffb1591a-83a7-47be-86ff-a5646b51e3e1@github.com> References: <-0iMsHeZnk_Ld_6D9zCBNFVcXi9rIq9S0NmmYEgqb0I=.ffb1591a-83a7-47be-86ff-a5646b51e3e1@github.com> Message-ID: On Mon, 10 Nov 2025 23:33:21 GMT, Nityanand Rai wrote: >> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Aleksey Shipil?v Looks fine. How's performance? I suppose this is a frequent path, and `is_in_young` checks are not necessarily free. ------------- PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3447143143 From iwalulya at openjdk.org Tue Nov 11 09:55:15 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 11 Nov 2025 09:55:15 GMT Subject: RFR: 8371625: G1: G1HeapRegion::print_on misalignment Message-ID: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> Hi, Please review this fix to a misalignment in G1HeapRegion::print_on. Additionally, increased the field width for `hrm_index` as this also causes misalignment on large heaps. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/28229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371625 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28229.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28229/head:pull/28229 PR: https://git.openjdk.org/jdk/pull/28229 From ayang at openjdk.org Tue Nov 11 10:06:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 11 Nov 2025 10:06:14 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence In-Reply-To: References: Message-ID: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com> On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik wrote: > move GC shutdown start after VM Death and agent's unloading Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)? (The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3515988219 From stefank at openjdk.org Tue Nov 11 10:25:43 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 11 Nov 2025 10:25:43 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence In-Reply-To: References: Message-ID: <0QVCSBQR8WrlEi7MbVIPpwgk5ndxBkTi7i-uK2z8P9U=.b105574d-980d-4303-9186-fece5e73f94d@github.com> On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik wrote: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. I agree with Albert. I would prefer a patch that moves the JVMTI code instead. This is also what I've tested through tier1-8 in my queue of patches to clean up some of the shutdown code: https://github.com/stefank/jdk/tree/remove_2s_shutdown_workaround ------------- PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3516108702 From jsjolen at openjdk.org Tue Nov 11 10:52:18 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 11 Nov 2025 10:52:18 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Thu, 30 Oct 2025 12:06:00 GMT, Afshin Zafari wrote: >> The issue happens when the HeapMinBaseAddress option gets 0 as input value. Since this option is used as an address, then using 0 in pointer arithmetics is UB. >> The fix is using `unitptr_t` instead of `address`/`char*`, etc. In doing that, it is found that an overflow check does not work in all cases due to checking more conditions. That overflow check is changed too. We also need to check overflow after aligning addresses and sizes of memory regions in this context. Assertions are added to check these cases. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix arguments.cpp for HeapMinBaseAddress type. Seems correct, LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3447447381 From ayang at openjdk.org Tue Nov 11 11:15:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 11 Nov 2025 11:15:10 GMT Subject: RFR: 8371625: G1: G1HeapRegion::print_on misalignment In-Reply-To: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> References: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> Message-ID: On Tue, 11 Nov 2025 09:45:25 GMT, Ivan Walulya wrote: > Hi, > > Please review this fix to a misalignment in G1HeapRegion::print_on. Additionally, increased the field width for `hrm_index` as this also causes misalignment on large heaps. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28229#pullrequestreview-3447532848 From ayang at openjdk.org Tue Nov 11 11:15:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 11 Nov 2025 11:15:12 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 14:32:38 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review, missing conversion of word size to byte size > previously IHOP logging used to report G1CollectedHeap::used() as occupancy (which is correct at a general level) Instead of passing the pending-allocation-size as an arg, what do you think of adding a new API, `used_with_pending_allocation`, which is used when pending-alloc is also interesting to the caller? src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 372: > 370: // include the waste in the following calculations. > 371: const size_t capacity_after_gc = _g1h->capacity(); > 372: const size_t used_after_gc = capacity_after_gc + It took me a while to understand this calculation; I wonder if this can broken down into two pieces, sth like: const size_t current_used_after_gc = capacity - unused - eden; // Add pending allocation; const size_t used_after_gc = existing_used + _g1h->allocation_used_bytes(allocation_word_size); ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3447491820 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2513784636 From tschatzl at openjdk.org Tue Nov 11 12:48:05 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 11 Nov 2025 12:48:05 GMT Subject: RFR: 8371625: G1: G1HeapRegion::print_on misalignment In-Reply-To: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> References: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> Message-ID: <9HjC57DiY9BqiwWaNIo61W3HRH26SRkiRytkStQ4Tpo=.9d58f9f0-712d-4967-bdc5-2042a5b2fd11@github.com> On Tue, 11 Nov 2025 09:45:25 GMT, Ivan Walulya wrote: > Hi, > > Please review this fix to a misalignment in G1HeapRegion::print_on. Additionally, increased the field width for `hrm_index` as this also causes misalignment on large heaps. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28229#pullrequestreview-3447907990 From iwalulya at openjdk.org Tue Nov 11 12:49:04 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 11 Nov 2025 12:49:04 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 14:32:38 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review, missing conversion of word size to byte size Changes requested by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1Policy.cpp line 746: > 744: } > 745: > 746: size_t G1Policy::conc_mark_occupancy(size_t allocation_word_size) const { is `old_gen_occupancy` a more appropriate name? Or a name that explicitly states that this is occupancy of the "non young regions". src/hotspot/share/gc/g1/g1Policy.hpp line 63: > 61: static G1IHOPControl* create_ihop_control(const G1OldGenAllocationTracker* old_gen_alloc_tracker, > 62: const G1Predictions* predictor); > 63: // Update the IHOP control with necessary statistics. Returns true if there Suggestion: // Update the IHOP control with the necessary statistics. Returns true if there src/hotspot/share/gc/g1/g1Policy.hpp line 311: > 309: > 310: private: > 311: // The current occupancy relevant to concurrent marking, that is compared to The comment does not make it any more clearer what this is. "Which occupancy is relevant for concurrent marking?" ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3447538309 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2514105727 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2513822821 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2514111220 From sjohanss at openjdk.org Tue Nov 11 13:03:58 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 11 Nov 2025 13:03:58 GMT Subject: RFR: 8371019: G1: Support heap expansion during startup In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 10:19:00 GMT, Erik ?sterlund wrote: >> Please review this change to allow G1 to expand the initial heap during startup >> >> **Summary** >> Currently G1 shuts down during startup if we allocate more memory than what's available in the initial young generation. The reason is that we can't allow GCs during initialization. To allow G1 to work in situations requiring additional memory during initialization, this change enables G1 to expand the initial young generation size all the way up the maximum heap size. When initialization is complete mutator allocations will no longer expand the heap. >> >> **Testing** >> * Mach 5 tier1-5 >> * Manual testing requiring additional allocations during startup > > I see now how the assert works: it only checks for the VM thread if not owning the heap lock, so I think it won't be an issue. Looks good. Thanks for the reviews @fisk and @tschatzl ------------- PR Comment: https://git.openjdk.org/jdk/pull/28213#issuecomment-3516820584 From sjohanss at openjdk.org Tue Nov 11 13:03:59 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 11 Nov 2025 13:03:59 GMT Subject: Integrated: 8371019: G1: Support heap expansion during startup In-Reply-To: References: Message-ID: <0_JCum_NHWYNDIXDXcu9_3FxuTOEZROVlWWc-ek2oh4=.4e480f46-dbe7-4fed-91e7-c47c806824df@github.com> On Mon, 10 Nov 2025 09:32:32 GMT, Stefan Johansson wrote: > Please review this change to allow G1 to expand the initial heap during startup > > **Summary** > Currently G1 shuts down during startup if we allocate more memory than what's available in the initial young generation. The reason is that we can't allow GCs during initialization. To allow G1 to work in situations requiring additional memory during initialization, this change enables G1 to expand the initial young generation size all the way up the maximum heap size. When initialization is complete mutator allocations will no longer expand the heap. > > **Testing** > * Mach 5 tier1-5 > * Manual testing requiring additional allocations during startup This pull request has now been integrated. Changeset: 2902436f Author: Stefan Johansson URL: https://git.openjdk.org/jdk/commit/2902436fb15c76755286ed2df444bc6f9d93af13 Stats: 24 lines in 3 files changed: 17 ins; 0 del; 7 mod 8371019: G1: Support heap expansion during startup Reviewed-by: eosterlund, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28213 From tschatzl at openjdk.org Tue Nov 11 13:25:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 11 Nov 2025 13:25:03 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v2] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 11:12:22 GMT, Albert Mingkun Yang wrote: > > previously IHOP logging used to report G1CollectedHeap::used() as occupancy (which is correct at a general level) > > Instead of passing the pending-allocation-size as an arg, what do you think of adding a new API, `used_with_pending_allocation`, which is used when pending-alloc is also interesting to the caller? First, we need a different `used` here - the old one counted young gen regions which are not interesting for starting concurrent mark. The second issue is a practical one: the pending-alloc is not stored in one place where we could get it, but in some temporary objects. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28175#issuecomment-3516914560 From tschatzl at openjdk.org Tue Nov 11 14:07:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 11 Nov 2025 14:07:51 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang, walulyai review * also fix JDK-8371635 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28175/files - new: https://git.openjdk.org/jdk/pull/28175/files/5b00c3a8..d94340ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=01-02 Stats: 48 lines in 5 files changed: 18 ins; 21 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From iwalulya at openjdk.org Tue Nov 11 14:30:32 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 11 Nov 2025 14:30:32 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v3] In-Reply-To: References: Message-ID: <0r3t4HG3vdY5buhbjYk9feuZ4UE2IEhi78c1DiNj6ns=.39ae0417-a0ea-4050-8fab-4dc91e49b4a5@github.com> On Tue, 11 Nov 2025 14:07:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang, walulyai review > * also fix JDK-8371635 Marked as reviewed by iwalulya (Reviewer). failing GHA ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3448333532 Changes requested by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3448340073 From tschatzl at openjdk.org Tue Nov 11 15:08:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 11 Nov 2025 15:08:23 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix compilation on osx ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28175/files - new: https://git.openjdk.org/jdk/pull/28175/files/d94340ad..15a720a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From tschatzl at openjdk.org Tue Nov 11 15:14:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 11 Nov 2025 15:14:24 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 15:08:23 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix compilation on osx Please hold off further reviewing it seems like the changes for [JDK-8371635](https://bugs.openjdk.org/browse/JDK-8371635) I rolled into this PR cause different concurrent mark starts. I'll separate it out again if it does. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28175#issuecomment-3517366887 From mdoerr at openjdk.org Tue Nov 11 16:12:25 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 11 Nov 2025 16:12:25 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 05:54:02 GMT, Axel Boldt-Christmas wrote: >> A few ZGC gtest reservers memory in valid ZAddress address ranges to mock and test different sub systems. When running in instrumented builds such as ASAN the address space we try to may be unavailable. This will cause a couple of our tests to fail. >> >> I propose we change all out gtests to do what `test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp` does. Namely uses our `ZVirtualMemoryManager` to reserve the address space and skip the test incase we are not able to reserve an adequate address range to use for the test. >> >> * Testing >> * GHA >> * gtest with and without ASAN, including artificially induced reservation clash with ASAN > > Thanks for the reviews @xmas92: We have seen an assertion in gtest on Windows: # Internal Error (openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\cpu\x86\gc/z/zAddress_x86.inline.hpp:35), pid=37128, tid=26420 # assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 15 Is this related to this change or one of the other ZGC changes which were pushed on the same date? I guess we'll need to file a new JBS bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28159#issuecomment-3517652580 From lmesnik at openjdk.org Tue Nov 11 17:26:34 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 17:26:34 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v2] In-Reply-To: References: Message-ID: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: moved jvmti/gc coce ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28227/files - new: https://git.openjdk.org/jdk/pull/28227/files/a49d67ca..e728034d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=00-01 Stats: 28 lines in 1 file changed: 14 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28227/head:pull/28227 PR: https://git.openjdk.org/jdk/pull/28227 From kdnilsen at openjdk.org Tue Nov 11 17:26:49 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 17:26:49 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v5] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'share-collector-reserves' of https://github.com/kdnilsen/jdk into share-collector-reserves - fix whitespace - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Fix assert_bounds() assertions when old_trash_not_in_bounds - respond to reviewer feedback - Keep gc cycle times with heuristics for the relevant generation - Fix whitespace - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Merge branch 'share-collector-reserves' of https://github.com/kdnilsen/jdk into share-collector-reserves - make old gc more aggresive - ... and 30 more: https://git.openjdk.org/jdk/compare/9bc23608...f25d5442 ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=04 Stats: 1259 lines in 24 files changed: 726 ins; 293 del; 240 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Tue Nov 11 17:30:26 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 17:30:26 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v6] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove debug instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/f25d5442..37b98e5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=04-05 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From lmesnik at openjdk.org Tue Nov 11 17:45:27 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 17:45:27 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v3] In-Reply-To: References: Message-ID: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: moving ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28227/files - new: https://git.openjdk.org/jdk/pull/28227/files/e728034d..be6eb483 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=01-02 Stats: 14 lines in 2 files changed: 8 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28227/head:pull/28227 PR: https://git.openjdk.org/jdk/pull/28227 From lmesnik at openjdk.org Tue Nov 11 18:15:23 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 18:15:23 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: dot added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28227/files - new: https://git.openjdk.org/jdk/pull/28227/files/be6eb483..6d367b4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28227/head:pull/28227 PR: https://git.openjdk.org/jdk/pull/28227 From duke at openjdk.org Tue Nov 11 18:31:36 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 11 Nov 2025 18:31:36 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO Message-ID: Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. Testing: jtreg gc. GHA pending. ------------- Commit messages: - 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO Changes: https://git.openjdk.org/jdk/pull/28242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371381 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28242/head:pull/28242 PR: https://git.openjdk.org/jdk/pull/28242 From lmesnik at openjdk.org Tue Nov 11 18:33:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 18:33:04 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence In-Reply-To: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com> References: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com> Message-ID: On Tue, 11 Nov 2025 10:03:23 GMT, Albert Mingkun Yang wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > >> move GC shutdown start after VM Death and agent's unloading > > Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)? > > (The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.) @albertnetymk, @stefank > > move GC shutdown start after VM Death and agent's unloading > > Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)? I updated to move jvmti code. Seems that following opertaions WatcherThread::stop(); NativeHeapTrimmer::cleanup(); might be done before sending jvmti vm_death. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3518247296 From kdnilsen at openjdk.org Tue Nov 11 18:43:07 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 18:43:07 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: On Fri, 3 Oct 2025 20:19:44 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 134: > >> 132: inline idx_t get_prev_one_offset(idx_t l_index, idx_t r_index) const; >> 133: >> 134: void clear_large_range(idx_t beg, idx_t end); > > documentation comment. I've added a comment here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2515271426 From kdnilsen at openjdk.org Tue Nov 11 19:03:10 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 19:03:10 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v13] In-Reply-To: <7ReicCCT86J3wPR8FzTdOfaKOvxYbj1dhXNkbDNvduU=.b178f2f0-a241-46a2-a201-cc5394706621@github.com> References: <7ReicCCT86J3wPR8FzTdOfaKOvxYbj1dhXNkbDNvduU=.b178f2f0-a241-46a2-a201-cc5394706621@github.com> Message-ID: On Mon, 10 Nov 2025 21:54:14 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: >> >> - Fix mistaken merge resolution >> - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates >> >> The resulting fastdebug build has 64 failures. I need to debug these. >> Probably introduced by improper resolution of merge conflicts >> - fix error in merge conflict resolution >> - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates >> - rework CompressedClassSpaceSizeinJmapHeap.java >> - fix errors in CompressedClassSpaceSizeInJmapHeap.java >> - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java >> - fix two indexing bugs >> - add an assert to detect suspected bug >> - Remove debug scaffolding >> - ... and 48 more: https://git.openjdk.org/jdk/compare/c272aca8...16cd6f8a > > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 165: > >> 163: } >> 164: >> 165: inline size_t ShenandoahHeapRegion::get_live_data_words(ShenandoahMarkingContext* ctx, size_t index) const { > > Why do we want to change this signature? If `index` is always `this->_index` why go through the trouble to pass a member field to a member function on the same instance? I have a similar sentiment about passing `ShenandoahMarkingContext` through the function. Should we have a member `ShenandoahMarkingContext* _marking_context`? Changing this signature creates a lot of noise on the PR and it's not clear to me why we would do this. Good call out. Am willing to back this change out. Motivation for this change is that we were seeing some performance regression in this PR. At first, I thought this was due to miscomputation of get_live_data_words(), but I confirmed through further testing that the results from get_live_data_words() were the same before and after this PR. So I concluded that the "explanation" for performance regression is that it now takes longer for us to compute get_live_data_words(). The original implementation was: return AtomicAccess::load(&_live_data) The new implementation added: Find the marking context by fetching this from ShenandoahHeap::heap() Find tams by consulting the marking context with region, which has to indirection through region to find index I found that passing this information into the function rather than having the function recompute it brought us back to par with performance of master. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2515338461 From ayang at openjdk.org Tue Nov 11 19:05:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 11 Nov 2025 19:05:04 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3449515538 From wkemper at openjdk.org Tue Nov 11 19:15:04 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 11 Nov 2025 19:15:04 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v12] In-Reply-To: <3LPIbWVGQhvFzoPWfZEVXdj8N-6bm_x3rqat4nZfKxY=.fd6e8854-3da1-4e6e-a7b8-2fdc4e8b1bb6@github.com> References: <3LPIbWVGQhvFzoPWfZEVXdj8N-6bm_x3rqat4nZfKxY=.fd6e8854-3da1-4e6e-a7b8-2fdc4e8b1bb6@github.com> Message-ID: On Mon, 10 Nov 2025 23:45:39 GMT, Kelvin Nilsen wrote: >> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. >> >> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Add two comments Marked as reviewed by wkemper (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27353#pullrequestreview-3449555306 From xpeng at openjdk.org Tue Nov 11 20:02:13 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 11 Nov 2025 20:02:13 GMT Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using CAS for memory allocation [v5] In-Reply-To: <5YSA3F88CmDDv09M2KOm_EFNDh_09LPO2WMrgETfupI=.cc658dc9-829e-41a5-ad76-393d3eb0f75a@github.com> References: <5YSA3F88CmDDv09M2KOm_EFNDh_09LPO2WMrgETfupI=.cc658dc9-829e-41a5-ad76-393d3eb0f75a@github.com> Message-ID: On Wed, 5 Nov 2025 22:17:54 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 2280: >> >>> 2278: } >>> 2279: >>> 2280: class DirectAllocatableRegionRefillClosure final : public ShenandoahHeapRegionIterationClosure { >> >> I don't think we want to subclass ShenandoahHeapRegionIterationClosure here. That iterates over all 2000 regions. We only want to iterate over the 13 Directly allocatable regions. Maybe we don't even need/want a closure iterator here. We could just write a loop. > > I think we should be borrowing from this code when replenishing the regions that are ready to be retired: > > if (_partitions.alloc_from_left_bias(ShenandoahFreeSetPartitionId::Mutator)) { > // Allocate from low to high memory. This keeps the range of fully empty regions more tightly packed. > // Note that the most recently allocated regions tend not to be evacuated in a given GC cycle. So this > // tends to accumulate "fragmented" uncollected regions in high memory. > ShenandoahLeftRightIterator iterator(&_partitions, ShenandoahFreeSetPartitionId::Mutator); > return allocate_from_regions(iterator, req, in_new_region); > } > > // Allocate from high to low memory. This preserves low memory for humongous allocations. > ShenandoahRightLeftIterator iterator(&_partitions, ShenandoahFreeSetPartitionId::Mutator); > return allocate_from_regions(iterator, req, in_new_region); Thanks, the closure I am using here returns a bool indicating when it needs to break out the iteration. We can get rid of the ShenandoahHeapRegionIterationClosure here, I'll replace it with simple loop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26171#discussion_r2515562893 From kdnilsen at openjdk.org Tue Nov 11 21:10:18 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 21:10:18 GMT Subject: Integrated: 8358735: GenShen: block_start() may be incorrect after class unloading In-Reply-To: References: Message-ID: <79B6TCe0QZO2iP37g1U6jYNe7uMc3vKkNhgVVKOtWhM=.304e2627-fd3c-4077-8af5-2aaf30851d1b@github.com> On Wed, 17 Sep 2025 20:12:49 GMT, Kelvin Nilsen wrote: > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. This pull request has now been integrated. Changeset: 8531fa14 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/8531fa146be1da5e96c0f23091882a27c67d7893 Stats: 893 lines in 12 files changed: 851 ins; 10 del; 32 mod 8358735: GenShen: block_start() may be incorrect after class unloading Co-authored-by: Y. Srinivas Ramakrishna Reviewed-by: wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27353 From kdnilsen at openjdk.org Tue Nov 11 22:07:05 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 22:07:05 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Fri, 31 Oct 2025 01:08:25 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 240: >> >>> 238: // Return available_in assuming caller does not hold the heap lock. In production builds, available is >>> 239: // returned without acquiring the lock. In debug builds, the global heap lock is acquired in order to >>> 240: // enforce a consistency assert. >> >> Can the comment be simplified to: >> >> >> // Return bytes `available` in the given `partition` >> // while holding the `rebuild_lock`. >> >> >> Don't say anything about the heap lock in the API comment. Rather, in the part that is `ifdef ASSERT` where you take the heap lock (line ~244), say: >> >> // Acquire the heap lock to get a consistent >> // snapshot to check assert. > > As I write this, I realize that in the most general case where two threads may call these API's independently in a fastdebug build, you could theoretically get into a deadlock because they attempted to acquire locks in different orders (this possibility exists -- statically -- only in the fastdebug builds). > > The general MuteLocker machinery has ranked mutexes to avoid such situations through static ranking and checks while acquiring locks (in debug builds as a way of potentially catching such situations and flagging them). > > With such ranking though this code would assert because the locks are acquired in different order between here and elsewhere. > > In product builds you are fine because the rebuild lock acts as a "leaf lock" (in hotspot parlance). But there seems to be a definite possibility of deadlock in debug builds if/when the rebuild is attempted by one thread while another checks available and attempts to acquire the heap lock to check the assertion. You could solve it by acquiring the heap lock before calling the work method where the assertion check is done. > > However, I'd be much more comfortable if we used some form of lock rank framework, unless it was utterly impossible to do so for some reason. (Here it was easy to spot the lock order inversion because it was in the code. Of course, if a debug build deadlocked you would also figure out the same, but having lock ordering gives you a quick and easy way to verify if there's potential for trouble.) > > Not sure of the history of ShenandoahLock or why the parallel infra to MutexLocker was introduced (perhaps for allowing some performance/tunability), but might be worthwhile to see if we want to build lock rank checks in for robustness/maintainability. I'm coming back to this PR after working on others. Thanks for your comments. This is a good catch. I know better than to do that! Sorry. My intention was to rank-order the locks. Whenever multiple locks are held, it should be in this order: first acquire the global heap lock In nested context, acquire the rebuild_lock Any thread that only acquires the global heap lock or only acquires the rebuild_lock will not deadlock. Multiple threads that acquire both locks will not deadlock because they acquire in the same order. The code you identified was definitely a problem because we were acquiring the two lock in the wrong order. I'm going to remove that assert and the lock associated with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2515961240 From kdnilsen at openjdk.org Tue Nov 11 22:12:05 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 22:12:05 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Fri, 31 Oct 2025 00:36:57 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1158: >> >>> 1156: size_t young_cset_regions, old_cset_regions, first_old, last_old, num_old; >>> 1157: ShenandoahFreeSet* free_set = heap->free_set(); >>> 1158: ShenandoahRebuildLocker rebuild_locker(free_set->lock()); >> >> Should you not create a scope around lines 1158 to line 1167, since you don't want to hold the rebuild lock as soon as the rebuild is done (i.e. immediately following `finish_rebuild()`)? > > May be it doesn't matter, since no one else is running during a full gc who needs to query `available()`? I'll tighten up the context for the rebuild lock. I was thinking that set_mark_incomplete() and clear_cancelled_gc() would be "fast enough" that it wouldn't matter to hold the rebuild_lock this much longer, but I agree it is better to release the lock as soon as possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2515969801 From kdnilsen at openjdk.org Tue Nov 11 22:18:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 22:18:22 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Fri, 31 Oct 2025 00:23:53 GMT, Y. Srinivas Ramakrishna wrote: >> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. >> >> This addresses a problem that results if available memory is probed while we are rebuilding the freeset. >> >> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 426: > >> 424: >> 425: >> 426: ShenandoahRebuildLock* lock() { > > `rebuild_lock()` instead? Good suggestion. Making this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2515981364 From ysr at openjdk.org Tue Nov 11 22:24:00 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 11 Nov 2025 22:24:00 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:24:25 GMT, Rui Li wrote: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. > > Testing: jtreg gc. GHA pending. Reviewed the `ergo` flg setting macro changes. They look good to me. For the passive mode that requires allowing evac reserve of 0, I'll request @kdnilsen or @earthling-amzn to review. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28242#pullrequestreview-3450362860 From cslucas at openjdk.org Tue Nov 11 22:33:03 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Tue, 11 Nov 2025 22:33:03 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:24:25 GMT, Rui Li wrote: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. > > Testing: jtreg gc. GHA pending. Marked as reviewed by cslucas (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28242#pullrequestreview-3450386135 From xpeng at openjdk.org Tue Nov 11 22:42:10 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 11 Nov 2025 22:42:10 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:24:25 GMT, Rui Li wrote: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. > > Testing: jtreg gc. GHA pending. Marked as reviewed by xpeng (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28242#pullrequestreview-3450413840 From kdnilsen at openjdk.org Tue Nov 11 22:44:04 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 11 Nov 2025 22:44:04 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Fri, 31 Oct 2025 00:23:18 GMT, Y. Srinivas Ramakrishna wrote: >> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. >> >> This addresses a problem that results if available memory is probed while we are rebuilding the freeset. >> >> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 323: > >> 321: ShenandoahRegionPartitions _partitions; >> 322: >> 323: // This locks the rebuild process (in combination with the global heap lock) > > Explain the role of this & the global heap lock vis-a-vis the rebuild process. > > Also may be call it `_rebuild_lock`, rather than just `_lock`. Am changing the name. I will add discussion of the rank ordering of locks here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2516042979 From wkemper at openjdk.org Tue Nov 11 23:09:02 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 11 Nov 2025 23:09:02 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:24:25 GMT, Rui Li wrote: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. > > Testing: jtreg gc. GHA pending. Changes requested by wkemper (Reviewer). Hmm, setting `ShenandoahEvacReserve` to zero will cause a divide by zero error in other modes (it will even cause a divide by zero error in the passive mode if `ShenandoahDegeneratedGC` is enabled). I'd rather contain the accommodation for this configuration to the passive mode, than accept values that will cause crashes. Could we "inline" the macro on line 41 and allow zero only for this special configuration (passive mode and only full gcs) by changing the "inlined" macro to use `SET_DEFAULT` still? src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 356: > 354: "regions) is also bounded by this parameter. In percents of " \ > 355: "total (young-generation) heap size.") \ > 356: range(0,100) \ If we allow this, somebody _will_ file a bug because `-XX:ShenandoahEvacReserve=0` will cause other modes to crash with divide by zero error. ------------- PR Review: https://git.openjdk.org/jdk/pull/28242#pullrequestreview-3450500792 PR Comment: https://git.openjdk.org/jdk/pull/28242#issuecomment-3519062971 PR Review Comment: https://git.openjdk.org/jdk/pull/28242#discussion_r2516100105 From duke at openjdk.org Tue Nov 11 23:44:02 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 11 Nov 2025 23:44:02 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: References: Message-ID: <43plTkqggX_oA_fGW7bKG0Gk_K5nzo4XeCvxswOYl6A=.a1770f88-cfc2-40d4-aa59-ff8e9413faa6@github.com> On Tue, 11 Nov 2025 23:06:25 GMT, William Kemper wrote: >> Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. >> >> Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. >> >> Testing: jtreg gc. GHA pending. > > src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 356: > >> 354: "regions) is also bounded by this parameter. In percents of " \ >> 355: "total (young-generation) heap size.") \ >> 356: range(0,100) \ > > If we allow this, somebody _will_ file a bug because `-XX:ShenandoahEvacReserve=0` will cause other modes to crash with divide by zero error. OK, I'll keep the range as it is `(1,100)`, but instead of setting the default with ergo at here: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 I'll just use `FLAG_SET_DEFAULT` to bypass the check? We wouldn't have the data source origin in passive mode which is only meant to be diagnostic, but that's better than causing problems in the regular mode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28242#discussion_r2516180561 From duke at openjdk.org Tue Nov 11 23:55:02 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 11 Nov 2025 23:55:02 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: <43plTkqggX_oA_fGW7bKG0Gk_K5nzo4XeCvxswOYl6A=.a1770f88-cfc2-40d4-aa59-ff8e9413faa6@github.com> References: <43plTkqggX_oA_fGW7bKG0Gk_K5nzo4XeCvxswOYl6A=.a1770f88-cfc2-40d4-aa59-ff8e9413faa6@github.com> Message-ID: On Tue, 11 Nov 2025 23:40:01 GMT, Rui Li wrote: >> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 356: >> >>> 354: "regions) is also bounded by this parameter. In percents of " \ >>> 355: "total (young-generation) heap size.") \ >>> 356: range(0,100) \ >> >> If we allow this, somebody _will_ file a bug because `-XX:ShenandoahEvacReserve=0` will cause other modes to crash with divide by zero error. > > OK, I'll keep the range as it is `(1,100)`, but instead of setting the default with ergo at here: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 I'll just use `FLAG_SET_DEFAULT` to bypass the check? We wouldn't have the data source origin in passive mode which is only meant to be diagnostic, but that's better than causing problems in the regular mode. Ah, missed your general comment above. I think we're talking about the same solution. I'll update the passive mode to use `FLAG_SET_DEFAULT`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28242#discussion_r2516213869 From duke at openjdk.org Wed Nov 12 00:22:39 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 12 Nov 2025 00:22:39 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v2] In-Reply-To: References: Message-ID: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > Had to expand `ShenandoahEvacReserve` range from `range(1,100)` to `range(0,100)` because when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L41 The issue is surfaced now because `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does. > > Testing: jtreg gc. GHA pending. Rui Li has updated the pull request incrementally with one additional commit since the last revision: Use FLAG_SET_DEFAULT for ShenandoahEvacReserve in passive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28242/files - new: https://git.openjdk.org/jdk/pull/28242/files/1a5a09bf..65fc9878 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28242&range=00-01 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28242/head:pull/28242 PR: https://git.openjdk.org/jdk/pull/28242 From kdnilsen at openjdk.org Wed Nov 12 00:58:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 12 Nov 2025 00:58:45 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v2] In-Reply-To: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: > This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. > > This addresses a problem that results if available memory is probed while we are rebuilding the freeset. > > Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. Kelvin Nilsen has updated the pull request incrementally with six additional commits since the last revision: - update comment - Add documentation for _rebuild_lock - Hide rebuild_lock inside prepare_to_rebuild and finish_rebuild - Rename rebuild_lock() - Tighten up context for holding rebuild_lock - Remove ShenandoahFreeSet::FreeSetUnderConstruction sentinel value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27612/files - new: https://git.openjdk.org/jdk/pull/27612/files/a6898392..091e23bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27612&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27612&range=00-01 Stats: 63 lines in 7 files changed: 18 ins; 26 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27612/head:pull/27612 PR: https://git.openjdk.org/jdk/pull/27612 From kdnilsen at openjdk.org Wed Nov 12 00:58:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 12 Nov 2025 00:58:45 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v2] In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Tue, 11 Nov 2025 22:04:04 GMT, Kelvin Nilsen wrote: >> As I write this, I realize that in the most general case where two threads may call these API's independently in a fastdebug build, you could theoretically get into a deadlock because they attempted to acquire locks in different orders (this possibility exists -- statically -- only in the fastdebug builds). >> >> The general MuteLocker machinery has ranked mutexes to avoid such situations through static ranking and checks while acquiring locks (in debug builds as a way of potentially catching such situations and flagging them). >> >> With such ranking though this code would assert because the locks are acquired in different order between here and elsewhere. >> >> In product builds you are fine because the rebuild lock acts as a "leaf lock" (in hotspot parlance). But there seems to be a definite possibility of deadlock in debug builds if/when the rebuild is attempted by one thread while another checks available and attempts to acquire the heap lock to check the assertion. You could solve it by acquiring the heap lock before calling the work method where the assertion check is done. >> >> However, I'd be much more comfortable if we used some form of lock rank framework, unless it was utterly impossible to do so for some reason. (Here it was easy to spot the lock order inversion because it was in the code. Of course, if a debug build deadlocked you would also figure out the same, but having lock ordering gives you a quick and easy way to verify if there's potential for trouble.) >> >> Not sure of the history of ShenandoahLock or why the parallel infra to MutexLocker was introduced (perhaps for allowing some performance/tunability), but might be worthwhile to see if we want to build lock rank checks in for robustness/maintainability. > > I'm coming back to this PR after working on others. Thanks for your comments. > > This is a good catch. I know better than to do that! Sorry. > > My intention was to rank-order the locks. Whenever multiple locks are held, it should be in this order: > first acquire the global heap lock > In nested context, acquire the rebuild_lock > > Any thread that only acquires the global heap lock or only acquires the rebuild_lock will not deadlock. > > Multiple threads that acquire both locks will not deadlock because they acquire in the same order. > > The code you identified was definitely a problem because we were acquiring the two lock in the wrong order. I'm going to remove that assert and the lock associated with it. I've updated this comment to clarify the refined intent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2516294135 From wkemper at openjdk.org Wed Nov 12 01:01:02 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 12 Nov 2025 01:01:02 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v2] In-Reply-To: References: <43plTkqggX_oA_fGW7bKG0Gk_K5nzo4XeCvxswOYl6A=.a1770f88-cfc2-40d4-aa59-ff8e9413faa6@github.com> Message-ID: On Tue, 11 Nov 2025 23:52:24 GMT, Rui Li wrote: >> OK, I'll keep the range as it is `(1,100)`, but instead of setting the default with ergo at here: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 I'll just use `FLAG_SET_DEFAULT` to bypass the check? We wouldn't have the data source origin in passive mode which is only meant to be diagnostic, but that's better than causing problems in the regular mode. > > Ah, missed your general comment above. I think we're talking about the same solution. I'll update the passive mode to use `FLAG_SET_DEFAULT`. Yeah, that's what I was suggesting. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28242#discussion_r2516301969 From ysr at openjdk.org Wed Nov 12 01:25:26 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 12 Nov 2025 01:25:26 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v12] In-Reply-To: <3LPIbWVGQhvFzoPWfZEVXdj8N-6bm_x3rqat4nZfKxY=.fd6e8854-3da1-4e6e-a7b8-2fdc4e8b1bb6@github.com> References: <3LPIbWVGQhvFzoPWfZEVXdj8N-6bm_x3rqat4nZfKxY=.fd6e8854-3da1-4e6e-a7b8-2fdc4e8b1bb6@github.com> Message-ID: On Mon, 10 Nov 2025 23:45:39 GMT, Kelvin Nilsen wrote: >> When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. >> >> The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Add two comments I am still going through this, but it seems as if there's a bunch of potential clean-ups to do here. I realize this has already been integrated; I can may be create a separate task to perhaps clean up some of the questions raised in this. Since there are quite a few comments now, I am going to flush these for now as a record of some of my thoughts and create a separate task in which I can see if these concerns are real and if the code can be somewhat simplified in a few places. Nothing specific to do here at this time in response to these stream-of-consciousness comments. src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.cpp line 70: > 68: assert(limit >= r->bottom(), "limit must be more than bottom"); > 69: assert(addr <= tams, "addr must be less than TAMS"); > 70: #endif Wouldn't it make more sense for these checks to move to the caller? It appears to me to be a leakage of abstraction to test these conditions here. We should be able to return the address for the marked bit found without interpreting the semantics of the bits themselves? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 251: > 249: #endif > 250: > 251: HeapWord* right = MIN2(region->top(), end_range_of_interest); This is a safe thing to do, but doesn't the caller already establish the invariant that `region->top() >= end_range_of_interest` ? Can we just assert that instead of doing the clip/clamp? (And rename the formal parameter name from `end_range_of_interest` to `right`?) If so, we might also want to change the name of the formal parameter from `card_index` to `left`, and change it to be a (card-aligned) _heap_ _address_ for symmetry in the API. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 252: > 250: > 251: HeapWord* right = MIN2(region->top(), end_range_of_interest); > 252: HeapWord* end_of_search_next = MIN2(right, tams); Does the caller ensure that `tams` is always valid (e.g. when `ctx == nullptr`)? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 261: > 259: last_relevant_card_index--; > 260: } > 261: } I am not sure this is necessary. I'd just adjust the caller so this is ensured, avoiding this computation here. I think the caller has the last dirty card address and can just use that? I realize there's a bit of an issue with the address for `tams` not necessarily being card-aligned, but I think we should be able to deal with that in the caller as well once we remember that all of this always happens within a single region. (We can add such an assertion so that future adjustments do not render this assumption invalid if the code is changed/adjusted later.) src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 296: > 294: // for scanning the portion of the obj-array overlapping the dirty cards in > 295: // its cluster. > 296: // 3. Non-array objects are precisely dirtied by the interpreter and the compilers This should say "imprecisely" at line 296, I think? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 410: > 408: ShenandoahCardCluster(ShenandoahDirectCardMarkRememberedSet* rs) { > 409: _rs = rs; > 410: _end_of_heap = ShenandoahHeap::heap()->end(); It is interesting why we should need end of heap but not start of heap. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 657: > 655: > 656: > 657: // Given a card_index, return the starting address of the first live object in the heap The interface/API comment should describe a Dijkstra-like pre- and post-condition. i.e. if these conditions are satisfied, we'll give you this result. A description of what the method does (i.e. how it implements the functionality) belongs in the method implementation. Here, the two are conflated making the interface description unnecessarily long and convoluted. Sometimes this might indicate that the interface isn't as frugal as it should be. I might state this more succinctly as follows: // Given: // `card_index`: a valid index of a card in the old generation // `ctx` : a valid marking context for the old generation // `tams` : a valid top-at-mark-start address for the old generation // region in which the card_index is located // `end_range_of_interest` : an address in that region beyond which we need // not locate an object // // Returns: // the address of the object, if any, at the least address that overlaps with // the address range between the start of card_index and end_range_of_interest, // or nullptr if no such object exists in the given range. Once you look at the spec in this manner, you realize that the first and last arguments go together and define a suitable address range, and the second and third arguments go together and provide a context. This allows you to divide the assertion checking and call interface most optimally between caller and callee. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 168: > 166: // The range of addresses to be scanned is empty > 167: continue; > 168: } When would this happen? We start off with dirty_l to the left of dirty_r, and with dirty_r having started at a card that would correspond to end_addr. I am not convinced this check is needed. I'd rather assert here that: ``` assert(left <= end_addr, "left should remain left of end_addr established above"); ``` src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 178: > 176: // if its head card is dirty. If not, (i.e. its head card is clean) > 177: // we'll call it each time we process a new dirty range on the object. > 178: // This is always the case for large object arrays, which are typically more Instead of `This is always the case ...` may be we can say `The latter is aways the case ...`? (Mea culpa for the old comment.) src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 181: > 179: // common. > 180: assert(ctx != nullptr || heap->old_generation()->is_parsable(), "Error"); > 181: HeapWord* p = _scc->first_object_start(dirty_l, ctx, tams, right); TODO: Wondering if we need to pass both tams and right, or just the max of the two. Will look at `first_object_start()`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27353#pullrequestreview-3445628617 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2516048266 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512594318 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2516272583 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512602336 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512514800 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512532407 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2516276311 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512428956 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512489229 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512496763 From ysr at openjdk.org Wed Nov 12 01:25:27 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 12 Nov 2025 01:25:27 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v12] In-Reply-To: References: <3LPIbWVGQhvFzoPWfZEVXdj8N-6bm_x3rqat4nZfKxY=.fd6e8854-3da1-4e6e-a7b8-2fdc4e8b1bb6@github.com> Message-ID: On Tue, 11 Nov 2025 22:42:46 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Add two comments > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.cpp line 70: > >> 68: assert(limit >= r->bottom(), "limit must be more than bottom"); >> 69: assert(addr <= tams, "addr must be less than TAMS"); >> 70: #endif > > Wouldn't it make more sense for these checks to move to the caller? It appears to me to be a leakage of abstraction to test these conditions here. We should be able to return the address for the marked bit found without interpreting the semantics of the bits themselves? I notice that this is the case for the `get_next_...` version below as well; if my comment makes some sense, this can be addressed separately. Perhaps frugality in testing the conditions required us to site these assertions here, which I kind of understand, although the right thing in that case is to have the wrapper class, viz. `ShenandoahMarkingContext` make those checks before calling here. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 252: > >> 250: >> 251: HeapWord* right = MIN2(region->top(), end_range_of_interest); >> 252: HeapWord* end_of_search_next = MIN2(right, tams); > > Does the caller ensure that `tams` is always valid (e.g. when `ctx == nullptr`)? The caller seems to allow for `tams==nullptr` and `ctx==nullptr`. In that case wouldn't we get `end_of_search_next==nullptr`? > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 181: > >> 179: // common. >> 180: assert(ctx != nullptr || heap->old_generation()->is_parsable(), "Error"); >> 181: HeapWord* p = _scc->first_object_start(dirty_l, ctx, tams, right); > > TODO: Wondering if we need to pass both tams and right, or just the max of the two. Will look at `first_object_start()`. Ah, looks like at this point we might potentially have `ctx == nullptr` and `tams == nullptr`. I wonder if we can do better here in terms of passing a sensible single `right` and dispense with passing `tams` entirely? Let me go back and look at the implementation of the method again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2516079967 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2516338478 PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2516323774 From ysr at openjdk.org Wed Nov 12 01:25:29 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 12 Nov 2025 01:25:29 GMT Subject: RFR: 8358735: GenShen: block_start() may be incorrect after class unloading [v2] In-Reply-To: References: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> Message-ID: On Fri, 3 Oct 2025 20:19:44 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix idiosyncratic formatting > > src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 134: > >> 132: inline idx_t get_prev_one_offset(idx_t l_index, idx_t r_index) const; >> 133: >> 134: void clear_large_range(idx_t beg, idx_t end); > > documentation comment. Nit: l_index <-> beg r_index <-> end in either comment or formal args to make them mutually consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27353#discussion_r2512337397 From kdnilsen at openjdk.org Wed Nov 12 02:01:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 12 Nov 2025 02:01:45 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v7] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Initialize young evac reserve based on soft-max-capacity ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/37b98e5f..35d3911d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=05-06 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From xpeng at openjdk.org Wed Nov 12 02:06:10 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 02:06:10 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code Message-ID: Current alloc request type enum: enum Type { _alloc_shared, // Allocate common, outside of TLAB _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB _alloc_cds, // Allocate for CDS _alloc_tlab, // Allocate TLAB _alloc_gclab, // Allocate GCLAB _alloc_plab, // Allocate PLAB _ALLOC_LIMIT }; With current design, we have to use switch statement resulting in unnecessary branches, for instance the function is_mutator_alloc: inline bool is_mutator_alloc() const { switch (_alloc_type) { case _alloc_tlab: case _alloc_shared: case _alloc_cds: return true; case _alloc_gclab: case _alloc_plab: case _alloc_shared_gc: return false; default: ShouldNotReachHere(); return false; } } In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: 1. Smaller value for mutator alloc, large value for gc alloc 2. Odd for lab, even number for non-lab Three functions have been simplified to one-line impl w/o branches in machine code: inline bool is_mutator_alloc() const { return _alloc_type <= _alloc_shared; } inline bool is_gc_alloc() const { return _alloc_type >= _alloc_shared_gc; } inline bool is_lab_alloc() const { return (_alloc_type & 1) == 1; } Test: - [x] TEST=hotspot_gc_shenandoah - [ ] Tier 1 ------------- Commit messages: - touch-up - Merge branch 'openjdk:master' into JDK-8371667 - re-shuffle the enum values and add comments - 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code Changes: https://git.openjdk.org/jdk/pull/28247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371667 Stats: 56 lines in 1 file changed: 6 ins; 41 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From aboldtch at openjdk.org Wed Nov 12 07:47:40 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 12 Nov 2025 07:47:40 GMT Subject: RFR: 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize Message-ID: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> G1YoungGenSizer ignores these values if they are not from the command line. Resulting in a different _sizer_kind than expected. The NewSize and MaxNewSize are also not bounded by the Initial and Max heap size respectively ([JDK-8370494](https://bugs.openjdk.org/browse/JDK-8370494)). I suggest we rewrite this logic using `!FLAG_IS_DEFAULT` to always get the correct behaviour. And only use `FLAG_IS_CMDLINE` for issuing warnings to the user when we ergonomically change or ignore these values to be compatible. As well as adding the proper truncation for HeapSize incompatible values. * Testing * GHA * Tier 1-5 on Oracle Supported Platforms ------------- Commit messages: - G1: Use of FLAG_IS_CMDLINE for NewRatio, NewSize and MaxNewSize Changes: https://git.openjdk.org/jdk/pull/28255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371672 Stats: 73 lines in 1 file changed: 49 ins; 1 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28255/head:pull/28255 PR: https://git.openjdk.org/jdk/pull/28255 From stefank at openjdk.org Wed Nov 12 07:51:18 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Nov 2025 07:51:18 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: <5D_njHSuB2BtayFBuDlHdkBZ6V9tjtMr1VDObzFoBFM=.7c2dcbb2-6e0b-4dbb-82b0-5298397d1613@github.com> On Tue, 11 Nov 2025 16:09:38 GMT, Martin Doerr wrote: >> Thanks for the reviews > > @xmas92: We have seen an assertion in gtest on Windows: > > # Internal Error (openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\cpu\x86\gc/z/zAddress_x86.inline.hpp:35), pid=37128, tid=26420 > # assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 15 > > Is this related to this change or one of the other ZGC changes which were pushed on the same date? > I guess we'll need to file a new JBS bug. @TheRealMDoerr If you don't mind, then it would be great if you could open a Bug containing the stactrace of the failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28159#issuecomment-3520500543 From stefank at openjdk.org Wed Nov 12 07:53:05 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Nov 2025 07:53:05 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Looks good and thanks for the test! ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452083212 From iwalulya at openjdk.org Wed Nov 12 08:39:05 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 12 Nov 2025 08:39:05 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452233407 From iwalulya at openjdk.org Wed Nov 12 08:48:01 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 12 Nov 2025 08:48:01 GMT Subject: RFR: 8371625: G1: G1HeapRegion::print_on misalignment In-Reply-To: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> References: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> Message-ID: On Tue, 11 Nov 2025 09:45:25 GMT, Ivan Walulya wrote: > Hi, > > Please review this fix to a misalignment in G1HeapRegion::print_on. Additionally, increased the field width for `hrm_index` as this also causes misalignment on large heaps. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28229#issuecomment-3520743610 From iwalulya at openjdk.org Wed Nov 12 08:51:16 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 12 Nov 2025 08:51:16 GMT Subject: Integrated: 8371625: G1: G1HeapRegion::print_on misalignment In-Reply-To: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> References: <_RbkpiBOxnsYtjK8zcr5SnwbSDP1Wz53uXTjmrW5KCc=.5bb3e202-79f9-4efd-9ebe-ba474877a43d@github.com> Message-ID: <3fEML8Q6OuKwORHEh_5v4tIOSa01ZCPwOc8NgULVLWQ=.88b2c9d6-757f-4c96-b500-4fdea735eb9c@github.com> On Tue, 11 Nov 2025 09:45:25 GMT, Ivan Walulya wrote: > Hi, > > Please review this fix to a misalignment in G1HeapRegion::print_on. Additionally, increased the field width for `hrm_index` as this also causes misalignment on large heaps. This pull request has now been integrated. Changeset: 400a83da Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/400a83da893f5fc285a175b63a266de21e93683c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8371625: G1: G1HeapRegion::print_on misalignment Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28229 From shade at openjdk.org Wed Nov 12 09:57:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 12 Nov 2025 09:57:07 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 01:29:53 GMT, Xiaolong Peng wrote: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Honestly, I don't believe switching from explicit switch cases to bit manipulation is that much readable here. If you want to pursue this, then maybe do the proper bitmask manipulation, something like: // bit 0: mutator (0) or GC (1) alloc // bit 1: LAB (0) or shared (1) alloc // bit 2: if LAB, then GCLAB (0) or PLAB (1) // bit 3: if mutator, then normal (0) or CDS (1) typedef int AllocType; constexpr int bit_gc_alloc = 1 << 1; constexpr int bit_lab_alloc = 1 << 2; constexpr int bit_plab_alloc = 1 << 3; constexpr int bit_cds_alloc = 1 << 4; ... const bool is_lab_alloc(AllocType type) { return (type & bit_lab_alloc) != 0; } constexpr AllocType _alloc_tlab = bit_lab_alloc; constexpr AllocType _alloc_plab = bit_gc_alloc | bit_lab_alloc | bit_plab_alloc; ... Remains to be seen what is the most sensible encoding scheme here. ------------- PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3452564118 From mdoerr at openjdk.org Wed Nov 12 09:59:18 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 12 Nov 2025 09:59:18 GMT Subject: RFR: 8371341: ZGC: Improve gtest interoperability with instrumented builds (ASAN) In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 16:09:38 GMT, Martin Doerr wrote: >> Thanks for the reviews > > @xmas92: We have seen an assertion in gtest on Windows: > > # Internal Error (openjdk-jdk-windows_x86_64-dbg\jdk\src\hotspot\cpu\x86\gc/z/zAddress_x86.inline.hpp:35), pid=37128, tid=26420 > # assert(index == 0 || is_power_of_2(index)) failed: Incorrect load shift: 15 > > Is this related to this change or one of the other ZGC changes which were pushed on the same date? > I guess we'll need to file a new JBS bug. > @TheRealMDoerr If you don't mind, then it would be great if you could open a Bug containing the stactrace of the failure. I've filed [JDK-8371698](https://bugs.openjdk.org/browse/JDK-8371698). Unfortunately, the stack trace is broken due to missing debug info. I'll update if we can reproduce it with having that fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28159#issuecomment-3521068029 From jsikstro at openjdk.org Wed Nov 12 10:59:34 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 12 Nov 2025 10:59:34 GMT Subject: RFR: 8371702: ZGC: NUMA-Affinity for Worker Threads in the Relocation Phase Message-ID: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> Hello, The main goal of this PR is to solve a performance regression in relatively small environments on a NUMA machine. See the associated issue for a more detailed explanation on regression itself. I propose we add functionality to set the affinity of worker threads in the Relocation Phase of ZGC so that the worker threads are *always* accessing NUMA-local memory when relocating objects. As soon as a worker threads is about to start relocating a new forwarding entry (or just page), it makes sure that it has the appropriate affinity set. At the most, each worker thread will set its own affinity the same number of times as there are NUMA nodes on the system. When the threads are about to exit the Relocation Phase (i.e. by completing `ZRelocateTask`), they "strip" their affinity so that they are allowed to run on any CPU that they were originally allowed to run on. I've done significant performance testing, which solves the observed regression and gives an additional performance boost in the same environments. I have not been able to observe similar boosts in performance on much larger environments (>=70 CPUs and >32GB memory) and also no regressions. ------------- Depends on: https://git.openjdk.org/jdk/pull/28261 Commit messages: - 8371702: ZGC: NUMA-Affinity for Worker Threads in the Relocation Phase Changes: https://git.openjdk.org/jdk/pull/28262/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371702 Stats: 41 lines in 1 file changed: 19 ins; 13 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28262/head:pull/28262 PR: https://git.openjdk.org/jdk/pull/28262 From tschatzl at openjdk.org Wed Nov 12 12:48:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 12 Nov 2025 12:48:27 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v3] In-Reply-To: <0r3t4HG3vdY5buhbjYk9feuZ4UE2IEhi78c1DiNj6ns=.39ae0417-a0ea-4050-8fab-4dc91e49b4a5@github.com> References: <0r3t4HG3vdY5buhbjYk9feuZ4UE2IEhi78c1DiNj6ns=.39ae0417-a0ea-4050-8fab-4dc91e49b4a5@github.com> Message-ID: On Tue, 11 Nov 2025 14:27:45 GMT, Ivan Walulya wrote: > failing GHA Not sure what happened here - rerun of tier1-3 does not give failures, the latest GHA does not either. Local runs of tier1 could not reproduce the issue too, so I think it is good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28175#issuecomment-3521756512 From jsikstro at openjdk.org Wed Nov 12 12:51:04 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 12 Nov 2025 12:51:04 GMT Subject: RFR: 8371702: ZGC: NUMA-Affinity for Worker Threads in the Relocation Phase [v2] In-Reply-To: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> References: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> Message-ID: > Hello, > > The main goal of this PR is to solve a performance regression in relatively small environments on a NUMA machine. See the associated issue for a more detailed explanation on regression itself. > > I propose we add functionality to set the affinity of worker threads in the Relocation Phase of ZGC so that the worker threads are *always* accessing NUMA-local memory when relocating objects. As soon as a worker threads is about to start relocating a new forwarding entry (or just page), it makes sure that it has the appropriate affinity set. At the most, each worker thread will set its own affinity the same number of times as there are NUMA nodes on the system. When the threads are about to exit the Relocation Phase (i.e. by completing `ZRelocateTask`), they "strip" their affinity so that they are allowed to run on any CPU that they were originally allowed to run on. > > I've done significant performance testing, which solves the observed regression and gives an additional performance boost in the same environments. I have not been able to observe similar boosts in performance on much larger environments (>=70 CPUs and >32GB memory) and also no regressions. Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Comment fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28262/files - new: https://git.openjdk.org/jdk/pull/28262/files/2aabc2fb..fea63eca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28262/head:pull/28262 PR: https://git.openjdk.org/jdk/pull/28262 From iwalulya at openjdk.org Wed Nov 12 13:16:11 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 12 Nov 2025 13:16:11 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: <8YcutKz0Hhm75TOzxDIYSy-MrblXhf_p8x6_UkJSh4g=.4003c325-fc2a-4829-afd2-4056be43b9ef@github.com> On Tue, 11 Nov 2025 15:08:23 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix compilation on osx Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3453385733 From ayang at openjdk.org Wed Nov 12 13:21:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 12 Nov 2025 13:21:16 GMT Subject: RFR: 8371465: Parallel: Revise asserts around heap expansion Message-ID: Revise heap/old-gen expansion asserts/comments to cover two paths: 1. startup: no gc can occur 2. after-startup: during safepoint, by vm-thread. Test: tier1-4 ------------- Commit messages: - pgc-assert-relax Changes: https://git.openjdk.org/jdk/pull/28266/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28266&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371465 Stats: 40 lines in 4 files changed: 19 ins; 18 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28266/head:pull/28266 PR: https://git.openjdk.org/jdk/pull/28266 From aboldtch at openjdk.org Wed Nov 12 14:06:32 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 12 Nov 2025 14:06:32 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3453617541 From iwalulya at openjdk.org Wed Nov 12 15:17:53 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 12 Nov 2025 15:17:53 GMT Subject: RFR: 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize In-Reply-To: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> References: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> Message-ID: <-eaVe6KucvNrkOhmbOzLznVe4B54rHm97K2JbjFttTk=.5c516333-6612-43b5-8be7-fa48a9749cdb@github.com> On Wed, 12 Nov 2025 07:40:01 GMT, Axel Boldt-Christmas wrote: > G1YoungGenSizer ignores these values if they are not from the command line. Resulting in a different _sizer_kind than expected. > The NewSize and MaxNewSize are also not bounded by the Initial and Max heap size respectively ([JDK-8370494](https://bugs.openjdk.org/browse/JDK-8370494)). > > I suggest we rewrite this logic using `!FLAG_IS_DEFAULT` to always get the correct behaviour. And only use `FLAG_IS_CMDLINE` for issuing warnings to the user when we ergonomically change or ignore these values to be compatible. > As well as adding the proper truncation for HeapSize incompatible values. > > * Testing > * GHA > * Tier 1-5 on Oracle Supported Platforms Marked as reviewed by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1YoungGenSizer.cpp line 116: > 114: _sizer_kind = SizerNewSizeOnly; > 115: } else { > 116: assert(user_specified_MaxNewSize, ""); postcond( ------------- PR Review: https://git.openjdk.org/jdk/pull/28255#pullrequestreview-3453976879 PR Review Comment: https://git.openjdk.org/jdk/pull/28255#discussion_r2518711682 From xpeng at openjdk.org Wed Nov 12 16:07:03 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 16:07:03 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 09:54:27 GMT, Aleksey Shipilev wrote: > Honestly, I don't believe switching from explicit switch cases to bit manipulation is that much readable here. If you want to pursue this, then maybe do the proper bitmask manipulation, something like: > > ``` > // bit 0: mutator (0) or GC (1) alloc > // bit 1: LAB (0) or shared (1) alloc > // bit 2: if LAB, then GCLAB (0) or PLAB (1) > // bit 3: if mutator, then normal (0) or CDS (1) > typedef int AllocType; > > constexpr int bit_gc_alloc = 1 << 1; > constexpr int bit_lab_alloc = 1 << 2; > constexpr int bit_plab_alloc = 1 << 3; > constexpr int bit_cds_alloc = 1 << 4; > ... > const bool is_lab_alloc(AllocType type) { > return (type & bit_lab_alloc) != 0; > } > > constexpr AllocType _alloc_tlab = bit_lab_alloc; > constexpr AllocType _alloc_plab = bit_gc_alloc | bit_lab_alloc | bit_plab_alloc; > ... > ``` > > Remains to be seen what is the most sensible encoding scheme here. Thanks you for the suggestion. I didn't think about changing the enum to constexpr int for alloc request type, just wanted to re-shuffle the values of current enum, so I only used bit manipulation when test if it lab allocation. I'll update the PR and use proper bitmask manipulation as you suggested. In terms of readability, explicit switch cases is definitely more readable, but machine code size will be also larger with more branches, so in theory it is less efficient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3522696592 From xpeng at openjdk.org Wed Nov 12 16:11:00 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 16:11:00 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v2] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Refactor alloc type with bit masks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/eaf5997c..e44a3013 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=00-01 Stats: 20 lines in 1 file changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From jsikstro at openjdk.org Wed Nov 12 16:11:51 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 12 Nov 2025 16:11:51 GMT Subject: RFR: 8371702: ZGC: NUMA-Affinity for Worker Threads in the Relocation Phase [v3] In-Reply-To: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> References: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> Message-ID: > Hello, > > The main goal of this PR is to solve a performance regression in relatively small environments on a NUMA machine. See the associated issue for a more detailed explanation on regression itself. > > I propose we add functionality to set the affinity of worker threads in the Relocation Phase of ZGC so that the worker threads are *always* accessing NUMA-local memory when relocating objects. As soon as a worker threads is about to start relocating a new forwarding entry (or just page), it makes sure that it has the appropriate affinity set. At the most, each worker thread will set its own affinity the same number of times as there are NUMA nodes on the system. When the threads are about to exit the Relocation Phase (i.e. by completing `ZRelocateTask`), they "strip" their affinity so that they are allowed to run on any CPU that they were originally allowed to run on. > > I've done significant performance testing, which solves the observed regression and gives an additional performance boost in the same environments. I have not been able to observe similar boosts in performance on much larger environments (>=70 CPUs and >32GB memory) and also no regressions. Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Small comment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28262/files - new: https://git.openjdk.org/jdk/pull/28262/files/fea63eca..8c0083c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28262/head:pull/28262 PR: https://git.openjdk.org/jdk/pull/28262 From shade at openjdk.org Wed Nov 12 16:58:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 12 Nov 2025 16:58:51 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v2] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 16:11:00 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Refactor alloc type with bit masks Now that we are doing this... I do wonder if we want to fold `_is_promotion` and `_affiliation` into the same bitset? src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp line 178: > 176: > 177: inline bool is_mutator_alloc() const { > 178: return !is_gc_alloc(); Inline this, to check the `bit_gc_alloc` directly. src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp line 182: > 180: > 181: inline bool is_gc_alloc() const { > 182: return (_alloc_type & bit_gc_alloc) == bit_gc_alloc; Check for `!= 0` in these. It is microscopically more efficient. ------------- PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3454438588 PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2519075032 PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2519052973 From wkemper at openjdk.org Wed Nov 12 17:08:31 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 12 Nov 2025 17:08:31 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v2] In-Reply-To: References: <43plTkqggX_oA_fGW7bKG0Gk_K5nzo4XeCvxswOYl6A=.a1770f88-cfc2-40d4-aa59-ff8e9413faa6@github.com> Message-ID: <2xpmXZKcmu3NPRYcj_0PZxLxN2dIF_LbhWerqJL7Ra0=.8552e539-0808-461e-be7b-3964c2a94c8c@github.com> On Wed, 12 Nov 2025 00:58:31 GMT, William Kemper wrote: >> Ah, missed your general comment above. I think we're talking about the same solution. I'll update the passive mode to use `FLAG_SET_DEFAULT`. > > Yeah, that's what I was suggesting. Thanks! Can we put the lower bound back to 1 now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28242#discussion_r2519122056 From xpeng at openjdk.org Wed Nov 12 17:29:24 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 17:29:24 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v3] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Address pr comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/e44a3013..5348c886 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Wed Nov 12 17:29:25 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 17:29:25 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v2] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 16:55:48 GMT, Aleksey Shipilev wrote: > Now that we are doing this... I do wonder if we want to fold `_is_promotion` and `_affiliation` into the same bitset? I'll take a look today and see if folding `_is_promotion` and `_affiliation` into the same bitset provides benefits we want. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3523066748 From kdnilsen at openjdk.org Wed Nov 12 18:08:00 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 12 Nov 2025 18:08:00 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> References: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> Message-ID: On Tue, 11 Nov 2025 00:33:36 GMT, William Kemper wrote: >> When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Revert "We can also filter out old when striclty marking young" > > This reverts commit c53c4f23f4401785e1049494b6c4e4b92f9a5701. Marked as reviewed by kdnilsen (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28183#pullrequestreview-3454779191 From sspitsyn at openjdk.org Wed Nov 12 18:33:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Nov 2025 18:33:46 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Looks good. Thank you for fixing this issue! ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3454892220 From ayang at openjdk.org Wed Nov 12 18:53:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 12 Nov 2025 18:53:02 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 15:08:23 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix compilation on osx src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1035: > 1033: inline void old_set_remove(G1HeapRegion* hr); > 1034: > 1035: size_t non_young_occupancy_after_allocation(size_t allocation_word_size); I think the original term `capacity` is less misleading -- with `occupancy` one always need to ponder a bit, is it just used-bytes or is it used-bytes aligned-up by region? src/hotspot/share/gc/g1/g1IHOPControl.cpp line 66: > 64: percent_of(cur_conc_mark_start_threshold, _target_occupancy), > 65: _target_occupancy, > 66: occupancy, Not sure if I misunderstood this or not -- this two value `_target_occupancy` vs `occupancy` mean sth quite different, one for whole-heap and the other for non-young regions. Based on their names, I'd expect them to refer to the same set of regions. src/hotspot/share/gc/g1/g1IHOPControl.cpp line 189: > 187: } > 188: > 189: void G1AdaptiveIHOPControl::send_jfr_event(G1NewTracer* tracer, size_t occupancy) { Why `jfr` in the name? There is nothing related to `jfr` in this context. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2519422730 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2519411406 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2519413843 From lmesnik at openjdk.org Wed Nov 12 18:58:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 12 Nov 2025 18:58:04 GMT Subject: Integrated: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik wrote: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. This pull request has now been integrated. Changeset: 705bd6fb Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/705bd6fbdc0e78625d05dbfa8af547c50b076e69 Stats: 161 lines in 3 files changed: 151 ins; 9 del; 1 mod 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence Reviewed-by: ayang, stefank, iwalulya, aboldtch, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28227 From duke at openjdk.org Wed Nov 12 19:33:13 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 12 Nov 2025 19:33:13 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v3] In-Reply-To: <2xpmXZKcmu3NPRYcj_0PZxLxN2dIF_LbhWerqJL7Ra0=.8552e539-0808-461e-be7b-3964c2a94c8c@github.com> References: <43plTkqggX_oA_fGW7bKG0Gk_K5nzo4XeCvxswOYl6A=.a1770f88-cfc2-40d4-aa59-ff8e9413faa6@github.com> <2xpmXZKcmu3NPRYcj_0PZxLxN2dIF_LbhWerqJL7Ra0=.8552e539-0808-461e-be7b-3964c2a94c8c@github.com> Message-ID: On Wed, 12 Nov 2025 17:05:17 GMT, William Kemper wrote: >> Yeah, that's what I was suggesting. Thanks! > > Can we put the lower bound back to 1 now? Sorry, forgot. Updating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28242#discussion_r2519528832 From duke at openjdk.org Wed Nov 12 19:33:12 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 12 Nov 2025 19:33:12 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v3] In-Reply-To: References: Message-ID: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > > For `ShenandoahEvacReserve` change: when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 > > `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does so some of the jtreg would fail because of this change. Had to move this ergo setting to regular `FLAG_SET_DEFAULT`. > > Testing: jtreg gc. GHA pending. Rui Li has updated the pull request incrementally with one additional commit since the last revision: Move ShenandoahEvacReserve back to (1,100) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28242/files - new: https://git.openjdk.org/jdk/pull/28242/files/65fc9878..6200456b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28242&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28242&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28242/head:pull/28242 PR: https://git.openjdk.org/jdk/pull/28242 From kdnilsen at openjdk.org Wed Nov 12 21:10:50 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 12 Nov 2025 21:10:50 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v8] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix merge error - compute_old_generation_balance() during freeset rebuild ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/35d3911d..18a49d8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=06-07 Stats: 45 lines in 4 files changed: 42 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From xpeng at openjdk.org Wed Nov 12 23:05:39 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 23:05:39 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v4] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Fold _affiliation and _is_promotion into the bitset of request type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/5348c886..2cf6600e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=02-03 Stats: 72 lines in 2 files changed: 14 ins; 28 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From duke at openjdk.org Wed Nov 12 23:08:08 2025 From: duke at openjdk.org (Rui Li) Date: Wed, 12 Nov 2025 23:08:08 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 19:33:12 GMT, Rui Li wrote: >> Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. >> >> >> For `ShenandoahEvacReserve` change: when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 >> >> `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does so some of the jtreg would fail because of this change. Had to move this ergo setting to regular `FLAG_SET_DEFAULT`. >> >> Testing: jtreg gc. GHA pending. > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Move ShenandoahEvacReserve back to (1,100) GHA test `test/jdk/java/util/Arrays/SortingNearlySortedPrimitive.java` failed, but it uses g1, should be unrelated: # JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-rgithubli-6200456b7130997d227dd5a128e4cefbd05059b5) # Java VM: OpenJDK 64-Bit Server VM (26-internal-rgithubli-6200456b7130997d227dd5a128e4cefbd05059b5, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x6765ff] frame::sender(RegisterMap*) const+0x29f It passed on my local. Rerun on GHA and check hs_err log. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28242#issuecomment-3524259349 From xpeng at openjdk.org Wed Nov 12 23:17:34 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 23:17:34 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v5] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - Remove dead code - Add asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/2cf6600e..e05b45bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=03-04 Stats: 9 lines in 1 file changed: 8 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Wed Nov 12 23:22:29 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 12 Nov 2025 23:22:29 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v6] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Add missing cases in ShenandoahHeapRegion::adjust_alloc_metadata ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/e05b45bd..4b9f1308 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Thu Nov 13 00:26:02 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 13 Nov 2025 00:26:02 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v6] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 23:22:29 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Add missing cases in ShenandoahHeapRegion::adjust_alloc_metadata src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3272: > 3270: switch (req.type()) { > 3271: case ShenandoahAllocRequest::_alloc_shared: > 3272: case ShenandoahAllocRequest::_alloc_shared_gc: humongous objects never move, not possible to be _alloc_shared_gc here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2520400311 From xpeng at openjdk.org Thu Nov 13 00:29:05 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 13 Nov 2025 00:29:05 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v2] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 17:25:52 GMT, Xiaolong Peng wrote: > > Now that we are doing this... I do wonder if we want to fold `_is_promotion` and `_affiliation` into the same bitset? > > I'll take a look today and see if folding `_is_promotion` and `_affiliation` into the same bitset provides benefits we want. I have made the change to fold `_is_promotion` and `_affiliation` into the same bitset of `_alloc`, but I am not 100% sure about whether we should do it or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3524505491 From xpeng at openjdk.org Thu Nov 13 01:03:28 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 13 Nov 2025 01:03:28 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v7] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Fix wrong bit masks(offset by 1) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/4b9f1308..131f6a6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=05-06 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From wkemper at openjdk.org Thu Nov 13 01:20:11 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 13 Nov 2025 01:20:11 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 19:33:12 GMT, Rui Li wrote: >> Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. >> >> >> For `ShenandoahEvacReserve` change: when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 >> >> `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does so some of the jtreg would fail because of this change. Had to move this ergo setting to regular `FLAG_SET_DEFAULT`. >> >> Testing: jtreg gc. GHA pending. > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Move ShenandoahEvacReserve back to (1,100) Thank you! ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28242#pullrequestreview-3456510194 From aboldtch at openjdk.org Thu Nov 13 06:22:38 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 13 Nov 2025 06:22:38 GMT Subject: RFR: 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize [v2] In-Reply-To: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> References: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> Message-ID: > G1YoungGenSizer ignores these values if they are not from the command line. Resulting in a different _sizer_kind than expected. > The NewSize and MaxNewSize are also not bounded by the Initial and Max heap size respectively ([JDK-8370494](https://bugs.openjdk.org/browse/JDK-8370494)). > > I suggest we rewrite this logic using `!FLAG_IS_DEFAULT` to always get the correct behaviour. And only use `FLAG_IS_CMDLINE` for issuing warnings to the user when we ergonomically change or ignore these values to be compatible. > As well as adding the proper truncation for HeapSize incompatible values. > > * Testing > * GHA > * Tier 1-5 on Oracle Supported Platforms Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Apply @walulyai suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28255/files - new: https://git.openjdk.org/jdk/pull/28255/files/91b86362..afba48e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28255&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28255&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28255/head:pull/28255 PR: https://git.openjdk.org/jdk/pull/28255 From aboldtch at openjdk.org Thu Nov 13 08:21:14 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 13 Nov 2025 08:21:14 GMT Subject: RFR: 8371465: Parallel: Revise asserts around heap expansion In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 13:14:34 GMT, Albert Mingkun Yang wrote: > Revise heap/old-gen expansion asserts/comments to cover two paths: > > 1. startup: no gc can occur > 2. after-startup: during safepoint, by vm-thread. > > Test: tier1-4 Alright so if I try to understand the invariants correct here surrounding the `_end`. For using unordered reads and modifying the value: * Before GC can run * Mapping AOT archive has no concurrency * Will take `PSOldGenExpand_lock` unnecessarily, but not the `Heap_lock` * assert_locked_or_safepoint(Heap_lock) is skipped because `!Universe::is_fully_initialized()` * Normal failed allocations (may be while loading Streamed AOT archive) * Holds the `Heap_lock` * After the GC can run * In the VM thread of a GC safepoint (no parallel GC threads are running) * By a GC thread during a GC * Uses `PSOldGenExpand_lock` Looking at the code and writing this out I can see that only half of my concerns raised in #28162 / [JDK-8371369](https://bugs.openjdk.org/browse/JDK-8371369) were addressed. The asserts in `MutableSpace::needs_expand` were addressed, but not the once in `PSOldGen::expand`. Right now if we are in no GC phase (`!is_init_completed()`) and we would fail to expand the young gen, and attempt to expand the old gen we would hit the assert inside `PSOldGen::expand` which says that any thread other than the VM thread must also hold `PSOldGenExpand_lock`. Which we do not in the allocation path. My guess is that this scenario is extremely unlikely to happen. However I think the assert inside `PSOldGen::expand` should be conditioned on `if (!Thread::current()->is_VM_thread() && !is_init_completed())`. Other than that I think these new invariants assert looks good. But some of the interactions between `PSOldGenExpand_lock`, `Heap_lock` are not obvious at a glance. May we should have some comment (or maybe there already is) describing how this works. Something along the lines of: Before `is_init_completed()` all expansion is performed while holding the `Heap_lock`. With the exception of when the AOT heap archive is mapped into the heap. After `is_init_completed()` all expansions are either preformed by active GC threads holding the `PSOldGenExpand_lock` or the VM thread in a GC safepoint. The GC threads' and the VM thread's expansion will never occur concurrently. _Note here we might just want to take the `Heap_lock` in `ParallelScavengeHeap::allocate_loaded_archive_space` and keep this invariant, just because it simplifies the invariant and we can remove the mapped AOT archive exception line._ ------------- PR Review: https://git.openjdk.org/jdk/pull/28266#pullrequestreview-3458284737 From tschatzl at openjdk.org Thu Nov 13 09:36:05 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 09:36:05 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 18:45:38 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix compilation on osx > > src/hotspot/share/gc/g1/g1IHOPControl.cpp line 66: > >> 64: percent_of(cur_conc_mark_start_threshold, _target_occupancy), >> 65: _target_occupancy, >> 66: occupancy, > > Not sure if I misunderstood this or not -- this two value `_target_occupancy` vs `occupancy` mean sth quite different, one for whole-heap and the other for non-young regions. > > Based on their names, I'd expect them to refer to the same set of regions. I had a follow-up planned to fix this (and the log message) to something like `non-young occupancy` (or similar). > src/hotspot/share/gc/g1/g1IHOPControl.cpp line 189: > >> 187: } >> 188: >> 189: void G1AdaptiveIHOPControl::send_jfr_event(G1NewTracer* tracer, size_t occupancy) { > > Why `jfr` in the name? There is nothing related to `jfr` in this context. Because this is what the method does. Send a JFR/trace event. I think the new name is more concise about that. Similar to the other name that is now called `print_log` to explicitly call out that we are printing the log message. In Hotspot, a "trace event" or just "event" is always a JFR event as opposed to printing log output. I can rename it back if you think the old name was more concise. Maybe it is better wrt to the `G1NewTracer` used here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2522547662 PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2522555842 From tschatzl at openjdk.org Thu Nov 13 09:49:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 09:49:29 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 09:30:17 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1IHOPControl.cpp line 189: >> >>> 187: } >>> 188: >>> 189: void G1AdaptiveIHOPControl::send_jfr_event(G1NewTracer* tracer, size_t occupancy) { >> >> Why `jfr` in the name? There is nothing related to `jfr` in this context. > > Because this is what the method does. Send a JFR/trace event. I think the new name is more concise about that. Similar to the other name that is now called `print_log` to explicitly call out that we are printing the log message. > > In Hotspot, a "trace event" or just "event" is always a JFR event as opposed to printing log output. > > I can rename it back if you think the old name was more concise. Maybe it is better wrt to the `G1NewTracer` used here. I.e. the identifier `jfr` is throughout the GC code (from quick searching) always associated to `events` or the `tracer`. We already use names like `*JFRTracer*` (in G1) or `_jfr_tracer` (in ZGC) to (apparently to me) make it clear that the related code is about jfr. To me the term tracing is too generic, whenever I read such a name I always need to think about what kind of tracing for what is actually meant, as opposed to printing a (text) log message. With something like "jfr" in the name it is very clear that this is not something generic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2522624794 From tschatzl at openjdk.org Thu Nov 13 10:04:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 10:04:23 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 18:50:17 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix compilation on osx > > src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1035: > >> 1033: inline void old_set_remove(G1HeapRegion* hr); >> 1034: >> 1035: size_t non_young_occupancy_after_allocation(size_t allocation_word_size); > > I think the original term `capacity` is less misleading -- with `occupancy` one always need to ponder a bit, is it just used-bytes or is it used-bytes aligned-up by region? To me something-capacity is always some kind of (lower or) upper threshold, i.e. what is possible (mostly related to regions too). (Like min or max capacity of a container or similar, or min/max of the heap). This is a current actual value of something, so "occupancy" and "used" seemed more appropriate to me. Additionally, to me "used" in G1 is actual usage without fragmentation losses, while "occupancy" tends to be the latter (including fragmentation) if I want to make the distinction. Since for IHOP only the usage with fragmentation losses matters - G1 can't allocate into the regions anyway, I selected occupancy here (and it does not take that last old gen alloc region into account which we can still allocate into, something else I was thinking about to fix). E.g. "used" for a set of humongous regions would be more related to the size of the object inside while "occupancy" the total size of the regions that object is allocated into. Vs. capacity that would be more about bounds (which isn't relevant in the context of this example, but just for contrast). So in my view the new name is better than the old. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2522701779 From jsikstro at openjdk.org Thu Nov 13 10:14:36 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 13 Nov 2025 10:14:36 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation Message-ID: Hello, We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. Testing: * Oracle's tier1-3 ------------- Commit messages: - 8371783: Refactor GCCause in VM_CollectForMetadataAllocation Changes: https://git.openjdk.org/jdk/pull/28287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371783 Stats: 14 lines in 3 files changed: 5 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28287/head:pull/28287 PR: https://git.openjdk.org/jdk/pull/28287 From ayang at openjdk.org Thu Nov 13 10:40:28 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 10:40:28 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 10:00:38 GMT, Thomas Schatzl wrote: > while "occupancy" tends to be the latter (including fragmentation) if I want to make the distinction. That's implicit in this context. One line comment for what "occupancy" means would nice, if you prefer this term. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2522865548 From tschatzl at openjdk.org Thu Nov 13 10:45:32 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 10:45:32 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v5] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * rename back `send_jfr_event` * rename `occupancy` to `non_young_occupancy` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28175/files - new: https://git.openjdk.org/jdk/pull/28175/files/15a720a9..c6e7e294 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=03-04 Stats: 30 lines in 4 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From ayang at openjdk.org Thu Nov 13 10:40:29 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 10:40:29 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: <39hSBmv2gxYvEw52B0BjXiWrTPZTkeXFnJJ0151SoYM=.81d65abe-d9e9-4d9b-b29e-2d3d1786bbd1@github.com> On Thu, 13 Nov 2025 09:45:08 GMT, Thomas Schatzl wrote: >> Because this is what the method does. Send a JFR/trace event. I think the new name is more concise about that. Similar to the other name that is now called `print_log` to explicitly call out that we are printing the log message. >> >> In Hotspot, a "trace event" or just "event" is always a JFR event as opposed to printing log output. >> >> I can rename it back if you think the old name was more concise. Maybe it is better wrt to the `G1NewTracer` used here. > > I.e. the identifier `jfr` is throughout the GC code (from quick searching) always associated to `events` or the `tracer`. We already use names like `*JFRTracer*` (in G1) or `_jfr_tracer` (in ZGC) to (apparently to me) make it clear that the related code is about jfr. > > To me the term tracing is too generic, whenever I read such a name I always need to think about what kind of tracing for what is actually meant, as opposed to printing a (text) log message. With something like "jfr" in the name it is very clear that this is not something generic. > Because this is what the method does. But what don't/can't know that info in this context. I'd slightly leaned towards the old name, as there is no jfr in the current context. (Ofc, that's a diff story if `G1NewTracer` is renamed to `G1NewJfrTracer`, or sth.) Very subjective; up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2522877456 From ayang at openjdk.org Thu Nov 13 10:40:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 10:40:27 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 15:08:23 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix compilation on osx Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3459052745 From tschatzl at openjdk.org Thu Nov 13 11:19:08 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 11:19:08 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v6] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * some additional documentation around `G1CollectedHeap::non_young_occupancy_after_allocation` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28175/files - new: https://git.openjdk.org/jdk/pull/28175/files/c6e7e294..0784435a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=04-05 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From ayang at openjdk.org Thu Nov 13 11:19:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 11:19:09 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v6] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:15:59 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * some additional documentation around `G1CollectedHeap::non_young_occupancy_after_allocation` Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3459265713 From ayang at openjdk.org Thu Nov 13 11:38:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 11:38:20 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Thu, 13 Nov 2025 09:31:53 GMT, Martin Doerr wrote: > ... make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders" I suspect the crash is caused by a preexisting issue that is exposed by this patch. In `vmClasses::resolve_all`: #if INCLUDE_CDS if (CDSConfig::is_using_aot_linked_classes()) { AOTLinkedClassBulkLoader::preload_classes(THREAD); } #endif // Preload commonly used klasses vmClassID scan = vmClassID::FIRST; // first do Object, then String, Class resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK); CollectedHeap::set_filler_object_klass(vmClasses::Object_klass()); The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj. @iklam What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3527395697 From tschatzl at openjdk.org Thu Nov 13 11:41:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 11:41:48 GMT Subject: RFR: 8371788: Fix documentation for CollectedHeap::collect(GCCause) Message-ID: Hi all, please review this trivial fix of the documentation of `Collectedheap::collect()` and all its overrides to indicate that it's not just used for `System.gc()` and will do a full collection. Testing: local compilation Thanks, Thomas ------------- Commit messages: - 8371788 Changes: https://git.openjdk.org/jdk/pull/28289/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28289&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371788 Stats: 10 lines in 4 files changed: 0 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28289.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28289/head:pull/28289 PR: https://git.openjdk.org/jdk/pull/28289 From ayang at openjdk.org Thu Nov 13 11:55:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 11:55:52 GMT Subject: RFR: 8371788: Fix documentation for CollectedHeap::collect(GCCause) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:33:53 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial fix of the documentation of `Collectedheap::collect()` and all its overrides to indicate that it's not just used for `System.gc()` and will do a full collection. > > Testing: local compilation > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28289#pullrequestreview-3459422326 From iwalulya at openjdk.org Thu Nov 13 12:08:26 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 13 Nov 2025 12:08:26 GMT Subject: RFR: 8371788: Fix documentation for CollectedHeap::collect(GCCause) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:33:53 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial fix of the documentation of `Collectedheap::collect()` and all its overrides to indicate that it's not just used for `System.gc()` and will do a full collection. > > Testing: local compilation > > Thanks, > Thomas Trivial! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28289#pullrequestreview-3459468139 From stefank at openjdk.org Thu Nov 13 12:44:15 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 13 Nov 2025 12:44:15 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v4] In-Reply-To: <39hSBmv2gxYvEw52B0BjXiWrTPZTkeXFnJJ0151SoYM=.81d65abe-d9e9-4d9b-b29e-2d3d1786bbd1@github.com> References: <39hSBmv2gxYvEw52B0BjXiWrTPZTkeXFnJJ0151SoYM=.81d65abe-d9e9-4d9b-b29e-2d3d1786bbd1@github.com> Message-ID: On Thu, 13 Nov 2025 10:37:43 GMT, Albert Mingkun Yang wrote: >> I.e. the identifier `jfr` is throughout the GC code (from quick searching) always associated to `events` or the `tracer`. We already use names like `*JFRTracer*` (in G1) or `_jfr_tracer` (in ZGC) to (apparently to me) make it clear that the related code is about jfr. >> >> To me the term tracing is too generic, whenever I read such a name I always need to think about what kind of tracing for what is actually meant, as opposed to printing a (text) log message. With something like "jfr" in the name it is very clear that this is not something generic. > >> Because this is what the method does. > > But we don't/can't know that info in this context. > > I'd slightly leaned towards the old name, as there is no jfr in the current context. (Ofc, that's a diff story if `G1NewTracer` is renamed to `G1NewJfrTracer`, or sth.) Very subjective; up to you. FWIW, the term "Tracer" comes from the time when JFR was a closed-source feature. The open-source code used the term "tracer" as some-sort of an interface. JFR was the closed-source implementation of the "tracer". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28175#discussion_r2523320791 From tschatzl at openjdk.org Thu Nov 13 12:58:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 12:58:09 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v7] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * one more log message clarification wrt to non-young occupancy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28175/files - new: https://git.openjdk.org/jdk/pull/28175/files/0784435a..a089e35d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28175&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28175/head:pull/28175 PR: https://git.openjdk.org/jdk/pull/28175 From ayang at openjdk.org Thu Nov 13 13:11:00 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 13:11:00 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v7] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 12:58:09 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. >> >> I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. >> >> Testing: tier1-3, GHA >> >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * one more log message clarification wrt to non-young occupancy Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28175#pullrequestreview-3459720433 From ayang at openjdk.org Thu Nov 13 13:16:48 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 13:16:48 GMT Subject: RFR: 8371465: Parallel: Revise asserts around heap expansion [v2] In-Reply-To: References: Message-ID: > Revise heap/old-gen expansion asserts/comments to cover two paths: > > 1. startup: no gc can occur > 2. after-startup: during safepoint, by vm-thread. > > Test: tier1-4 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28266/files - new: https://git.openjdk.org/jdk/pull/28266/files/f590079b..59d7d1eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28266&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28266&range=00-01 Stats: 15 lines in 1 file changed: 12 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28266.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28266/head:pull/28266 PR: https://git.openjdk.org/jdk/pull/28266 From aboldtch at openjdk.org Thu Nov 13 13:26:13 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 13 Nov 2025 13:26:13 GMT Subject: RFR: 8371465: Parallel: Revise asserts around heap expansion [v2] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 13:16:48 GMT, Albert Mingkun Yang wrote: >> Revise heap/old-gen expansion asserts/comments to cover two paths: >> >> 1. startup: no gc can occur >> 2. after-startup: during safepoint, by vm-thread. >> >> Test: tier1-4 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good. Thanks! ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28266#pullrequestreview-3459776873 From tschatzl at openjdk.org Thu Nov 13 13:55:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 13:55:27 GMT Subject: RFR: 8371788: Fix documentation for CollectedHeap::collect(GCCause) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 12:04:34 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this trivial fix of the documentation of `Collectedheap::collect()` and all its overrides to indicate that it's not just used for `System.gc()` and will do a full collection. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Trivial! Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28289#issuecomment-3527924051 From tschatzl at openjdk.org Thu Nov 13 13:55:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 13:55:28 GMT Subject: Integrated: 8371788: Fix documentation for CollectedHeap::collect(GCCause) In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:33:53 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial fix of the documentation of `Collectedheap::collect()` and all its overrides to indicate that it's not just used for `System.gc()` and will do a full collection. > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: bbc0f9ef Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/bbc0f9ef30c467c8da8b873813bde50a7e9ff697 Stats: 10 lines in 4 files changed: 0 ins; 9 del; 1 mod 8371788: Fix documentation for CollectedHeap::collect(GCCause) Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28289 From tschatzl at openjdk.org Thu Nov 13 13:58:25 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 13:58:25 GMT Subject: RFR: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate [v7] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 13:08:38 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * one more log message clarification wrt to non-young occupancy > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for the reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28175#issuecomment-3527932949 From tschatzl at openjdk.org Thu Nov 13 13:58:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 13:58:27 GMT Subject: Integrated: 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 10:33:46 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that modifies heap occupancy reporting for IHOP to use the actual occupancy value the IHOP calculation actually uses. > > I.e. previously IHOP logging used to report `G1CollectedHeap::used()` as occupancy (which is correct at a general level), but for IHOP/marking that value is not interesting, but the "occupancy" value used for comparing against the current heap occupancy threshold. > > Testing: tier1-3, GHA > > Thomas This pull request has now been integrated. Changeset: 7d78818a Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/7d78818ae609461ab830c32c222f15f1cab0d2d4 Stats: 120 lines in 9 files changed: 42 ins; 29 del; 49 mod 8274178: G1: Occupancy value in IHOP logging and JFR event is inaccurate 8371635: G1: Young gen allocations should never be considered when comparing against IHOP threshold Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28175 From tschatzl at openjdk.org Thu Nov 13 14:10:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 14:10:02 GMT Subject: RFR: 8371465: Parallel: Revise asserts around heap expansion [v2] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 13:16:48 GMT, Albert Mingkun Yang wrote: >> Revise heap/old-gen expansion asserts/comments to cover two paths: >> >> 1. startup: no gc can occur >> 2. after-startup: during safepoint, by vm-thread. >> >> Test: tier1-4 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review okay ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28266#pullrequestreview-3459968485 From tschatzl at openjdk.org Thu Nov 13 14:10:33 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 14:10:33 GMT Subject: RFR: 8371791: G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation() Message-ID: Hi all, please review this change that improves the accuracy of `G1CollectedHeap::non_young_occupancy_after_allocation()` by considering the free space in the old gen retained region. Testing: tier1-3, gha Thanks, Thomas ------------- Commit messages: - 8371791 Changes: https://git.openjdk.org/jdk/pull/28294/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28294&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371791 Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28294.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28294/head:pull/28294 PR: https://git.openjdk.org/jdk/pull/28294 From tschatzl at openjdk.org Thu Nov 13 14:14:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 14:14:01 GMT Subject: RFR: 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize [v2] In-Reply-To: References: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> Message-ID: On Thu, 13 Nov 2025 06:22:38 GMT, Axel Boldt-Christmas wrote: >> G1YoungGenSizer ignores these values if they are not from the command line. Resulting in a different _sizer_kind than expected. >> The NewSize and MaxNewSize are also not bounded by the Initial and Max heap size respectively ([JDK-8370494](https://bugs.openjdk.org/browse/JDK-8370494)). >> >> I suggest we rewrite this logic using `!FLAG_IS_DEFAULT` to always get the correct behaviour. And only use `FLAG_IS_CMDLINE` for issuing warnings to the user when we ergonomically change or ignore these values to be compatible. >> As well as adding the proper truncation for HeapSize incompatible values. >> >> * Testing >> * GHA >> * Tier 1-5 on Oracle Supported Platforms > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Apply @walulyai suggestion Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28255#pullrequestreview-3459993443 From tschatzl at openjdk.org Thu Nov 13 14:17:00 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 13 Nov 2025 14:17:00 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Tue, 11 Nov 2025 17:50:43 GMT, Albert Mingkun Yang wrote: >> Trivial removing obsoleted code for unsupported arch. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Change looks good, but these AOT-related crashes should be fixed first. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28240#pullrequestreview-3460006822 From kdnilsen at openjdk.org Thu Nov 13 16:45:24 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 13 Nov 2025 16:45:24 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v9] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix race so freeset rebuild can happen concurrently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/18a49d8d..8f3751ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=07-08 Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From iklam at openjdk.org Thu Nov 13 17:04:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 13 Nov 2025 17:04:26 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: <9o8TjNxCbwshwMuqpS-CyyhwNciw1WQ6w1_ijy39DEc=.fe11d68c-f925-4c07-9c46-42c9093a5448@github.com> On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang wrote: > The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj. > > @iklam What do you think? I am working on a fix now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3528798525 From ysr at openjdk.org Thu Nov 13 17:09:12 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 13 Nov 2025 17:09:12 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v13] In-Reply-To: References: Message-ID: <74ZcsLnzeVJr4F54L7-nPE5IkWPHh77SLeHiXxlZzJ0=.c5061494-27d8-40ee-b1e5-18946853e2e9@github.com> On Mon, 10 Nov 2025 14:39:09 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: > > - Fix mistaken merge resolution > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > > The resulting fastdebug build has 64 failures. I need to debug these. > Probably introduced by improper resolution of merge conflicts > - fix error in merge conflict resolution > - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates > - rework CompressedClassSpaceSizeinJmapHeap.java > - fix errors in CompressedClassSpaceSizeInJmapHeap.java > - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java > - fix two indexing bugs > - add an assert to detect suspected bug > - Remove debug scaffolding > - ... and 48 more: https://git.openjdk.org/jdk/compare/c272aca8...16cd6f8a What if one used "garbage" as the sorting metric for efficiency (under assumption that I stated earlier of considering only retired, fully allocated regions -- the alternative makes the metric a bit more nuanced), and compute garbage as `[regionSize(or used assuming all of region allocated) - markedLive]`. This makes the metric invariant after final marking for any region considered in the target evacuation set, and you don't deal with trying to determine the amount allocated above TAMS, keeping the calculations simple and the selection and sorting criteria clean and easy to reason about. I also noticed that choosing selection set etc. takes the heap lock. Why? I'll leave more specific comments in the code later today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3528816403 From ayang at openjdk.org Thu Nov 13 17:11:05 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 17:11:05 GMT Subject: RFR: 8371791: G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation() In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 14:00:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that improves the accuracy of `G1CollectedHeap::non_young_occupancy_after_allocation()` by considering the free space in the old gen retained region. > > Testing: tier1-3, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28294#pullrequestreview-3460821247 From ayang at openjdk.org Thu Nov 13 17:21:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 13 Nov 2025 17:21:15 GMT Subject: RFR: 8371825: G1: Ues more precise filler API in fill_range_with_dead_objects Message-ID: Replace `fill_with_objects` with `fill_with_object` for dead-space inside a heap-region. Test: tier1-5 ------------- Commit messages: - g1-zap Changes: https://git.openjdk.org/jdk/pull/28302/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371825 Stats: 15 lines in 1 file changed: 0 ins; 10 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28302/head:pull/28302 PR: https://git.openjdk.org/jdk/pull/28302 From iwalulya at openjdk.org Thu Nov 13 17:24:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 13 Nov 2025 17:24:46 GMT Subject: RFR: 8371791: G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation() In-Reply-To: References: Message-ID: <-UyUWp9Dm4eLFh5lLFBadM_UIu1mlG9tlBItNU481PU=.b8da907d-0528-49e3-a699-9f87a8140764@github.com> On Thu, 13 Nov 2025 14:00:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that improves the accuracy of `G1CollectedHeap::non_young_occupancy_after_allocation()` by considering the free space in the old gen retained region. > > Testing: tier1-3, gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28294#pullrequestreview-3460877133 From xpeng at openjdk.org Thu Nov 13 17:39:28 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Thu, 13 Nov 2025 17:39:28 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 19:33:12 GMT, Rui Li wrote: >> Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. >> >> >> For `ShenandoahEvacReserve` change: when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 >> >> `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does so some of the jtreg would fail because of this change. Had to move this ergo setting to regular `FLAG_SET_DEFAULT`. >> >> Testing: jtreg gc. GHA pending. > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Move ShenandoahEvacReserve back to (1,100) Marked as reviewed by xpeng (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28242#pullrequestreview-3460930727 From duke at openjdk.org Thu Nov 13 17:48:17 2025 From: duke at openjdk.org (duke) Date: Thu, 13 Nov 2025 17:48:17 GMT Subject: RFR: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 19:33:12 GMT, Rui Li wrote: >> Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. >> >> >> For `ShenandoahEvacReserve` change: when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 >> >> `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does so some of the jtreg would fail because of this change. Had to move this ergo setting to regular `FLAG_SET_DEFAULT`. >> >> Testing: jtreg gc. GHA pending. > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > Move ShenandoahEvacReserve back to (1,100) @rgithubli Your change (at version 6200456b7130997d227dd5a128e4cefbd05059b5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28242#issuecomment-3528982588 From duke at openjdk.org Thu Nov 13 18:05:09 2025 From: duke at openjdk.org (Rui Li) Date: Thu, 13 Nov 2025 18:05:09 GMT Subject: Integrated: 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO In-Reply-To: References: Message-ID: <5VdDwrmM_qxAOSIr0KDwmQasQ6UPK-y_a-JMa5F0o-E=.e9c67c95-30ab-4037-90fb-5c2cdb22bfa3@github.com> On Tue, 11 Nov 2025 18:24:25 GMT, Rui Li wrote: > Setting ergo flags using `FLAG_SET_ERGO`, instead of `FLAG_SET_DEFAULT`, so we can have the right origin info. > > > For `ShenandoahEvacReserve` change: when we use shenandoah passive mode and degen is also turned off (`-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC`), we set the ShenandoahEvacReserve to 0: https://github.com/openjdk/jdk/blob/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f/src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp#L40-L42 > > `FLAG_SET_DEFAULT` doesn't check the range but `FLAG_SET_ERGO` does so some of the jtreg would fail because of this change. Had to move this ergo setting to regular `FLAG_SET_DEFAULT`. > > Testing: jtreg gc. GHA pending. This pull request has now been integrated. Changeset: 2199b5fe Author: Rui Li Committer: Xiaolong Peng URL: https://git.openjdk.org/jdk/commit/2199b5fef4540ae8da77c5c4feafc8822a3d9d3d Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod 8371381: [Shenandoah] Setting ergo flags should use FLAG_SET_ERGO Reviewed-by: xpeng, wkemper, ysr, cslucas ------------- PR: https://git.openjdk.org/jdk/pull/28242 From kdnilsen at openjdk.org Thu Nov 13 18:12:38 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 13 Nov 2025 18:12:38 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v3] In-Reply-To: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: > This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. > > This addresses a problem that results if available memory is probed while we are rebuilding the freeset. > > Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge remote-tracking branch 'jdk/master' into synchronize-available-with-rebuild - update comment - Add documentation for _rebuild_lock - Hide rebuild_lock inside prepare_to_rebuild and finish_rebuild - Rename rebuild_lock() - Tighten up context for holding rebuild_lock - Remove ShenandoahFreeSet::FreeSetUnderConstruction sentinel value - Revert "revert introduction of RebuildLock" This reverts commit bec73da1dc169d391e9919203e5a406ea02a699c. - Revert "available() returns previous value if called during freeset rebuild" This reverts commit 1a5e483a4abb04b6045175e8bd4b0c11fa68cb73. - Revert "remove obsolete assertion" This reverts commit 717e7da17f03f1e52008d154fafcbbfc5f2bb20e. - ... and 7 more: https://git.openjdk.org/jdk/compare/bfc048ab...8462a290 ------------- Changes: https://git.openjdk.org/jdk/pull/27612/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27612&range=02 Stats: 90 lines in 7 files changed: 44 ins; 29 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27612/head:pull/27612 PR: https://git.openjdk.org/jdk/pull/27612 From kdnilsen at openjdk.org Thu Nov 13 19:28:34 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 13 Nov 2025 19:28:34 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v10] In-Reply-To: References: Message-ID: <4xOcHBZN-D6qbe1vq5gMtvdXHbRVL8_jzhn_78THy98=.abb2c5ee-3188-4825-9066-6959ee49a9cd@github.com> > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix release build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/8f3751ff..68814cd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=08-09 Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From duke at openjdk.org Thu Nov 13 21:00:19 2025 From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac) Date: Thu, 13 Nov 2025 21:00:19 GMT Subject: RFR: 8371825: G1: Ues more precise filler API in fill_range_with_dead_objects In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 17:14:03 GMT, Albert Mingkun Yang wrote: > Replace `fill_with_objects` with `fill_with_object` for dead-space inside a heap-region. > > Test: tier1-5 There's a typo in the PR title: s/Ues/Use/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28302#issuecomment-3529681973 From kdnilsen at openjdk.org Thu Nov 13 21:06:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 13 Nov 2025 21:06:09 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v11] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Fix release build - Fix race so freeset rebuild can happen concurrently - Fix merge error - compute_old_generation_balance() during freeset rebuild - Initialize young evac reserve based on soft-max-capacity - Remove debug instrumentation - Merge branch 'share-collector-reserves' of https://github.com/kdnilsen/jdk into share-collector-reserves - fix whitespace - Merge remote-tracking branch 'jdk/master' into share-collector-reserves - Fix assert_bounds() assertions when old_trash_not_in_bounds - ... and 36 more: https://git.openjdk.org/jdk/compare/6322aaba...f0d99ae4 ------------- Changes: https://git.openjdk.org/jdk/pull/25357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=10 Stats: 1223 lines in 24 files changed: 725 ins; 259 del; 239 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From iklam at openjdk.org Fri Nov 14 04:48:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 14 Nov 2025 04:48:16 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2] In-Reply-To: <9o8TjNxCbwshwMuqpS-CyyhwNciw1WQ6w1_ijy39DEc=.fe11d68c-f925-4c07-9c46-42c9093a5448@github.com> References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> <9o8TjNxCbwshwMuqpS-CyyhwNciw1WQ6w1_ijy39DEc=.fe11d68c-f925-4c07-9c46-42c9093a5448@github.com> Message-ID: On Thu, 13 Nov 2025 17:01:45 GMT, Ioi Lam wrote: > > The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj. > > @iklam What do you think? > > I am working on a fix now. The fix is quite simple. See https://github.com/openjdk/jdk/pull/28315 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3530816677 From shade at openjdk.org Fri Nov 14 07:49:12 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 14 Nov 2025 07:49:12 GMT Subject: RFR: 8371825: G1: Ues more precise filler API in fill_range_with_dead_objects In-Reply-To: References: Message-ID: <040E9gyaB-qNLnQIfqUb67SoPt4B6CXE4LTrd0pIGME=.58fa0ad9-5e74-40aa-8ce6-3c476f5b09ba@github.com> On Thu, 13 Nov 2025 17:14:03 GMT, Albert Mingkun Yang wrote: > Replace `fill_with_objects` with `fill_with_object` for dead-space inside a heap-region. > > Test: tier1-5 Marked as reviewed by shade (Reviewer). (I also fixed the bug title, fix the PR title) ------------- PR Review: https://git.openjdk.org/jdk/pull/28302#pullrequestreview-3463353955 PR Comment: https://git.openjdk.org/jdk/pull/28302#issuecomment-3531376117 From tschatzl at openjdk.org Fri Nov 14 07:52:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 14 Nov 2025 07:52:06 GMT Subject: RFR: 8371825: G1: Ues more precise filler API in fill_range_with_dead_objects In-Reply-To: References: Message-ID: <-gfqxLq-vsw5NqniPAewBApYZFsh8uIH18zDkgPE0i8=.76562f3d-73a2-4187-a34b-8f232b41df79@github.com> On Thu, 13 Nov 2025 17:14:03 GMT, Albert Mingkun Yang wrote: > Replace `fill_with_objects` with `fill_with_object` for dead-space inside a heap-region. > > Test: tier1-5 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28302#pullrequestreview-3463374840 From jsikstro at openjdk.org Fri Nov 14 09:19:41 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 14 Nov 2025 09:19:41 GMT Subject: RFR: 8371702: ZGC: NUMA-Affinity for Worker Threads in the Relocation Phase [v4] In-Reply-To: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> References: <8MwCqbXOK29gIArQoejfDgRp97USf4oFsGq76ex0oLI=.635ac311-0fe5-40bb-9bc6-8fc4d2890ebe@github.com> Message-ID: > Hello, > > The main goal of this PR is to solve a performance regression in relatively small environments on a NUMA machine. See the associated issue for a more detailed explanation on regression itself. > > I propose we add functionality to set the affinity of worker threads in the Relocation Phase of ZGC so that the worker threads are *always* accessing NUMA-local memory when relocating objects. As soon as a worker threads is about to start relocating a new forwarding entry (or just page), it makes sure that it has the appropriate affinity set. At the most, each worker thread will set its own affinity the same number of times as there are NUMA nodes on the system. When the threads are about to exit the Relocation Phase (i.e. by completing `ZRelocateTask`), they "strip" their affinity so that they are allowed to run on any CPU that they were originally allowed to run on. > > I've done significant performance testing, which solves the observed regression and gives an additional performance boost in the same environments. I have not been able to observe similar boosts in performance on much larger environments (>=70 CPUs and >32GB memory) and also no regressions. 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 five additional commits since the last revision: - Merge branch 'pull/28261' into JDK-8371702_zgc_narc_regression_fix - Offline review feedback from Axel - Small comment fix - Comment fixes - 8371702: ZGC: NUMA-Affinity for Worker Threads in the Relocation Phase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28262/files - new: https://git.openjdk.org/jdk/pull/28262/files/8c0083c9..f8cd6aac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28262&range=02-03 Stats: 71 lines in 7 files changed: 20 ins; 23 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/28262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28262/head:pull/28262 PR: https://git.openjdk.org/jdk/pull/28262 From shade at openjdk.org Fri Nov 14 09:45:20 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 14 Nov 2025 09:45:20 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v7] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 01:03:28 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong bit masks(offset by 1) A bit confusing still. How about this: [x|xx|xxx|xx] ^---- Requester: 00 -- mutator 10 -- mutator (CDS) 01 -- GC ^------- Purpose: 00 -- shared 01 -- TLAB/GCLAB 11 -- PLAB ^---------- Affiliation: 00 -- YOUNG 01 -- OLD 11 -- OLD, promotion Then: static constexpr int bit_gc_alloc = 1 << 0; static constexpr int bit_cds_alloc = 1 << 1; static constexpr int bit_lab_alloc = 1 << 2; static constexpr int bit_plab_alloc = 1 << 3; static constexpr int bit_old_alloc = 1 << 4; static constexpr int bit_promotion_alloc = 1 << 5; static constexpr Type _alloc_shared = 0; static constexpr Type _alloc_tlab = bit_lab_alloc; static constexpr Type _alloc_cds = bit_cds_alloc; static constexpr Type _alloc_shared_gc = bit_gc_alloc; static constexpr Type _alloc_shared_gc_old = bit_gc_alloc | bit_old_alloc; static constexpr Type _alloc_shared_gc_promotion = bit_gc_alloc | bit_old_alloc | bit_promotion_alloc; static constexpr Type _alloc_gclab = bit_gc_alloc | bit_lab_alloc; static constexpr Type _alloc_plab = bit_gc_alloc | bit_plab_alloc | bit_old_alloc; ------------- PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3463990104 From tschatzl at openjdk.org Fri Nov 14 12:09:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 14 Nov 2025 12:09:20 GMT Subject: RFR: 8371895: G1: TestUseGCOverheadLimit.java#G1 fails Message-ID: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Hi all, please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. Testing: gha, reporter Thanks, Thomas ------------- Commit messages: - 8371895 Changes: https://git.openjdk.org/jdk/pull/28321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371895 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28321/head:pull/28321 PR: https://git.openjdk.org/jdk/pull/28321 From tschatzl at openjdk.org Fri Nov 14 12:53:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 14 Nov 2025 12:53:28 GMT Subject: RFR: 8371791: G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation() In-Reply-To: References: Message-ID: <1DcLhODQBQGdLyGMVE9bFjdORukJuk8WvJuPqWejJoY=.f20095fb-63c7-498c-a2dc-fb9e8b6edc9f@github.com> On Thu, 13 Nov 2025 17:08:40 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that improves the accuracy of `G1CollectedHeap::non_young_occupancy_after_allocation()` by considering the free space in the old gen retained region. >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thank you for your reviews, @albertnetymk @walulyai . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28294#issuecomment-3532581038 From tschatzl at openjdk.org Fri Nov 14 12:53:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 14 Nov 2025 12:53:29 GMT Subject: Integrated: 8371791: G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation() In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 14:00:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that improves the accuracy of `G1CollectedHeap::non_young_occupancy_after_allocation()` by considering the free space in the old gen retained region. > > Testing: tier1-3, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 4cc655a2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/4cc655a2f445bb32ce555b80ac28610b26c51f4c Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod 8371791: G1: Improve accuracy of G1CollectedHeap::non_young_occupancy_after_allocation() Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28294 From ayang at openjdk.org Fri Nov 14 13:43:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 14 Nov 2025 13:43:09 GMT Subject: RFR: 8371895: G1: TestUseGCOverheadLimit.java#G1 fails In-Reply-To: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> References: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Message-ID: On Fri, 14 Nov 2025 11:59:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. > > Testing: gha, reporter > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28321#pullrequestreview-3464999695 From iwalulya at openjdk.org Fri Nov 14 14:44:35 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 14 Nov 2025 14:44:35 GMT Subject: RFR: 8371895: G1: TestUseGCOverheadLimit.java#G1 fails In-Reply-To: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> References: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Message-ID: On Fri, 14 Nov 2025 11:59:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. > > Testing: gha, reporter > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28321#pullrequestreview-3465261242 From shade at openjdk.org Fri Nov 14 15:34:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 14 Nov 2025 15:34:53 GMT Subject: RFR: 8371895: G1: TestUseGCOverheadLimit.java#G1 fails In-Reply-To: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> References: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Message-ID: On Fri, 14 Nov 2025 11:59:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. > > Testing: gha, reporter > > Thanks, > Thomas Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28321#pullrequestreview-3465477060 From iklam at openjdk.org Fri Nov 14 19:13:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 14 Nov 2025 19:13:04 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: <09Z7-ZZkmzO2T0nkSl3czZlkhJPzun79PkiNngWrQcU=.472c6dd5-5f54-42f2-ae16-62cc74c197fe@github.com> On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang wrote: >> We have seen crashes on many platforms (including x64) while running `make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"`: >> >> SIGSEGV (0xb) at pc=0x00007f2f95a61e7a, pid=18554, tid=18557 >> V [libjvm.so+0x15bfe7a] MemAllocator::finish(HeapWordImpl**) const+0xca (klass.inline.hpp:72) >> V [libjvm.so+0x15c029f] ObjAllocator::initialize(HeapWordImpl**) const+0x2f (memAllocator.cpp:391) >> V [libjvm.so+0xb0630b] CollectedHeap::fill_with_object(HeapWordImpl**, unsigned long, bool)+0x27b (collectedHeap.cpp:491) >> V [libjvm.so+0x1c7a0bb] ThreadLocalAllocBuffer::retire(ThreadLocalAllocStats*)+0x11b (threadLocalAllocBuffer.cpp:118) >> V [libjvm.so+0x15c0b14] MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x84 (memAllocator.cpp:286) >> V [libjvm.so+0x15c13ab] MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0xbb (memAllocator.cpp:340) >> V [libjvm.so+0x15c14f9] MemAllocator::allocate() const+0xa9 (memAllocator.cpp:353) >> V [libjvm.so+0x1cc052e] TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13e (collectedHeap.inline.hpp:41) >> V [libjvm.so+0x16fbc98] oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38 (typeArrayKlass.hpp:51) >> V [libjvm.so+0x106b0f3] java_lang_Class::restore_archived_mirror(Klass*, Handle, Handle, Handle, JavaThread*)+0x413 (javaClasses.cpp:1246) >> V [libjvm.so+0x14100bc] Klass::restore_unshareable_info(ClassLoaderData*, Handle, JavaThread*)+0x66c (klass.cpp:903) >> V [libjvm.so+0xfe2cb1] InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, PackageEntry*, JavaThread*)+0x81 (instanceKlass.cpp:2823) >> V [libjvm.so+0x1c0f5ad] SystemDictionary::preload_class(Handle, InstanceKlass*, JavaThread*)+0x1ed (systemDictionary.cpp:1198) >> V [libjvm.so+0x676e83] AOTLinkedClassBulkLoader::preload_classes_in_table(Array*, char const*, Handle, JavaThread*)+0x1a3 (aotLinkedClassBulkLoader.cpp:103) >> V [libjvm.so+0x679af5] AOTLinkedClassBulkLoader::preload_classes_impl(JavaThread*)+0x165 (aotLinkedClassBulkLoader.cpp:76) >> V [libjvm.so+0x67c371] AOTLinkedClassBulkLoader::preload_classes(JavaThread*)+0x11 (aotLinkedClassBulkLoader.cpp:61) >> V [libjvm.so+0x1d5bf30] vmClasses::resolve_all(JavaThread*)+0x3e0 (vmClasses.cpp:126) >> V [libjvm.so+0x1c0f28c] SystemDictionary::initialize(JavaThread*)+0x10c (systemDictionary.cpp:1623) >> V [libjvm.so+0x1cc74ca] Uni... > >> ... make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders" > > I suspect the crash is caused by a preexisting issue that is exposed by this patch. > > In `vmClasses::resolve_all`: > > #if INCLUDE_CDS > if (CDSConfig::is_using_aot_linked_classes()) { > AOTLinkedClassBulkLoader::preload_classes(THREAD); > } > #endif > > // Preload commonly used klasses > vmClassID scan = vmClassID::FIRST; > // first do Object, then String, Class > resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK); > CollectedHeap::set_filler_object_klass(vmClasses::Object_klass()); > > > The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj. > > @iklam What do you think? @albertnetymk I've pushed https://github.com/openjdk/jdk/pull/28315. Please verify if it fixes the crash before integrating this PR. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3534185759 From ayang at openjdk.org Fri Nov 14 19:22:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 14 Nov 2025 19:22:39 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v3] In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: > Trivial removing obsoleted code for unsupported arch. > > Test: tier1 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into remove-tlab-reserve - review - remove-tlab-reserve ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28240/files - new: https://git.openjdk.org/jdk/pull/28240/files/0e447848..d6c34da7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28240&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28240&range=01-02 Stats: 10141 lines in 159 files changed: 5771 ins; 3554 del; 816 mod Patch: https://git.openjdk.org/jdk/pull/28240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28240/head:pull/28240 PR: https://git.openjdk.org/jdk/pull/28240 From duke at openjdk.org Fri Nov 14 20:44:24 2025 From: duke at openjdk.org (Nityanand Rai) Date: Fri, 14 Nov 2025 20:44:24 GMT Subject: RFR: 8371852: Shenandoah: Remove unused =?UTF-8?B?U2hlbmFuZG9haEZyZWVTZXQ6Ol9hbGxvY2F0ZWRfc2luY+KApg==?= Message-ID: Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. ------------- Commit messages: - 8371852: Shenandoah: Remove unused ShenandoahFreeSet::_allocated_since_gc_start field Changes: https://git.openjdk.org/jdk/pull/28332/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28332&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371852 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28332/head:pull/28332 PR: https://git.openjdk.org/jdk/pull/28332 From duke at openjdk.org Fri Nov 14 21:05:46 2025 From: duke at openjdk.org (Nityanand Rai) Date: Fri, 14 Nov 2025 21:05:46 GMT Subject: RFR: 8371852: Shenandoah: Remove unused =?UTF-8?B?U2hlbmFuZG9haEZyZWVTZXQ6Ol9hbGxvY2F0ZWRfc2luY+KApg==?= [v2] In-Reply-To: References: Message-ID: > Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. 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 two additional commits since the last revision: - Merge branch 'openjdk:master' into 8371852-nityanar - 8371852: Shenandoah: Remove unused ShenandoahFreeSet::_allocated_since_gc_start field Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. Reviewed-by: TBD ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28332/files - new: https://git.openjdk.org/jdk/pull/28332/files/e7dbd54e..887d25e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28332&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28332&range=00-01 Stats: 164817 lines in 903 files changed: 113165 ins; 23348 del; 28304 mod Patch: https://git.openjdk.org/jdk/pull/28332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28332/head:pull/28332 PR: https://git.openjdk.org/jdk/pull/28332 From duke at openjdk.org Fri Nov 14 21:49:46 2025 From: duke at openjdk.org (Nityanand Rai) Date: Fri, 14 Nov 2025 21:49:46 GMT Subject: RFR: 8371854: Shenandoah - Simplify WALK_FORWARD_IN_BLOCK_START use Message-ID: Replace define/undefine pattern with #ifdef ASSERT block ------------- Commit messages: - Update JDK-8371854 fix: Simplify WALK_FORWARD_IN_BLOCK_START macro usage Changes: https://git.openjdk.org/jdk/pull/28333/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28333&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371854 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28333/head:pull/28333 PR: https://git.openjdk.org/jdk/pull/28333 From ysr at openjdk.org Sat Nov 15 00:22:16 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 15 Nov 2025 00:22:16 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v3] In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Thu, 13 Nov 2025 18:12:38 GMT, Kelvin Nilsen wrote: >> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. >> >> This addresses a problem that results if available memory is probed while we are rebuilding the freeset. >> >> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge remote-tracking branch 'jdk/master' into synchronize-available-with-rebuild > - update comment > - Add documentation for _rebuild_lock > - Hide rebuild_lock inside prepare_to_rebuild and finish_rebuild > - Rename rebuild_lock() > - Tighten up context for holding rebuild_lock > - Remove ShenandoahFreeSet::FreeSetUnderConstruction sentinel value > - Revert "revert introduction of RebuildLock" > > This reverts commit bec73da1dc169d391e9919203e5a406ea02a699c. > - Revert "available() returns previous value if called during freeset rebuild" > > This reverts commit 1a5e483a4abb04b6045175e8bd4b0c11fa68cb73. > - Revert "remove obsolete assertion" > > This reverts commit 717e7da17f03f1e52008d154fafcbbfc5f2bb20e. > - ... and 7 more: https://git.openjdk.org/jdk/compare/bfc048ab...8462a290 src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 790: > 788: inline size_t available() { > 789: shenandoah_assert_not_heaplocked(); > 790: ShenandoahRebuildLocker locker(rebuild_lock()); May be motivate in a brief comment why we need the rebuild lock in this API, but not around the other APIs such as capacity() and used()? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2529307229 From ysr at openjdk.org Sat Nov 15 00:36:45 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 15 Nov 2025 00:36:45 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v3] In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Thu, 13 Nov 2025 18:12:38 GMT, Kelvin Nilsen wrote: >> This code introduces a new rebuild-freeset lock for purposes of coordinating the freeset rebuild activities and queries as to memory available for allocation in the mutator partition. >> >> This addresses a problem that results if available memory is probed while we are rebuilding the freeset. >> >> Rather than using the existing global heap lock to synchronize these activities, a new more narrowly scoped lock is introduced. This allows the available memory to be probed even when other activities hold the global heap lock for reasons other than rebuilding the freeset, such as when they are allocating memory. It is known that the global heap lock is heavily contended for certain workloads, and using this new lock avoids adding to contention for the global heap lock. > > Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge remote-tracking branch 'jdk/master' into synchronize-available-with-rebuild > - update comment > - Add documentation for _rebuild_lock > - Hide rebuild_lock inside prepare_to_rebuild and finish_rebuild > - Rename rebuild_lock() > - Tighten up context for holding rebuild_lock > - Remove ShenandoahFreeSet::FreeSetUnderConstruction sentinel value > - Revert "revert introduction of RebuildLock" > > This reverts commit bec73da1dc169d391e9919203e5a406ea02a699c. > - Revert "available() returns previous value if called during freeset rebuild" > > This reverts commit 1a5e483a4abb04b6045175e8bd4b0c11fa68cb73. > - Revert "remove obsolete assertion" > > This reverts commit 717e7da17f03f1e52008d154fafcbbfc5f2bb20e. > - ... and 7 more: https://git.openjdk.org/jdk/compare/bfc048ab...8462a290 This looks good to me. Curious if any performance delta was noted in fresh measurements following this final shape of fix. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27612#pullrequestreview-3467303404 From duke at openjdk.org Sat Nov 15 00:50:36 2025 From: duke at openjdk.org (duke) Date: Sat, 15 Nov 2025 00:50:36 GMT Subject: Withdrawn: 8367754: G1: Add a fast path in heap resize related method In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:32:12 GMT, Guanqiang Han wrote: > Please review this change. > > **Description:** > > It's common for some Java application engineers to configure the heap with the same minimum and maximum size in order to avoid the overhead of heap resizing.In such cases no expansion or shrinkage is possible, so i think we can adds a fast path at the beginning of the method to detect when the heap?s min and max capacities are equal and return early, thereby avoiding unnecessary computation. > I added a check to determine whether MinHeapSize and MaxHeapSize are equal before performing the heap resize calculation. Since both MaxHeapSize and MinHeapSize are aligned to HeapAlignment, so i think comparing them directly is good. > > **Test:** > > GHA This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27349 From kdnilsen at openjdk.org Sat Nov 15 00:55:18 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 15 Nov 2025 00:55:18 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v12] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Do not reset generation reserves at end of GC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/f0d99ae4..6b62448d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=10-11 Stats: 29 lines in 3 files changed: 0 ins; 29 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From ysr at openjdk.org Sat Nov 15 01:56:05 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 15 Nov 2025 01:56:05 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> References: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> Message-ID: On Tue, 11 Nov 2025 00:33:36 GMT, William Kemper wrote: >> When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Revert "We can also filter out old when striclty marking young" > > This reverts commit c53c4f23f4401785e1049494b6c4e4b92f9a5701. Thank you for the clean up and corrections. I am curious how you found this issue -- nice catch! Any performance data to share, may be even from a microbenchmark perhaps or any other benchmark that exercises array copying -- may be something in DaCapo/Renaissance? ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28183#pullrequestreview-3467459541 From mdoerr at openjdk.org Sun Nov 16 13:23:07 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Sun, 16 Nov 2025 13:23:07 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v2] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Thu, 13 Nov 2025 11:35:04 GMT, Albert Mingkun Yang wrote: >> We have seen crashes on many platforms (including x64) while running `make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders"`: >> >> SIGSEGV (0xb) at pc=0x00007f2f95a61e7a, pid=18554, tid=18557 >> V [libjvm.so+0x15bfe7a] MemAllocator::finish(HeapWordImpl**) const+0xca (klass.inline.hpp:72) >> V [libjvm.so+0x15c029f] ObjAllocator::initialize(HeapWordImpl**) const+0x2f (memAllocator.cpp:391) >> V [libjvm.so+0xb0630b] CollectedHeap::fill_with_object(HeapWordImpl**, unsigned long, bool)+0x27b (collectedHeap.cpp:491) >> V [libjvm.so+0x1c7a0bb] ThreadLocalAllocBuffer::retire(ThreadLocalAllocStats*)+0x11b (threadLocalAllocBuffer.cpp:118) >> V [libjvm.so+0x15c0b14] MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&) const+0x84 (memAllocator.cpp:286) >> V [libjvm.so+0x15c13ab] MemAllocator::mem_allocate(MemAllocator::Allocation&) const+0xbb (memAllocator.cpp:340) >> V [libjvm.so+0x15c14f9] MemAllocator::allocate() const+0xa9 (memAllocator.cpp:353) >> V [libjvm.so+0x1cc052e] TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13e (collectedHeap.inline.hpp:41) >> V [libjvm.so+0x16fbc98] oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38 (typeArrayKlass.hpp:51) >> V [libjvm.so+0x106b0f3] java_lang_Class::restore_archived_mirror(Klass*, Handle, Handle, Handle, JavaThread*)+0x413 (javaClasses.cpp:1246) >> V [libjvm.so+0x14100bc] Klass::restore_unshareable_info(ClassLoaderData*, Handle, JavaThread*)+0x66c (klass.cpp:903) >> V [libjvm.so+0xfe2cb1] InstanceKlass::restore_unshareable_info(ClassLoaderData*, Handle, PackageEntry*, JavaThread*)+0x81 (instanceKlass.cpp:2823) >> V [libjvm.so+0x1c0f5ad] SystemDictionary::preload_class(Handle, InstanceKlass*, JavaThread*)+0x1ed (systemDictionary.cpp:1198) >> V [libjvm.so+0x676e83] AOTLinkedClassBulkLoader::preload_classes_in_table(Array*, char const*, Handle, JavaThread*)+0x1a3 (aotLinkedClassBulkLoader.cpp:103) >> V [libjvm.so+0x679af5] AOTLinkedClassBulkLoader::preload_classes_impl(JavaThread*)+0x165 (aotLinkedClassBulkLoader.cpp:76) >> V [libjvm.so+0x67c371] AOTLinkedClassBulkLoader::preload_classes(JavaThread*)+0x11 (aotLinkedClassBulkLoader.cpp:61) >> V [libjvm.so+0x1d5bf30] vmClasses::resolve_all(JavaThread*)+0x3e0 (vmClasses.cpp:126) >> V [libjvm.so+0x1c0f28c] SystemDictionary::initialize(JavaThread*)+0x10c (systemDictionary.cpp:1623) >> V [libjvm.so+0x1cc74ca] Uni... > >> ... make run-test TEST=runtime/cds/appcds/aotClassLinking/LambdaInExcludedClass.java JTREG="VM_OPTIONS=-XX:+UseCompactObjectHeaders" > > I suspect the crash is caused by a preexisting issue that is exposed by this patch. > > In `vmClasses::resolve_all`: > > #if INCLUDE_CDS > if (CDSConfig::is_using_aot_linked_classes()) { > AOTLinkedClassBulkLoader::preload_classes(THREAD); > } > #endif > > // Preload commonly used klasses > vmClassID scan = vmClassID::FIRST; > // first do Object, then String, Class > resolve_through(VM_CLASS_ID(Object_klass), scan, CHECK); > CollectedHeap::set_filler_object_klass(vmClasses::Object_klass()); > > > The filler-klass is not initialized when `preload_classes` is invoked, but `preload_classes` use heap-allocation, which may require filler-obj. > > @iklam What do you think? > @albertnetymk I've pushed #28315. Please verify if it fixes the crash before integrating this PR. Thanks! The crashes are fixed. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3538748578 From mdoerr at openjdk.org Sun Nov 16 13:42:02 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Sun, 16 Nov 2025 13:42:02 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch In-Reply-To: <8ikwqN309ZPAORjL2YvE1hgvChrTfhi3slz1r4XIK5E=.41d37c1b-ae3e-43f5-9fe0-43ae2294e57c@github.com> References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> <8ikwqN309ZPAORjL2YvE1hgvChrTfhi3slz1r4XIK5E=.41d37c1b-ae3e-43f5-9fe0-43ae2294e57c@github.com> Message-ID: On Tue, 11 Nov 2025 16:18:04 GMT, Vladimir Kozlov wrote: >> Trivial removing obsoleted code for unsupported arch. >> >> Test: tier1 > > Please ask all OpenJDK platforms supporters to test these changes. > > Note, when this code was introduced we did not have so many platforms. This change looks incomplete to me. @vnkozlov: Shouldn't we remove `AllocatePrefetchStyle == 3` completely? `PhaseMacroExpand::prefetch_allocation` still mentions "BIS instruction is used on SPARC as prefetch". Please note that PPC64 also still has an implementation for it (nodes with `predicate(AllocatePrefetchStyle == 3)`). I guess that we don't need it any more. Maybe we should check performance again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3538765487 From ayang at openjdk.org Sun Nov 16 17:19:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 16 Nov 2025 17:19:13 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v3] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Fri, 14 Nov 2025 19:22:39 GMT, Albert Mingkun Yang wrote: >> Trivial removing obsoleted code for unsupported arch. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into remove-tlab-reserve > - review > - remove-tlab-reserve `AllocatePrefetchStyle == 3` means "generate one prefetch instruction per cache line". This patch removes the reserved alignment that was required for `AllocatePrefetchStyle == 3` on SPARC, but that does not imply that `AllocatePrefetchStyle == 3` itself should be removed. (Maybe a separate ticket if it's indeed deemed useless.) > PhaseMacroExpand::prefetch_allocation still mentions "BIS instruction is used on SPARC as prefetch". Will remove it in the next revision. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3538970541 From mdoerr at openjdk.org Sun Nov 16 21:13:05 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Sun, 16 Nov 2025 21:13:05 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v3] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Fri, 14 Nov 2025 19:22:39 GMT, Albert Mingkun Yang wrote: >> Trivial removing obsoleted code for unsupported arch. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into remove-tlab-reserve > - review > - remove-tlab-reserve At least PPC64 will need an update because your change breaks the following nodes: diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad index 7fcd096d2ad..c169d673aaf 100644 --- a/src/hotspot/cpu/ppc/ppc.ad +++ b/src/hotspot/cpu/ppc/ppc.ad @@ -6328,36 +6328,8 @@ instruct loadConD_Ex(regD dst, immD src) %{ // Prefetch instructions. // Must be safe to execute with invalid address (cannot fault). -// Special prefetch versions which use the dcbz instruction. -instruct prefetch_alloc_zero(indirectMemory mem, iRegLsrc src) %{ - match(PrefetchAllocation (AddP mem src)); - predicate(AllocatePrefetchStyle == 3); - ins_cost(MEMORY_REF_COST); - - format %{ "PREFETCH $mem, 2, $src \t// Prefetch write-many with zero" %} - size(4); - ins_encode %{ - __ dcbz($src$$Register, $mem$$base$$Register); - %} - ins_pipe(pipe_class_memory); -%} - -instruct prefetch_alloc_zero_no_offset(indirectMemory mem) %{ - match(PrefetchAllocation mem); - predicate(AllocatePrefetchStyle == 3); - ins_cost(MEMORY_REF_COST); - - format %{ "PREFETCH $mem, 2 \t// Prefetch write-many with zero" %} - size(4); - ins_encode %{ - __ dcbz($mem$$base$$Register); - %} - ins_pipe(pipe_class_memory); -%} - instruct prefetch_alloc(indirectMemory mem, iRegLsrc src) %{ match(PrefetchAllocation (AddP mem src)); - predicate(AllocatePrefetchStyle != 3); ins_cost(MEMORY_REF_COST); format %{ "PREFETCH $mem, 2, $src \t// Prefetch write-many" %} @@ -6370,7 +6342,6 @@ instruct prefetch_alloc(indirectMemory mem, iRegLsrc src) %{ instruct prefetch_alloc_no_offset(indirectMemory mem) %{ match(PrefetchAllocation mem); - predicate(AllocatePrefetchStyle != 3); ins_cost(MEMORY_REF_COST); format %{ "PREFETCH $mem, 2 \t// Prefetch write-many" %} ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3539357960 From dholmes at openjdk.org Mon Nov 17 01:26:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 17 Nov 2025 01:26:14 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> On Thu, 30 Oct 2025 12:06:00 GMT, Afshin Zafari wrote: >> The issue happens when the HeapMinBaseAddress option gets 0 as input value. Since this option is used as an address, then using 0 in pointer arithmetics is UB. >> The fix is using `unitptr_t` instead of `address`/`char*`, etc. In doing that, it is found that an overflow check does not work in all cases due to checking more conditions. That overflow check is changed too. We also need to check overflow after aligning addresses and sizes of memory regions in this context. Assertions are added to check these cases. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix arguments.cpp for HeapMinBaseAddress type. Sorry but I am finding that the actual fix here is getting lost in a lot of not-obviously-needed changes to variable type declarations. src/hotspot/share/memory/memoryReserver.cpp line 549: > 547: const size_t attach_point_alignment = lcm(alignment, os_attach_point_alignment); > 548: > 549: uintptr_t aligned_heap_base_min_address = align_up(MAX2(HeapBaseMinAddress, alignment), alignment); Just to be clear, this is the crux of the fix, where we ensure the min-address is now never zero - right? src/hotspot/share/memory/memoryReserver.cpp line 586: > 584: lowest_start, highest_start); > 585: reserved = try_reserve_range((char*)highest_start, (char*)lowest_start, attach_point_alignment, > 586: (char*)aligned_heap_base_min_address, (char*)UnscaledOopHeapMax, size, alignment, page_size); Not obvious to me this actually improves anything - what is it fixing? src/hotspot/share/memory/memoryReserver.cpp line 590: > 588: > 589: // zerobased: Attempt to allocate in the lower 32G. > 590: size_t zerobased_max = OopEncodingHeapMax; Again not obvious what this improves. We obviously have very inconsistent use of types here in that we loosely use `char*`, `uint64_t` and `size_t` to all mean a 64-bit unsigned value, ansd no matter what types we use in the declarations we have to cast something somewhere. ------------- PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3470648246 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2532394079 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2532395457 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2532399134 From xpeng at openjdk.org Mon Nov 17 06:21:56 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 06:21:56 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v8] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision: - touch up - Update bits encoding scheme and comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/131f6a6a..2fa1e443 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=06-07 Stats: 21 lines in 1 file changed: 8 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Mon Nov 17 06:25:29 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 06:25:29 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v9] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/2fa1e443..f875355f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Mon Nov 17 06:46:30 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 06:46:30 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v10] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: _alloc_plab is also lab alloc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/f875355f..66352ab0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Mon Nov 17 07:10:13 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 07:10:13 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v7] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 09:42:46 GMT, Aleksey Shipilev wrote: > A bit confusing still. How about this: > > ``` > [x|xx|xxx|xx] > ^---- Requester: > 00 -- mutator > 10 -- mutator (CDS) > 01 -- GC > ^------- Purpose: > 00 -- shared > 01 -- TLAB/GCLAB > 11 -- PLAB > ^---------- Affiliation: > 00 -- YOUNG > 01 -- OLD > 11 -- OLD, promotion > ``` > > Then: > > ``` > static constexpr int bit_gc_alloc = 1 << 0; > static constexpr int bit_cds_alloc = 1 << 1; > static constexpr int bit_lab_alloc = 1 << 2; > static constexpr int bit_plab_alloc = 1 << 3; > static constexpr int bit_old_alloc = 1 << 4; > static constexpr int bit_promotion_alloc = 1 << 5; > > static constexpr Type _alloc_shared = 0; > static constexpr Type _alloc_tlab = bit_lab_alloc; > static constexpr Type _alloc_cds = bit_cds_alloc; > static constexpr Type _alloc_shared_gc = bit_gc_alloc; > static constexpr Type _alloc_shared_gc_old = bit_gc_alloc | bit_old_alloc; > static constexpr Type _alloc_shared_gc_promotion = bit_gc_alloc | bit_old_alloc | bit_promotion_alloc; > static constexpr Type _alloc_gclab = bit_gc_alloc | bit_lab_alloc; > static constexpr Type _alloc_plab = bit_gc_alloc | bit_plab_alloc | bit_old_alloc; > ``` Thanks Aleksey! This is good, I have applied the change, and fixed the wrong value for _alloc_plab, it should be `bit_gc_alloc | bit_lab_alloc | bit_plab_alloc | bit_old_alloc`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3540274358 From aboldtch at openjdk.org Mon Nov 17 07:36:15 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 17 Nov 2025 07:36:15 GMT Subject: RFR: 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize [v2] In-Reply-To: References: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> Message-ID: On Thu, 13 Nov 2025 06:22:38 GMT, Axel Boldt-Christmas wrote: >> G1YoungGenSizer ignores these values if they are not from the command line. Resulting in a different _sizer_kind than expected. >> The NewSize and MaxNewSize are also not bounded by the Initial and Max heap size respectively ([JDK-8370494](https://bugs.openjdk.org/browse/JDK-8370494)). >> >> I suggest we rewrite this logic using `!FLAG_IS_DEFAULT` to always get the correct behaviour. And only use `FLAG_IS_CMDLINE` for issuing warnings to the user when we ergonomically change or ignore these values to be compatible. >> As well as adding the proper truncation for HeapSize incompatible values. >> >> * Testing >> * GHA >> * Tier 1-5 on Oracle Supported Platforms > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Apply @walulyai suggestion Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28255#issuecomment-3540339107 From aboldtch at openjdk.org Mon Nov 17 07:36:17 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 17 Nov 2025 07:36:17 GMT Subject: Integrated: 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize In-Reply-To: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> References: <3mS8PgylKpJwLtEUK4cbgB3IG9liy9SuiCUbruTa7-c=.f6fbd5b0-abfa-4a59-a32d-9d11aadb1eec@github.com> Message-ID: On Wed, 12 Nov 2025 07:40:01 GMT, Axel Boldt-Christmas wrote: > G1YoungGenSizer ignores these values if they are not from the command line. Resulting in a different _sizer_kind than expected. > The NewSize and MaxNewSize are also not bounded by the Initial and Max heap size respectively ([JDK-8370494](https://bugs.openjdk.org/browse/JDK-8370494)). > > I suggest we rewrite this logic using `!FLAG_IS_DEFAULT` to always get the correct behaviour. And only use `FLAG_IS_CMDLINE` for issuing warnings to the user when we ergonomically change or ignore these values to be compatible. > As well as adding the proper truncation for HeapSize incompatible values. > > * Testing > * GHA > * Tier 1-5 on Oracle Supported Platforms This pull request has now been integrated. Changeset: ce1adf63 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/ce1adf63ea1146fba4cf36c10dc5f1d33aa88000 Stats: 73 lines in 1 file changed: 49 ins; 1 del; 23 mod 8371672: G1: G1YoungGenSizer handling of NewRatio, NewSize and MaxNewSize 8370494: G1: NewSize not bounded by InitialHeapSize or MaxHeapSize Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28255 From ayang at openjdk.org Mon Nov 17 09:31:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 09:31:08 GMT Subject: RFR: 8371895: G1: TestUseGCOverheadLimit.java#G1 fails In-Reply-To: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> References: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Message-ID: On Fri, 14 Nov 2025 11:59:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. > > Testing: gha, reporter > > Thanks, > Thomas test/hotspot/jtreg/gc/TestUseGCOverheadLimit.java line 70: > 68: "-XX:+UseGCOverheadLimit", > 69: "-Xlog:gc=debug", > 70: "-XX:GCTimeLimit=80", // Ease the CPU requirement. I think the title can probably be revised a bit, as this changes common args, not just G1-specific ones. Maybe sth like "Lower GCTimeLimit in TestUseGCOverheadLimit.java". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28321#discussion_r2533347470 From shade at openjdk.org Mon Nov 17 09:34:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 17 Nov 2025 09:34:41 GMT Subject: RFR: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:40:42 GMT, Nityanand Rai wrote: > Replace define/undefine pattern with #ifdef ASSERT block This looks fine to me, but I think we want to go a bit further. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 383: > 381: oop obj = cast_to_oop(p); > 382: assert(oopDesc::is_oop(obj), "Should be an object"); > 383: #ifdef ASSERT Minor: Move `#ifdef ASSERT` before `oop obj = ...` assignment. I am fairly certain that load would be folded in product configuration, but there is no point in risking it. Same with `#endif` below, move it just before return. Plus, change `guarantee(false, "...")` to `fatal("...")`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28333#pullrequestreview-3471823341 PR Review Comment: https://git.openjdk.org/jdk/pull/28333#discussion_r2533354653 From shade at openjdk.org Mon Nov 17 09:34:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 17 Nov 2025 09:34:40 GMT Subject: RFR: 8371852: Shenandoah: Unused ShenandoahFreeSet::_allocated_since_gc_start field [v2] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:05:46 GMT, Nityanand Rai wrote: >> Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. > > 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8371852-nityanar > - 8371852: Shenandoah: Remove unused ShenandoahFreeSet::_allocated_since_gc_start field > > Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from > ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 > unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. > > Reviewed-by: TBD Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28332#pullrequestreview-3471825940 From ayang at openjdk.org Mon Nov 17 09:35:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 09:35:49 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v4] In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: > Trivial removing obsoleted code for unsupported arch. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: - review - patch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28240/files - new: https://git.openjdk.org/jdk/pull/28240/files/d6c34da7..6c5a07ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28240&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28240&range=02-03 Stats: 31 lines in 2 files changed: 0 ins; 30 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28240/head:pull/28240 PR: https://git.openjdk.org/jdk/pull/28240 From ayang at openjdk.org Mon Nov 17 09:38:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 09:38:02 GMT Subject: RFR: 8371465: Parallel: Revise asserts around heap expansion [v2] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 13:16:48 GMT, Albert Mingkun Yang wrote: >> Revise heap/old-gen expansion asserts/comments to cover two paths: >> >> 1. startup: no gc can occur >> 2. after-startup: during safepoint, by vm-thread. >> >> Test: tier1-4 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28266#issuecomment-3540730457 From ayang at openjdk.org Mon Nov 17 09:41:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 09:41:26 GMT Subject: Integrated: 8371465: Parallel: Revise asserts around heap expansion In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 13:14:34 GMT, Albert Mingkun Yang wrote: > Revise heap/old-gen expansion asserts/comments to cover two paths: > > 1. startup: no gc can occur > 2. after-startup: during safepoint, by vm-thread. > > Test: tier1-4 This pull request has now been integrated. Changeset: 09b25cd0 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/09b25cd0a24a4eaddce49917d958adc667ab5465 Stats: 55 lines in 4 files changed: 31 ins; 19 del; 5 mod 8371465: Parallel: Revise asserts around heap expansion Reviewed-by: aboldtch, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28266 From mdoerr at openjdk.org Mon Nov 17 09:53:16 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 17 Nov 2025 09:53:16 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v4] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Mon, 17 Nov 2025 09:35:49 GMT, Albert Mingkun Yang wrote: >> Trivial removing obsoleted code for unsupported arch. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - review > - patch Thanks for the updates! `make run-test TEST=test/hotspot/jtreg/compiler/c2 JTREG="VM_OPTIONS=-XX:AllocatePrefetchStyle=3"` has passed on PPC64. I agree, the general AllocatePrefetchStyle==3 topic can be discussed separately. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28240#pullrequestreview-3471900133 From shade at openjdk.org Mon Nov 17 09:55:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 17 Nov 2025 09:55:09 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v10] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 06:46:30 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > _alloc_plab is also lab alloc Thanks, looks reasonable. A few more nits. src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp line 140: > 138: return ShenandoahAllocRequest(0, requested_size, _alloc_shared_gc_promotion); > 139: } > 140: if (affiliation ==OLD_GENERATION) { Suggestion: if (affiliation == OLD_GENERATION) { src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1612: > 1610: assert(req.type() == ShenandoahAllocRequest::_alloc_tlab || > 1611: req.type() == ShenandoahAllocRequest::_alloc_shared || > 1612: req.type() == ShenandoahAllocRequest::_alloc_cds, "Must be one of the mutator alloc types."); Are these asserts tautological? Meaning, we have just checked `is_mutator_alloc()` or `is_old()` -- surely we rely them to be typed well? ------------- PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3471882208 PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2533403435 PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2533412463 From shade at openjdk.org Mon Nov 17 09:55:11 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 17 Nov 2025 09:55:11 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v10] In-Reply-To: References: Message-ID: <3N-swWizY5S4UqJ0ivsmUquDwgRWjZlfKyXJUbz4SQ8=.0bb02842-7db3-4320-ac92-629c705cf785@github.com> On Thu, 13 Nov 2025 00:23:01 GMT, Xiaolong Peng wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> _alloc_plab is also lab alloc > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3272: > >> 3270: switch (req.type()) { >> 3271: case ShenandoahAllocRequest::_alloc_shared: >> 3272: case ShenandoahAllocRequest::_alloc_shared_gc: > > humongous objects never move, not possible to be _alloc_shared_gc here? Yes, I am not sure why we have the case for `_alloc_shared_gc` here. But I would leave it for extra safety in this "optimization/cleanup" change. We can yank this case later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2533422472 From ayang at openjdk.org Mon Nov 17 09:56:35 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 09:56:35 GMT Subject: RFR: 8371985: Parallel: Move should_attempt_scavenge to ParallelScavengeHeap Message-ID: Move young/full-gc criteria heuristics outside of `psScavenge.cpp` so that young-gc API runs to completion. Test: tier1-3 ------------- Commit messages: - pgc-move-heuristic Changes: https://git.openjdk.org/jdk/pull/28346/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28346&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371985 Stats: 121 lines in 4 files changed: 53 ins; 62 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28346.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28346/head:pull/28346 PR: https://git.openjdk.org/jdk/pull/28346 From kbarrett at openjdk.org Mon Nov 17 10:20:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 17 Nov 2025 10:20:16 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic Message-ID: Please review this change to OopStorage to use Atomic rather than directly applying AtomicAccess to volatile members. Testing: mach5 tier1-5 ------------- Commit messages: - OopStorage uses Atomic Changes: https://git.openjdk.org/jdk/pull/28338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371956 Stats: 103 lines in 5 files changed: 8 ins; 2 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/28338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28338/head:pull/28338 PR: https://git.openjdk.org/jdk/pull/28338 From kbarrett at openjdk.org Mon Nov 17 10:29:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 17 Nov 2025 10:29:50 GMT Subject: RFR: 8371965: Convert TaskQueueSuper to use Atomic Message-ID: Please review this change to TaskQueueSuper to use Atomic rather than directly applying AtomicAccess to (sometimes!) volatile members. There was some sketchy stuff around TaskQueueSuper::Age. This has been cleaned up by hoisting that class to namespace scope (now called TaskQueueAge) and declaring a PrimitiveConversion::Translate for it. Testing: mach5 tier1-5 ------------- Commit messages: - convert TaskQueueSuper to use Atomic Changes: https://git.openjdk.org/jdk/pull/28347/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371965 Stats: 87 lines in 1 file changed: 44 ins; 25 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/28347.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28347/head:pull/28347 PR: https://git.openjdk.org/jdk/pull/28347 From fandreuzzi at openjdk.org Mon Nov 17 10:35:33 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 17 Nov 2025 10:35:33 GMT Subject: RFR: 8371852: Shenandoah: Unused ShenandoahFreeSet::_allocated_since_gc_start field [v2] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:05:46 GMT, Nityanand Rai wrote: >> Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. > > 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8371852-nityanar > - 8371852: Shenandoah: Remove unused ShenandoahFreeSet::_allocated_since_gc_start field > > Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from > ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 > unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. > > Reviewed-by: TBD Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28332#pullrequestreview-3472057943 From fandreuzzi at openjdk.org Mon Nov 17 10:40:03 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 17 Nov 2025 10:40:03 GMT Subject: RFR: 8371985: Parallel: Move should_attempt_scavenge to ParallelScavengeHeap In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 09:49:30 GMT, Albert Mingkun Yang wrote: > Move young/full-gc criteria heuristics outside of `psScavenge.cpp` so that young-gc API runs to completion. > > Test: tier1-3 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28346#pullrequestreview-3472073569 From stefank at openjdk.org Mon Nov 17 10:43:07 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 17 Nov 2025 10:43:07 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 06:10:54 GMT, Kim Barrett wrote: > Please review this change to OopStorage to use Atomic rather than directly > applying AtomicAccess to volatile members. > > Testing: mach5 tier1-5 Looks like a good change. There's one load_acquire below that isn't clear to me why it was used. I also noticed that we use `volatile` with `_owner_address`, is that because of the SafeFetch usage? test/hotspot/gtest/gc/shared/test_oopStorage.cpp line 50: > 48: > 49: static ActiveArray& active_array(const OopStorage& storage) { > 50: return *storage._active_array.load_acquire(); Is there a reason why this was changed to `load_acquire` instead of `load_relaxed`? ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28338#pullrequestreview-3472054244 PR Review Comment: https://git.openjdk.org/jdk/pull/28338#discussion_r2533544999 From kbarrett at openjdk.org Mon Nov 17 11:58:21 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 17 Nov 2025 11:58:21 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 10:32:16 GMT, Stefan Karlsson wrote: >> Please review this change to OopStorage to use Atomic rather than directly >> applying AtomicAccess to volatile members. >> >> Testing: mach5 tier1-5 > > test/hotspot/gtest/gc/shared/test_oopStorage.cpp line 50: > >> 48: >> 49: static ActiveArray& active_array(const OopStorage& storage) { >> 50: return *storage._active_array.load_acquire(); > > Is there a reason why this was changed to `load_acquire` instead of `load_relaxed`? I think my fingers automatically typed "acquire" instead of "relaxed". Will be fixed in next push. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28338#discussion_r2533778771 From stefank at openjdk.org Mon Nov 17 12:30:48 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 17 Nov 2025 12:30:48 GMT Subject: RFR: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported Message-ID: We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. ------------- Commit messages: - ZGC: Call GTEST_SKIP when OS is unsupported Changes: https://git.openjdk.org/jdk/pull/28348/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371698 Stats: 40 lines in 4 files changed: 9 ins; 31 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28348.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28348/head:pull/28348 PR: https://git.openjdk.org/jdk/pull/28348 From ayang at openjdk.org Mon Nov 17 12:31:25 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 12:31:25 GMT Subject: RFR: 8371825: G1: Use more precise filler API in fill_range_with_dead_objects In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 17:14:03 GMT, Albert Mingkun Yang wrote: > Replace `fill_with_objects` with `fill_with_object` for dead-space inside a heap-region. > > Test: tier1-5 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28302#issuecomment-3541582953 From ayang at openjdk.org Mon Nov 17 12:31:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 12:31:26 GMT Subject: Integrated: 8371825: G1: Use more precise filler API in fill_range_with_dead_objects In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 17:14:03 GMT, Albert Mingkun Yang wrote: > Replace `fill_with_objects` with `fill_with_object` for dead-space inside a heap-region. > > Test: tier1-5 This pull request has now been integrated. Changeset: 8301d991 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/8301d9917ec9fed40e3af77998f88165e0837daf Stats: 15 lines in 1 file changed: 0 ins; 10 del; 5 mod 8371825: G1: Use more precise filler API in fill_range_with_dead_objects Reviewed-by: shade, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28302 From aboldtch at openjdk.org Mon Nov 17 13:02:21 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 17 Nov 2025 13:02:21 GMT Subject: RFR: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported In-Reply-To: References: Message-ID: <7uaYHRsIKgIX28axt4ti6gf9uW_e5iGtZB9AFEe7Ozg=.99ee5f3e-97c4-4dda-aaae-75b059b976e7@github.com> On Mon, 17 Nov 2025 11:12:36 GMT, Stefan Karlsson wrote: > We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. > > I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28348#pullrequestreview-3472594217 From mdoerr at openjdk.org Mon Nov 17 13:39:23 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 17 Nov 2025 13:39:23 GMT Subject: RFR: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 11:12:36 GMT, Stefan Karlsson wrote: > We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. > > I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. I'll put it into our test queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28348#issuecomment-3541875401 From stefank at openjdk.org Mon Nov 17 13:53:40 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 17 Nov 2025 13:53:40 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson wrote: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Moved from hotspot to hotspot-gc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28349#issuecomment-3541930053 From jsikstro at openjdk.org Mon Nov 17 14:00:57 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 17 Nov 2025 14:00:57 GMT Subject: RFR: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 11:12:36 GMT, Stefan Karlsson wrote: > We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. > > I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. Looks good. ------------- Marked as reviewed by jsikstro (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28348#pullrequestreview-3472836556 From shade at openjdk.org Mon Nov 17 14:42:21 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 17 Nov 2025 14:42:21 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> References: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> Message-ID: <4JpTVvsVyPGaIoYtghK3qOx6LDfuRVJg4-Mamrdvb3c=.cccedc0e-437f-4635-af1f-c7155206c6ad@github.com> On Tue, 11 Nov 2025 00:33:36 GMT, William Kemper wrote: >> When an array copy happens concurrently with old and young marking, Shenandoah's generational mode walks over the array twice. This is unnecessary and increases the workload for marking threads. It also has been unconditionally enqueuing old references during a young mark. This is also unnecessary and also increases marking workload. Finally, the barrier went through a somewhat complicated decision process based on affiliation of the region where the array resides. However, the barrier must consider the affiliation of objects that are pointed at by array elements. > > William Kemper has updated the pull request incrementally with one additional commit since the last revision: > > Revert "We can also filter out old when striclty marking young" > > This reverts commit c53c4f23f4401785e1049494b6c4e4b92f9a5701. Looks reasonable, but a question. src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 428: > 426: > 427: const char gc_state = ShenandoahThreadLocalData::gc_state(Thread::current()); > 428: if ((gc_state & ShenandoahHeap::MARKING) != 0) { A question on sequencing. Can we have marking and update-refs at the same time? If so, should update-refs happen first, and then marking should be doing the walk over (fixed-up) objects? ------------- PR Review: https://git.openjdk.org/jdk/pull/28183#pullrequestreview-3472900617 PR Review Comment: https://git.openjdk.org/jdk/pull/28183#discussion_r2534226107 From iwalulya at openjdk.org Mon Nov 17 15:44:06 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 17 Nov 2025 15:44:06 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson wrote: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... src/hotspot/share/gc/shared/gcVMOperations.hpp line 143: > 141: > 142: // Queried value of CollectedHeap::is_shutting_down while holding the Heap_lock. > 143: bool is_shutting_down() const { return _is_shutting_down; } Maybe we assert on the "holding the Heap_lock" instead of having the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2534579005 From xpeng at openjdk.org Mon Nov 17 16:18:32 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:18:32 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v10] In-Reply-To: References: Message-ID: <29PrvuCUR2gUEx2CoJXEQUCJvJAfj84ujb0fKgbcNYE=.62ec716d-3b90-4128-879a-effce37422fe@github.com> On Mon, 17 Nov 2025 09:48:57 GMT, Aleksey Shipilev wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> _alloc_plab is also lab alloc > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1612: > >> 1610: assert(req.type() == ShenandoahAllocRequest::_alloc_tlab || >> 1611: req.type() == ShenandoahAllocRequest::_alloc_shared || >> 1612: req.type() == ShenandoahAllocRequest::_alloc_cds, "Must be one of the mutator alloc types."); > > Are these asserts tautological? Meaning, we have just checked `is_mutator_alloc()` or `is_old()` -- surely we rely them to be typed well? Kind of, I'll remove them from here and some other places. I added these just in case some of the types are not encoded well, e.g. when people want to add a new type and change the encodings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2534707230 From xpeng at openjdk.org Mon Nov 17 16:25:55 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:25:55 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v11] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/66352ab0..1c2ab8fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=09-10 Stats: 11 lines in 2 files changed: 1 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Mon Nov 17 16:36:15 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:36:15 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v10] In-Reply-To: <29PrvuCUR2gUEx2CoJXEQUCJvJAfj84ujb0fKgbcNYE=.62ec716d-3b90-4128-879a-effce37422fe@github.com> References: <29PrvuCUR2gUEx2CoJXEQUCJvJAfj84ujb0fKgbcNYE=.62ec716d-3b90-4128-879a-effce37422fe@github.com> Message-ID: On Mon, 17 Nov 2025 16:15:49 GMT, Xiaolong Peng wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1612: >> >>> 1610: assert(req.type() == ShenandoahAllocRequest::_alloc_tlab || >>> 1611: req.type() == ShenandoahAllocRequest::_alloc_shared || >>> 1612: req.type() == ShenandoahAllocRequest::_alloc_cds, "Must be one of the mutator alloc types."); >> >> Are these asserts tautological? Meaning, we have just checked `is_mutator_alloc()` or `is_old()` -- surely we rely them to be typed well? > > Kind of, I'll remove them from here and some other places. > I added these just in case some of the types are not encoded well, e.g. when people want to add a new type and change the encodings. I have removed them, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2534768149 From xpeng at openjdk.org Mon Nov 17 16:36:18 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:36:18 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v11] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 16:25:55 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1618: > 1616: size_t ac = alloc_capacity(r); > 1617: ShenandoahFreeSetPartitionId orig_partition; > 1618: ShenandoahGeneration* request_generation = nullptr; `ac` and `request_generation` are not actually used, we can remove them, but it is not really related to the purpose of this PR, probably better create a separate PR for the clean-ups. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2534765340 From xpeng at openjdk.org Mon Nov 17 16:44:00 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:44:00 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v12] In-Reply-To: References: Message-ID: <-lmcq3SlLiWl1HNh2RwnDg8m6AE0zaC5mPyi2v7YsH8=.84ff64ac-4e44-4090-88e1-d148c5660bae@github.com> On Mon, 17 Nov 2025 16:32:35 GMT, Xiaolong Peng wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding unnecessary back > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1618: > >> 1616: size_t ac = alloc_capacity(r); >> 1617: ShenandoahFreeSetPartitionId orig_partition; >> 1618: ShenandoahGeneration* request_generation = nullptr; > > `ac` and `request_generation` are not actually used, we can remove them, but it is not really related to the purpose of this PR, probably better create a separate PR for the clean-ups. Reverted the unnecessary change for `ac` and `request_generation` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2534788166 From xpeng at openjdk.org Mon Nov 17 16:43:58 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:43:58 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v12] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Adding unnecessary back ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/1c2ab8fc..480f7abb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=10-11 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Mon Nov 17 16:46:06 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 16:46:06 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: tidy up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/480f7abb..121faa90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=11-12 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From kdnilsen at openjdk.org Mon Nov 17 17:47:13 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 17 Nov 2025 17:47:13 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: <3N-swWizY5S4UqJ0ivsmUquDwgRWjZlfKyXJUbz4SQ8=.0bb02842-7db3-4320-ac92-629c705cf785@github.com> References: <3N-swWizY5S4UqJ0ivsmUquDwgRWjZlfKyXJUbz4SQ8=.0bb02842-7db3-4320-ac92-629c705cf785@github.com> Message-ID: On Mon, 17 Nov 2025 09:52:13 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 3272: >> >>> 3270: switch (req.type()) { >>> 3271: case ShenandoahAllocRequest::_alloc_shared: >>> 3272: case ShenandoahAllocRequest::_alloc_shared_gc: >> >> humongous objects never move, not possible to be _alloc_shared_gc here? > > Yes, I am not sure why we have the case for `_alloc_shared_gc` here. But I would leave it for extra safety in this "optimization/cleanup" change. We can yank this case later. Humongous objects do move under full gc, and may eventually move under concurrent GC with some refactoring. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2534995388 From kdnilsen at openjdk.org Mon Nov 17 17:51:08 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 17 Nov 2025 17:51:08 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: References: Message-ID: <4vtR_WCVg1eJ6kcwKPU8ih9Qbh4tSX8ho_T8Y-I7AL0=.8c811ca0-24e5-4655-8ee3-0202f9a9c46e@github.com> On Mon, 17 Nov 2025 16:46:06 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > tidy up Regarding the original code, was that release-build code, with optimization? That looks more like slowdebug code. I would have expected a computed goto rather than cascaded if-then-elses. With computed-goto and with range checks, I suspect there may still be issues with branch-prediction efficiency in hardware. Do we see any measurable impact on performance? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3543140236 From xpeng at openjdk.org Mon Nov 17 18:19:13 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 18:19:13 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: References: <3N-swWizY5S4UqJ0ivsmUquDwgRWjZlfKyXJUbz4SQ8=.0bb02842-7db3-4320-ac92-629c705cf785@github.com> Message-ID: <56n7FtkzQ6sdllQtipFk5zMbf8t8ZHC3SKfhPm-VDVY=.05daf8b1-14b5-4e84-8334-9e6e8de368b8@github.com> On Mon, 17 Nov 2025 17:43:56 GMT, Kelvin Nilsen wrote: >> Yes, I am not sure why we have the case for `_alloc_shared_gc` here. But I would leave it for extra safety in this "optimization/cleanup" change. We can yank this case later. > > Humongous objects do move under full gc, and may eventually move under concurrent GC with some refactoring. I have added the line `case ShenandoahAllocRequest::_alloc_shared_gc:` back. For full gc, we may move humongous objects in compaction, not by evacuation, so it won't call into `ShenandoahFreeSet::allocate` method, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2535086190 From xpeng at openjdk.org Mon Nov 17 18:26:12 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 17 Nov 2025 18:26:12 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: <4vtR_WCVg1eJ6kcwKPU8ih9Qbh4tSX8ho_T8Y-I7AL0=.8c811ca0-24e5-4655-8ee3-0202f9a9c46e@github.com> References: <4vtR_WCVg1eJ6kcwKPU8ih9Qbh4tSX8ho_T8Y-I7AL0=.8c811ca0-24e5-4655-8ee3-0202f9a9c46e@github.com> Message-ID: On Mon, 17 Nov 2025 17:47:53 GMT, Kelvin Nilsen wrote: > Regarding the original code, was that release-build code, with optimization? That looks more like slowdebug code. I would have expected a computed goto rather than cascaded if-then-elses. > > With computed-goto and with range checks, I suspect there may still be issues with branch-prediction efficiency in hardware. Do we see any measurable impact on performance? It was release-build code, I used https://godbolt.org to generated the assembly code for comparison, the one in description is less optimization, here is the one with `-O3` flag: https://godbolt.org/z/3317zYqYh ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3543298577 From ayang at openjdk.org Mon Nov 17 18:55:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 17 Nov 2025 18:55:08 GMT Subject: RFR: 8037914: Add JFR event for string deduplication [v8] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 14:45:29 GMT, Francesco Andreuzzi wrote: >> 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: > > fix year Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28015#pullrequestreview-3474115864 From egahlin at openjdk.org Mon Nov 17 18:55:09 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 17 Nov 2025 18:55:09 GMT Subject: RFR: 8037914: Add JFR event for string deduplication [v8] In-Reply-To: References: Message-ID: <_StovLFzWCTY3tLarfVFee0vcsPLgcYjrzL0Xq-7n2A=.304d6035-496f-43d8-9a8e-06f159c78e8c@github.com> On Mon, 17 Nov 2025 14:45:29 GMT, Francesco Andreuzzi wrote: >> 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: > > fix year Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28015#pullrequestreview-3474120613 From stefank at openjdk.org Mon Nov 17 19:53:03 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 17 Nov 2025 19:53:03 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 15:41:17 GMT, Ivan Walulya wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > src/hotspot/share/gc/shared/gcVMOperations.hpp line 143: > >> 141: >> 142: // Queried value of CollectedHeap::is_shutting_down while holding the Heap_lock. >> 143: bool is_shutting_down() const { return _is_shutting_down; } > > Maybe we assert on the "holding the Heap_lock" instead of having the comment. This function can (and will) be called without holding the `Heap_lock`. That's what the comment tried, but obviously failed, to say. :. The point it tried to convey was that `VM_GC_Operation::_is_shutting_down` was initialized with the value read from `CollectedHeap::_is_shutting_down` while holding the `Heap_lock`. Subsequent code, that doesn't hold the `Heap_lock` could check `VM_GC_Operation::_is_shutting_down` to see if we skipped the GC operation because the JVM is shutting down. I'll see if I can make the comment more clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2535331068 From iwalulya at openjdk.org Mon Nov 17 20:13:04 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 17 Nov 2025 20:13:04 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 19:49:06 GMT, Stefan Karlsson wrote: >> src/hotspot/share/gc/shared/gcVMOperations.hpp line 143: >> >>> 141: >>> 142: // Queried value of CollectedHeap::is_shutting_down while holding the Heap_lock. >>> 143: bool is_shutting_down() const { return _is_shutting_down; } >> >> Maybe we assert on the "holding the Heap_lock" instead of having the comment. > > This function can (and will) be called without holding the `Heap_lock`. That's what the comment tried, but obviously failed, to say. :. > > The point it tried to convey was that `VM_GC_Operation::_is_shutting_down` was initialized with the value read from `CollectedHeap::_is_shutting_down` while holding the `Heap_lock`. Subsequent code, that doesn't hold the `Heap_lock` could check `VM_GC_Operation::_is_shutting_down` to see if we skipped the GC operation because the JVM is shutting down. > > I'll see if I can make the comment more clear. yeah, after the explanation, now comment makes sense. I didn't understand it on first pass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2535376447 From kbarrett at openjdk.org Mon Nov 17 20:17:22 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 17 Nov 2025 20:17:22 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic [v2] In-Reply-To: References: Message-ID: > Please review this change to OopStorage to use Atomic rather than directly > applying AtomicAccess to volatile members. > > Testing: mach5 tier1-5 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: fixed unintentional load_acquire in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28338/files - new: https://git.openjdk.org/jdk/pull/28338/files/554f3229..7f78403f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28338&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28338&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28338/head:pull/28338 PR: https://git.openjdk.org/jdk/pull/28338 From duke at openjdk.org Mon Nov 17 23:31:22 2025 From: duke at openjdk.org (Nityanand Rai) Date: Mon, 17 Nov 2025 23:31:22 GMT Subject: RFR: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use [v2] In-Reply-To: References: Message-ID: > Replace define/undefine pattern with #ifdef ASSERT block Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: incorporate feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28333/files - new: https://git.openjdk.org/jdk/pull/28333/files/bfdf9e41..27ccdb3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28333&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28333&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28333.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28333/head:pull/28333 PR: https://git.openjdk.org/jdk/pull/28333 From kdnilsen at openjdk.org Mon Nov 17 23:43:12 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Mon, 17 Nov 2025 23:43:12 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 16:46:06 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > tidy up Thanks for this cleanup and these improvements. Just two minor suggestions. src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp line 204: > 202: } > 203: > 204: bool is_old() const { Should all of these be inline? (Looks to me like the implementations are no larger than the code required to call and process result.) src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1618: > 1616: orig_partition = ShenandoahFreeSetPartitionId::OldCollector; > 1617: } else { > 1618: request_generation = _heap->mode()->is_generational()? _heap->young_generation(): _heap->global_generation(); It took me some time to convince myself this is equivalent code, mainly because the original code (quite likely written by me) was so "clumsy". Maybe a comment here would be helpful: // This is a young collector gclab or shared allocation ------------- PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3474845477 PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2535753518 PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2535829886 From duke at openjdk.org Tue Nov 18 00:19:08 2025 From: duke at openjdk.org (duke) Date: Tue, 18 Nov 2025 00:19:08 GMT Subject: RFR: 8371852: Shenandoah: Unused ShenandoahFreeSet::_allocated_since_gc_start field [v2] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:05:46 GMT, Nityanand Rai wrote: >> Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. > > 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8371852-nityanar > - 8371852: Shenandoah: Remove unused ShenandoahFreeSet::_allocated_since_gc_start field > > Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from > ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 > unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. > > Reviewed-by: TBD @nityarai08 Your change (at version 887d25e204622d07e2d1c513dcf343343428c8f8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28332#issuecomment-3544425527 From ysr at openjdk.org Tue Nov 18 00:42:32 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 18 Nov 2025 00:42:32 GMT Subject: RFR: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 23:31:22 GMT, Nityanand Rai wrote: >> Replace define/undefine pattern with #ifdef ASSERT block > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > incorporate feedback Change looks good locally. The comments may need to be fixed up, but that's part of a bigger cleanup suggested in the review for the original PR that came too late. Will create a separate task for that larger refactor effort. This change can be integrated in its current form as it's obviously correct. ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28333#pullrequestreview-3475066037 From stefank at openjdk.org Tue Nov 18 06:42:35 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 06:42:35 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 20:17:22 GMT, Kim Barrett wrote: >> Please review this change to OopStorage to use Atomic rather than directly >> applying AtomicAccess to volatile members. >> >> Testing: mach5 tier1-5 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fixed unintentional load_acquire in test Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28338#pullrequestreview-3475753036 From kbarrett at openjdk.org Tue Nov 18 06:47:09 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Nov 2025 06:47:09 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 10:08:36 GMT, Joel Sikstr?m wrote: > Hello, > > We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. > > When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. > > The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. > > Testing: > * Oracle's tier1-3 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28287#pullrequestreview-3475764571 From shade at openjdk.org Tue Nov 18 06:50:35 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 18 Nov 2025 06:50:35 GMT Subject: RFR: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 23:31:22 GMT, Nityanand Rai wrote: >> Replace define/undefine pattern with #ifdef ASSERT block > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > incorporate feedback Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28333#pullrequestreview-3475774871 From duke at openjdk.org Tue Nov 18 06:52:29 2025 From: duke at openjdk.org (Nityanand Rai) Date: Tue, 18 Nov 2025 06:52:29 GMT Subject: Integrated: 8371852: Shenandoah: Unused ShenandoahFreeSet::_allocated_since_gc_start field In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 20:37:29 GMT, Nityanand Rai wrote: > Removed the unused _allocated_since_gc_start[UIntNumPartitions] field from ShenandoahRegionPartitions class. This field became obsolete after JDK-8365880 unified memory usage accounting in ShenandoahFreeSet but was not cleaned up. This pull request has now been integrated. Changeset: 8cdfec8d Author: Nityanand Rai <163765635+nityarai08 at users.noreply.github.com> Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/8cdfec8d1cdc7e3137035cebe1cc189e36c0e319 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8371852: Shenandoah: Unused ShenandoahFreeSet::_allocated_since_gc_start field Reviewed-by: shade, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/28332 From xpeng at openjdk.org Tue Nov 18 06:59:13 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 18 Nov 2025 06:59:13 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 23:38:27 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> tidy up > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1618: > >> 1616: orig_partition = ShenandoahFreeSetPartitionId::OldCollector; >> 1617: } else { >> 1618: request_generation = _heap->mode()->is_generational()? _heap->young_generation(): _heap->global_generation(); > > It took me some time to convince myself this is equivalent code, mainly because the original code (quite likely written by me) was so "clumsy". Maybe a comment here would be helpful: > > // This is a young collector gclab or shared allocation I will add the comments, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2536554046 From tschatzl at openjdk.org Tue Nov 18 07:52:16 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 18 Nov 2025 07:52:16 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 20:17:22 GMT, Kim Barrett wrote: >> Please review this change to OopStorage to use Atomic rather than directly >> applying AtomicAccess to volatile members. >> >> Testing: mach5 tier1-5 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fixed unintentional load_acquire in test Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28338#pullrequestreview-3475965165 From fandreuzzi at openjdk.org Tue Nov 18 09:23:38 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 18 Nov 2025 09:23:38 GMT Subject: RFR: 8037914: Add JFR event for string deduplication [v7] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 14:27:24 GMT, Erik Gahlin wrote: >> Francesco Andreuzzi 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: >> >> - remove elapsed. remove idle >> - Merge branch 'master' into JDK-8037914 >> - rename. start/end time >> - no start >> - enable >> - bytes to size >> - disable >> - revert >> - one event >> - trailing >> - ... and 5 more: https://git.openjdk.org/jdk/compare/c7ce9f21...fc47a64e > > From a JFR perspective, this looks good. Ideally, the values of the event should be sanity-checked, but I understand this might be tricky to do in a reliable manner. Hunting down false positives would just be a waste of time. The copyright year of the test should be 2025. > > It would be good if someone on the GC team could take a look at the GC-related code. Thanks for the review @egahlin and @albertnetymk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3546398933 From duke at openjdk.org Tue Nov 18 09:23:39 2025 From: duke at openjdk.org (duke) Date: Tue, 18 Nov 2025 09:23:39 GMT Subject: RFR: 8037914: Add JFR event for string deduplication [v8] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 14:45:29 GMT, Francesco Andreuzzi wrote: >> 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: > > fix year @fandreuz Your change (at version 40829ead2e80bab673d4852914eabfdee72dc7ce) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3546402253 From ayang at openjdk.org Tue Nov 18 09:40:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 18 Nov 2025 09:40:37 GMT Subject: RFR: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch [v4] In-Reply-To: References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Mon, 17 Nov 2025 09:35:49 GMT, Albert Mingkun Yang wrote: >> Trivial removing obsoleted code for unsupported arch. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - review > - patch Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28240#issuecomment-3546476614 From ayang at openjdk.org Tue Nov 18 09:40:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 18 Nov 2025 09:40:38 GMT Subject: Integrated: 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch In-Reply-To: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> References: <73HZdkIlDts3as9Xfechu5Sj4RhDGpUx-HVxj6B9m5o=.d147e8ff-7488-4358-af54-956b966d499d@github.com> Message-ID: On Tue, 11 Nov 2025 15:42:21 GMT, Albert Mingkun Yang wrote: > Trivial removing obsoleted code for unsupported arch. > > Test: tier1 This pull request has now been integrated. Changeset: 50a30497 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/50a30497370799e8f377a11914562a15b0a48fbb Stats: 69 lines in 7 files changed: 0 ins; 66 del; 3 mod 8371643: Remove ThreadLocalAllocBuffer::_reserve_for_allocation_prefetch Reviewed-by: mdoerr, kvn, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28240 From mdoerr at openjdk.org Tue Nov 18 09:42:20 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 18 Nov 2025 09:42:20 GMT Subject: RFR: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 11:12:36 GMT, Stefan Karlsson wrote: > We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. > > I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. This looks good and solves the issue. Thanks for improving it! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28348#pullrequestreview-3476523010 From fandreuzzi at openjdk.org Tue Nov 18 09:46:47 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 18 Nov 2025 09:46:47 GMT Subject: Integrated: 8037914: Add JFR event for string deduplication In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 10:09:58 GMT, Francesco Andreuzzi wrote: > 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). This pull request has now been integrated. Changeset: 3a2845f3 Author: Francesco Andreuzzi Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/3a2845f334a59670d54699919073f0e908c038c4 Stats: 261 lines in 9 files changed: 244 ins; 10 del; 7 mod 8037914: Add JFR event for string deduplication Reviewed-by: ayang, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/28015 From ayang at openjdk.org Tue Nov 18 09:55:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 18 Nov 2025 09:55:26 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com> On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson wrote: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/shared/gcVMOperations.cpp line 101: > 99: while (true) { > 100: Heap_lock->wait(); > 101: } The intention here is to block all java-threads indefinitely, and those threads don't need to wait for any signals. I wonder if using a local always-zero semaphore might convey the intention more explicitly. ------------- PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3476609791 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537210706 From xpeng at openjdk.org Tue Nov 18 09:55:27 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 18 Nov 2025 09:55:27 GMT Subject: RFR: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 23:31:22 GMT, Nityanand Rai wrote: >> Replace define/undefine pattern with #ifdef ASSERT block > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > incorporate feedback Marked as reviewed by xpeng (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28333#pullrequestreview-3476609209 From xpeng at openjdk.org Tue Nov 18 10:13:41 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 18 Nov 2025 10:13:41 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v13] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 22:54:45 GMT, Kelvin Nilsen wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> tidy up > > src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp line 204: > >> 202: } >> 203: >> 204: bool is_old() const { > > Should all of these be inline? (Looks to me like the implementations are no larger than the code required to call and process result.) Yes, they are all inline methods, even w/o the explicit `inline`, CLion simply tells me the keyword `inline` is redundant in the header file if the method is entirely declared in header file. Just be better readability, I added `inline` for all these methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28247#discussion_r2537289651 From kbarrett at openjdk.org Tue Nov 18 10:21:30 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Nov 2025 10:21:30 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson wrote: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3476754135 From iwalulya at openjdk.org Tue Nov 18 10:21:32 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 18 Nov 2025 10:21:32 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson wrote: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Marked as reviewed by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1Policy.cpp line 1284: > 1282: // We should not be starting a concurrent start pause if the concurrent mark > 1283: // thread is terminating. > 1284: assert(!_g1h->concurrent_mark_is_terminating(), "Should not reach here"); We can also remove this assert and associated comment. src/hotspot/share/gc/g1/g1RemSet.cpp line 1020: > 1018: // Mark phase midway, which might have also left stale marks in old generation regions. > 1019: // There might actually have been scheduled multiple collections, but at that point we do > 1020: // not care that much about performance and just do the work multiple times if needed. We can do away with the comment and the assert as we can no longer have GCs after shutdown has been initiated. ------------- PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3476648375 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537281693 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537241668 From xpeng at openjdk.org Tue Nov 18 10:28:04 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 18 Nov 2025 10:28:04 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v14] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/121faa90..674753bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=12-13 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From iwalulya at openjdk.org Tue Nov 18 10:36:25 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 18 Nov 2025 10:36:25 GMT Subject: RFR: 8371985: Parallel: Move should_attempt_scavenge to ParallelScavengeHeap In-Reply-To: References: Message-ID: <2oO_6Um_9GvAMhuX58h97cpC7wB1zKEUI2fHe_Jf0R4=.e62cbfb3-46cc-4ef2-9011-22dca05c279a@github.com> On Mon, 17 Nov 2025 09:49:30 GMT, Albert Mingkun Yang wrote: > Move young/full-gc criteria heuristics outside of `psScavenge.cpp` so that young-gc API runs to completion. > > Test: tier1-3 Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28346#pullrequestreview-3476883401 From iwalulya at openjdk.org Tue Nov 18 11:39:11 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 18 Nov 2025 11:39:11 GMT Subject: RFR: 8371965: Convert TaskQueueSuper to use Atomic In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 10:22:13 GMT, Kim Barrett wrote: > Please review this change to TaskQueueSuper to use Atomic rather than > directly applying AtomicAccess to (sometimes!) volatile members. There was > some sketchy stuff around TaskQueueSuper::Age. This has been cleaned up by > hoisting that class to namespace scope (now called TaskQueueAge) and declaring > a PrimitiveConversion::Translate for it. > > Testing: mach5 tier1-5 Looks good! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28347#pullrequestreview-3477266982 From stefank at openjdk.org Tue Nov 18 12:01:18 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:01:18 GMT Subject: RFR: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 11:12:36 GMT, Stefan Karlsson wrote: > We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. > > I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. Thanks for the reviews and verification! I've run this through tier1 without any issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28348#issuecomment-3547266800 From stefank at openjdk.org Tue Nov 18 12:01:18 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:01:18 GMT Subject: Integrated: 8371698: ZGC: Call GTEST_SKIP when OS is unsupported In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 11:12:36 GMT, Stefan Karlsson wrote: > We have a ZGC-specific test fixture for our gtests. This fixture bails out if the OS is unsupported. In addition to that, all tests need to bail out as well. It turns out that we missed this bail-out in one of our tests. > > I propose that we perform a stronger bail-out in the test fixture to make this error less likely to happen in the future. This pull request has now been integrated. Changeset: df5b105b Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/df5b105bbb55d9cc923ac45ff99e702126626670 Stats: 40 lines in 4 files changed: 9 ins; 31 del; 0 mod 8371698: ZGC: Call GTEST_SKIP when OS is unsupported Reviewed-by: aboldtch, jsikstro, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/28348 From stefank at openjdk.org Tue Nov 18 12:22:43 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:22:43 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 10:08:16 GMT, Ivan Walulya wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > src/hotspot/share/gc/g1/g1Policy.cpp line 1284: > >> 1282: // We should not be starting a concurrent start pause if the concurrent mark >> 1283: // thread is terminating. >> 1284: assert(!_g1h->concurrent_mark_is_terminating(), "Should not reach here"); > > We can also remove this assert and associated comment. OK! > src/hotspot/share/gc/g1/g1RemSet.cpp line 1020: > >> 1018: // Mark phase midway, which might have also left stale marks in old generation regions. >> 1019: // There might actually have been scheduled multiple collections, but at that point we do >> 1020: // not care that much about performance and just do the work multiple times if needed. > > We can do away with the comment and the assert as we can no longer have GCs after shutdown has been initiated. Thanks for the feedback! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537938874 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537937985 From stefank at openjdk.org Tue Nov 18 12:22:45 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:22:45 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com> References: <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com> Message-ID: On Tue, 18 Nov 2025 09:52:35 GMT, Albert Mingkun Yang wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > src/hotspot/share/gc/shared/gcVMOperations.cpp line 101: > >> 99: while (true) { >> 100: Heap_lock->wait(); >> 101: } > > The intention here is to block all java-threads indefinitely, and those threads don't need to wait for any signals. I wonder if using a local always-zero semaphore might convey the intention more explicitly. It also has the side-effect that it releases the Heap_lock and moves the thread into the blocked state. If we don't release the lock then we will not be able to complete the shutdown sequence, which acquires the Heap_lock before the exit VM operation (or shutting down the VM thread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537935932 From stefank at openjdk.org Tue Nov 18 12:22:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:22:46 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 20:09:04 GMT, Ivan Walulya wrote: >> This function can (and will) be called without holding the `Heap_lock`. That's what the comment tried, but obviously failed, to say. :. >> >> The point it tried to convey was that `VM_GC_Operation::_is_shutting_down` was initialized with the value read from `CollectedHeap::_is_shutting_down` while holding the `Heap_lock`. Subsequent code, that doesn't hold the `Heap_lock` could check `VM_GC_Operation::_is_shutting_down` to see if we skipped the GC operation because the JVM is shutting down. >> >> I'll see if I can make the comment more clear. > > yeah, after the explanation, now comment makes sense. I didn't understand it on first pass. I'll update the comment. Let's see if that makes things clearer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2537944274 From stefank at openjdk.org Tue Nov 18 12:38:55 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:38:55 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v2] In-Reply-To: References: Message-ID: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Review comments - Merge remote-tracking branch 'upstream/master' into remove_2s_shutdown_workaround - Filter out ConcurrentGCThreads from GC operation shutdown - Revert VM_G1PauseConcurrent::doit_prologue - Sleep from concurrent thread - Move log_cpu_time back to Universe - Block for shutdown in GC safepoint prologue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28349/files - new: https://git.openjdk.org/jdk/pull/28349/files/c46b90df..b5b7c68a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28349&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28349&range=00-01 Stats: 7837 lines in 142 files changed: 6605 ins; 345 del; 887 mod Patch: https://git.openjdk.org/jdk/pull/28349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28349/head:pull/28349 PR: https://git.openjdk.org/jdk/pull/28349 From stefank at openjdk.org Tue Nov 18 12:46:28 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:46:28 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v3] In-Reply-To: References: Message-ID: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Add comment to block_if_java_thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28349/files - new: https://git.openjdk.org/jdk/pull/28349/files/b5b7c68a..c5f65378 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28349&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28349&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28349/head:pull/28349 PR: https://git.openjdk.org/jdk/pull/28349 From stefank at openjdk.org Tue Nov 18 12:46:30 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 12:46:30 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v3] In-Reply-To: References: <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com> Message-ID: On Tue, 18 Nov 2025 12:17:20 GMT, Stefan Karlsson wrote: >> src/hotspot/share/gc/shared/gcVMOperations.cpp line 101: >> >>> 99: while (true) { >>> 100: Heap_lock->wait(); >>> 101: } >> >> The intention here is to block all java-threads indefinitely, and those threads don't need to wait for any signals. I wonder if using a local always-zero semaphore might convey the intention more explicitly. > > It also has the side-effect that it releases the Heap_lock and moves the thread into the blocked state. If we don't release the lock then we will not be able to complete the shutdown sequence, which acquires the Heap_lock before the exit VM operation (or shutting down the VM thread). I've pushed a comment stating the above. Maybe that helps explaining why Heap_lock->wait() is called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2538043494 From ayang at openjdk.org Tue Nov 18 13:00:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 18 Nov 2025 13:00:12 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v3] In-Reply-To: References: <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com> Message-ID: On Tue, 18 Nov 2025 12:43:25 GMT, Stefan Karlsson wrote: >> It also has the side-effect that it releases the Heap_lock and moves the thread into the blocked state. If we don't release the lock then we will not be able to complete the shutdown sequence, which acquires the Heap_lock before the exit VM operation (or shutting down the VM thread). > > I've pushed a comment stating the above. Maybe that helps explaining why Heap_lock->wait() is called. > It also has the side-effect that it releases the Heap_lock ... Yes. My msg was probably unclear; I meant to suggest using sth like: Heap_lock->unlock(); { Semaphore always_blocked_sema{0}; always_blocked_sema.wait(); // never return } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2538103942 From shade at openjdk.org Tue Nov 18 13:12:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 18 Nov 2025 13:12:19 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v14] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 10:28:04 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Looks fine, assuming it passes tests. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3477777825 From stefank at openjdk.org Tue Nov 18 13:54:15 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 18 Nov 2025 13:54:15 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v3] In-Reply-To: References: <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com> Message-ID: On Tue, 18 Nov 2025 12:57:13 GMT, Albert Mingkun Yang wrote: >> I've pushed a comment stating the above. Maybe that helps explaining why Heap_lock->wait() is called. > >> It also has the side-effect that it releases the Heap_lock ... > > Yes. My msg was probably unclear; I meant to suggest using sth like: > > > Heap_lock->unlock(); > { > Semaphore always_blocked_sema{0}; > always_blocked_sema.wait(); // never return > } Yeah, I got that. I just don't think that's much clearer. (BTW, you need to use `Semaphore::wait_with_safepoint_check` because `Semaphore::wait` doesn't transition to the blocked state. Or use ThreadBlockInVM.) Maybe if we had some API that could change the code to be: Heap_lock->unlock(); block_forever(); But I don't think we have that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2538303025 From duke at openjdk.org Tue Nov 18 13:55:11 2025 From: duke at openjdk.org (duke) Date: Tue, 18 Nov 2025 13:55:11 GMT Subject: RFR: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 23:31:22 GMT, Nityanand Rai wrote: >> Replace define/undefine pattern with #ifdef ASSERT block > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > incorporate feedback @nityarai08 Your change (at version 27ccdb3c47c51aecbef565a1979671508b0e182f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28333#issuecomment-3547740511 From eosterlund at openjdk.org Tue Nov 18 14:44:47 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 18 Nov 2025 14:44:47 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race [v2] In-Reply-To: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> Message-ID: <2t7atbFpaHbBOH70fk-JDI1dU_xt1FNeesfOfe3Gf4M=.c2811325-b98c-49a3-8ebc-ff3722344a8d@github.com> > C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. > > When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. > > ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. > > Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. > > However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. > > This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. > > If the guard check is performed before the handshake, then the JIT-compiled code will continue to execute past the code that as... Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Remove assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28176/files - new: https://git.openjdk.org/jdk/pull/28176/files/33864748..0e935fd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28176&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28176&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28176/head:pull/28176 PR: https://git.openjdk.org/jdk/pull/28176 From kdnilsen at openjdk.org Tue Nov 18 15:46:37 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 18 Nov 2025 15:46:37 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v14] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 10:28:04 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/28247#pullrequestreview-3478467122 From shade at openjdk.org Tue Nov 18 15:50:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 18 Nov 2025 15:50:42 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v14] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 10:28:04 GMT, Xiaolong Peng wrote: >> Current alloc request type enum: >> >> enum Type { >> _alloc_shared, // Allocate common, outside of TLAB >> _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB >> _alloc_cds, // Allocate for CDS >> _alloc_tlab, // Allocate TLAB >> _alloc_gclab, // Allocate GCLAB >> _alloc_plab, // Allocate PLAB >> _ALLOC_LIMIT >> }; >> >> With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: >> >> >> inline bool is_mutator_alloc() const { >> switch (_alloc_type) { >> case _alloc_tlab: >> case _alloc_shared: >> case _alloc_cds: >> return true; >> case _alloc_gclab: >> case _alloc_plab: >> case _alloc_shared_gc: >> return false; >> default: >> ShouldNotReachHere(); >> return false; >> } >> } >> >> >> >> In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: >> 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. >> 2. Odd for lab, even number for non-lab >> >> Three functions have been simplified to one-line impl w/o branches in machine code: >> >> >> inline bool is_mutator_alloc() const { >> return _alloc_type <= _alloc_shared; >> } >> >> inline bool is_gc_alloc() const { >> return _alloc_type >= _alloc_shared_gc; >> } >> >> inline bool is_lab_alloc() const { >> return (_alloc_type & 1) == 1; >> } >> >> >> I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: >> >> bool is_lab_alloc(int alloc_type) { >> return (alloc_type & 1) == 1; >> } >> >> bool is_lab_alloc_switch(int alloc_type) { >> switch (alloc_type) { >> case 0: >> case 2: >> case 4: >> return false; >> case 1: >> case 3: >> case 5: >> return true; >> default: >> throw "Should not reach here"; >> >> } >> } >> >> x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): >> >> is_lab_alloc(int): >> push rbp >> mov rbp, rsp >> mov DWORD PTR [rbp-4], edi >> mov eax, DWORD PTR [rbp-4] >> and eax, 1 >> and eax, 1 >> pop rbp >> ret >> .LC0: >> .string "Should not reach here" >> is_lab_allo... > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Note the test failures in GHA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3548303692 From duke at openjdk.org Tue Nov 18 15:50:46 2025 From: duke at openjdk.org (Nityanand Rai) Date: Tue, 18 Nov 2025 15:50:46 GMT Subject: Integrated: 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:40:42 GMT, Nityanand Rai wrote: > Replace define/undefine pattern with #ifdef ASSERT block This pull request has now been integrated. Changeset: 713de231 Author: Nityanand Rai Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/713de231a61234632e2f9858b222b5f7fd0bdaf1 Stats: 10 lines in 1 file changed: 2 ins; 6 del; 2 mod 8371854: Shenandoah: Simplify WALK_FORWARD_IN_BLOCK_START use Reviewed-by: shade, ysr, xpeng ------------- PR: https://git.openjdk.org/jdk/pull/28333 From kdnilsen at openjdk.org Tue Nov 18 15:55:38 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 18 Nov 2025 15:55:38 GMT Subject: RFR: 8372110: GenShen: Fix erroneous asssert Message-ID: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> Code recently integrated (https://github.com/openjdk/jdk/pull/27353) had an erroneous (meaningless) assert. Closer examination of intended behavior revealed that the fix involves replacing the assert with a new run-time check, as implemented here. ------------- Commit messages: - Fix erroneous assert Changes: https://git.openjdk.org/jdk/pull/28375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28375&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372110 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28375/head:pull/28375 PR: https://git.openjdk.org/jdk/pull/28375 From wkemper at openjdk.org Tue Nov 18 17:04:09 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 18 Nov 2025 17:04:09 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: <4JpTVvsVyPGaIoYtghK3qOx6LDfuRVJg4-Mamrdvb3c=.cccedc0e-437f-4635-af1f-c7155206c6ad@github.com> References: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> <4JpTVvsVyPGaIoYtghK3qOx6LDfuRVJg4-Mamrdvb3c=.cccedc0e-437f-4635-af1f-c7155206c6ad@github.com> Message-ID: On Mon, 17 Nov 2025 14:10:33 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "We can also filter out old when striclty marking young" >> >> This reverts commit c53c4f23f4401785e1049494b6c4e4b92f9a5701. > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 428: > >> 426: >> 427: const char gc_state = ShenandoahThreadLocalData::gc_state(Thread::current()); >> 428: if ((gc_state & ShenandoahHeap::MARKING) != 0) { > > A question on sequencing. Can we have marking and update-refs at the same time? If so, should update-refs happen first, and then marking should be doing the walk over (fixed-up) objects? I can change the sequencing, though I'm not sure it's necessary. Old marking shouldn't be following references into the young generation, so updating references in old that point to young shouldn't matter to old marking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28183#discussion_r2538998438 From wkemper at openjdk.org Tue Nov 18 17:07:57 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 18 Nov 2025 17:07:57 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: References: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> Message-ID: <7gXJPJWjpbPhasLRiKjQ0w5-2JTdJYL2RuGv1OVXt-c=.a83348db-bde0-48c4-a5ca-ceb963855bab@github.com> On Sat, 15 Nov 2025 01:53:05 GMT, Y. Srinivas Ramakrishna wrote: >> William Kemper has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "We can also filter out old when striclty marking young" >> >> This reverts commit c53c4f23f4401785e1049494b6c4e4b92f9a5701. > > Thank you for the clean up and corrections. > > I am curious how you found this issue -- nice catch! > > Any performance data to share, may be even from a microbenchmark perhaps or any other benchmark that exercises array copying -- may be something in DaCapo/Renaissance? @ysramakrishna - I found the issue while carefully reading the code for the related SATB filtering PR that was integrated a couple of weeks ago. We have also seen Genshen spend more time flushing the SATBs before final mark and I believe this code contributed to that. I didn't see any notable performance improvements in benchmark scores, but there is also a correctness issue here that needs to be addressed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28183#issuecomment-3548670206 From shade at openjdk.org Tue Nov 18 17:14:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 18 Nov 2025 17:14:05 GMT Subject: RFR: 8370039: GenShen: array copy SATB barrier improvements [v3] In-Reply-To: References: <4pRORBaXYXwyCJyUp3BKA4I8bHlTfkfNldK9EnDJvZw=.b0a53f9b-a9a0-4c75-a823-7cf82f69a40b@github.com> <4JpTVvsVyPGaIoYtghK3qOx6LDfuRVJg4-Mamrdvb3c=.cccedc0e-437f-4635-af1f-c7155206c6ad@github.com> Message-ID: On Tue, 18 Nov 2025 17:01:13 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 428: >> >>> 426: >>> 427: const char gc_state = ShenandoahThreadLocalData::gc_state(Thread::current()); >>> 428: if ((gc_state & ShenandoahHeap::MARKING) != 0) { >> >> A question on sequencing. Can we have marking and update-refs at the same time? If so, should update-refs happen first, and then marking should be doing the walk over (fixed-up) objects? > > I can change the sequencing, though I'm not sure it's necessary. Old marking shouldn't be following references into the young generation, so updating references in old that point to young shouldn't matter to old marking. Okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28183#discussion_r2539036634 From kbarrett at openjdk.org Tue Nov 18 21:49:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Nov 2025 21:49:12 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 12:46:28 GMT, Stefan Karlsson wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to block_if_java_thread A few remaining comment nits. Marked as reviewed by kbarrett (Reviewer). src/hotspot/share/gc/shared/gcVMOperations.cpp line 132: > 130: if (_is_shutting_down) { > 131: // Block forever if a Java thread is triggering a GC after > 132: // the GC have started to shut down. s/have/has/ src/hotspot/share/gc/shared/gcVMOperations.hpp line 143: > 141: > 142: // This function returns the value of CollectedHeap::is_shutting_down() that > 143: // was recorded in the prologue. Unlike, CollectedHeap::is_shutting_down(), Remove comma after "Unlike". src/hotspot/share/gc/shared/gcVMOperations.hpp line 146: > 144: // this function can be called without acquiring the Heap_lock. > 145: // > 146: // This funciton exists so that code that tries to schedule a GC operation s/funciton/function/ ------------- PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3479724039 PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3479729718 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2539666824 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2539665681 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2539666064 From kbarrett at openjdk.org Tue Nov 18 21:49:50 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Nov 2025 21:49:50 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic [v2] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 06:40:04 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed unintentional load_acquire in test > > Marked as reviewed by stefank (Reviewer). Thanks for reviews @stefank and @tschatzl ------------- PR Comment: https://git.openjdk.org/jdk/pull/28338#issuecomment-3549485991 From duke at openjdk.org Tue Nov 18 23:10:42 2025 From: duke at openjdk.org (Nityanand Rai) Date: Tue, 18 Nov 2025 23:10:42 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v4] In-Reply-To: References: Message-ID: > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: remove UseCondCardMark chnages, to decouple issues fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28204/files - new: https://git.openjdk.org/jdk/pull/28204/files/1c85da72..123078b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28204/head:pull/28204 PR: https://git.openjdk.org/jdk/pull/28204 From duke at openjdk.org Tue Nov 18 23:10:43 2025 From: duke at openjdk.org (Nityanand Rai) Date: Tue, 18 Nov 2025 23:10:43 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v3] In-Reply-To: <-0iMsHeZnk_Ld_6D9zCBNFVcXi9rIq9S0NmmYEgqb0I=.ffb1591a-83a7-47be-86ff-a5646b51e3e1@github.com> References: <-0iMsHeZnk_Ld_6D9zCBNFVcXi9rIq9S0NmmYEgqb0I=.ffb1591a-83a7-47be-86ff-a5646b51e3e1@github.com> Message-ID: On Mon, 10 Nov 2025 23:33:21 GMT, Nityanand Rai wrote: >> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Aleksey Shipil?v We are seeing mixed results, I need to do more validation. Here are GenShen results over 100+ sample collections +1.90% philosophers/philosophers_duration p=0.00142 (Wilcoxon) Control: 2.620s (+/-173.82ms) 120 Test: 2.670s (+/-205.24ms) 120 +1.68% finagle-chirper/finagle-chirper_duration p=0.00343 (Wilcoxon) Control: 2.802s (+/-130.38ms) 360 Test: 2.850s (+/-131.25ms) 360 +1.04% rx-scrabble/rx-scrabble_duration p=0.00000 (Wilcoxon) Control: 148.308ms (+/- 0.88ms) 320 Test: 149.855ms (+/- 0.60ms) 320 -2.48% scrabble/scrabble_duration p=0.00000 (Wilcoxon) Control: 169.599ms (+/- 2.90ms) 200 Test: 165.399ms (+/- 3.40ms) 200 -2.24% scala-kmeans/scala-kmeans_duration p=0.00000 (Wilcoxon) Control: 479.973ms (+/- 1.92ms) 200 Test: 469.219ms (+/- 1.98ms) 200 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28204#issuecomment-3529225545 PR Comment: https://git.openjdk.org/jdk/pull/28204#issuecomment-3549800707 From kbarrett at openjdk.org Tue Nov 18 23:45:49 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Nov 2025 23:45:49 GMT Subject: Integrated: 8371956: Convert OopStorage to use Atomic In-Reply-To: References: Message-ID: <5b_bP_7eQ6N44m0OHHm_DcI35dGEAphKYoKXHB6xT_I=.5b809ee9-a51c-4dc6-9cc0-6050f3f8c160@github.com> On Sun, 16 Nov 2025 06:10:54 GMT, Kim Barrett wrote: > Please review this change to OopStorage to use Atomic rather than directly > applying AtomicAccess to volatile members. > > Testing: mach5 tier1-5 This pull request has now been integrated. Changeset: 152cd4d8 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/152cd4d8bab7d3428d0330c56a3cb9ed7feef313 Stats: 103 lines in 5 files changed: 8 ins; 2 del; 93 mod 8371956: Convert OopStorage to use Atomic Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28338 From kbarrett at openjdk.org Wed Nov 19 00:18:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 19 Nov 2025 00:18:59 GMT Subject: RFR: 8371956: Convert OopStorage to use Atomic [v2] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 10:40:24 GMT, Stefan Karlsson wrote: > [...] I also noticed that we use `volatile` with `_owner_address`, is that because of the SafeFetch usage? I forgot to respond to this question. As the comment says, the member clearing in ~Block resets values used elsewhere for mapping from an entry to its containing block, and validating that lookup. So this clearing will cause the lookup to fail if the block has been destructed and not reallocated by the same storage object, or reallocated by the same storage object but the specific entry hasn't been reallocated. So perhaps being somewhat paranoid, but that lookup and block management are a little bit tricky. The reason for the cast to volatile isn't about SafeFetch usage specifically though. Rather, as the comment says, it's to prevent the compiler from (potentially) eliminating the dead store, since we're in the destructor and that member is about to be (trivially) destructed itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28338#issuecomment-3549995629 From stefank at openjdk.org Wed Nov 19 07:21:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 19 Nov 2025 07:21:51 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v4] In-Reply-To: References: Message-ID: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28349/files - new: https://git.openjdk.org/jdk/pull/28349/files/c5f65378..8a928cae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28349&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28349&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28349.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28349/head:pull/28349 PR: https://git.openjdk.org/jdk/pull/28349 From stefank at openjdk.org Wed Nov 19 07:21:58 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 19 Nov 2025 07:21:58 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v3] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 20:48:42 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment to block_if_java_thread > > src/hotspot/share/gc/shared/gcVMOperations.cpp line 132: > >> 130: if (_is_shutting_down) { >> 131: // Block forever if a Java thread is triggering a GC after >> 132: // the GC have started to shut down. > > s/have/has/ Fixed. Thanks. > src/hotspot/share/gc/shared/gcVMOperations.hpp line 143: > >> 141: >> 142: // This function returns the value of CollectedHeap::is_shutting_down() that >> 143: // was recorded in the prologue. Unlike, CollectedHeap::is_shutting_down(), > > Remove comma after "Unlike". Fixed. Thanks. > src/hotspot/share/gc/shared/gcVMOperations.hpp line 146: > >> 144: // this function can be called without acquiring the Heap_lock. >> 145: // >> 146: // This funciton exists so that code that tries to schedule a GC operation > > s/funciton/function/ Fixed. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2540827549 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2540827393 PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2540827732 From kbarrett at openjdk.org Wed Nov 19 07:30:56 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 19 Nov 2025 07:30:56 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v4] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 07:21:51 GMT, Stefan Karlsson wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3481203855 From shade at openjdk.org Wed Nov 19 08:04:29 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 19 Nov 2025 08:04:29 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v4] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 23:10:42 GMT, Nityanand Rai wrote: >> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > remove UseCondCardMark chnages, to decouple issues fixed Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3481319357 From ayang at openjdk.org Wed Nov 19 11:47:33 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 11:47:33 GMT Subject: RFR: 8371985: Parallel: Move should_attempt_scavenge to ParallelScavengeHeap In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 09:49:30 GMT, Albert Mingkun Yang wrote: > Move young/full-gc criteria heuristics outside of `psScavenge.cpp` so that young-gc API runs to completion. > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28346#issuecomment-3552246854 From ayang at openjdk.org Wed Nov 19 11:50:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 11:50:41 GMT Subject: Integrated: 8371985: Parallel: Move should_attempt_scavenge to ParallelScavengeHeap In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 09:49:30 GMT, Albert Mingkun Yang wrote: > Move young/full-gc criteria heuristics outside of `psScavenge.cpp` so that young-gc API runs to completion. > > Test: tier1-3 This pull request has now been integrated. Changeset: 54893dc5 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/54893dc5c2a4702896029b1844bc9496325c8f26 Stats: 121 lines in 4 files changed: 53 ins; 62 del; 6 mod 8371985: Parallel: Move should_attempt_scavenge to ParallelScavengeHeap Reviewed-by: fandreuzzi, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28346 From ayang at openjdk.org Wed Nov 19 12:00:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 12:00:24 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 10:08:36 GMT, Joel Sikstr?m wrote: > Hello, > > We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. > > When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. > > The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. > > Testing: > * Oracle's tier1-3 src/hotspot/share/gc/shared/gcVMOperations.cpp line 210: > 208: SvcGCMarker sgcm(SvcGCMarker::FULL); > 209: > 210: CollectedHeap* heap = Universe::heap(); This `heap` var can be moved down now, I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28287#discussion_r2541693878 From azafari at openjdk.org Wed Nov 19 13:31:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 19 Nov 2025 13:31:15 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> Message-ID: On Mon, 17 Nov 2025 01:16:31 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix arguments.cpp for HeapMinBaseAddress type. > > src/hotspot/share/memory/memoryReserver.cpp line 549: > >> 547: const size_t attach_point_alignment = lcm(alignment, os_attach_point_alignment); >> 548: >> 549: uintptr_t aligned_heap_base_min_address = align_up(MAX2(HeapBaseMinAddress, alignment), alignment); > > Just to be clear, this is the crux of the fix, where we ensure the min-address is now never zero - right? Right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2542017385 From azafari at openjdk.org Wed Nov 19 13:48:21 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 19 Nov 2025 13:48:21 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> Message-ID: On Mon, 17 Nov 2025 01:18:11 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix arguments.cpp for HeapMinBaseAddress type. > > src/hotspot/share/memory/memoryReserver.cpp line 586: > >> 584: lowest_start, highest_start); >> 585: reserved = try_reserve_range((char*)highest_start, (char*)lowest_start, attach_point_alignment, >> 586: (char*)aligned_heap_base_min_address, (char*)UnscaledOopHeapMax, size, alignment, page_size); > > Not obvious to me this actually improves anything - what is it fixing? First, the pointer arithmetics are done on `uintptr_t` types to avoid UB. Second, it is checked that `lowest` and `highest` are still valid after becoming larger or smaller, respectively. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2542076686 From azafari at openjdk.org Wed Nov 19 13:56:04 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 19 Nov 2025 13:56:04 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> Message-ID: On Mon, 17 Nov 2025 01:21:52 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fix arguments.cpp for HeapMinBaseAddress type. > > src/hotspot/share/memory/memoryReserver.cpp line 590: > >> 588: >> 589: // zerobased: Attempt to allocate in the lower 32G. >> 590: size_t zerobased_max = OopEncodingHeapMax; > > Again not obvious what this improves. We obviously have very inconsistent use of types here in that we loosely use `char*`, `uint64_t` and `size_t` to all mean a 64-bit unsigned value, ansd no matter what types we use in the declarations we have to cast something somewhere. According to reviewers' suggestions, the pointers used in arithmeitc are typed as numeric like `size_t` or `uintptr_t`. And only when they are going to be passed as pointers to other functions, they will be cast to the desired pointers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2542089700 From ayang at openjdk.org Wed Nov 19 15:21:33 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 15:21:33 GMT Subject: RFR: 8372162: G1: Merging subclasses of G1IHOPControl into parent class Message-ID: Merging two subclasses into the parent class to simplify type hierarchy. The internal `bool` flag doesn't introduce much complexity; instead, improves readability, IMO. Perf neutral on linux-x64/aarch64: cachestree, dacapo, dacapo23, specjbb2005, specjbb2015, specjvm2008. Test: tier1-5 ------------- Commit messages: - g1-ihop Changes: https://git.openjdk.org/jdk/pull/28391/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372162 Stats: 321 lines in 5 files changed: 91 ins; 154 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/28391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28391/head:pull/28391 PR: https://git.openjdk.org/jdk/pull/28391 From ayang at openjdk.org Wed Nov 19 15:24:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 15:24:56 GMT Subject: RFR: 8372163: G1: Remove unused G1HeapRegion::remove_code_root Message-ID: Trivial removing dead code. Test: build ------------- Commit messages: - g1-trivial-remove Changes: https://git.openjdk.org/jdk/pull/28392/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28392&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372163 Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28392.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28392/head:pull/28392 PR: https://git.openjdk.org/jdk/pull/28392 From tschatzl at openjdk.org Wed Nov 19 15:44:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 19 Nov 2025 15:44:53 GMT Subject: RFR: 8372163: G1: Remove unused G1HeapRegion::remove_code_root In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:16:16 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: build Lgtm and trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28392#pullrequestreview-3483451916 From ayang at openjdk.org Wed Nov 19 15:51:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 15:51:47 GMT Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed: assert(left >= right) failed: avoid underflow Message-ID: Add an early-return for outside-heap address in `CollectedHeap::is_in` API. While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable. Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs. ------------- Commit messages: - sgc-is-in-early-return Changes: https://git.openjdk.org/jdk/pull/28393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370198 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28393/head:pull/28393 PR: https://git.openjdk.org/jdk/pull/28393 From jsikstro at openjdk.org Wed Nov 19 16:11:42 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 19 Nov 2025 16:11:42 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v2] In-Reply-To: References: Message-ID: > Hello, > > We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. > > When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. > > The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. > > Testing: > * Oracle's tier1-3 Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Move heap variable down a bit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28287/files - new: https://git.openjdk.org/jdk/pull/28287/files/25da0eef..4355bd66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28287&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28287&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28287/head:pull/28287 PR: https://git.openjdk.org/jdk/pull/28287 From aboldtch at openjdk.org Wed Nov 19 17:01:32 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 19 Nov 2025 17:01:32 GMT Subject: RFR: 8372150: Parallel: Tighten requirements around MinHeapSize with NUMA and Large Pages In-Reply-To: <_nJ3sxtl4WL88gpE1VQgR-lSry1K_t60lqc8am2cWzU=.09c65da8-9cae-41c5-9eac-ee9172149b39@github.com> References: <_nJ3sxtl4WL88gpE1VQgR-lSry1K_t60lqc8am2cWzU=.09c65da8-9cae-41c5-9eac-ee9172149b39@github.com> Message-ID: On Wed, 19 Nov 2025 15:44:57 GMT, Joel Sikstr?m wrote: > Hello, > > Today, Parallel decides to opt out of using Large pages if the initial heap size does not cover enough Large pages for all spaces. Additionally, if we don't get enough initial heap size for at least one OS page per MutableNUMASpace (one per NUMA-node), Parallel decides to run in a NUMA-degraded mode, where it skips allocating memory locally for some NUMA-nodes. Both of these issues are problematic if we want to start the JVM with a default initial heap size that is equal to the minimum heap size (see [JDK-8371986](https://bugs.openjdk.org/browse/JDK-8371986)). To solve this, we should consider making sure that the minimum heap size is always enough to cover precisely one page per space, where the page size may be Large or not. By making sure the minimum heap size covers this, we never have to disable Large pages or run in a NUMA-degraded mode based on the setting of the initial heap size. > > For completeness, when user-proided settings for UseNUMA, UseLargePages and InitialHeapSize can't be satisfied at the same time, one must be prioritised over others. Today, we prioritise InitialHeapSize over both UseNUMA and UseLargePages. This change suggest shifting the priority to UseNUMA and UseLargePages, by bumping MinHeapSize to an adequate number. Bumping MinHeapSize directly affects InitialHeapSize, since InitialHeapSize must be equal to or greater than MinHeapSize. > >
> > Min and Initial heap sizes before/after (expandable section) > > Before changes. We always get Min&Initial 2MB that we request: > > java -XX:+UseParallelGC -Xms2M -Xmx1G > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > java -XX:+UseParallelGC -XX:+UseLargePages -Xms2M -Xmx1G > MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > java -XX:+UseParallelGC -XX:+UseNUMA -Xms2M -Xmx1G > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > java -XX:+UseParallelGC -XX:+UseLargePages -XX:+UseNUMA -Xms2M -Xmx1G > MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > > After changes. We bump Min, and in turn also Initial, to accommodate enough Large Pages for all spaces. This is run on a NUMA machine with two NUMA nodes, so we get an extra 2MB when NUMA is enabled for the additi... lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28394#pullrequestreview-3483834939 From jsikstro at openjdk.org Wed Nov 19 17:37:56 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 19 Nov 2025 17:37:56 GMT Subject: RFR: 8372150: Parallel: Tighten requirements around MinHeapSize with NUMA and Large Pages [v2] In-Reply-To: <_nJ3sxtl4WL88gpE1VQgR-lSry1K_t60lqc8am2cWzU=.09c65da8-9cae-41c5-9eac-ee9172149b39@github.com> References: <_nJ3sxtl4WL88gpE1VQgR-lSry1K_t60lqc8am2cWzU=.09c65da8-9cae-41c5-9eac-ee9172149b39@github.com> Message-ID: <5vDCL3V5Gq13ay3zN4ly0mO1wmjg5X-n4bCPqIGrF-Q=.d11c5e80-479e-48cc-960d-8a4c353b4036@github.com> > Hello, > > Today, Parallel decides to opt out of using Large pages if the initial heap size does not cover enough Large pages for all spaces. Additionally, if we don't get enough initial heap size for at least one OS page per MutableNUMASpace (one per NUMA-node), Parallel decides to run in a NUMA-degraded mode, where it skips allocating memory locally for some NUMA-nodes. Both of these issues are problematic if we want to start the JVM with a default initial heap size that is equal to the minimum heap size (see [JDK-8371986](https://bugs.openjdk.org/browse/JDK-8371986)). To solve this, we should consider making sure that the minimum heap size is always enough to cover precisely one page per space, where the page size may be Large or not. By making sure the minimum heap size covers this, we never have to disable Large pages or run in a NUMA-degraded mode based on the setting of the initial heap size. > > For completeness, when user-proided settings for UseNUMA, UseLargePages and InitialHeapSize can't be satisfied at the same time, one must be prioritised over others. Today, we prioritise InitialHeapSize over both UseNUMA and UseLargePages. This change suggest shifting the priority to UseNUMA and UseLargePages, by bumping MinHeapSize to an adequate number. Bumping MinHeapSize directly affects InitialHeapSize, since InitialHeapSize must be equal to or greater than MinHeapSize. > >
> > Min and Initial heap sizes before/after (expandable section) > > Before changes. We always get Min&Initial 2MB that we request: > > java -XX:+UseParallelGC -Xms2M -Xmx1G > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > java -XX:+UseParallelGC -XX:+UseLargePages -Xms2M -Xmx1G > MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > java -XX:+UseParallelGC -XX:+UseNUMA -Xms2M -Xmx1G > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > java -XX:+UseParallelGC -XX:+UseLargePages -XX:+UseNUMA -Xms2M -Xmx1G > MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap > Alignments: Space 512K, Heap 2M > Heap Min Capacity: 2M > Heap Initial Capacity: 2M > > > After changes. We bump Min, and in turn also Initial, to accommodate enough Large Pages for all spaces. This is run on a NUMA machine with two NUMA nodes, so we get an extra 2MB when NUMA is enabled for the additi... Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: Albert review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28394/files - new: https://git.openjdk.org/jdk/pull/28394/files/c02e08ad..66928d22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28394&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28394&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28394.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28394/head:pull/28394 PR: https://git.openjdk.org/jdk/pull/28394 From kbarrett at openjdk.org Wed Nov 19 21:04:32 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 19 Nov 2025 21:04:32 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v2] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 16:11:42 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. >> >> When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. >> >> The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. >> >> Testing: >> * Oracle's tier1-3 > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Move heap variable down a bit Still good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28287#pullrequestreview-3484730546 From ayang at openjdk.org Wed Nov 19 21:29:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 19 Nov 2025 21:29:52 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v2] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 16:11:42 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. >> >> When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. >> >> The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. >> >> Testing: >> * Oracle's tier1-3 > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Move heap variable down a bit Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28287#pullrequestreview-3484805596 From kdnilsen at openjdk.org Wed Nov 19 22:28:21 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 19 Nov 2025 22:28:21 GMT Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v7] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 00:21:27 GMT, William Kemper wrote: >> Notable changes: >> * Improvements to logging >> * More accurate tracking of promotion failures >> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size) >> * Use census information gathered during mark to size promotion reserves and old generation >> >> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results. >> >> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks: >> >> >> Concurrent Evacuation: 7 improvements, 3 regressions >> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%) >> ? Worst regression: xalan (+53.7%) >> >> Concurrent Marking: 15 improvements, 1 regression >> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%) >> ? Only regression: serial (+8.9%) >> >> Concurrent Scan Remembered Set: 7 improvements, 2 regressions >> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%) >> ? Worst regression: extremem-phased (+52.4%) >> >> Concurrent Update Refs: 5 improvements, 4 regressions >> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%) >> ? Worst regression: xalan (+89.4%) > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Merge tag 'jdk-26+20' into promotion-budget-improvements > > Added tag jdk-26+20 for changeset b5b83247 > - Proper format bytes in logs for better readability > - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements > - Review feedback, bug fixes > - Fix windows build more > - Fix windows build > - Little cleanup > - Fix wrong asserts > - ... and 50 more: https://git.openjdk.org/jdk/compare/6347f10b...1d81159a src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 661: > 659: const size_t tenurable_next_cycle = heap->age_census()->get_tenurable_bytes(tenuring_threshold - 1); > 660: const size_t tenurable_this_cycle = heap->age_census()->get_tenurable_bytes(tenuring_threshold); > 661: I'm wondering if we should subtract tenurable_this_cycle from tenurable_next_cycle. (and assert that tenurable_this_cycle is <= tenurable_next_cycle) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2543694437 From ysr at openjdk.org Wed Nov 19 22:32:47 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 19 Nov 2025 22:32:47 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v4] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 23:10:42 GMT, Nityanand Rai wrote: >> Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. > > Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: > > remove UseCondCardMark chnages, to decouple issues fixed Description states: > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. I don't see any change for the latter. I believe `UseCondCardMark` is already enabled with GenShen, and the barrier ode respects it. Also `Exclude young-young, old-old` skips the part of the change that also skips `young->old`. I'd reword the synopsis to: > Skips card marks for stores in young generation objects, old -> old, and null stores. which I think is what the code does. In the performance comparisons, did you see any effect on remembered set scan times (there are card-scan stats that can be enabled in a "release" (non product) build, as needed). Left some suggestions for tightening up documentation comment. Rest looks good. As Aleksey noted, the conditional card marks can of course slow down the mutator, so we want to see if the savings in card scan times (because of skipping old->old, or null writes in old) would make up. src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 199: > 197: } > 198: T heap_oop = RawAccess<>::oop_load(field); > 199: if (CompressedOops::is_null(heap_oop)) { For completeness, add a comment: // Null reference store src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 204: > 202: oop obj = CompressedOops::decode_not_null(heap_oop); > 203: if (!_heap->is_in_young(obj)) { > 204: // Young object -> old field stores do not require card mark. As worded, this comment is wrong (or at least confusing). May be rephrase to: // Not an old->young reference store ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28204#pullrequestreview-3484940575 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2543736759 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2543729096 From duke at openjdk.org Wed Nov 19 23:31:41 2025 From: duke at openjdk.org (Nityanand Rai) Date: Wed, 19 Nov 2025 23:31:41 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v5] In-Reply-To: References: Message-ID: > Exclude young-young, old-old and honor UseCondCardMark in dirty card marking. Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: hardening of comments remove unintended files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28204/files - new: https://git.openjdk.org/jdk/pull/28204/files/123078b2..4054a52e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28204&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28204/head:pull/28204 PR: https://git.openjdk.org/jdk/pull/28204 From duke at openjdk.org Wed Nov 19 23:31:44 2025 From: duke at openjdk.org (Nityanand Rai) Date: Wed, 19 Nov 2025 23:31:44 GMT Subject: RFR: 8371284: GenShen: Avoid unnecessary card marking [v4] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 22:16:39 GMT, Y. Srinivas Ramakrishna wrote: >> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision: >> >> remove UseCondCardMark chnages, to decouple issues fixed > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 199: > >> 197: } >> 198: T heap_oop = RawAccess<>::oop_load(field); >> 199: if (CompressedOops::is_null(heap_oop)) { > > For completeness, add a comment: > > // Null reference store Added > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 204: > >> 202: oop obj = CompressedOops::decode_not_null(heap_oop); >> 203: if (!_heap->is_in_young(obj)) { >> 204: // Young object -> old field stores do not require card mark. > > As worded, this comment is wrong (or at least confusing). May be rephrase to: > > > // Not an old->young reference store Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2543863775 PR Review Comment: https://git.openjdk.org/jdk/pull/28204#discussion_r2543864179 From ysr at openjdk.org Thu Nov 20 02:30:44 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 20 Nov 2025 02:30:44 GMT Subject: RFR: 8372110: GenShen: Fix erroneous assert In-Reply-To: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> References: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> Message-ID: On Tue, 18 Nov 2025 15:40:35 GMT, Kelvin Nilsen wrote: > Code recently integrated (https://github.com/openjdk/jdk/pull/27353) had an erroneous (meaningless) assert. Closer examination of intended behavior revealed that the fix involves replacing the assert with a new run-time check, as implemented here. Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28375#pullrequestreview-3485431864 From ysr at openjdk.org Thu Nov 20 02:36:16 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 20 Nov 2025 02:36:16 GMT Subject: RFR: 8372110: GenShen: Fix erroneous assert In-Reply-To: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> References: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> Message-ID: <_fXtv5S9qOByjlDYbDZNKT216WlmJLqfxTmRfGYhVxk=.0d3ddcf5-7306-4733-9e1d-f2ca9b116a1a@github.com> On Tue, 18 Nov 2025 15:40:35 GMT, Kelvin Nilsen wrote: > Code recently integrated (https://github.com/openjdk/jdk/pull/27353) had an erroneous (meaningless) assert. Closer examination of intended behavior revealed that the fix involves replacing the assert with a new run-time check, as implemented here. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28375#issuecomment-3555504468 From kdnilsen at openjdk.org Thu Nov 20 03:30:10 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 20 Nov 2025 03:30:10 GMT Subject: RFR: 8372110: GenShen: Fix erroneous assert [v2] In-Reply-To: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> References: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> Message-ID: > Code recently integrated (https://github.com/openjdk/jdk/pull/27353) had an erroneous (meaningless) assert. Closer examination of intended behavior revealed that the fix involves replacing the assert with a new run-time check, as implemented here. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'jdk/master' into fix-finish-block-start-assert - Fix erroneous assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28375/files - new: https://git.openjdk.org/jdk/pull/28375/files/86d92901..591f09e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28375&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28375&range=00-01 Stats: 5609 lines in 146 files changed: 3405 ins; 891 del; 1313 mod Patch: https://git.openjdk.org/jdk/pull/28375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28375/head:pull/28375 PR: https://git.openjdk.org/jdk/pull/28375 From dholmes at openjdk.org Thu Nov 20 05:13:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Nov 2025 05:13:52 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> Message-ID: On Wed, 19 Nov 2025 13:45:11 GMT, Afshin Zafari wrote: >> src/hotspot/share/memory/memoryReserver.cpp line 586: >> >>> 584: lowest_start, highest_start); >>> 585: reserved = try_reserve_range((char*)highest_start, (char*)lowest_start, attach_point_alignment, >>> 586: (char*)aligned_heap_base_min_address, (char*)UnscaledOopHeapMax, size, alignment, page_size); >> >> Not obvious to me this actually improves anything - what is it fixing? > > First, the pointer arithmetics are done on `uintptr_t` types to avoid UB. > Second, it is checked that `lowest` and `highest` are still valid after becoming larger or smaller, respectively. I think it would be more accurate to say we are avoiding actual pointer arithmetic here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2544355021 From dholmes at openjdk.org Thu Nov 20 05:18:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Nov 2025 05:18:57 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> Message-ID: On Wed, 19 Nov 2025 13:48:41 GMT, Afshin Zafari wrote: >> src/hotspot/share/memory/memoryReserver.cpp line 590: >> >>> 588: >>> 589: // zerobased: Attempt to allocate in the lower 32G. >>> 590: size_t zerobased_max = OopEncodingHeapMax; >> >> Again not obvious what this improves. We obviously have very inconsistent use of types here in that we loosely use `char*`, `uint64_t` and `size_t` to all mean a 64-bit unsigned value, ansd no matter what types we use in the declarations we have to cast something somewhere. > > According to reviewers' suggestions, the pointers used in arithmeitc are typed as numeric like `size_t` or `uintptr_t`. And only when they are going to be passed as pointers to other functions, they will be cast to the desired pointers. Okay but why `size_t` in places and `uintptr_t` in others? In this case `zerobased_max` seems an address not a size - similar to `highest_start` and `lowest_start` in the other part of the change. But then `OopEncodingHeapMax` is `uint64_t` so why not use that? I'm just not seeing the rules that are being applied here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2544365753 From aboldtch at openjdk.org Thu Nov 20 06:20:45 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 06:20:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <1p_wEewR-A5FFkJasTnjbE4brFCQIUNp7hmP8WfhV6g=.9ab47c1c-b749-484c-b282-9ad678a06d13@github.com> Message-ID: On Thu, 20 Nov 2025 05:15:48 GMT, David Holmes wrote: >> According to reviewers' suggestions, the pointers used in arithmeitc are typed as numeric like `size_t` or `uintptr_t`. And only when they are going to be passed as pointers to other functions, they will be cast to the desired pointers. > > Okay but why `size_t` in places and `uintptr_t` in others? In this case `zerobased_max` seems an address not a size - similar to `highest_start` and `lowest_start` in the other part of the change. But then `OopEncodingHeapMax` is `uint64_t` so why not use that? > > I'm just not seeing the rules that are being applied here. Not using `uint64_t` I think was to be pragmatic because it is a different type than `uintptr_t` (on MacOS iirc). One is `unsigned long long` and the other is `unsigned long`. Causes issues with overload resolution for templated functions. (Maybe that was just the issue with the similarly typed `UnscaledOopHeapMax`) I think `OopEncodingHeapMax` is unfortunately typed. It might be intentional. Because we use it in two ways. Either as the `Maximal size of heap`, or as the `zero based address: 0 + OopEncodingHeapMax` (the max end address of the `Maximal size of heap` Heap). In one case the type is more natural to be `size_t` and in the other it is `uintptr_t`. Right here though I agree type should be `uintptr_t`. We are using it as the max address our heap can end in. I would much rather we had ```c++ const uintptr_t zerobased_max = OopEncodingHeapMax; In my opinion `UnscaledOopHeapMax` `OopEncodingHeapMax` should be typed as size_t, better named (to reflect their compressed oop nature and that they relate to the `Maximal size of heap`) and only be available in 64-bit VM (as using these in a 32-bit VM smells buggy). And when we want to use it as the max end address we put it in a `uintptr_t` typed variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2544488536 From stefank at openjdk.org Thu Nov 20 09:21:20 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 20 Nov 2025 09:21:20 GMT Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed: assert(left >= right) failed: avoid underflow In-Reply-To: References: Message-ID: <6l6zbFw04NoELlc-_nTeRFGeGUVBCpT1RRyKfeA8H_s=.3f047a15-86f1-48ab-b22b-dc01223b3c21@github.com> On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang wrote: > Add an early-return for outside-heap address in `CollectedHeap::is_in` API. > > While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable. > > Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs. This is quite conspicuous. Could this the addition be added to a function (or macro) so that the check becomes a one-liner. We have a similar function inside the ZGC runtime barriers. See: template inline zaddress ZBarrier::barrier(ZBarrierFastPath fast_path, ZBarrierSlowPath slow_path, ZBarrierColor color, volatile zpointer* p, zpointer o, bool allow_null) { z_verify_safepoints_are_blocked(); ... < rest of the function > I don't understand why we would want to put this check between the two range changes. Is there a reason why the added check couldn't be done at the beginning of the function? ------------- PR Review: https://git.openjdk.org/jdk/pull/28393#pullrequestreview-3486554067 From aboldtch at openjdk.org Thu Nov 20 09:30:25 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 09:30:25 GMT Subject: RFR: 8372244: ZGC: Split ZTest into a VM and not VM test fixture Message-ID: The `ZTest` GTest fixture is used for both VM and not VM tests, however the implementation requires VM. The not VM tests which use it are only interested in a sub-set of its features. I propose we split `ZTest` into a hierarchy of fixtures, one for not VM tests, and the other for VM tests. I could not find an easy way to identity which category of test a fixture is used in, so for now we just have to be diligent to use the appropriate fixture. We do have an assumption here that `os::next_random` is fine to call without having setup the VM. If this is changes in future we would have to add a not VM dependent prng function. Also the VMless fixture do not test if the OS is supported, as it might require VM features to work. But tests which run without VM should not be dependent if the VM is OS is supported. ------------- Depends on: https://git.openjdk.org/jdk/pull/28409 Commit messages: - ZGC: Split ZTest into a VM and not VM test fixture Changes: https://git.openjdk.org/jdk/pull/28414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28414&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372244 Stats: 37 lines in 11 files changed: 16 ins; 8 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28414/head:pull/28414 PR: https://git.openjdk.org/jdk/pull/28414 From aboldtch at openjdk.org Thu Nov 20 09:39:31 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 09:39:31 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race [v2] In-Reply-To: <2t7atbFpaHbBOH70fk-JDI1dU_xt1FNeesfOfe3Gf4M=.c2811325-b98c-49a3-8ebc-ff3722344a8d@github.com> References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> <2t7atbFpaHbBOH70fk-JDI1dU_xt1FNeesfOfe3Gf4M=.c2811325-b98c-49a3-8ebc-ff3722344a8d@github.com> Message-ID: On Tue, 18 Nov 2025 14:44:47 GMT, Erik ?sterlund wrote: >> C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. >> >> When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. >> >> ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. >> >> Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. >> >> However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. >> >> This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. >> >> If the guard check is performed before the handshake, then the JIT-compiled code will continue to exe... > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Remove assert Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28176#pullrequestreview-3486650881 From tschatzl at openjdk.org Thu Nov 20 10:05:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 10:05:49 GMT Subject: RFR: 8372162: G1: Merging subclasses of G1IHOPControl into parent class In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:12:39 GMT, Albert Mingkun Yang wrote: > Merging two subclasses into the parent class to simplify type hierarchy. The internal `bool` flag doesn't introduce much complexity; instead, improves readability, IMO. > > Perf neutral on linux-x64/aarch64: cachestree, dacapo, dacapo23, specjbb2005, specjbb2015, specjvm2008. > > Test: tier1-5 Seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28391#pullrequestreview-3486799504 From tschatzl at openjdk.org Thu Nov 20 10:08:57 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 10:08:57 GMT Subject: RFR: 8371965: Convert TaskQueueSuper to use Atomic In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 10:22:13 GMT, Kim Barrett wrote: > Please review this change to TaskQueueSuper to use Atomic rather than > directly applying AtomicAccess to (sometimes!) volatile members. There was > some sketchy stuff around TaskQueueSuper::Age. This has been cleaned up by > hoisting that class to namespace scope (now called TaskQueueAge) and declaring > a PrimitiveConversion::Translate for it. > > Testing: mach5 tier1-5 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28347#pullrequestreview-3486821784 From tschatzl at openjdk.org Thu Nov 20 10:13:22 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 10:13:22 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v4] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 07:21:51 GMT, Stefan Karlsson wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3486839623 From iwalulya at openjdk.org Thu Nov 20 10:29:44 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 20 Nov 2025 10:29:44 GMT Subject: RFR: 8372162: G1: Merging subclasses of G1IHOPControl into parent class In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:12:39 GMT, Albert Mingkun Yang wrote: > Merging two subclasses into the parent class to simplify type hierarchy. The internal `bool` flag doesn't introduce much complexity; instead, improves readability, IMO. > > Perf neutral on linux-x64/aarch64: cachestree, dacapo, dacapo23, specjbb2005, specjbb2015, specjvm2008. > > Test: tier1-5 Looks good! Fix title after triage changed it ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28391#pullrequestreview-3486923118 From tschatzl at openjdk.org Thu Nov 20 10:34:41 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 10:34:41 GMT Subject: RFR: 8372149: G1: Remove unnecessary num_added_to_group from G1CollectionSetCandidates::set_candidates_from_marking() Message-ID: Hi all, please review this tiny change to remove some local variable (and management) in G1. The one use of the getter from the container is just as easy to understand to me (vs. declaration and management). Testing: gha Thanks, Thomas ------------- Commit messages: - 8372149 Changes: https://git.openjdk.org/jdk/pull/28419/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28419&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372149 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28419/head:pull/28419 PR: https://git.openjdk.org/jdk/pull/28419 From iwalulya at openjdk.org Thu Nov 20 10:53:26 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 20 Nov 2025 10:53:26 GMT Subject: RFR: 8372149: G1: Remove unnecessary num_added_to_group from G1CollectionSetCandidates::set_candidates_from_marking() In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:18:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change to remove some local variable (and management) in G1. The one use of the getter from the container is just as easy to understand to me (vs. declaration and management). > > Testing: gha > > Thanks, > Thomas Trivial! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28419#pullrequestreview-3487091936 From rsunderbabu at openjdk.org Thu Nov 20 11:11:38 2025 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Thu, 20 Nov 2025 11:11:38 GMT Subject: RFR: 8319540: GC: Make TestSelectDefaultGC use createTestJavaProcessBuilder Message-ID: Make TestSelectDefaultGC forward VM/JAVA_OPTIONS. Testing: Tiers 1 to 5 Ran with all flag combinations in CI ------------- Commit messages: - 8319540: GC: Make TestSelectDefaultGC use createTestJavaProcessBuilder Changes: https://git.openjdk.org/jdk/pull/28422/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319540 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28422/head:pull/28422 PR: https://git.openjdk.org/jdk/pull/28422 From tschatzl at openjdk.org Thu Nov 20 11:21:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 11:21:48 GMT Subject: RFR: 8371998: G1: Rename G1MergeHeapRootsTask::G1ClearBitmapClosure to be more distinct Message-ID: Hi all, please review the renaming of `G1MergeHeapRootsTask::G1ClearBitmapClosure` to something more distinct and appropriate to its function. This also helps distinguishing it to the G1ClearBitmapHRClosure from concurrent marking that just does that. Testing: compilation, gha Thanks, Thomas ------------- Commit messages: - 8371998 Changes: https://git.openjdk.org/jdk/pull/28424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371998 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28424/head:pull/28424 PR: https://git.openjdk.org/jdk/pull/28424 From ayang at openjdk.org Thu Nov 20 11:33:27 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 11:33:27 GMT Subject: RFR: 8372149: G1: Remove unnecessary num_added_to_group from G1CollectionSetCandidates::set_candidates_from_marking() In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:18:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change to remove some local variable (and management) in G1. The one use of the getter from the container is just as easy to understand to me (vs. declaration and management). > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28419#pullrequestreview-3487307274 From ayang at openjdk.org Thu Nov 20 11:38:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 11:38:45 GMT Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed: assert(left >= right) failed: avoid underflow In-Reply-To: <6l6zbFw04NoELlc-_nTeRFGeGUVBCpT1RRyKfeA8H_s=.3f047a15-86f1-48ab-b22b-dc01223b3c21@github.com> References: <6l6zbFw04NoELlc-_nTeRFGeGUVBCpT1RRyKfeA8H_s=.3f047a15-86f1-48ab-b22b-dc01223b3c21@github.com> Message-ID: On Thu, 20 Nov 2025 09:17:27 GMT, Stefan Karlsson wrote: > Could this the addition be added to a function (or macro) so that the check becomes a one-liner. I can't come up with a good name to abstract its semantics -- its correct invocation requires quite specific calling context, so I think it's best to "inline" it to the caller. > Is there a reason why the added check couldn't be done at the beginning of the function? `MacroAssembler::set_narrow_klass` is an example that will fail the assert, if placed at the beginning of the method. The thing is that `CollectedHeap::is_in` need to take heap-resizing into account for input address that lie within heap-reserved space, which places some extra constraint for callers. OTOH, for outside-heap-reserved addresses, heap-resizing is orthogonal to the result, so calling constraint can be relaxed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3557516939 From ayang at openjdk.org Thu Nov 20 11:38:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 11:38:45 GMT Subject: RFR: 8372163: G1: Remove unused G1HeapRegion::remove_code_root In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:16:16 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: build Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28392#issuecomment-3557518118 From ayang at openjdk.org Thu Nov 20 11:38:47 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 11:38:47 GMT Subject: RFR: 8372150: Parallel: Tighten requirements around MinHeapSize with NUMA and Large Pages [v2] In-Reply-To: <5vDCL3V5Gq13ay3zN4ly0mO1wmjg5X-n4bCPqIGrF-Q=.d11c5e80-479e-48cc-960d-8a4c353b4036@github.com> References: <_nJ3sxtl4WL88gpE1VQgR-lSry1K_t60lqc8am2cWzU=.09c65da8-9cae-41c5-9eac-ee9172149b39@github.com> <5vDCL3V5Gq13ay3zN4ly0mO1wmjg5X-n4bCPqIGrF-Q=.d11c5e80-479e-48cc-960d-8a4c353b4036@github.com> Message-ID: <9PNwBZJdVB49jnPy6sA-4NXTpgNDiAE6EzKInIV9gEA=.93ffe2bf-0190-46cf-92fd-1005ab18ad85@github.com> On Wed, 19 Nov 2025 17:37:56 GMT, Joel Sikstr?m wrote: >> Hello, >> >> Today, Parallel decides to opt out of using Large pages if the heap size, either minimum, initial or maximum, does not cover enough Large pages for all spaces. Additionally, if we don't get enough heap size for at least one OS page per MutableNUMASpace (one per NUMA-node), Parallel decides to run in a NUMA-degraded mode, where it skips allocating memory locally for some NUMA-nodes. Both of these issues are problematic if we want to start the JVM with a default initial heap size that is equal to the minimum heap size (see JDK-8371986). To solve this, we should consider making sure that the minimum heap size is always enough to cover precisely one page per space, where the page size may be Large or not. By making sure the minimum heap size covers this, we never have to disable Large pages or run in a NUMA-degraded mode based on the settings of minimum, initial or maximum heap sizes. >> >> For completeness, when user-provided settings for UseNUMA, UseLargePages and heap sizes can't be satisfied at the same time, one must be prioritised over others. Today, we prioritise heap size settings over both UseNUMA and UseLargePages. This change suggest shifting the priority to UseNUMA and UseLargePages, by bumping MinHeapSize, InitialHeapSize and MaxHeapSize to an adequate number, if not already enough. By bumping the minimum heap size to an adequate number, we are also bumping the lower-limit for the Initial heap size and maximum heap size, which must be equal to or greater than the minimum heap size. >> >>
>> >> Min and Initial heap sizes before/after (expandable section) >> >> Before changes. We always get Min&Initial 2MB that we request: >> >> java -XX:+UseParallelGC -Xms2M -Xmx1G >> Alignments: Space 512K, Heap 2M >> Heap Min Capacity: 2M >> Heap Initial Capacity: 2M >> >> java -XX:+UseParallelGC -XX:+UseLargePages -Xms2M -Xmx1G >> MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap >> Alignments: Space 512K, Heap 2M >> Heap Min Capacity: 2M >> Heap Initial Capacity: 2M >> >> java -XX:+UseParallelGC -XX:+UseNUMA -Xms2M -Xmx1G >> Alignments: Space 512K, Heap 2M >> Heap Min Capacity: 2M >> Heap Initial Capacity: 2M >> >> java -XX:+UseParallelGC -XX:+UseLargePages -XX:+UseNUMA -Xms2M -Xmx1G >> MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap >> Alignments: Space 512K, Heap 2M >> Heap Min Capacity: 2M >> Heap Initial Capacity: 2M >> >> >> After changes... > > Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision: > > Albert review feedback Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28394#pullrequestreview-3487336157 From ayang at openjdk.org Thu Nov 20 11:41:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 11:41:17 GMT Subject: RFR: 8371998: G1: Rename G1MergeHeapRootsTask::G1ClearBitmapClosure to be more distinct In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 11:15:55 GMT, Thomas Schatzl wrote: > Hi all, > > please review the renaming of `G1MergeHeapRootsTask::G1ClearBitmapClosure` to something more distinct and appropriate to its function. > > This also helps distinguishing it to the G1ClearBitmapHRClosure from concurrent marking that just does that. > > Testing: compilation, gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28424#pullrequestreview-3487350991 From ayang at openjdk.org Thu Nov 20 11:44:02 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 11:44:02 GMT Subject: Integrated: 8372163: G1: Remove unused G1HeapRegion::remove_code_root In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:16:16 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: build This pull request has now been integrated. Changeset: c419dda4 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/c419dda4e99c3b72fbee95b93159db2e23b994b6 Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod 8372163: G1: Remove unused G1HeapRegion::remove_code_root Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28392 From iwalulya at openjdk.org Thu Nov 20 11:56:01 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 20 Nov 2025 11:56:01 GMT Subject: RFR: 8371998: G1: Rename G1MergeHeapRootsTask::G1ClearBitmapClosure to be more distinct In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 11:15:55 GMT, Thomas Schatzl wrote: > Hi all, > > please review the renaming of `G1MergeHeapRootsTask::G1ClearBitmapClosure` to something more distinct and appropriate to its function. > > This also helps distinguishing it to the G1ClearBitmapHRClosure from concurrent marking that just does that. > > Testing: compilation, gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28424#pullrequestreview-3487419631 From ayang at openjdk.org Thu Nov 20 13:06:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 20 Nov 2025 13:06:04 GMT Subject: RFR: 8372269: Parallel: Remove unused ParallelScavengeHeap::base Message-ID: Trivial removing dead code. Test: tier1 ------------- Commit messages: - pgc-trivial-remove Changes: https://git.openjdk.org/jdk/pull/28427/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28427&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372269 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28427.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28427/head:pull/28427 PR: https://git.openjdk.org/jdk/pull/28427 From aboldtch at openjdk.org Thu Nov 20 13:16:35 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 13:16:35 GMT Subject: RFR: 8372244: ZGC: Split ZTest into a VM and not VM test fixture [v2] In-Reply-To: References: Message-ID: > The `ZTest` GTest fixture is used for both VM and not VM tests, however the implementation requires VM. The not VM tests which use it are only interested in a sub-set of its features. > > I propose we split `ZTest` into a hierarchy of fixtures, one for not VM tests, and the other for VM tests. > > I could not find an easy way to identity which category of test a fixture is used in, so for now we just have to be diligent to use the appropriate fixture. > > We do have an assumption here that `os::next_random` is fine to call without having setup the VM. If this is changes in future we would have to add a not VM dependent prng function. > > Also the VMless fixture do not test if the OS is supported, as it might require VM features to work. But tests which run without VM should not be dependent if the VM is OS is supported. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'JDK-8372241' into JDK-8372244 - ZGC: Split ZTest into a VM and not VM test fixture ------------- Changes: https://git.openjdk.org/jdk/pull/28414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28414&range=01 Stats: 38 lines in 11 files changed: 16 ins; 9 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28414/head:pull/28414 PR: https://git.openjdk.org/jdk/pull/28414 From aboldtch at openjdk.org Thu Nov 20 13:28:09 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 13:28:09 GMT Subject: RFR: 8372269: Parallel: Remove unused ParallelScavengeHeap::base In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 12:56:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Trivial change. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28427#pullrequestreview-3487854893 From eosterlund at openjdk.org Thu Nov 20 13:40:01 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 20 Nov 2025 13:40:01 GMT Subject: RFR: 8371200: ZGC: C2 allocation deopt race [v2] In-Reply-To: References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> <2t7atbFpaHbBOH70fk-JDI1dU_xt1FNeesfOfe3Gf4M=.c2811325-b98c-49a3-8ebc-ff3722344a8d@github.com> Message-ID: On Thu, 20 Nov 2025 09:35:53 GMT, Axel Boldt-Christmas wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove assert > > Marked as reviewed by aboldtch (Reviewer). Thanks for the reviews @xmas92 and @stefank! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28176#issuecomment-3558102724 From kdnilsen at openjdk.org Thu Nov 20 14:20:14 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 20 Nov 2025 14:20:14 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v13] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: add debugging instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/6b62448d..ad283caf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=11-12 Stats: 64 lines in 1 file changed: 64 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From eosterlund at openjdk.org Thu Nov 20 14:37:31 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 20 Nov 2025 14:37:31 GMT Subject: Integrated: 8371200: ZGC: C2 allocation deopt race In-Reply-To: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> References: <4TaC7Nisa8OjB24VHHY-YTyA7rcKPP7YTAm2P7bzqSo=.f29df70b-5c4c-40e3-82ed-3a359f52ddd4@github.com> Message-ID: <7BGihdE5ulhMxLDGLpSY33gIwHPj57iTyHVrAShEbjI=.fcfa08df-cef6-4ff3-8c82-4303e3c93eee@github.com> On Thu, 6 Nov 2025 11:35:50 GMT, Erik ?sterlund wrote: > C2 compiled code enjoys initializing newly allocated objects with zeros and eliding write barriers. This is good for performance, but is only really allowed for objects in the young generation. Objects in the old generation need appropriate barriers and coloring null pointers when using ZGC - otherwise remembered set updates will be lost and the JVM will eventually crash. > > When the JIT calls into the runtime in the slow path of an allocation, we will allocate an object initially in the young generation. However, when transitioning from vm back to Java on the way back to the JIT compiled code, the GC can make unexpected progress, causing the just allocated object to age unexpectedly. > > ZGC currently has guards that try to detect objects that relocated to the old generation, as well as detecting flip promotions where a ZPage flips from young to old in the page table. This happens when pages are too dense to warrant relocation, or when the objects are too large to relocate. > > Such flip promotion happens between mark end and relocate start. ZGC has guards trying to detect that by looking if the current GC phase is between those points for the young generation, and if the page is a candidate for promotion. > > However, whether a page is a candidate for promotion is subject to the tenuring threshold, which is calculated in the same phase. Therefore, there exists a theoretical race that may occur if the guarding code observes a higher tenuring threshold and it then gets lowered, causing a racy flip promotion of a page. Racy flip promotion can cause promotion barriers that wash away uncolored null pointers to race with JIT-compiled code that puts raw nulls back into the object. This will cause reference locations to not have bad bits when the relocate start GC pause comes, which means that after relocation, store barriers will not trap to register the first mutation of a reference field in the old generation, causing remembered set entries to be lost. > > This patch proposes a more controlled race. We first flip age pages, then handshake, and then execute the promotion barriers that purge raw null pointers from objects being promoted. This way, the guarding code that detects unfortunately aged objects only needs to check if the object returned is old, and then deopt the frame to the interpreter which will run the required barriers and not cheat. > > If the guard check is performed before the handshake, then the JIT-compiled code will continue to execute past the code that as... This pull request has now been integrated. Changeset: b9ee9541 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/b9ee9541cffb6c5a737b08a69ae04472b3bcab3e Stats: 104 lines in 5 files changed: 52 ins; 44 del; 8 mod 8371200: ZGC: C2 allocation deopt race Reviewed-by: aboldtch, stefank ------------- PR: https://git.openjdk.org/jdk/pull/28176 From tschatzl at openjdk.org Thu Nov 20 15:51:18 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 15:51:18 GMT Subject: RFR: 8372149: G1: Remove unnecessary num_added_to_group from G1CollectionSetCandidates::set_candidates_from_marking() In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:51:15 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this tiny change to remove some local variable (and management) in G1. The one use of the getter from the container is just as easy to understand to me (vs. declaration and management). >> >> Testing: gha >> >> Thanks, >> Thomas > > Trivial! Thanks @walulyai @albertnetymk for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28419#issuecomment-3558755053 From tschatzl at openjdk.org Thu Nov 20 15:51:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 20 Nov 2025 15:51:19 GMT Subject: Integrated: 8372149: G1: Remove unnecessary num_added_to_group from G1CollectionSetCandidates::set_candidates_from_marking() In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:18:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this tiny change to remove some local variable (and management) in G1. The one use of the getter from the container is just as easy to understand to me (vs. declaration and management). > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 267ce917 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/267ce91766c0500485ac3d9d36dfef0c09505498 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8372149: G1: Remove unnecessary num_added_to_group from G1CollectionSetCandidates::set_candidates_from_marking() Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/28419 From fandreuzzi at openjdk.org Thu Nov 20 16:12:29 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 20 Nov 2025 16:12:29 GMT Subject: RFR: 8372269: Parallel: Remove unused ParallelScavengeHeap::base In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 12:56:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/28427#pullrequestreview-3488677720 From kdnilsen at openjdk.org Thu Nov 20 18:04:27 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 20 Nov 2025 18:04:27 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v14] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Do not compute_old_generation_balance when preparing to evacuate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/ad283caf..662ae423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=12-13 Stats: 22 lines in 3 files changed: 12 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Thu Nov 20 18:23:47 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 20 Nov 2025 18:23:47 GMT Subject: RFR: 8357471: GenShen: Share collector reserves between young and old [v15] In-Reply-To: References: Message-ID: > Genshen independently reserves memory to hold evacuations into young and old generations. We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young). > > This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle. In this case, we can share the young collector reserves with the old generation. This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity. > > The following spreadsheet snapshots highlight the benefits of this change. In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time). This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young. This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC. In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive. The total number of GC cycles decreases significantly. > > ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a) > > With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles. By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles. This reduces CPU load. The impact on response times is not as significant as with the 6G heap size. We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100. > > ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f) > > At 8G heap size, the GC is not at all stressed. We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100. > > ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c) > > The command line for these comparisons follows: > > > ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \ > -XX:+Unlock... Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: remove debug instrumentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25357/files - new: https://git.openjdk.org/jdk/pull/25357/files/662ae423..9845def3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=13-14 Stats: 77 lines in 2 files changed: 0 ins; 77 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25357/head:pull/25357 PR: https://git.openjdk.org/jdk/pull/25357 From kdnilsen at openjdk.org Thu Nov 20 18:44:52 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 20 Nov 2025 18:44:52 GMT Subject: Integrated: 8372110: GenShen: Fix erroneous assert In-Reply-To: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> References: <0Ion_LAp84g6QSHt5RvGicunOUwsjkg5QK0XhTUhUqM=.e3e9806e-d8fb-4651-b728-e2d77d06b977@github.com> Message-ID: <0Ie0a7kwSRcyxiSD0yc_W_eNvLE3wcl5Fhrwy0dABPo=.d8cc8aea-d82c-426c-9b69-220f1493af8f@github.com> On Tue, 18 Nov 2025 15:40:35 GMT, Kelvin Nilsen wrote: > Code recently integrated (https://github.com/openjdk/jdk/pull/27353) had an erroneous (meaningless) assert. Closer examination of intended behavior revealed that the fix involves replacing the assert with a new run-time check, as implemented here. This pull request has now been integrated. Changeset: aa7718d1 Author: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/aa7718d1d2008c240c197383c493955d8b654bf3 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod 8372110: GenShen: Fix erroneous assert Reviewed-by: ysr ------------- PR: https://git.openjdk.org/jdk/pull/28375 From dholmes at openjdk.org Thu Nov 20 22:10:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Nov 2025 22:10:18 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v11] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Thu, 30 Oct 2025 12:06:00 GMT, Afshin Zafari wrote: >> The issue happens when the HeapMinBaseAddress option gets 0 as input value. Since this option is used as an address, then using 0 in pointer arithmetics is UB. >> The fix is using `unitptr_t` instead of `address`/`char*`, etc. In doing that, it is found that an overflow check does not work in all cases due to checking more conditions. That overflow check is changed too. We also need to check overflow after aligning addresses and sizes of memory regions in this context. Assertions are added to check these cases. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fix arguments.cpp for HeapMinBaseAddress type. Okay nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3490162115 From kbarrett at openjdk.org Thu Nov 20 23:12:29 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 20 Nov 2025 23:12:29 GMT Subject: RFR: 8371965: Convert TaskQueueSuper to use Atomic In-Reply-To: References: Message-ID: <3pWeXYwH4YLjelhe6rEl0e2G2IhGaDLWeMtSxzvGuyo=.abcd4d90-4bb9-419b-aa3a-3078d80a04a2@github.com> On Tue, 18 Nov 2025 11:36:18 GMT, Ivan Walulya wrote: >> Please review this change to TaskQueueSuper to use Atomic rather than >> directly applying AtomicAccess to (sometimes!) volatile members. There was >> some sketchy stuff around TaskQueueSuper::Age. This has been cleaned up by >> hoisting that class to namespace scope (now called TaskQueueAge) and declaring >> a PrimitiveConversion::Translate for it. >> >> Testing: mach5 tier1-5 > > Looks good! Thanks for reviews @walulyai and @tschatzl ------------- PR Comment: https://git.openjdk.org/jdk/pull/28347#issuecomment-3560529041 From kbarrett at openjdk.org Thu Nov 20 23:12:31 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 20 Nov 2025 23:12:31 GMT Subject: Integrated: 8371965: Convert TaskQueueSuper to use Atomic In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 10:22:13 GMT, Kim Barrett wrote: > Please review this change to TaskQueueSuper to use Atomic rather than > directly applying AtomicAccess to (sometimes!) volatile members. There was > some sketchy stuff around TaskQueueSuper::Age. This has been cleaned up by > hoisting that class to namespace scope (now called TaskQueueAge) and declaring > a PrimitiveConversion::Translate for it. > > Testing: mach5 tier1-5 This pull request has now been integrated. Changeset: 45246bc7 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/45246bc72daf68b905d7342f478e53bfe2883796 Stats: 87 lines in 1 file changed: 44 ins; 25 del; 18 mod 8371965: Convert TaskQueueSuper to use Atomic Reviewed-by: iwalulya, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28347 From kdnilsen at openjdk.org Fri Nov 21 01:07:09 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 21 Nov 2025 01:07:09 GMT Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during rebuild [v3] In-Reply-To: References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com> Message-ID: On Sat, 15 Nov 2025 00:19:11 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Merge remote-tracking branch 'jdk/master' into synchronize-available-with-rebuild >> - update comment >> - Add documentation for _rebuild_lock >> - Hide rebuild_lock inside prepare_to_rebuild and finish_rebuild >> - Rename rebuild_lock() >> - Tighten up context for holding rebuild_lock >> - Remove ShenandoahFreeSet::FreeSetUnderConstruction sentinel value >> - Revert "revert introduction of RebuildLock" >> >> This reverts commit bec73da1dc169d391e9919203e5a406ea02a699c. >> - Revert "available() returns previous value if called during freeset rebuild" >> >> This reverts commit 1a5e483a4abb04b6045175e8bd4b0c11fa68cb73. >> - Revert "remove obsolete assertion" >> >> This reverts commit 717e7da17f03f1e52008d154fafcbbfc5f2bb20e. >> - ... and 7 more: https://git.openjdk.org/jdk/compare/bfc048ab...8462a290 > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 790: > >> 788: inline size_t available() { >> 789: shenandoah_assert_not_heaplocked(); >> 790: ShenandoahRebuildLocker locker(rebuild_lock()); > > May be motivate in a brief comment why we need the rebuild lock in this API, but not around the other APIs such as capacity() and used()? Good point. I'll address this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2548193913 From stefank at openjdk.org Fri Nov 21 08:19:03 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 21 Nov 2025 08:19:03 GMT Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed: assert(left >= right) failed: avoid underflow In-Reply-To: References: <6l6zbFw04NoELlc-_nTeRFGeGUVBCpT1RRyKfeA8H_s=.3f047a15-86f1-48ab-b22b-dc01223b3c21@github.com> Message-ID: On Thu, 20 Nov 2025 11:34:26 GMT, Albert Mingkun Yang wrote: > > Could this the addition be added to a function (or macro) so that the check becomes a one-liner. > > I can't come up with a good name to abstract its semantics -- its correct invocation requires quite specific calling context, so I think it's best to "inline" it to the caller. That doesn't instill confidence. I think we might have to figure out what semantics we want the check to have. Maybe it can be fixed by the suggestion below: > > > Is there a reason why the added check couldn't be done at the beginning of the function? > > `MacroAssembler::set_narrow_klass` is an example that will fail the assert, if placed at the beginning of the method. > > The thing is that `CollectedHeap::is_in` need to take heap-resizing into account for input address that lie within heap-reserved space, which places some extra constraint for callers. OTOH, for outside-heap-reserved addresses, heap-resizing is orthogonal to the result, so calling constraint can be relaxed. This also means that this calling code can only use the negative version of that check: assert(! Universe::heap()->is_in(k), "should not be an oop"); A check like: assert(Universe::heap()->is_in(obj), "should be an oop"); would trigger the introduced assert that we are calling this from `native`. I suggest that we remove this assert. It was needed when we had PermGen, but now we have other safeguards. Just a few lines below we have `CompressedKlassPointers::encode(k);`, which I think performs enough sanity check on the provided `Klass*` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3561912427 From stefank at openjdk.org Fri Nov 21 08:23:55 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 21 Nov 2025 08:23:55 GMT Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown [v4] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 07:21:51 GMT, Stefan Karlsson wrote: >> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. >> >> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. >> >> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). >> >> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). >> >> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. >> >> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: >> >> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. >> >> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. >> >> There are some G1 specific details to look at: >> >> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. >> >> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. >> >> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d... > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Thank you all for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28349#issuecomment-3561928695 From stefank at openjdk.org Fri Nov 21 08:23:56 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 21 Nov 2025 08:23:56 GMT Subject: Integrated: 8371990: Remove two second delayed OOME after GC shutdown In-Reply-To: References: Message-ID: <1rrKNoaXmN5a5LLfhpZS8ioPMoCXZJzcxSPLqZ8gTIo=.1e2e8f3f-2103-4b90-8771-530ad63e5bb5@github.com> On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson wrote: > In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread. > > One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process. > > The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902). > > So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865). > > The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation. > > Depending on the type of thread that is trying to schedule the GC operation we do one out of two things: > > 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads. > > 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion. > > There are some G1 specific details to look at: > > 1) I've reverted the G1 `concurrent_mark_is_terminating` checks. > > 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released. > > 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert? > > This has been ... This pull request has now been integrated. Changeset: 5922c3cb Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/5922c3cbac43795275422f2484082d1e725e4bcc Stats: 144 lines in 14 files changed: 46 ins; 66 del; 32 mod 8371990: Remove two second delayed OOME after GC shutdown Reviewed-by: kbarrett, tschatzl, ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28349 From kbarrett at openjdk.org Fri Nov 21 09:16:14 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 21 Nov 2025 09:16:14 GMT Subject: RFR: 8372240: Convert FreeListAllocator to use Atomic Message-ID: Please review this change to FreeListAllocator to use Atomic rather than directly applying AtomicAccess to volatile members. Testing: mach5 tier1-5 ------------- Commit messages: - FreeListAllocator uses Atomic Changes: https://git.openjdk.org/jdk/pull/28447/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28447&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372240 Stats: 31 lines in 2 files changed: 0 ins; 0 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/28447.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28447/head:pull/28447 PR: https://git.openjdk.org/jdk/pull/28447 From tschatzl at openjdk.org Fri Nov 21 09:24:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 21 Nov 2025 09:24:48 GMT Subject: RFR: 8372269: Parallel: Remove unused ParallelScavengeHeap::base In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 12:56:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28427#pullrequestreview-3491855081 From tschatzl at openjdk.org Fri Nov 21 09:25:21 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 21 Nov 2025 09:25:21 GMT Subject: RFR: 8371895: Lower GCTimeLimit in TestUseGCOverheadLimit.java In-Reply-To: References: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Message-ID: On Fri, 14 Nov 2025 13:40:13 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. >> >> Testing: gha, reporter >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Having seen no further objections from the reporter, pushing. Thanks @albertnetymk @shipilev @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/28321#issuecomment-3562130859 From tschatzl at openjdk.org Fri Nov 21 09:29:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 21 Nov 2025 09:29:12 GMT Subject: Integrated: 8371895: Lower GCTimeLimit in TestUseGCOverheadLimit.java In-Reply-To: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> References: <_nShBKUpnwsY6oGTKRjwUM4FK9xnq-EBTmaHeJSqh3I=.a37565ae-8ef9-4ecb-b3d7-6ca54ce85aae@github.com> Message-ID: On Fri, 14 Nov 2025 11:59:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix to the `TestUseGCOverheadLimit` test to ease the CPU overhead requirement a bit further since it seems too high for some particularly loaded machines. > > Testing: gha, reporter > > Thanks, > Thomas This pull request has now been integrated. Changeset: eeb7c3f2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/eeb7c3f2e8e645938d9db0cf61c1d98d751f2845 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8371895: Lower GCTimeLimit in TestUseGCOverheadLimit.java Reviewed-by: ayang, iwalulya, shade ------------- PR: https://git.openjdk.org/jdk/pull/28321 From tschatzl at openjdk.org Fri Nov 21 09:33:20 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 21 Nov 2025 09:33:20 GMT Subject: RFR: 8372240: Convert FreeListAllocator to use Atomic In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 09:09:03 GMT, Kim Barrett wrote: > Please review this change to FreeListAllocator to use Atomic rather than > directly applying AtomicAccess to volatile members. > > Testing: mach5 tier1-5 Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28447#pullrequestreview-3491888129 From stefank at openjdk.org Fri Nov 21 09:42:56 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 21 Nov 2025 09:42:56 GMT Subject: RFR: 8372240: Convert FreeListAllocator to use Atomic In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 09:09:03 GMT, Kim Barrett wrote: > Please review this change to FreeListAllocator to use Atomic rather than > directly applying AtomicAccess to volatile members. > > Testing: mach5 tier1-5 Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28447#pullrequestreview-3491925245 From jsikstro at openjdk.org Fri Nov 21 09:58:59 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 21 Nov 2025 09:58:59 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v3] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 21:01:54 GMT, Kim Barrett 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 three additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8371783_refactor_vm_collectformetadataallocation >> - Move heap variable down a bit >> - 8371783: Refactor GCCause in VM_CollectForMetadataAllocation > > Still good. Thank you for the reviews @kimbarrett @albertnetymk ------------- PR Comment: https://git.openjdk.org/jdk/pull/28287#issuecomment-3562249237 From jsikstro at openjdk.org Fri Nov 21 09:58:59 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 21 Nov 2025 09:58:59 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v3] In-Reply-To: References: Message-ID: > Hello, > > We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. > > When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. > > The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. > > Testing: > * Oracle's tier1-3 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8371783_refactor_vm_collectformetadataallocation - Move heap variable down a bit - 8371783: Refactor GCCause in VM_CollectForMetadataAllocation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28287/files - new: https://git.openjdk.org/jdk/pull/28287/files/4355bd66..02e4e3fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28287&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28287&range=01-02 Stats: 61493 lines in 856 files changed: 41694 ins; 14059 del; 5740 mod Patch: https://git.openjdk.org/jdk/pull/28287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28287/head:pull/28287 PR: https://git.openjdk.org/jdk/pull/28287 From ayang at openjdk.org Fri Nov 21 10:05:48 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 10:05:48 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v3] In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 09:58:59 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. >> >> When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. >> >> The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. >> >> Testing: >> * Oracle's tier1-3 > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8371783_refactor_vm_collectformetadataallocation > - Move heap variable down a bit > - 8371783: Refactor GCCause in VM_CollectForMetadataAllocation Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28287#pullrequestreview-3492012094 From jsikstro at openjdk.org Fri Nov 21 13:47:30 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 21 Nov 2025 13:47:30 GMT Subject: RFR: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation [v3] In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 09:58:59 GMT, Joel Sikstr?m wrote: >> Hello, >> >> We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. >> >> When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. >> >> The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. >> >> Testing: >> * Oracle's tier1-3 > > 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 three additional commits since the last revision: > > - Merge branch 'master' into JDK-8371783_refactor_vm_collectformetadataallocation > - Move heap variable down a bit > - 8371783: Refactor GCCause in VM_CollectForMetadataAllocation Seems like Skara lost the issue... Let's try this again. Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28287#issuecomment-3563082294 PR Comment: https://git.openjdk.org/jdk/pull/28287#issuecomment-3563087513 From jsikstro at openjdk.org Fri Nov 21 13:49:52 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 21 Nov 2025 13:49:52 GMT Subject: Integrated: 8371783: Refactor GCCause in VM_CollectForMetadataAllocation In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 10:08:36 GMT, Joel Sikstr?m wrote: > Hello, > > We should improve how we use and set GCCause in VM_CollectForMetadataAllocation to make it more clear when reading the code what is going on. > > When constructing a VM_CollectForMetadataAllocation operation, we pass in a GCCause, which is not always the cause that is used, since we might also have to clear soft references as a last resort if earlier collection attemps is not enough to free up memory. > > The GCCauseSetter at the start of this operation is also redundant as subsequent calls to initiate a GC set the cause themselves. > > Testing: > * Oracle's tier1-3 This pull request has now been integrated. Changeset: d01e7d98 Author: Joel Sikstr?m URL: https://git.openjdk.org/jdk/commit/d01e7d9850a57dd8e4849e2b7db6eacb37605647 Stats: 15 lines in 3 files changed: 5 ins; 3 del; 7 mod 8371783: Refactor GCCause in VM_CollectForMetadataAllocation Reviewed-by: kbarrett, ayang ------------- PR: https://git.openjdk.org/jdk/pull/28287 From ayang at openjdk.org Fri Nov 21 13:55:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 13:55:09 GMT Subject: RFR: 8372162: G1: Merge subclasses of G1IHOPControl into parent class In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:12:39 GMT, Albert Mingkun Yang wrote: > Merging two subclasses into the parent class to simplify type hierarchy. The internal `bool` flag doesn't introduce much complexity; instead, improves readability, IMO. > > Perf neutral on linux-x64/aarch64: cachestree, dacapo, dacapo23, specjbb2005, specjbb2015, specjvm2008. > > Test: tier1-5 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28391#issuecomment-3563112941 From ayang at openjdk.org Fri Nov 21 13:55:10 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 13:55:10 GMT Subject: Integrated: 8372162: G1: Merge subclasses of G1IHOPControl into parent class In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:12:39 GMT, Albert Mingkun Yang wrote: > Merging two subclasses into the parent class to simplify type hierarchy. The internal `bool` flag doesn't introduce much complexity; instead, improves readability, IMO. > > Perf neutral on linux-x64/aarch64: cachestree, dacapo, dacapo23, specjbb2005, specjbb2015, specjvm2008. > > Test: tier1-5 This pull request has now been integrated. Changeset: 018284d0 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/018284d08cd5b4c2c1a5735b5d11e63dc769fb37 Stats: 321 lines in 5 files changed: 91 ins; 154 del; 76 mod 8372162: G1: Merge subclasses of G1IHOPControl into parent class Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/28391 From ayang at openjdk.org Fri Nov 21 13:57:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 13:57:22 GMT Subject: RFR: 8372269: Parallel: Remove unused ParallelScavengeHeap::base In-Reply-To: References: Message-ID: <1u4b8B7zylfU6jaDrM0j87RCLgrw7hkqTDDJZ8-_28I=.fb813098-11db-467a-a9a2-d40f08ca9b02@github.com> On Thu, 20 Nov 2025 12:56:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28427#issuecomment-3563113080 From ayang at openjdk.org Fri Nov 21 13:57:23 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 13:57:23 GMT Subject: Integrated: 8372269: Parallel: Remove unused ParallelScavengeHeap::base In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 12:56:39 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. > > Test: tier1 This pull request has now been integrated. Changeset: 41e0017b Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/41e0017bdbd8c818a57509a914ae77c2a903a01c Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8372269: Parallel: Remove unused ParallelScavengeHeap::base Reviewed-by: aboldtch, fandreuzzi, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/28427 From ayang at openjdk.org Fri Nov 21 14:07:20 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 14:07:20 GMT Subject: RFR: 8370198: Test gc/arguments/TestShrinkHeapInSteps.java crashed: assert(left >= right) failed: avoid underflow In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 15:39:27 GMT, Albert Mingkun Yang wrote: > Add an early-return for outside-heap address in `CollectedHeap::is_in` API. > > While investigating this failure (JDK-8370198), I realized that some java-threads (compiler-threads) in `native` state can invoke `CollectedHeap` APIs. Since heap-resizing occurs inside safepoint but java-threads in `native` state just ignore safepoint, I have added some assert to catch such dangerous uses, where the return value might not be stable. > > Test: tie1-5; can't reproduce the JDK-8370198 with or without this patch for >8000 runs. There are three related but distinct parts in this problem/solution: 1. **Asserting that an address is outside the heap-reserved space when the caller is in native state.** For example, the assertion in `MacroAssembler::set_narrow_klass`. 2. **Adding an early return to `is_in` for addresses outside the heap-reserved space.** This is always correct and almost trivial. 3. **Adding an assertion inside `is_in` to catch potentially racy or unsafe uses of this API for addresses that fall inside the heap-reserved range.** --- ## Analysis To resolve the specific crash observed once in JDK-8370198, removing the unnecessary assertion in `set_narrow_klass` is sufficient. However, because the reproduction rate is extremely low, I suspect there may be other call sites with similar usage patterns -- that is, calling `is_in` with addresses outside the heap-reserved range. For this reason, part (2) is beneficial. Additionally, there may be other problematic uses of this API that became unsafe after the recent heap/young-generation resizing support. Part (3) aims to uncover such issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28393#issuecomment-3563162859 From ayang at openjdk.org Fri Nov 21 14:23:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 14:23:15 GMT Subject: RFR: 8372285: G1: Micro-optimize x86 barrier code [v3] In-Reply-To: References: Message-ID: <6GM7vtD34m6llQY1qgeXuLxEonBmLaQWIBJYRgu-dzk=.bcf2a835-1dab-4108-8d74-1779b947990e@github.com> On Fri, 21 Nov 2025 10:07:35 GMT, Aleksey Shipilev wrote: >> We know from [JDK-8372284](https://bugs.openjdk.org/browse/JDK-8372284) that G1 C2 stubs can take ~10% of total instructions. So minor optimizations in hand-written assembly pay off for code density. This PR does a little x86-specific polishing: `testptr` where possible, short forward branches where possible. I rewired some code to make it abundantly clear the branches in question are short. It also makes clear that lots of the affected methods are essentially fall-through. >> >> The patch is deliberately on simpler side, so we can backport it to 25u, if need arises. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `tier1` >> - [ ] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Make some backward branches explicitly short Marked as reviewed by ayang (Reviewer). src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 208: > 206: > 207: // Jump out if done, or fall-through to runtime. > 208: // "Done" is far away, so jump cannot be short. I believe "Done" refers to `L_done`, so I wonder if we use that directly. ------------- PR Review: https://git.openjdk.org/jdk/pull/28446#pullrequestreview-3492959775 PR Review Comment: https://git.openjdk.org/jdk/pull/28446#discussion_r2549912395 From shade at openjdk.org Fri Nov 21 16:09:20 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 21 Nov 2025 16:09:20 GMT Subject: RFR: 8372285: G1: Micro-optimize x86 barrier code [v3] In-Reply-To: <6GM7vtD34m6llQY1qgeXuLxEonBmLaQWIBJYRgu-dzk=.bcf2a835-1dab-4108-8d74-1779b947990e@github.com> References: <6GM7vtD34m6llQY1qgeXuLxEonBmLaQWIBJYRgu-dzk=.bcf2a835-1dab-4108-8d74-1779b947990e@github.com> Message-ID: On Fri, 21 Nov 2025 14:20:06 GMT, Albert Mingkun Yang wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Make some backward branches explicitly short > > src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 208: > >> 206: >> 207: // Jump out if done, or fall-through to runtime. >> 208: // "Done" is far away, so jump cannot be short. > > I believe "Done" refers to `L_done`, so I wonder if we use that directly. Yes, is it about `L_done`. Fixed the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28446#discussion_r2550250301 From shade at openjdk.org Fri Nov 21 16:09:17 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 21 Nov 2025 16:09:17 GMT Subject: RFR: 8372285: G1: Micro-optimize x86 barrier code [v4] In-Reply-To: References: Message-ID: > We know from [JDK-8372284](https://bugs.openjdk.org/browse/JDK-8372284) that G1 C2 stubs can take ~10% of total instructions. So minor optimizations in hand-written assembly pay off for code density. This PR does a little x86-specific polishing: `testptr` where possible, short forward branches where possible. I rewired some code to make it abundantly clear the branches in question are short. It also makes clear that lots of the affected methods are essentially fall-through. > > The patch is deliberately on simpler side, so we can backport it to 25u, if need arises. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `tier1` > - [ ] Linux x86_64 server fastdebug, `all` Aleksey Shipilev 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: - Adjust label name - Merge branch 'master' into JDK-8372285-g1-barrier-micro - Make some backward branches explicitly short - Comment - Shorten a few more branches - Also reflow generate_pre_barrier_slow_path, so it is obvious the branches are short - More touchups - Also optimize queue insertion - Touchups - WIP ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28446/files - new: https://git.openjdk.org/jdk/pull/28446/files/1f57d0d9..c23bac46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28446&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28446&range=02-03 Stats: 1409 lines in 83 files changed: 622 ins; 421 del; 366 mod Patch: https://git.openjdk.org/jdk/pull/28446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28446/head:pull/28446 PR: https://git.openjdk.org/jdk/pull/28446 From xpeng at openjdk.org Fri Nov 21 17:33:45 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 21 Nov 2025 17:33:45 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v15] In-Reply-To: References: Message-ID: > Current alloc request type enum: > > enum Type { > _alloc_shared, // Allocate common, outside of TLAB > _alloc_shared_gc, // Allocate common, outside of GCLAB/PLAB > _alloc_cds, // Allocate for CDS > _alloc_tlab, // Allocate TLAB > _alloc_gclab, // Allocate GCLAB > _alloc_plab, // Allocate PLAB > _ALLOC_LIMIT > }; > > With current design, we have to use switch statement in multiple places resulting in unnecessary branches, for instance the function is_mutator_alloc: > > > inline bool is_mutator_alloc() const { > switch (_alloc_type) { > case _alloc_tlab: > case _alloc_shared: > case _alloc_cds: > return true; > case _alloc_gclab: > case _alloc_plab: > case _alloc_shared_gc: > return false; > default: > ShouldNotReachHere(); > return false; > } > } > > > > In PR, I have re-designed the enum to make the function like is_mutator_alloc much simpler by making the values of the enum follow two simple rules: > 1. Smaller value for mutator alloc, larger value for gc alloc; GC alloc types are always greater than any of mutator alloc types. > 2. Odd for lab, even number for non-lab > > Three functions have been simplified to one-line impl w/o branches in machine code: > > > inline bool is_mutator_alloc() const { > return _alloc_type <= _alloc_shared; > } > > inline bool is_gc_alloc() const { > return _alloc_type >= _alloc_shared_gc; > } > > inline bool is_lab_alloc() const { > return (_alloc_type & 1) == 1; > } > > > I didn't check compiled assemble code of hotspot, in instead, I wrote similar/equivalent code and compile with gcc for comparison using godbolt.org: > > bool is_lab_alloc(int alloc_type) { > return (alloc_type & 1) == 1; > } > > bool is_lab_alloc_switch(int alloc_type) { > switch (alloc_type) { > case 0: > case 2: > case 4: > return false; > case 1: > case 3: > case 5: > return true; > default: > throw "Should not reach here"; > > } > } > > x86_64 assembly code (https://godbolt.org/z/h7xfz8PaT): > > is_lab_alloc(int): > push rbp > mov rbp, rsp > mov DWORD PTR [rbp-4], edi > mov eax, DWORD PTR [rbp-4] > and eax, 1 > and eax, 1 > pop rbp > ret > .LC0: > .string "Should not reach here" > is_lab_alloc_switch(int): > push rbp > mov rbp, rsp > sub rsp, 16 > mov DWORD PTR [rbp-4], edi > cmp DWORD PTR [rbp-4], 5 > je .L... Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: Revert inline for affiliation_name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28247/files - new: https://git.openjdk.org/jdk/pull/28247/files/674753bb..93943a02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28247&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28247/head:pull/28247 PR: https://git.openjdk.org/jdk/pull/28247 From xpeng at openjdk.org Fri Nov 21 17:37:09 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 21 Nov 2025 17:37:09 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v14] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:47:30 GMT, Aleksey Shipilev wrote: > Note the test failures in GHA. Thanks, I looked into the GHA test, it is strange that I only updated some methods and added the missing inline keywords, it has to be related to one of the methods, more likely the `affiliation_name()`, I'll figure it out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3564008248 From ayang at openjdk.org Fri Nov 21 18:08:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 21 Nov 2025 18:08:01 GMT Subject: RFR: 8372285: G1: Micro-optimize x86 barrier code [v4] In-Reply-To: References: Message-ID: <5Kq7vQWy6cVryk4TSboKZYFuf8vSZxBFk0sltlmUNvk=.abff54bb-3a68-4775-b369-50d260418faf@github.com> On Fri, 21 Nov 2025 16:09:17 GMT, Aleksey Shipilev wrote: >> We know from [JDK-8372284](https://bugs.openjdk.org/browse/JDK-8372284) that G1 C2 stubs can take ~10% of total instructions. So minor optimizations in hand-written assembly pay off for code density. This PR does a little x86-specific polishing: `testptr` where possible, short forward branches where possible. I rewired some code to make it abundantly clear the branches in question are short. It also makes clear that lots of the affected methods are essentially fall-through. >> >> The patch is deliberately on simpler side, so we can backport it to 25u, if need arises. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `tier1` >> - [ ] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev 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: > > - Adjust label name > - Merge branch 'master' into JDK-8372285-g1-barrier-micro > - Make some backward branches explicitly short > - Comment > - Shorten a few more branches > - Also reflow generate_pre_barrier_slow_path, so it is obvious the branches are short > - More touchups > - Also optimize queue insertion > - Touchups > - WIP Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28446#pullrequestreview-3493844075 From kvn at openjdk.org Fri Nov 21 18:33:00 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 21 Nov 2025 18:33:00 GMT Subject: RFR: 8372285: G1: Micro-optimize x86 barrier code [v4] In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 16:09:17 GMT, Aleksey Shipilev wrote: >> We know from [JDK-8372284](https://bugs.openjdk.org/browse/JDK-8372284) that G1 C2 stubs can take ~10% of total instructions. So minor optimizations in hand-written assembly pay off for code density. This PR does a little x86-specific polishing: `testptr` where possible, short forward branches where possible. I rewired some code to make it abundantly clear the branches in question are short. It also makes clear that lots of the affected methods are essentially fall-through. >> >> The patch is deliberately on simpler side, so we can backport it to 25u, if need arises. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `tier1` >> - [ ] Linux x86_64 server fastdebug, `all` > > Aleksey Shipilev 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: > > - Adjust label name > - Merge branch 'master' into JDK-8372285-g1-barrier-micro > - Make some backward branches explicitly short > - Comment > - Shorten a few more branches > - Also reflow generate_pre_barrier_slow_path, so it is obvious the branches are short > - More touchups > - Also optimize queue insertion > - Touchups > - WIP Comments. src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 92: > 90: void G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler* masm, DecoratorSet decorators, > 91: Register addr, Register count, Register tmp) { > 92: Label done; Since you are touching this code can you add `L_` to labels in this code? This is our usual practice for labels to clear see them. src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 193: > 191: // Is the previous value null? > 192: __ testptr(pre_val, pre_val); > 193: __ jccb(Assembler::equal, L_null); I know that this short jump will be fused to one instruction with testptr on modern x86. But you will have jump-to-jump sequence. So you may win size wise but "throughput" could be worser. Especially if it is "fast" path. Can you check performance of these changes vs using `jcc(Assembler::equal, L_done);` here. src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 282: > 280: Register thread = r15_thread; > 281: > 282: Label done; Please use `L_done`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28446#pullrequestreview-3493923593 PR Review Comment: https://git.openjdk.org/jdk/pull/28446#discussion_r2550629465 PR Review Comment: https://git.openjdk.org/jdk/pull/28446#discussion_r2550627841 PR Review Comment: https://git.openjdk.org/jdk/pull/28446#discussion_r2550630291 From xpeng at openjdk.org Fri Nov 21 21:20:27 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 21 Nov 2025 21:20:27 GMT Subject: RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code [v14] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 15:47:30 GMT, Aleksey Shipilev wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Note the test failures in GHA. @shipilev @kdnilsen Now it works, the inline added to `affiliation_name()` caused some GHA failure on Windows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3564612071