From wkemper at openjdk.org  Thu May  1 14:25:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 May 2025 14:25:25 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <Ul7i1vO3CPPzwwuHXz9FoYSNhyAetGhzAkkXFw6_7SE=.598629ab-6829-4204-bc93-a54e42a93789@github.com>

Merges tag jdk-21.0.8+1

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

Commit messages:
 - 8318700: MacOS Zero cannot run gtests due to wrong JVM path
 - 8319690: [AArch64] C2 compilation hits offset_ok_for_immed: assert "c2 compiler bug"
 - 8314236: Overflow in Collections.rotate
 - 8320687: sun.jvmstat.monitor.MonitoredHost.getMonitoredHost() throws unexpected exceptions when invoked concurrently
 - 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint
 - 8352706: httpclient HeadTest does not run on HTTP2
 - 8330598: java/net/httpclient/Http1ChunkedTest.java fails with java.util.MissingFormatArgumentException: Format specifier '%s'
 - 8343891: Test javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
 - 8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual
 - 8350224: Test javax/swing/JComboBox/TestComboBoxComponentRendering.java fails in ubuntu 23.x and later
 - ... and 253 more: https://git.openjdk.org/shenandoah-jdk21u/compare/42157792...d5a2f768

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=191&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/191/files
  Stats: 83674 lines in 1494 files changed: 64735 ins; 8729 del; 10210 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/191.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/191/head:pull/191

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

From wkemper at openjdk.org  Thu May  1 17:43:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 May 2025 17:43:59 GMT
Subject: Integrated: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
Message-ID: <3bV-rGkGRHjkUNAEElE0_aSdO8t81oMrd88bjWmZY6Y=.0df6a3b1-29db-4592-aa42-7d3d15684455@github.com>

On Fri, 25 Apr 2025 20:40:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.

This pull request has now been integrated.

Changeset: 9e26b9fa
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e26b9facba09c4d6f516e8032b876c6d9e95e9e
Stats:     24 lines in 1 file changed: 15 ins; 8 del; 1 mod

8355372: GenShen: Test gc/shenandoah/generational/TestOldGrowthTriggers.java fails with UseCompactObjectHeaders enabled

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Thu May  1 17:50:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 May 2025 17:50:18 GMT
Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts
Message-ID: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>

Conflict in file missing from 21.

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

Commit messages:
 - 8354541: Remove Shenandoah post barrier expand loop opts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/192/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354541
  Stats: 250 lines in 5 files changed: 0 ins; 248 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/192.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/192/head:pull/192

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

From cslucas at openjdk.org  Thu May  1 18:32:12 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 1 May 2025 18:32:12 GMT
Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts
In-Reply-To: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>
References: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>
Message-ID: <T7mg1Ck1J1beq3XJ1bim5QIssuFtSB4lAn0rxRLnwdo=.26303d0d-bf4e-4e85-b5a6-3446104ce276@github.com>

On Thu, 1 May 2025 17:45:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in file missing from 21.

Thank you. LGTM.

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

Marked as reviewed by cslucas (no project role).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/192#pullrequestreview-2810410863

From ysr at openjdk.org  Thu May  1 21:14:04 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 1 May 2025 21:14:04 GMT
Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts
In-Reply-To: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>
References: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>
Message-ID: <zuFbUlR17iPw-8vyk5eEJS6__tkcVa_5uXkT68jPAyg=.f0b3391e-197f-4dd0-ab0f-faea42999ff7@github.com>

On Thu, 1 May 2025 17:45:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in file missing from 21.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/192#pullrequestreview-2810738833

From wkemper at openjdk.org  Thu May  1 21:43:07 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 May 2025 21:43:07 GMT
Subject: Integrated: 8354541: Remove Shenandoah post barrier expand loop opts
In-Reply-To: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>
References: <TGI426T9rdIe_ZJ9tt49L1XuL-FWsREqkfP2Zv5uRLY=.7a3b43c6-ad68-420d-ac11-6a89f07f0d5b@github.com>
Message-ID: <ngN7yCgHZPUaAknHPheKAv417hImieTwEo7S5JFizCA=.f9a7d954-2987-4519-9c82-5ecc5869e841@github.com>

On Thu, 1 May 2025 17:45:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in file missing from 21.

This pull request has now been integrated.

Changeset: 115e9281
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/115e92811971684751d1b570c5982e632cdb532f
Stats:     250 lines in 5 files changed: 0 ins; 248 del; 2 mod

8354541: Remove Shenandoah post barrier expand loop opts

Reviewed-by: cslucas, ysr
Backport-of: 4eae9b5ba61bfe262b43346a7499c98c1a54d2fe

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

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

From wkemper at openjdk.org  Thu May  1 22:01:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 May 2025 22:01:27 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <Ul7i1vO3CPPzwwuHXz9FoYSNhyAetGhzAkkXFw6_7SE=.598629ab-6829-4204-bc93-a54e42a93789@github.com>
References: <Ul7i1vO3CPPzwwuHXz9FoYSNhyAetGhzAkkXFw6_7SE=.598629ab-6829-4204-bc93-a54e42a93789@github.com>
Message-ID: <wkXuo32CtiXWKHKqq4N9sgRv8i5hXNo3I5iRe-oTqLw=.dcf2d025-a6fd-400f-b607-e822073b79f5@github.com>

> Merges tag jdk-21.0.8+1

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

 - Merge tag 'jdk-21.0.8+1' into merge-jdk-21.0.8+1
   
   Added tag jdk-21.0.8+1 for changeset d5a2f7685996
 - 8318700: MacOS Zero cannot run gtests due to wrong JVM path
   
   Backport-of: 744e0893100d402b2b51762d57bcc2e99ab7fdcc
 - 8319690: [AArch64] C2 compilation hits offset_ok_for_immed: assert "c2 compiler bug"
   
   Backport-of: 98f0b86641d84048949ed3da1cb14f3820b01c12
 - 8314236: Overflow in Collections.rotate
   
   Backport-of: 3828dc913a3ea28d622b69bd07f26949128eb5f7
 - 8320687: sun.jvmstat.monitor.MonitoredHost.getMonitoredHost() throws unexpected exceptions when invoked concurrently
   
   Backport-of: 81484d8c0520cf55ec58fc7b4c81880e69537674
 - 8353787: Increased number of SHA-384-Digest java.util.jar.Attributes$Name instances leading to higher memory footprint
   
   Backport-of: b64cdc28132c889ca8e21dc9534590ba2a778bcd
 - 8352706: httpclient HeadTest does not run on HTTP2
   
   Backport-of: e32a0c90feb231d791e6c17e6360f629189cab8b
 - 8330598: java/net/httpclient/Http1ChunkedTest.java fails with java.util.MissingFormatArgumentException: Format specifier '%s'
   
   Backport-of: c9c3c1536880d81ab84d5cb55f4fd0fe3bbf60a2
 - 8343891: Test javax/swing/JTabbedPane/TestJTabbedPaneBackgroundColor.java failed
   
   Backport-of: c2e14b1b304796753bea2eca81aa24ab4b3bf6db
 - 8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual
   
   Backport-of: 08929134b3533362133139c4e964b1b28de6ebfb
 - ... and 254 more: https://git.openjdk.org/shenandoah-jdk21u/compare/115e9281...de4a4a11

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/191/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=191&range=01
  Stats: 83554 lines in 1483 files changed: 64677 ins; 8722 del; 10155 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/191.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/191/head:pull/191

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

From mbaesken at openjdk.org  Fri May  2 06:39:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 2 May 2025 06:39:52 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <kq3_Hv_tGpZNkyD8H-mSRgzu3pIWQvTw32xE572p3C8=.eee51f5d-d598-47a3-a8d8-6be41c199edf@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
 <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>
 <A7uJv2S_xHnx2RWajqZ79drsBKIsEHwGLOuPVS-QFMY=.7914d187-ca22-4532-b7b3-9a900cb4b032@github.com>
 <_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com>
 <kq3_Hv_tGpZNkyD8H-mSRgzu3pIWQvTw32xE572p3C8=.eee51f5d-d598-47a3-a8d8-6be41c199edf@github.com>
Message-ID: <bcvKCtrut96MYucnlDor0QXONPvNEmGziWT7kF8t3jQ=.3a6883f7-3e15-4882-962b-c54500a1a174@github.com>

On Wed, 30 Apr 2025 15:36:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

> have you had a chance to retest after PR#24940 was integrated?

Did not see the issue again after this (of course this is no 'proof' that they will never come back), so I would say looks good !

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2846479688

From wkemper at openjdk.org  Fri May  2 18:19:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 May 2025 18:19:21 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <Ul7i1vO3CPPzwwuHXz9FoYSNhyAetGhzAkkXFw6_7SE=.598629ab-6829-4204-bc93-a54e42a93789@github.com>
References: <Ul7i1vO3CPPzwwuHXz9FoYSNhyAetGhzAkkXFw6_7SE=.598629ab-6829-4204-bc93-a54e42a93789@github.com>
Message-ID: <q3P2Pd_ieMtv9HT-KHV3aF33tPVqQxJ6AtK37Ti_Bb4=.8dc0a0c6-bd65-4cbe-8fe4-f87bcb3911cf@github.com>

On Thu, 1 May 2025 14:20:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.8+1

This pull request has now been integrated.

Changeset: ee00dcf4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ee00dcf4c276ae458093483ec686b6d2f1213408
Stats:     83554 lines in 1483 files changed: 64677 ins; 8722 del; 10155 mod

Merge

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

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

From rkennke at openjdk.org  Mon May  5 13:43:23 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 13:43:23 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI
Message-ID: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>

In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.

Testing:
 - [x] extensive testing with https://github.com/oracle/graal/pull/10904

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

Commit messages:
 - Fix ordering of includes
 - Remove unnecessary stuff
 - Revert unrelated changes
 - Revert unrelated changes
 - Merge branch 'master' into graal-shenandoah-support
 - Support for Shenandoah card-table barriers in JVMCI
 - Revert "8321373: Build should use LC_ALL=C.UTF-8"
 - Graal Shenandoah support

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

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

From dnsimon at openjdk.org  Mon May  5 13:53:50 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 May 2025 13:53:50 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI
In-Reply-To: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
Message-ID: <KZvgnkiTE4GW44_x8SX8hsGYAkS0orwQ6lVtf6jlWnI=.3549331c-1de2-4db2-b3d1-b52beb5edf5f@github.com>

On Fri, 2 May 2025 10:35:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
> 
> Testing:
>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904

LGTM

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25001#pullrequestreview-2814890860

From shade at openjdk.org  Mon May  5 15:38:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 May 2025 15:38:46 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI
In-Reply-To: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
Message-ID: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>

On Fri, 2 May 2025 10:35:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
> 
> Testing:
>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904

A few questions:

src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp line 42:

> 40:   static void pre_barrier(JavaThread* thread, oopDesc* orig) {
> 41:     write_ref_field_pre(orig, thread);
> 42:   }

So, why not export `write_ref_field_pre`, instead of introducing this new method? Style/cleanliness, or something else? I am asking, because every time we add a new stub here, we would need to record it in `AOTCache` tables for Leyden benefit.

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 240:

> 238:     cardtable_shift = CardTable::card_shift();
> 239:   } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) {
> 240:     cardtable_shift = CardTable::card_shift();

I understand the barrier code does not use `cardtable_start_address`, but should we still initialize it here to `nullptr`?

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

PR Review: https://git.openjdk.org/jdk/pull/25001#pullrequestreview-2815217376
PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073674847
PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073678010

From rkennke at openjdk.org  Mon May  5 15:54:29 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 15:54:29 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2]
In-Reply-To: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
Message-ID: <zirO8JqJ6A-rSFurqv31UD33CqIUSGjL6sgiztKyupw=.5a4f29db-f0bd-4870-aebd-a62c2a35db70@github.com>

> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
> 
> Testing:
>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Initialize cardtable_start_address to nullptr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25001/files
  - new: https://git.openjdk.org/jdk/pull/25001/files/6487a9f7..c95313a9

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

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

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

From rkennke at openjdk.org  Mon May  5 15:54:29 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 15:54:29 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2]
In-Reply-To: <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>
Message-ID: <HqLJu_x8t7TPsusCAVeHrPH1NByjNuqUK0ipkEEDDFw=.cec49cc5-d6d0-4a15-b8c1-19e1b303da9b@github.com>

On Mon, 5 May 2025 15:31:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Initialize cardtable_start_address to nullptr
>
> src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp line 42:
> 
>> 40:   static void pre_barrier(JavaThread* thread, oopDesc* orig) {
>> 41:     write_ref_field_pre(orig, thread);
>> 42:   }
> 
> So, why not export `write_ref_field_pre`, instead of introducing this new method? Style/cleanliness, or something else? I am asking, because every time we add a new stub here, we would need to record it in `AOTCache` tables for Leyden benefit.

It's about the argument ordering. Graal expects the Thread* to be prependend, while other JITs call it with the Thread* appended. I guess we could change other JIT calls to also prepend the thread, or change the interface to not pass the Thread* at all. I chose to follow G1 and export both variants.

> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 240:
> 
>> 238:     cardtable_shift = CardTable::card_shift();
>> 239:   } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) {
>> 240:     cardtable_shift = CardTable::card_shift();
> 
> I understand the barrier code does not use `cardtable_start_address`, but should we still initialize it here to `nullptr`?

Good point, did that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073702873
PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073705091

From cslucas at openjdk.org  Mon May  5 16:26:49 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 5 May 2025 16:26:49 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2]
In-Reply-To: <zirO8JqJ6A-rSFurqv31UD33CqIUSGjL6sgiztKyupw=.5a4f29db-f0bd-4870-aebd-a62c2a35db70@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <zirO8JqJ6A-rSFurqv31UD33CqIUSGjL6sgiztKyupw=.5a4f29db-f0bd-4870-aebd-a62c2a35db70@github.com>
Message-ID: <SUV0kGv2SY2Xe3q7ufsUto-fNnpro6JNjG6aT2HcbRU=.d399da30-8193-41da-90ce-91365090be96@github.com>

On Mon, 5 May 2025 15:54:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
>> 
>> Testing:
>>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize cardtable_start_address to nullptr

LGTM. Thanks.

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

Marked as reviewed by cslucas (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25001#pullrequestreview-2815365611

From shade at openjdk.org  Mon May  5 16:50:46 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 May 2025 16:50:46 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2]
In-Reply-To: <HqLJu_x8t7TPsusCAVeHrPH1NByjNuqUK0ipkEEDDFw=.cec49cc5-d6d0-4a15-b8c1-19e1b303da9b@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>
 <HqLJu_x8t7TPsusCAVeHrPH1NByjNuqUK0ipkEEDDFw=.cec49cc5-d6d0-4a15-b8c1-19e1b303da9b@github.com>
Message-ID: <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com>

On Mon, 5 May 2025 15:49:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp line 42:
>> 
>>> 40:   static void pre_barrier(JavaThread* thread, oopDesc* orig) {
>>> 41:     write_ref_field_pre(orig, thread);
>>> 42:   }
>> 
>> So, why not export `write_ref_field_pre`, instead of introducing this new method? Style/cleanliness, or something else? I am asking, because every time we add a new stub here, we would need to record it in `AOTCache` tables for Leyden benefit.
>
> It's about the argument ordering. Graal expects the Thread* to be prependend, while other JITs call it with the Thread* appended. I guess we could change other JIT calls to also prepend the thread, or change the interface to not pass the Thread* at all. I chose to follow G1 and export both variants.

Oh, so this matches `JVMCIRuntime::write_barrier_pre` for G1 (weird place to have it, but oh well). 

Does Graal need the `Thread*` argument?

I think this method is only called when SATB buffer is full. So the performance of this method is likely not affected by getting the current thread down in caller. So I think it would be more straight-forward to sharpen `ShenandoahRuntime::write_ref_field_pre` by dropping `Thread*` and then exporting that. Maybe also under the `SR::write_barrier_pre` name to be even more consistent for everything else.

Maybe @JohnTortugo wants to clean up more mess in C2 related to this :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073800305

From shade at openjdk.org  Mon May  5 16:50:48 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 May 2025 16:50:48 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v2]
In-Reply-To: <zirO8JqJ6A-rSFurqv31UD33CqIUSGjL6sgiztKyupw=.5a4f29db-f0bd-4870-aebd-a62c2a35db70@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <zirO8JqJ6A-rSFurqv31UD33CqIUSGjL6sgiztKyupw=.5a4f29db-f0bd-4870-aebd-a62c2a35db70@github.com>
Message-ID: <tght4dG6QGhaZk2e0JAjkGGfUe1_UdC1EkTiaONhWZQ=.80b5bbcd-8d66-42a2-967c-5c779c76ac23@github.com>

On Mon, 5 May 2025 15:54:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
>> 
>> Testing:
>>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize cardtable_start_address to nullptr

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 137:

> 135:   ZGC_ONLY(static_field(CompilerToVM::Data,    sizeof_ZStoreBarrierEntry,              int))                                         \
> 136:   SHENANDOAHGC_ONLY(static_field(CompilerToVM::Data, shenandoah_in_cset_fast_test_addr, address))                                      \
> 137:   SHENANDOAHGC_ONLY(static_field(CompilerToVM::Data, shenandoah_region_size_bytes_shift,int))                                        \

Also indent trailing backslashes.

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 909:

> 907:   SHENANDOAHGC_ONLY(declare_function(ShenandoahRuntime::load_reference_barrier_weak_narrow))    \
> 908:   SHENANDOAHGC_ONLY(declare_function(ShenandoahRuntime::load_reference_barrier_phantom))           \
> 909:   SHENANDOAHGC_ONLY(declare_function(ShenandoahRuntime::load_reference_barrier_phantom_narrow))    \

Also indent trailing backslashes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073801311
PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073801126

From rkennke at openjdk.org  Mon May  5 16:58:01 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 16:58:01 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3]
In-Reply-To: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
Message-ID: <gWhERSP3RH5uwLO6UMo5Xrp_XPrYrF2jWi96tCpeCU0=.25ce4174-e11f-43ca-ac68-34bf20920f99@github.com>

> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
> 
> Testing:
>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Align backslashes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25001/files
  - new: https://git.openjdk.org/jdk/pull/25001/files/c95313a9..44344585

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

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

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

From rkennke at openjdk.org  Mon May  5 16:58:01 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 16:58:01 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3]
In-Reply-To: <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>
 <HqLJu_x8t7TPsusCAVeHrPH1NByjNuqUK0ipkEEDDFw=.cec49cc5-d6d0-4a15-b8c1-19e1b303da9b@github.com>
 <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com>
Message-ID: <qmJ8YI0naIrRqDY2_LCRbXW1Dj5DZs_JkkoFXkGqYLU=.f41fbf1b-3f1e-4638-b0a1-7a16564f47ac@github.com>

On Mon, 5 May 2025 16:46:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It's about the argument ordering. Graal expects the Thread* to be prependend, while other JITs call it with the Thread* appended. I guess we could change other JIT calls to also prepend the thread, or change the interface to not pass the Thread* at all. I chose to follow G1 and export both variants.
>
> Oh, so this matches `JVMCIRuntime::write_barrier_pre` for G1 (weird place to have it, but oh well). 
> 
> Does Graal need the `Thread*` argument?
> 
> I think this method is only called when SATB buffer is full. So the performance of this method is likely not affected by getting the current thread down in caller. So I think it would be more straight-forward to sharpen `ShenandoahRuntime::write_ref_field_pre` by dropping `Thread*` and then exporting that. Maybe also under the `SR::write_barrier_pre` name to be even more consistent for everything else.
> 
> Maybe @JohnTortugo wants to clean up more mess in C2 related to this :)

Graal does not need the Thread* argument, but the runtime code behind write_ref_pre() currently uses it. I agree, it does not look performance critical to pass it through. However, getting rid of it seems to blow the scope of this PR. I'd rather do this as a follow-up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073807949

From rkennke at openjdk.org  Mon May  5 16:58:02 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 16:58:02 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3]
In-Reply-To: <qmJ8YI0naIrRqDY2_LCRbXW1Dj5DZs_JkkoFXkGqYLU=.f41fbf1b-3f1e-4638-b0a1-7a16564f47ac@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>
 <HqLJu_x8t7TPsusCAVeHrPH1NByjNuqUK0ipkEEDDFw=.cec49cc5-d6d0-4a15-b8c1-19e1b303da9b@github.com>
 <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com>
 <qmJ8YI0naIrRqDY2_LCRbXW1Dj5DZs_JkkoFXkGqYLU=.f41fbf1b-3f1e-4638-b0a1-7a16564f47ac@github.com>
Message-ID: <_4ebbEF2UTOwozaLgA8ibDcCi1YF5I4rKA1NN3tBozs=.7ce738b0-7e79-4c93-bc4d-63f534ccc536@github.com>

On Mon, 5 May 2025 16:51:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Oh, so this matches `JVMCIRuntime::write_barrier_pre` for G1 (weird place to have it, but oh well). 
>> 
>> Does Graal need the `Thread*` argument?
>> 
>> I think this method is only called when SATB buffer is full. So the performance of this method is likely not affected by getting the current thread down in caller. So I think it would be more straight-forward to sharpen `ShenandoahRuntime::write_ref_field_pre` by dropping `Thread*` and then exporting that. Maybe also under the `SR::write_barrier_pre` name to be even more consistent for everything else.
>> 
>> Maybe @JohnTortugo wants to clean up more mess in C2 related to this :)
>
> Graal does not need the Thread* argument, but the runtime code behind write_ref_pre() currently uses it. I agree, it does not look performance critical to pass it through. However, getting rid of it seems to blow the scope of this PR. I'd rather do this as a follow-up.

Actually, I'd probably add the new entry for Graal without the Thread* argument now, and fix the others in a follow-up. Otherwise we need to deal with it on the Graal side again later once we change the entry points.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073813072

From shade at openjdk.org  Mon May  5 17:03:47 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 May 2025 17:03:47 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v3]
In-Reply-To: <_4ebbEF2UTOwozaLgA8ibDcCi1YF5I4rKA1NN3tBozs=.7ce738b0-7e79-4c93-bc4d-63f534ccc536@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <26EKhVnyWuLQxzRjvvLzzLcY2iW6fmgqs7qHWOdZQvA=.99efcb44-5788-403a-8ad1-83766184aa17@github.com>
 <HqLJu_x8t7TPsusCAVeHrPH1NByjNuqUK0ipkEEDDFw=.cec49cc5-d6d0-4a15-b8c1-19e1b303da9b@github.com>
 <92qsu_6Qj0xyyGYK8dDm97enzXvKNgj7obDEHnhVcds=.d4671e44-1ef0-4c79-a286-fa578a6eb25f@github.com>
 <qmJ8YI0naIrRqDY2_LCRbXW1Dj5DZs_JkkoFXkGqYLU=.f41fbf1b-3f1e-4638-b0a1-7a16564f47ac@github.com>
 <_4ebbEF2UTOwozaLgA8ibDcCi1YF5I4rKA1NN3tBozs=.7ce738b0-7e79-4c93-bc4d-63f534ccc536@github.com>
Message-ID: <o4_ZemkCW10hN2elN_3KW74SPCYV_rOjSznqmKVnCpc=.d21bb661-b52d-44d2-94c3-25321bb317ac@github.com>

On Mon, 5 May 2025 16:55:36 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Graal does not need the Thread* argument, but the runtime code behind write_ref_pre() currently uses it. I agree, it does not look performance critical to pass it through. However, getting rid of it seems to blow the scope of this PR. I'd rather do this as a follow-up.
>
> Actually, I'd probably add the new entry for Graal without the Thread* argument now, and fix the others in a follow-up. Otherwise we need to deal with it on the Graal side again later once we change the entry points.

OK, but that follow-up risks changing the JVMCI interface _again_? How about we introduce:


static void write_barrier_pre(oopDesc* pre_val) {
  write_ref_field_pre(pre_val, JavaThread::current());
}


...and then the follow-up purges the old `write_ref_field_pre`? The implementation might need to be in `.cpp`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2073820137

From rkennke at openjdk.org  Mon May  5 20:25:27 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 5 May 2025 20:25:27 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v4]
In-Reply-To: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
Message-ID: <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>

> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
> 
> Testing:
>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Simplify pre-barrier runtime entry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25001/files
  - new: https://git.openjdk.org/jdk/pull/25001/files/44344585..41084f3e

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

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

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

From shade at openjdk.org  Tue May  6 08:15:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 May 2025 08:15:16 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v4]
In-Reply-To: <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>
Message-ID: <yCtKBT4wEUERpf_F77nWQjEaPlc4TypD2S3xRrG7Qzc=.b9e110c1-2e64-442d-8ed3-b9f9aa39053f@github.com>

On Mon, 5 May 2025 20:25:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
>> 
>> Testing:
>>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify pre-barrier runtime entry

All right, this works, thanks!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25001#pullrequestreview-2817308091

From rkennke at openjdk.org  Tue May  6 11:11:19 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 6 May 2025 11:11:19 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v4]
In-Reply-To: <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>
Message-ID: <nP9LzqrUbUBvmgbSu0HB4Z0woXzxEk-K6vTNOatdQ1M=.69b52422-ae8d-412d-9030-c75728f1664b@github.com>

On Mon, 5 May 2025 20:25:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
>> 
>> Testing:
>>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify pre-barrier runtime entry

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/25001#issuecomment-2854170217

From rkennke at openjdk.org  Tue May  6 11:11:19 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 6 May 2025 11:11:19 GMT
Subject: Integrated: 8356075: Support Shenandoah GC in JVMCI
In-Reply-To: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
Message-ID: <tmdA6heOmPzZfEGa_IO7ocNooDFyEeSZQlkEbnXwAug=.14f43427-d0f7-410c-9d33-07f6a7532e7f@github.com>

On Fri, 2 May 2025 10:35:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
> 
> Testing:
>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904

This pull request has now been integrated.

Changeset: 614ba9fc
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/614ba9fc41a0274a31f0e8eff8a598a7c5afe164
Stats:     62 lines in 7 files changed: 61 ins; 0 del; 1 mod

8356075: Support Shenandoah GC in JVMCI

Reviewed-by: shade, dnsimon, cslucas

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

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

From dnsimon at openjdk.org  Tue May  6 11:56:23 2025
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 May 2025 11:56:23 GMT
Subject: RFR: 8356075: Support Shenandoah GC in JVMCI [v4]
In-Reply-To: <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>
References: <pGN_wuIoTkDaMGwotFCH_1PiohTPyFP05-7DNXmsWU4=.ce3fff95-7bd5-4e9b-aa29-cd93c0016cc2@github.com>
 <dsYp242p-1jCg-9vmI8fKobTJqQlT8WACQ1e2McNLtg=.973251bd-e79e-4835-8a22-f24a6a60289a@github.com>
Message-ID: <DtPx69gE3XTj--bYZNZqvlVhgx6DGptRASZDeXuvF2E=.e0d179c7-55b1-466a-93d6-160d7185b451@github.com>

On Mon, 5 May 2025 20:25:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In order to support Shenandoah GC in Graal, some changes are required in JVMCI, namely, export Shenandoah relevant symbols.
>> 
>> Testing:
>>  - [x] extensive testing with https://github.com/oracle/graal/pull/10904
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify pre-barrier runtime entry

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 239:

> 237:     cardtable_start_address = base;
> 238:     cardtable_shift = CardTable::card_shift();
> 239:   } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) {

This change is causing a failure in mach5 tier 1:

[2025-05-06T11:34:44,742Z] /workspace/open/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:239:35: error: no member named 'ShenandoahBarrierSet' in 'BarrierSet'
[2025-05-06T11:34:44,742Z]   } else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) {
[2025-05-06T11:34:44,742Z]                       ~~~~~~~~~~~~^
[2025-05-06T11:34:45,729Z] 1 error generated.

 I assume it's missing `#if INCLUDE_SHENANDOAHGC`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25001#discussion_r2075304100

From stefank at openjdk.org  Thu May  8 10:06:47 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 10:06:47 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with outside
 TLAB allocations
Message-ID: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>

While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java

The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.

The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.

The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.

The idea is to better account how much we have allocated in three different buckets:
* Outside of TLAB allocations
* Accounted TLAB allocations
* The last bit of TLAB allocations that hasn't been accounted yet

And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.

There are a few things to think about when reading this code:
* The thread can allocate and retire multiple TLABs before we cross the sample threshold.
* The sampling can take multiple samples in a single TLAB
* Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.

There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:

1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
2) Moved thread allocation accounting and sampling code out of the TLAB
3) Moved retiring of TLABs out of make_parseable (needed to support (2))

Some of that could be extracted into a separate PR if that's deemed worthwhile.

Tested with the HeapMonitor tests various TLAB sizes.

If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

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

Commit messages:
 - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Changes: https://git.openjdk.org/jdk/pull/25114/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25114&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356372
  Stats: 224 lines in 14 files changed: 136 ins; 42 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

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

From wkemper at openjdk.org  Thu May  8 14:25:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 8 May 2025 14:25:34 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <H3ivUK6LcTEUhlFK5DJyIQCYHoVR0BudZOPJgvtzJIc=.ed58de85-4d65-4356-8bf4-eea68dfa0e0b@github.com>

Merges tag jdk-21.0.8+2

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

Commit messages:
 - 8353190: Use "/native" Run Option for TestAvailableProcessors Execution
 - 8354802: MAX_SECS definition is unused in os_linux
 - 8349501: Relocate supporting classes in security/testlibrary to test/lib/jdk tree
 - 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect"
 - 8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't use finalization
 - 8320948: NPE due to unreported compiler error

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/193/files
  Stats: 555 lines in 52 files changed: 228 ins; 223 del; 104 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/193.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/193/head:pull/193

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

From wkemper at openjdk.org  Mon May 12 18:59:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 12 May 2025 18:59:57 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <H3ivUK6LcTEUhlFK5DJyIQCYHoVR0BudZOPJgvtzJIc=.ed58de85-4d65-4356-8bf4-eea68dfa0e0b@github.com>
References: <H3ivUK6LcTEUhlFK5DJyIQCYHoVR0BudZOPJgvtzJIc=.ed58de85-4d65-4356-8bf4-eea68dfa0e0b@github.com>
Message-ID: <evCGdQBIWprzLAwGXlzhhvhx5aNN2sz1y9Hmt-xsuAc=.bddf56a2-f4ec-4321-bc75-1b696745c951@github.com>

> Merges tag jdk-21.0.8+2

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/193/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/193/files/96f7dbfd..96f7dbfd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=193&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=193&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/193.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/193/head:pull/193

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

From wkemper at openjdk.org  Mon May 12 18:59:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 12 May 2025 18:59:59 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <H3ivUK6LcTEUhlFK5DJyIQCYHoVR0BudZOPJgvtzJIc=.ed58de85-4d65-4356-8bf4-eea68dfa0e0b@github.com>
References: <H3ivUK6LcTEUhlFK5DJyIQCYHoVR0BudZOPJgvtzJIc=.ed58de85-4d65-4356-8bf4-eea68dfa0e0b@github.com>
Message-ID: <qQIL2HA7uLMa1P6f9RNYMQL8i0hqsofkLmnq_09QaAo=.29463b70-7be2-468d-abc7-2ae0d360b1c0@github.com>

On Thu, 8 May 2025 14:21:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.8+2

This pull request has now been integrated.

Changeset: 159e959d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/159e959dd41565b6dce1645be30a0324fa45b11a
Stats:     555 lines in 52 files changed: 228 ins; 223 del; 104 mod

Merge

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

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

From kdnilsen at openjdk.org  Mon May 12 22:40:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 22:40:33 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table [v2]
In-Reply-To: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
Message-ID: <0rJUri0R4B1p5Vf_3tzRegWxn3T6r7046gKXUJbeYV8=.af67166b-45bc-4888-82ec-c69fbdb5c6af@github.com>

> Remove unneeded log messages related to processing of the remembered set write card table.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Use log_develop_debug message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24809/files
  - new: https://git.openjdk.org/jdk/pull/24809/files/c1f65632..9cb54f3a

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

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

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

From kdnilsen at openjdk.org  Mon May 12 22:40:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 22:40:33 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table
In-Reply-To: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
Message-ID: <VBxcl-M1oqOlBxNhpTOSUNGvlhVNN4ywvmVMKK-G9tk=.f203d7e9-12c2-45db-9574-6b6ac1760e14@github.com>

On Wed, 23 Apr 2025 00:54:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Remove unneeded log messages related to processing of the remembered set write card table.

Replaced original messages with log_develop_debug() messages.

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

PR Comment: https://git.openjdk.org/jdk/pull/24809#issuecomment-2874353597

From kdnilsen at openjdk.org  Mon May 12 22:43:26 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 22:43:26 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available()
Message-ID: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>

Two changes:

1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

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

Commit messages:
 - Fix white apce
 - available() returns Sentinel if under construction
 - Log full gc region transfers outside heaplock
 - Make ShenFreeSet::available() race free
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 29 more: https://git.openjdk.org/jdk/compare/92730945...6353f1f7

Changes: https://git.openjdk.org/jdk/pull/25165/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25165&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356667
  Stats: 95 lines in 10 files changed: 72 ins; 9 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25165/head:pull/25165

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

From wkemper at openjdk.org  Mon May 12 23:09:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 12 May 2025 23:09:53 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available()
In-Reply-To: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
Message-ID: <SISy-mOCkx3gNUsARHybjvaFunIZ7-9kvLRAV0m-NyE=.54d11271-6250-4ec9-8c72-a5f1882311de@github.com>

On Fri, 9 May 2025 23:45:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Two changes:
> 
> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

Minor nits.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 235:

> 233: 
> 234:   // Acquire heap lock and return available_in, assuming heap lock is not acquired by the caller.
> 235:   inline size_t available_in_under_lock(ShenandoahFreeSetPartitionId which_partition) const {

This name confuses me: `available_in_under_lock`. Should it be called `available_without_lock` or `available_no_lock`? Or, switch it with `available_in` (which asserts that the heap lock is held). I see that it takes the lock, but this is only to make the assertion.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 242:

> 240:   }
> 241: 
> 242:   ShenandoahGenerationalHeap::TransferResult result;;

Extra `;` here.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25165#pullrequestreview-2834801227
PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2085650563
PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2085648309

From wkemper at openjdk.org  Mon May 12 23:10:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 12 May 2025 23:10:52 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table [v2]
In-Reply-To: <0rJUri0R4B1p5Vf_3tzRegWxn3T6r7046gKXUJbeYV8=.af67166b-45bc-4888-82ec-c69fbdb5c6af@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
 <0rJUri0R4B1p5Vf_3tzRegWxn3T6r7046gKXUJbeYV8=.af67166b-45bc-4888-82ec-c69fbdb5c6af@github.com>
Message-ID: <9ZAGrz5s4dOvL3oaBpQ014-qW272MewsPGOK9JordRc=.c21440fc-129e-4bfd-b5b4-3ad55459264d@github.com>

On Mon, 12 May 2025 22:40:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Remove unneeded log messages related to processing of the remembered set write card table.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use log_develop_debug message

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24809#pullrequestreview-2834806479

From kdnilsen at openjdk.org  Mon May 12 23:16:58 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 23:16:58 GMT
Subject: Integrated: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table
In-Reply-To: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
Message-ID: <Y3J8Ka5y1nPN13PY--jVIUmtkBBDyR-cZfdpsnRcofY=.16c3b33b-3359-4545-9f72-27cbc1efd9b0@github.com>

On Wed, 23 Apr 2025 00:54:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Remove unneeded log messages related to processing of the remembered set write card table.

This pull request has now been integrated.

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

8355340: GenShen: Remove unneeded log messages related to remembered set write table

Reviewed-by: wkemper, ysr

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

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

From kdnilsen at openjdk.org  Mon May 12 23:17:51 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 23:17:51 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available()
In-Reply-To: <SISy-mOCkx3gNUsARHybjvaFunIZ7-9kvLRAV0m-NyE=.54d11271-6250-4ec9-8c72-a5f1882311de@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
 <SISy-mOCkx3gNUsARHybjvaFunIZ7-9kvLRAV0m-NyE=.54d11271-6250-4ec9-8c72-a5f1882311de@github.com>
Message-ID: <V2dC-6OQNk-XKbWI_pvqiZwakZYCYmbaThZdgEghxa0=.9bc3a110-55c6-47b5-9df1-acef5e74f706@github.com>

On Mon, 12 May 2025 23:05:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Two changes:
>> 
>> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
>> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 235:
> 
>> 233: 
>> 234:   // Acquire heap lock and return available_in, assuming heap lock is not acquired by the caller.
>> 235:   inline size_t available_in_under_lock(ShenandoahFreeSetPartitionId which_partition) const {
> 
> This name confuses me: `available_in_under_lock`. Should it be called `available_without_lock` or `available_no_lock`? Or, switch it with `available_in` (which asserts that the heap lock is held). I see that it takes the lock, but this is only to make the assertion.

Thanks for review and comments.  I'll change the name.  It follows a pattern that is admittedly very confusing...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2085656619

From kdnilsen at openjdk.org  Mon May 12 23:22:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 23:22:33 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v2]
In-Reply-To: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
Message-ID: <9O1jQ5rn-sWaFz3hO-5tn4CCiDbyh1Q5E1fXDTM_Tco=.5efc1191-0c87-47d1-b219-737249bfe63d@github.com>

> Two changes:
> 
> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Respond to reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25165/files
  - new: https://git.openjdk.org/jdk/pull/25165/files/6353f1f7..ffe1113e

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

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

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

From kdnilsen at openjdk.org  Mon May 12 23:22:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 23:22:33 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v2]
In-Reply-To: <V2dC-6OQNk-XKbWI_pvqiZwakZYCYmbaThZdgEghxa0=.9bc3a110-55c6-47b5-9df1-acef5e74f706@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
 <SISy-mOCkx3gNUsARHybjvaFunIZ7-9kvLRAV0m-NyE=.54d11271-6250-4ec9-8c72-a5f1882311de@github.com>
 <V2dC-6OQNk-XKbWI_pvqiZwakZYCYmbaThZdgEghxa0=.9bc3a110-55c6-47b5-9df1-acef5e74f706@github.com>
Message-ID: <TGQN-Urh7QX3co2S_xoGNiN-NhXfKRCgFkB3vtxjkJc=.ff46fdc1-d723-467b-a0be-68ac73855f77@github.com>

On Mon, 12 May 2025 23:14:59 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 235:
>> 
>>> 233: 
>>> 234:   // Acquire heap lock and return available_in, assuming heap lock is not acquired by the caller.
>>> 235:   inline size_t available_in_under_lock(ShenandoahFreeSetPartitionId which_partition) const {
>> 
>> This name confuses me: `available_in_under_lock`. Should it be called `available_without_lock` or `available_no_lock`? Or, switch it with `available_in` (which asserts that the heap lock is held). I see that it takes the lock, but this is only to make the assertion.
>
> Thanks for review and comments.  I'll change the name.  It follows a pattern that is admittedly very confusing...

changing to available_in_not_locked()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2085660231

From kdnilsen at openjdk.org  Mon May 12 23:22:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 May 2025 23:22:33 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v2]
In-Reply-To: <SISy-mOCkx3gNUsARHybjvaFunIZ7-9kvLRAV0m-NyE=.54d11271-6250-4ec9-8c72-a5f1882311de@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
 <SISy-mOCkx3gNUsARHybjvaFunIZ7-9kvLRAV0m-NyE=.54d11271-6250-4ec9-8c72-a5f1882311de@github.com>
Message-ID: <e8YA7V7GiRNLoQWG9HnmgjrvObnG58_p5UxQjWhArT0=.bdd4222a-e1bf-4af2-8f0d-54091600b099@github.com>

On Mon, 12 May 2025 23:02:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer comments
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 242:
> 
>> 240:   }
>> 241: 
>> 242:   ShenandoahGenerationalHeap::TransferResult result;;
> 
> Extra `;` here.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2085660144

From wkemper at openjdk.org  Mon May 12 23:31:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 12 May 2025 23:31:54 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v2]
In-Reply-To: <9O1jQ5rn-sWaFz3hO-5tn4CCiDbyh1Q5E1fXDTM_Tco=.5efc1191-0c87-47d1-b219-737249bfe63d@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
 <9O1jQ5rn-sWaFz3hO-5tn4CCiDbyh1Q5E1fXDTM_Tco=.5efc1191-0c87-47d1-b219-737249bfe63d@github.com>
Message-ID: <j-On_9Aoq8xXlz_o1pNvSnF_6Kbxxeb17gd0GgwU3_Q=.199631f6-df2d-4364-9991-79e988e7f199@github.com>

On Mon, 12 May 2025 23:22:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Two changes:
>> 
>> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
>> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer comments

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 234:

> 232:   }
> 233: 
> 234:   // Acquire heap lock and return available_in, assuming heap lock is not acquired by the caller.

Sorry - can we change this comment too? This method does _not_ acquire the lock in release builds. Comment could mention that it acquires the lock only for the correctness of the assertion?

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

PR Review: https://git.openjdk.org/jdk/pull/25165#pullrequestreview-2834876929
PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2085680099

From stefank at openjdk.org  Tue May 13 08:33:38 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 13 May 2025 08:33:38 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v2]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <AdzgnExe6-5U9gLhlhZolAxZ0mkCxICqJyyX1vAHHjs=.c7f10951-a75c-47c6-9df5-11e80aefaf91@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

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 three additional commits since the last revision:

 - Re-enable tests after merge
 - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
 - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/ed0c412d..0485cd2f

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

  Stats: 75811 lines in 2330 files changed: 52604 ins; 13809 del; 9398 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

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

From kdnilsen at openjdk.org  Tue May 13 17:55:07 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 13 May 2025 17:55:07 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v3]
In-Reply-To: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
Message-ID: <vUaBdYvGJNh0SdLwBEzDXphx9KXha7f1DjkmkuFBGXw=.610f5279-e771-41e9-894f-8aafe9561ae0@github.com>

> Two changes:
> 
> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25165/files
  - new: https://git.openjdk.org/jdk/pull/25165/files/ffe1113e..c4bb674d

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

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

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

From kdnilsen at openjdk.org  Tue May 13 17:55:10 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 13 May 2025 17:55:10 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v2]
In-Reply-To: <j-On_9Aoq8xXlz_o1pNvSnF_6Kbxxeb17gd0GgwU3_Q=.199631f6-df2d-4364-9991-79e988e7f199@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
 <9O1jQ5rn-sWaFz3hO-5tn4CCiDbyh1Q5E1fXDTM_Tco=.5efc1191-0c87-47d1-b219-737249bfe63d@github.com>
 <j-On_9Aoq8xXlz_o1pNvSnF_6Kbxxeb17gd0GgwU3_Q=.199631f6-df2d-4364-9991-79e988e7f199@github.com>
Message-ID: <iS4fwtuKazuyFub6i3pD8eu_hQH_GntaNZ7lYA8Dk4M=.dd2ebd79-3a88-4006-9368-4a1bd40b15c8@github.com>

On Mon, 12 May 2025 23:28:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer comments
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 234:
> 
>> 232:   }
>> 233: 
>> 234:   // Acquire heap lock and return available_in, assuming heap lock is not acquired by the caller.
> 
> Sorry - can we change this comment too? This method does _not_ acquire the lock in release builds. Comment could mention that it acquires the lock only for the correctness of the assertion?

Very good point.  I've made this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25165#discussion_r2087358566

From kdnilsen at openjdk.org  Tue May 13 18:04:13 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 13 May 2025 18:04:13 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v4]
In-Reply-To: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
Message-ID: <UaFAaoN4jj1heV0G9eM5Yb2dK5N1LGTpEwJVEQqcjJc=.4791e6ce-83a9-4300-99f2-60de2af2d86a@github.com>

> Two changes:
> 
> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix white space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25165/files
  - new: https://git.openjdk.org/jdk/pull/25165/files/c4bb674d..13b53514

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

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

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

From wkemper at openjdk.org  Tue May 13 18:11:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 May 2025 18:11:25 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v5]
In-Reply-To: <IqBj3S0HVsqvOYk44NAgpJQbnyWPqo6XmurMrbBcfvs=.09b75466-0db7-4d65-b26a-5358d109e130@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
 <IqBj3S0HVsqvOYk44NAgpJQbnyWPqo6XmurMrbBcfvs=.09b75466-0db7-4d65-b26a-5358d109e130@github.com>
Message-ID: <9JQe7kdBr__vV--6YCxZ2VfRPQU5ruXVuae6J-TUIuo=.a65b9aee-f43c-4343-bc1f-4d065718ef28@github.com>

On Tue, 13 May 2025 18:08:21 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Two changes:
>> 
>> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
>> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another white space problem

Thanks for the changes. Looks good to me!

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25165#pullrequestreview-2837697704

From kdnilsen at openjdk.org  Tue May 13 18:11:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 13 May 2025 18:11:24 GMT
Subject: RFR: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available() [v5]
In-Reply-To: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
Message-ID: <IqBj3S0HVsqvOYk44NAgpJQbnyWPqo6XmurMrbBcfvs=.09b75466-0db7-4d65-b26a-5358d109e130@github.com>

> Two changes:
> 
> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Another white space problem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25165/files
  - new: https://git.openjdk.org/jdk/pull/25165/files/13b53514..10373305

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

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

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

From kdnilsen at openjdk.org  Tue May 13 18:11:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 13 May 2025 18:11:25 GMT
Subject: Integrated: 8356667: GenShen: Eliminate races with
 ShenandoahFreeSet::available()
In-Reply-To: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
References: <13TqKn0YFISVnkWRhFsnR-e-T7_CL2orLWHIiDMc0qM=.ad4f4b45-6342-4453-84fe-acd3900c4040@github.com>
Message-ID: <E6f7hz9kPpABL4GxDZhHkopxNXdOMYEv0HT7dLc9cJ4=.49e30d59-fce1-4c4f-bd78-bcb97ab86e30@github.com>

On Fri, 9 May 2025 23:45:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Two changes:
> 
> 1. Compute the difference between capacity and used while holding the heap lock (so that these two values do not change in incompatible ways while the difference is being computed)
> 2. Return a "harmless" Sentinel value in case available() is consulted while we are in the process of rebuilding the freeset.  The SIZE_MAX value is considered harmless in that it will not cause immediate trigger of a new GC.  In typical usage, the control or regulator thread will check available() again in another millisecond, at which time a more accurate accounting of available will be provided (if the freeset reconstruction has been completed).

This pull request has now been integrated.

Changeset: e7ce661a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7ce661adb01fba4bb690d51cc2858c822008654
Stats:     97 lines in 10 files changed: 74 ins; 9 del; 14 mod

8356667: GenShen: Eliminate races with ShenandoahFreeSet::available()

Reviewed-by: wkemper

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

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

From sjohanss at openjdk.org  Wed May 14 12:26:54 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 14 May 2025 12:26:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v2]
In-Reply-To: <AdzgnExe6-5U9gLhlhZolAxZ0mkCxICqJyyX1vAHHjs=.c7f10951-a75c-47c6-9df5-11e80aefaf91@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <AdzgnExe6-5U9gLhlhZolAxZ0mkCxICqJyyX1vAHHjs=.c7f10951-a75c-47c6-9df5-11e80aefaf91@github.com>
Message-ID: <R_rxLKXQrE05ftpeZniBdXH2s7s8Of4JkcKaQrUInsU=.00bbb53e-36e9-4587-a9e6-b33b4b2515e3@github.com>

On Tue, 13 May 2025 08:33:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> 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 three additional commits since the last revision:
> 
>  - Re-enable tests after merge
>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>  - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Looks great :)

Suggestion to name it `reset_after_sample(...)` instead of `reset_after_sampling(...)` to be more consistent.

src/hotspot/share/runtime/threadHeapSampler.cpp line 440:

> 438:   pick_next_sample();
> 439: 
> 440:   reset_after_sampling(tlab_top);

Suggestion:

  reset_after_sample(tlab_top);

src/hotspot/share/runtime/threadHeapSampler.hpp line 110:

> 108:   }
> 109: 
> 110:   void reset_after_sampling(HeapWord* tlab_top) {

Suggestion:

  void reset_after_sample(HeapWord* tlab_top) {

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2839968906
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2088811246
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2088810407

From stefank at openjdk.org  Wed May 14 12:47:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 May 2025 12:47:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/0485cd2f..a318053e

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

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

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

From stefank at openjdk.org  Wed May 14 12:47:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 May 2025 12:47:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <SN1mWdNqyukzv9ea5GhfzofjH8czSVEv1DKgJlwziNs=.29311f5c-1042-4e19-a037-fadc6ca688a4@github.com>

On Wed, 14 May 2025 12:43:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Thanks for reviewing and pair-fixing!

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2840036844

From wkemper at openjdk.org  Thu May 15 14:28:37 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 May 2025 14:28:37 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <Ie3kToN5uD6pzPUXgjxdohqfi3dZvrNfx1U3Ogh-qhs=.cc1fdaab-8397-4e01-bb9f-79edb5efef8a@github.com>

Merges tag jdk-21.0.8+3

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

Commit messages:
 - 8316629: j.text.DateFormatSymbols setZoneStrings() exception is unhelpful
 - 8333117: Remove support of remote and manual debuggee launchers
 - 8267174: Many test files have the wrong Copyright header
 - 8310643: Misformatted copyright messages in FFM
 - 8210471: GZIPInputStream constructor could leak an un-end()ed Inflater
 - 8314319: LogCompilation doesn't reset lateInlining when it encounters a failure.
 - 8324345: Stack overflow during C2 compilation when splitting memory phi
 - 8315827: Kitchensink.java and RenaissanceStressTest.java  time out with jvmti module errors
 - 8312246: NPE when HSDB visits bad oop
 - 8313290: Misleading exception message from STS.Subtask::get when task forked after shutdown
 - ... and 20 more: https://git.openjdk.org/shenandoah-jdk21u/compare/96f7dbfd...38a356d3

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/194/files
  Stats: 9264 lines in 1002 files changed: 3496 ins; 3523 del; 2245 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/194.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/194/head:pull/194

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

From wkemper at openjdk.org  Thu May 15 18:14:43 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 May 2025 18:14:43 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <Ie3kToN5uD6pzPUXgjxdohqfi3dZvrNfx1U3Ogh-qhs=.cc1fdaab-8397-4e01-bb9f-79edb5efef8a@github.com>
References: <Ie3kToN5uD6pzPUXgjxdohqfi3dZvrNfx1U3Ogh-qhs=.cc1fdaab-8397-4e01-bb9f-79edb5efef8a@github.com>
Message-ID: <SyM06YTfGL2i_sJzYMwavUSjSCApB2Njn9plyqdfAeA=.a6052cf6-6f97-4f8d-bb69-9ac4d1857ccc@github.com>

> Merges tag jdk-21.0.8+3

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/194/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/194/files/38a356d3..38a356d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=194&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=194&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/194.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/194/head:pull/194

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

From wkemper at openjdk.org  Thu May 15 18:14:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 May 2025 18:14:46 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <Ie3kToN5uD6pzPUXgjxdohqfi3dZvrNfx1U3Ogh-qhs=.cc1fdaab-8397-4e01-bb9f-79edb5efef8a@github.com>
References: <Ie3kToN5uD6pzPUXgjxdohqfi3dZvrNfx1U3Ogh-qhs=.cc1fdaab-8397-4e01-bb9f-79edb5efef8a@github.com>
Message-ID: <7QBfmSccdrZV2467mbBeMC2yphUzfGX9371llBMGvlo=.873fe17c-0bb8-4a9b-b288-0132c30a1d3a@github.com>

On Thu, 15 May 2025 14:24:18 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.8+3

This pull request has now been integrated.

Changeset: bcbc7014
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/bcbc70140c8dda2bf0da1b020118365a5e8a7864
Stats:     9264 lines in 1002 files changed: 3496 ins; 3523 del; 2245 mod

Merge

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

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

From wkemper at openjdk.org  Fri May 16 17:34:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 May 2025 17:34:28 GMT
Subject: RFR: 8354078: Shenandoah: Make the generational mode be
 non-experimental (implementation)
Message-ID: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>

Testing:

% ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
openjdk 25 2025-09-16
OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)

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

Commit messages:
 - Make generational mode non-experimental

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

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

From sspitsyn at openjdk.org  Fri May 16 18:45:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:45:55 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>

On Wed, 14 May 2025 12:47:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

src/hotspot/share/runtime/threadHeapSampler.cpp line 399:

> 397:   assert(result > 0 && result < static_cast<double>(SIZE_MAX), "Result is not in an acceptable range.");
> 398:   size_t interval = static_cast<size_t>(result);
> 399:   _sample_threshold = interval;

Nit: The line 399 is not needed as the value is reset at 400.

src/hotspot/share/runtime/threadHeapSampler.hpp line 89:

> 87: 
> 88:     // Call this after _rnd is initialized to initialize _bytes_until_sample.
> 89:     pick_next_sample();

The old identifier is used: _bytes_until_sample.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093526227
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093523489

From sspitsyn at openjdk.org  Fri May 16 18:50:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:50:52 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <BVgcUFxoNDseh6iWTfm2dcFL36o4km8ehX1YLoRBLRM=.40898d89-05e3-48d8-a646-e2eccbceb9a2@github.com>

On Wed, 14 May 2025 12:47:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

src/hotspot/share/runtime/threadHeapSampler.hpp line 82:

> 80:       _tlab_top_at_sample_start(nullptr),
> 81:       _accumulated_tlab_bytes_since_sample(0),
> 82:       _accumulated_outside_tlab_bytes_since_sample(0) {

Nit: Would it make sense to initialize `_sample_threshold` as well to make it consistent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093531027

From sspitsyn at openjdk.org  Fri May 16 18:57:58 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 May 2025 18:57:58 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
Message-ID: <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>

On Wed, 14 May 2025 12:47:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

src/hotspot/share/runtime/threadHeapSampler.hpp line 92:

> 90:   }
> 91: 
> 92:   size_t bytes_since_last_sample(HeapWord* tlab_top) const {

Nit: I wonder if we can make names shorter with replacing:
  `bytes_since_last_sample` => `unsampled_bytes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2093538501

From ysr at openjdk.org  Fri May 16 23:44:52 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 May 2025 23:44:52 GMT
Subject: RFR: 8354078: Shenandoah: Make the generational mode be
 non-experimental (implementation)
In-Reply-To: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
References: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
Message-ID: <lrR2LnsB2Wooi8_1kMn8sFUbpJWejaKOXfKYffvvfmY=.2b69b460-36a4-4c11-85e6-dc21dbc04bc6@github.com>

On Fri, 16 May 2025 17:30:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Testing:
> 
> % ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
> OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)

Break out the production bubbly! ? 

Reviewed!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25270#pullrequestreview-2847770147

From ysr at openjdk.org  Fri May 16 23:50:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 May 2025 23:50:50 GMT
Subject: RFR: 8354078: Shenandoah: Make the generational mode be
 non-experimental (implementation)
In-Reply-To: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
References: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
Message-ID: <fJrqKhhuh2tUuuZW2tSMlCiRdRnuKWTmUGqq9SKzfDk=.496cf5f9-84d3-4355-9ab0-7208e7fc499d@github.com>

On Fri, 16 May 2025 17:30:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Testing:
> 
> % ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
> OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)

Just noticed that gc/shenandoah/options/TestModeUnlock.java needs to be taught that "generational" is no longer experimental. It's failing in the GHA tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25270#issuecomment-2887854018

From stefank at openjdk.org  Mon May 19 07:16:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 07:16:57 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
Message-ID: <9q7hRcm2nmf5OcESOgXafmZpvdqhZynStU7F5EKAMso=.ba487e7f-d681-45ef-968c-af6066f8163a@github.com>

On Fri, 16 May 2025 18:43:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>
> src/hotspot/share/runtime/threadHeapSampler.cpp line 399:
> 
>> 397:   assert(result > 0 && result < static_cast<double>(SIZE_MAX), "Result is not in an acceptable range.");
>> 398:   size_t interval = static_cast<size_t>(result);
>> 399:   _sample_threshold = interval;
> 
> Nit: The line 399 is not needed as the value is reset at 400.

Nice catch. This is debugging code from the early stage of this patch. It set up a consistent state to make it easier to get consistent data from the test runs. This also means that we need to respin our testing to make sure that the randomization doesn't trigger anything that we didn't catch with the fixed _sample_threshold.

> src/hotspot/share/runtime/threadHeapSampler.hpp line 82:
> 
>> 80:       _tlab_top_at_sample_start(nullptr),
>> 81:       _accumulated_tlab_bytes_since_sample(0),
>> 82:       _accumulated_outside_tlab_bytes_since_sample(0) {
> 
> Nit: Would it make sense to initialize `_sample_threshold` as well to make it consistent?

To me it makes sense. I didn't do it here because it gets initialized further down and I didn't want reviewers to get hung up on that change. But I'll take this as a go-ahead to make that change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2094996935
PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095001254

From stefank at openjdk.org  Mon May 19 07:24:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 07:24:56 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>
Message-ID: <yhU7wsM2AaOzrTf9Y2tqCKbibNgtdq0f8XZZHpWYs-k=.12520429-14e7-4305-8fef-eb253cbd8edd@github.com>

On Fri, 16 May 2025 18:54:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>
> src/hotspot/share/runtime/threadHeapSampler.hpp line 92:
> 
>> 90:   }
>> 91: 
>> 92:   size_t bytes_since_last_sample(HeapWord* tlab_top) const {
> 
> Nit: I wonder if we can make names shorter with replacing:
>   `bytes_since_last_sample` => `unsampled_bytes`

I had it like that but previous reviewers complained about the name. I made it longer to make sure that it is as clear as possible what this value is about. IMHO, one of the reasons why this code was hard to figure out why it was broken was because the names where not precise enough to explain what was stored in the variables.

Let me try to go the other way and completely remove the "unsampled" name. And then you can take a look and see if you really hate it and if you do I'll take a stab at finding some shorter names that still are descriptive for the casual reader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095012687

From stefank at openjdk.org  Mon May 19 08:28:45 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 08:28:45 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v4]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

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:

 - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
 - Tweak names
 - Fix sample threshold setup
 - Apply suggestions from code review
   
   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
 - Re-enable tests after merge
 - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
 - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/a318053e..dd6d8b4d

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

  Stats: 28120 lines in 704 files changed: 10509 ins; 13536 del; 4075 mod
  Patch: https://git.openjdk.org/jdk/pull/25114.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25114/head:pull/25114

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

From sspitsyn at openjdk.org  Mon May 19 09:28:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 09:28:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <yhU7wsM2AaOzrTf9Y2tqCKbibNgtdq0f8XZZHpWYs-k=.12520429-14e7-4305-8fef-eb253cbd8edd@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lUEUWm08Xo5NEHwUHEUJXo1yWvhsOfNuPk7R3G2O3ww=.c5979394-edcf-455e-89bd-1336857b5eff@github.com>
 <yhU7wsM2AaOzrTf9Y2tqCKbibNgtdq0f8XZZHpWYs-k=.12520429-14e7-4305-8fef-eb253cbd8edd@github.com>
Message-ID: <WTc3Tc0NS0u0maMaB1DwU398fs_3rt0lYHxn_SJw3bM=.fd13c38f-878d-4670-9513-de8433d222d2@github.com>

On Mon, 19 May 2025 07:22:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadHeapSampler.hpp line 92:
>> 
>>> 90:   }
>>> 91: 
>>> 92:   size_t bytes_since_last_sample(HeapWord* tlab_top) const {
>> 
>> Nit: I wonder if we can make names shorter with replacing:
>>   `bytes_since_last_sample` => `unsampled_bytes`
>
> I had it like that but previous reviewers complained about the name. I made it longer to make sure that it is as clear as possible what this value is about. IMHO, one of the reasons why this code was hard to figure out why it was broken was because the names where not precise enough to explain what was stored in the variables.
> 
> Let me try to go the other way and completely remove the "unsampled" name. And then you can take a look and see if you really hate it and if you do I'll take a stab at finding some shorter names that still are descriptive for the casual reader.

Okay, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095271858

From sspitsyn at openjdk.org  Mon May 19 09:36:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 09:36:52 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
Message-ID: <Er3hjHw4a4gmnbX92ZbUm3oz8S9E7f1WpjAuW2kxHE4=.80f36b9c-ecf6-4a92-9b41-afd9a747becd@github.com>

On Fri, 16 May 2025 18:41:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>
> src/hotspot/share/runtime/threadHeapSampler.hpp line 89:
> 
>> 87: 
>> 88:     // Call this after _rnd is initialized to initialize _bytes_until_sample.
>> 89:     pick_next_sample();
> 
> The old identifier is used: _bytes_until_sample.

This comment still need a fix as this name was removed by this fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095287505

From sspitsyn at openjdk.org  Mon May 19 09:43:56 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 09:43:56 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v4]
In-Reply-To: <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>
Message-ID: <vU1GGQ252mKW7Js9EFSGHZrU4ltSsg1Fa4m2DEB8Xvk=.1f9b182a-3fa1-4ab3-a83b-a3697c665869@github.com>

On Mon, 19 May 2025 08:28:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> 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:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>  - Tweak names
>  - Fix sample threshold setup
>  - Apply suggestions from code review
>    
>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>  - Re-enable tests after merge
>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>  - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Stefan, thank you for the update. The whole fix looks good in general. I like the refactoring.
One comment still need an update though as it has a removed/renamed field name.

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

PR Comment: https://git.openjdk.org/jdk/pull/25114#issuecomment-2890353605

From stefank at openjdk.org  Mon May 19 11:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:40:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v5]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/dd6d8b4d..ea0c8c7c

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

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

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

From stefank at openjdk.org  Mon May 19 11:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:40:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <9q7hRcm2nmf5OcESOgXafmZpvdqhZynStU7F5EKAMso=.ba487e7f-d681-45ef-968c-af6066f8163a@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
 <9q7hRcm2nmf5OcESOgXafmZpvdqhZynStU7F5EKAMso=.ba487e7f-d681-45ef-968c-af6066f8163a@github.com>
Message-ID: <Re1dZUeCELI5_A3XuixwKKcH5jWY8XdXtRX3XNQGMqg=.94cb1e92-9192-4204-8aa9-d16f562d0912@github.com>

On Mon, 19 May 2025 07:11:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadHeapSampler.cpp line 399:
>> 
>>> 397:   assert(result > 0 && result < static_cast<double>(SIZE_MAX), "Result is not in an acceptable range.");
>>> 398:   size_t interval = static_cast<size_t>(result);
>>> 399:   _sample_threshold = interval;
>> 
>> Nit: The line 399 is not needed as the value is reset at 400.
>
> Nice catch. This is debugging code from the early stage of this patch. It set up a consistent state to make it easier to get consistent data from the test runs. This also means that we need to respin our testing to make sure that the randomization doesn't trigger anything that we didn't catch with the fixed _sample_threshold.

The unit tests still pass after the fix for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095512240

From stefank at openjdk.org  Mon May 19 11:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:40:08 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v3]
In-Reply-To: <Er3hjHw4a4gmnbX92ZbUm3oz8S9E7f1WpjAuW2kxHE4=.80f36b9c-ecf6-4a92-9b41-afd9a747becd@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <QRPLTMB-q0AHPo2U7r4XIFQo3_QBJ7XN3rga2n78jzg=.e17f9305-759a-4d06-8f2d-0ab75b99248f@github.com>
 <lxfw_Iz8BCmWthXznAyKL51NETOCaZF3AOgGr-ZKT2I=.0819202d-54a6-473f-b218-b10e3e1e27f7@github.com>
 <Er3hjHw4a4gmnbX92ZbUm3oz8S9E7f1WpjAuW2kxHE4=.80f36b9c-ecf6-4a92-9b41-afd9a747becd@github.com>
Message-ID: <sCmXP1F3e_qhqkjo5PQxCZzGE07sVywGk2k5Tt102m0=.1d529f55-1ccb-4fb8-bed7-1bdb9a013bdf@github.com>

On Mon, 19 May 2025 09:34:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadHeapSampler.hpp line 89:
>> 
>>> 87: 
>>> 88:     // Call this after _rnd is initialized to initialize _bytes_until_sample.
>>> 89:     pick_next_sample();
>> 
>> The old identifier is used: _bytes_until_sample.
>
> The comment at line 89 still need a tweak as the name `_bytes_until_sample` is being removed by this fix.

Thanks! I've now updated the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2095510797

From stefank at openjdk.org  Mon May 19 11:44:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 May 2025 11:44:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v4]
In-Reply-To: <vU1GGQ252mKW7Js9EFSGHZrU4ltSsg1Fa4m2DEB8Xvk=.1f9b182a-3fa1-4ab3-a83b-a3697c665869@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <wJgL80EeSXuMdgI0KZHsMw7Ta8UUAmOuiyJtSehrobE=.28266832-66b6-43b6-b71b-087d10a5bf26@github.com>
 <vU1GGQ252mKW7Js9EFSGHZrU4ltSsg1Fa4m2DEB8Xvk=.1f9b182a-3fa1-4ab3-a83b-a3697c665869@github.com>
Message-ID: <WFWQzi3h5hVwBL6fkBqg6AxlC9ICtXfsfPwj7VIF5qg=.7c963345-0324-4881-ab2f-c7535ae99683@github.com>

On Mon, 19 May 2025 09:40:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 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:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>>  - Tweak names
>>  - Fix sample threshold setup
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>
>>  - Re-enable tests after merge
>>  - Merge remote-tracking branch 'upstream/master' into 8356372_thread_heap_sampler
>>  - 8356372: JVMTI heap sampling not working properly with outside TLAB allocations
>
> Stefan, thank you for the update. The whole fix looks good in general. I like the refactoring.
> One comment still need an update though as it has a removed/renamed field name.

Thanks, @sspitsyn! I think I've addressed all your comments now except making the names shorter. I hope that's OK and if we really want to shorten then, I don't mind doing it in a follow-up RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/25114#issuecomment-2890697415

From sspitsyn at openjdk.org  Mon May 19 14:52:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 19 May 2025 14:52:54 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v5]
In-Reply-To: <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
Message-ID: <8cfhMuruRD9FElCefMcCv672JxoDoCKFPkfKfylmZy4=.ae2a6901-275a-4405-a9a4-9597e1c7d168@github.com>

On Mon, 19 May 2025 11:40:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Looks good. Thank you for the update!
I'm okay with current naming. Consistency is more important than shortness.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2851051486

From rkennke at openjdk.org  Mon May 19 15:30:53 2025
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 19 May 2025 15:30:53 GMT
Subject: RFR: 8354078: Shenandoah: Make the generational mode be
 non-experimental (implementation)
In-Reply-To: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
References: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
Message-ID: <iTfbtsVDx9Q0tmal_yFipUdkUtKK4vBWKtFOuwNShZc=.8acc58d9-2ef2-4a4d-b2fd-e072ec725988@github.com>

On Fri, 16 May 2025 17:30:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Testing:
> 
> % ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
> OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)

Many tests specify `-XX:+UseExperimentalVMOptions` to be able to use generational mode. Those `-XX:+UseExperimentalVMOptions` should be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25270#issuecomment-2891447874

From wkemper at openjdk.org  Mon May 19 17:30:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 May 2025 17:30:35 GMT
Subject: RFR: 8354078: Shenandoah: Make the generational mode be
 non-experimental (implementation) [v2]
In-Reply-To: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
References: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
Message-ID: <dUTHXukBDOUd8vscUX4z6J-feUeKGaXiigNgiB8WvzU=.8deb0107-d292-4320-ae7d-0fce8f1a938c@github.com>

> Testing:
> 
> % ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
> OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Update test asserting that generational mode is experimental

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25270/files
  - new: https://git.openjdk.org/jdk/pull/25270/files/719126e6..198fb3ba

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

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

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

From ysr at openjdk.org  Mon May 19 23:20:53 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 19 May 2025 23:20:53 GMT
Subject: RFR: 8354078: Implement JEP 521: Generational Shenandoah [v2]
In-Reply-To: <dUTHXukBDOUd8vscUX4z6J-feUeKGaXiigNgiB8WvzU=.8deb0107-d292-4320-ae7d-0fce8f1a938c@github.com>
References: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
 <dUTHXukBDOUd8vscUX4z6J-feUeKGaXiigNgiB8WvzU=.8deb0107-d292-4320-ae7d-0fce8f1a938c@github.com>
Message-ID: <Yyj3sgVjJwjjgbCR3BEUkrzuTX6Nz5NJuRYWf762hxE=.da235917-cb73-48b6-ac1a-6651f1640e0f@github.com>

On Mon, 19 May 2025 17:30:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Testing:
>> 
>> % ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
>> openjdk 25 2025-09-16
>> OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
>> OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test asserting that generational mode is experimental

Looks good, thanks!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25270#pullrequestreview-2852164466

From sjohanss at openjdk.org  Tue May 20 06:27:53 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 20 May 2025 06:27:53 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v5]
In-Reply-To: <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <EQjy1slJNAF8v7sgF2s727Hwvdb2NsUxYycPXtILC_Q=.7f2c2e7c-8316-4f36-bcad-7af09b0c214f@github.com>
Message-ID: <HA4_0k1Pnjx81E9mBkXbS6SjBRSsS6ap_C8kJeDHOOA=.00647189-6a9f-466d-9b0c-7f9ffb0941e8@github.com>

On Mon, 19 May 2025 11:40:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

src/hotspot/share/runtime/threadHeapSampler.cpp line 423:

> 421:   if (log.is_enabled()) {
> 422:     const bool should_sample = bytes_since_last_sample(tlab_top) >= _sample_threshold;
> 423:     log_debug(gc, tlab)("Should sample: %s _sample_threshold: %zu total: %zu tlab: %zu current tlab: %zu outside_tlab: %zu",

Suggestion:

    log_debug(gc, tlab)("Should sample: %s _sample_threshold: %zu total: %zu tlab: %zu current tlab: %zu outside tlab: %zu",

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25114#discussion_r2097025408

From stefank at openjdk.org  Tue May 20 07:14:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 May 2025 07:14:39 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/threadHeapSampler.cpp
  
  Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25114/files
  - new: https://git.openjdk.org/jdk/pull/25114/files/ea0c8c7c..aa006f98

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

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

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

From sjohanss at openjdk.org  Tue May 20 07:14:39 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 20 May 2025 07:14:39 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
Message-ID: <3vaduHUfzw_A9KmpHmEIJ0Eqow6G_g6goUIhJZVX5Fc=.ee325778-f05e-4a84-8543-138522a242de@github.com>

On Tue, 20 May 2025 07:10:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/threadHeapSampler.cpp
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2852945669

From sspitsyn at openjdk.org  Tue May 20 10:58:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 20 May 2025 10:58:00 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
Message-ID: <UGatIBNvFwqKXwVXv0dXK8ZRdkSZCQGjhK0_ZqTqkTc=.2d6bac35-29c5-4d76-a991-ae757df14f8b@github.com>

On Tue, 20 May 2025 07:14:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/threadHeapSampler.cpp
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2853704891

From stefank at openjdk.org  Tue May 20 13:49:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 May 2025 13:49:02 GMT
Subject: RFR: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations [v6]
In-Reply-To: <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
 <m5fVmheS1FbEjj_j2LUKpqjv50WbkePhS6k6Fsc97Y0=.60a15aff-38e4-4d90-bc9e-19910761d986@github.com>
Message-ID: <-8tAtM1OKthqHMXlA7TgOsh6RCz5dGvSHgpscyhhCpo=.25653274-38ff-4517-ba7a-eac23d801a85@github.com>

On Tue, 20 May 2025 07:14:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
>> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
>> 
>> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
>> 
>> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
>> 
>> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
>> 
>> The idea is to better account how much we have allocated in three different buckets:
>> * Outside of TLAB allocations
>> * Accounted TLAB allocations
>> * The last bit of TLAB allocations that hasn't been accounted yet
>> 
>> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
>> 
>> There are a few things to think about when reading this code:
>> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
>> * The sampling can take multiple samples in a single TLAB
>> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
>> 
>> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
>> 
>> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
>> 2) Moved thread allocation accounting and sampling code out of the TLAB
>> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
>> 
>> Some of that could be extracted into a separate PR if that's deemed worthwhile.
>> 
>> Tested with the HeapMonitor tests various TLAB sizes.
>> 
>> If there are anyone using these APIs it would be nice to get feedba...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/runtime/threadHeapSampler.cpp
>   
>   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Thanks for the reviews! If final testing passes I plan to integrate tomorrow (unless new reviewers show up).

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

PR Review: https://git.openjdk.org/jdk/pull/25114#pullrequestreview-2854266934

From kdnilsen at openjdk.org  Wed May 21 16:08:05 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 May 2025 16:08:05 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and old
Message-ID: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@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:+UnlockExperimentalVMOptions \
                -XX:-ShenandoahPacing \
                -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms$s -Xmx$s \
                -XX:ShenandoahMinimumOldTimeMs=25 \
                -XX:ShenandoahFullGCThreshold=1024 \
                -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
                -Xlog:"gc*=info,ergo" \
                -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \
                -XX:+UnlockDiagnosticVMOptions \
                -jar ~/github/heapothesys/Extremem/src/main/java/extremem.jar \
                -dInitializationDelay=45s \
                -dDictionarySize=3000000 \
                -dNumCustomers=300000 \
                -dNumProducts=60000 \
                -dCustomerThreads=500 \
                -dCustomerPeriod=7s \
                -dCustomerThinkTime=1s \
                -dKeywordSearchCount=4 \
                -dServerThreads=5 \
                -dServerPeriod=5s \
                -dProductNameLength=10 \
                -dBrowsingHistoryQueueCount=5 \
                -dSalesTransactionQueueCount=5 \
                -dProductDescriptionLength=32 \
                -dProductReplacementPeriod=25s \
                -dProductReplacementCount=10 \
                -dCustomerReplacementPeriod=30s \
                -dCustomerReplacementCount=1000 \
                -dBrowsingExpiration=1m \
                -dPhasedUpdates=true \
                -dPhasedUpdateInterval=90s \
                -dSimulationDuration=25m \
                -dResponseTimeMeasurements=100000 \
                >$t.genshen.share-reserves.$r-evac-ratio.$s.out 2>$t.genshen.share-reserves.$r-evac-ratio.$s.err
            gzip $t.genshen.share-reserves.$r-evac-ratio.$s.out $t.genshen.share-reserves.$r-evac-ratio.$s.err



We have tested this patch through our performance pipeline.  Both aarch64 and x86 show similar results, a small increase in concurrent evacuation on the graphchi benchmark, with slight improvements of other metrics on a number of other test workloads:


Genshen aarch64
-------------------------------------------------------------------------------------------------------
+16.35% graphchi/concurrent_evacuation p=0.00000
  Control:      1.895ms (+/-392.33us)        306
  Test:         2.205ms (+/-401.72us)        124

-33.43% specjbb2015/concurrent_marking_old p=0.00213
  Control:    513.923ms (+/-225.22ms)        338
  Test:       385.169ms (+/-231.25ms)         38

-28.58% specjbb2015/cm_parallel_mark_old p=0.00833
  Control:      1.022s  (+/-446.83ms)        333
  Test:       794.476ms (+/-440.83ms)         35

-25.31% crypto.aes/shenandoahfinalupdaterefs_stopped p=0.00000
  Control:      0.113ms (+/-  0.01ms)        285
  Test:         0.090ms (+/-  0.02ms)        158

-18.52% scimark.fft.small/shenandoahfinalupdaterefs_stopped p=0.00000
  Control:      0.106ms (+/-  0.01ms)        474
  Test:         0.090ms (+/-  0.01ms)        180

-15.29% hyperalloc_a3072_o2048/concurrent_marking_old p=0.00103
  Control:    384.599ms (+/- 76.47ms)        277
  Test:       333.581ms (+/- 89.51ms)         55

-15.28% hyperalloc_a3072_o2048/cm_total_old p=0.00105
  Control:    768.676ms (+/-152.94ms)        277
  Test:       666.786ms (+/-178.97ms)         55

-15.28% hyperalloc_a3072_o2048/cm_parallel_mark_old p=0.00105
  Control:    768.676ms (+/-152.94ms)        277
  Test:       666.786ms (+/-178.97ms)         55


Shenandoah aarch64
-------------------------------------------------------------------------------------------------------
-12.07% extremem-phased/update_references p=0.00050
  Control:    479.826ms (+/- 52.78ms)         23
  Test:       428.148ms (+/-  2.26ms)          3




Genshen x86
-------------------------------------------------------------------------------------------------------
+16.35% graphchi/concurrent_evacuation p=0.00000
  Control:      1.895ms (+/-392.33us)        306
  Test:         2.205ms (+/-401.72us)        124

-33.43% specjbb2015/concurrent_marking_old p=0.00213
  Control:    513.923ms (+/-225.22ms)        338
  Test:       385.169ms (+/-231.25ms)         38

-28.58% specjbb2015/cm_parallel_mark_old p=0.00833
  Control:      1.022s  (+/-446.83ms)        333
  Test:       794.476ms (+/-440.83ms)         35

-25.31% crypto.aes/shenandoahfinalupdaterefs_stopped p=0.00000
  Control:      0.113ms (+/-  0.01ms)        285
  Test:         0.090ms (+/-  0.02ms)        158

-18.52% scimark.fft.small/shenandoahfinalupdaterefs_stopped p=0.00000
  Control:      0.106ms (+/-  0.01ms)        474
  Test:         0.090ms (+/-  0.01ms)        180

-15.29% hyperalloc_a3072_o2048/concurrent_marking_old p=0.00103
  Control:    384.599ms (+/- 76.47ms)        277
  Test:       333.581ms (+/- 89.51ms)         55

-15.28% hyperalloc_a3072_o2048/cm_total_old p=0.00105
  Control:    768.676ms (+/-152.94ms)        277
  Test:       666.786ms (+/-178.97ms)         55

-15.28% hyperalloc_a3072_o2048/cm_parallel_mark_old p=0.00105
  Control:    768.676ms (+/-152.94ms)        277
  Test:       666.786ms (+/-178.97ms)         55


Shenandoah x86
-------------------------------------------------------------------------------------------------------
-12.07% extremem-phased/update_references p=0.00050
  Control:    479.826ms (+/- 52.78ms)         23
  Test:       428.148ms (+/-  2.26ms)          3

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

Commit messages:
 - 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
 - Change fullgc phase5 return type
 - compute_old_generation_balance needs available computations under lock
 - Merge branch 'share-collector-reserves' of https://github.com/kdnilsen/jdk into share-collector-reserves
 - Fixup bugs introduced by most recent commit
 - Improve empty region accounting in FreeSet
 - Revert "Acquire heaplock before adjusting interval for old"
 - ... and 24 more: https://git.openjdk.org/jdk/compare/6162e2c5...3d55a646

Changes: https://git.openjdk.org/jdk/pull/25357/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25357&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357471
  Stats: 1354 lines in 28 files changed: 781 ins; 333 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 wkemper at openjdk.org  Wed May 21 18:37:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 May 2025 18:37:54 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old
In-Reply-To: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
Message-ID: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>

On Wed, 21 May 2025 15:29:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> 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...

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 193:

> 191:   const size_t new_size = old_gen->max_capacity();
> 192:   log_info(gc, ergo)("Forcing transfer of %zu region(s) from %s to %s, yielding increased size: " PROPERFMT,
> 193:                      regions, young_gen->name(), old_gen->name(), PROPERFMTARGS(new_size));

If this is now really only used for in-place promotions, can we change the log message to indicate the region is being promoted? I think when users see messages about things being "forced" in the log, they start to wonder if young/old sizes need to adjusted.

src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 206:

> 204:   old_gen->decrease_capacity(bytes_to_transfer);
> 205:   const size_t new_size = young_gen->max_capacity();
> 206:   log_info(gc)("Forcing transfer of %zu region(s) from %s to %s, yielding increased size: " PROPERFMT,

Can this be `gc, ergo` like the method to transfer regions to old?

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 298:

> 296:     if (copy == nullptr) {
> 297:       // If we failed to allocate in LAB, we'll try a shared allocation.
> 298: #ifdef KELVIN_ORIGINAL

This looks like debugging code? Should we back this out?

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 149:

> 147: 
> 148:   // Transfers surplus old regions to young, or takes regions from young to satisfy old region deficit
> 149:   TransferResult balance_generations();

Are we still using this `TransferResult` thing? Seems like we might be able to delete it with this change.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1670:

> 1668: 
> 1669:   if (mode()->is_generational()) {
> 1670:     // young-gen heuristics track young, bootstrap, and global GC cycle times

This seems like an unrelated change. Mixing in bootstrap and global gc cycle times is likely to increase the average time and make the heuristics more aggressive.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 279:

> 277:   static size_t setup_sizes(size_t max_heap_size);
> 278: 
> 279:   inline bool is_recycling() {

Is this used anywhere?

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 376:

> 374:           "runs out of memory too early.")                                  \
> 375:                                                                             \
> 376:   product(uintx, ShenandoahOldEvacRatioPercent, 75, EXPERIMENTAL,           \

Phew, this is a lot of explanatory text and it reads like the target audience are GC developers. If we are going to expose this as a user configurable option, I think the help text should just explain how the behavior changes as this values goes up or down.  Something like:
> Increasing this allows for more old regions in mixed collections. Decreasing this reduces the number of old regions in mixed collections. 

The first sentence makes it seem as though this is the percentage of the entire heap to reserve for old evacuations, but the next clarifies that this is the percentage of the collection set.

Question about this sentence:
> A value of 100 allows a mixed evacuation to focus entirely on old-gen memory, allowing no young-gen regions to be collected.

With a setting of 100, would GenShen still "preselect" young regions of tenuring age with sufficient garbage into the collection set?

 I also find the name of the option slightly confusing - is it a ratio? or a percentage? Seems like it's really a percentage (though it controls the ratio of reserves used for the collection).

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

PR Review: https://git.openjdk.org/jdk/pull/25357#pullrequestreview-2858665038
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100871366
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100868280
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100879212
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100931112
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100887452
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100894053
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2100926884

From stefank at openjdk.org  Thu May 22 06:43:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 May 2025 06:43:02 GMT
Subject: Integrated: 8356372: JVMTI heap sampling not working properly with
 outside TLAB allocations
In-Reply-To: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
References: <uHYl6FBt2o0N6pLyS9_6vb_XrHad-3wxH7F1BAg1TLs=.f14a0fc4-5d14-4034-a063-1bdefeb75336@github.com>
Message-ID: <1K72xS65DDQdoYYsq8qF8jRD81puFZcvLijmNfze6GM=.e20e4213-17c9-48b3-bafe-0aba62b966af@github.com>

On Thu, 8 May 2025 10:01:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While working on improving the TLAB sizing code for ZGC @kstefanj ran into an issue with the following tests failing:
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorInterpreterObjectTest.java
> serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java
> 
> The reason for seeing the problems now is that with the new sizing code ZGC used smaller TLABs at first, before resizing them to a proper size (to lower the waste). In the HeapMonitor tests we don't allocate enough to trigger GCs that will resize the TLABs so most of the tests will now run with small TLABs. This should not be a problem, but it turns out the current sampling code is not working properly when you get a lot of outside TLAB allocations. You get those when trying to allocate a fairly large object (~1400B) that won't fit into the TLAB, but there are still quite a bit of room in the TLAB so we don't want to throw it away and take a new one.
> 
> The problem in the current code is that we keep track of when to sample with multiple variables and when getting out of TLAB allocations these get out of sync.
> 
> The proposed patch is the result of a restructuring and fixing of the the code that me and @kstefanj did to fix this issue.
> 
> The idea is to better account how much we have allocated in three different buckets:
> * Outside of TLAB allocations
> * Accounted TLAB allocations
> * The last bit of TLAB allocations that hasn't been accounted yet
> 
> And then use the sum of that to compare against a *non-changing* threshold to see if it is time to take a sample.
> 
> There are a few things to think about when reading this code:
> * The thread can allocate and retire multiple TLABs before we cross the sample threshold.
> * The sampling can take multiple samples in a single TLAB
> * Any overshooting of the sample threshold triggers only one sample and the extra bytes are ignored when checking for the next sample.
> 
> There are some restructuring in the patch to confine the ThreadHeapSampler variables and code. For example:
> 
> 1) Moved accounting variables out of TLAB and into the ThreadHeapSampler
> 2) Moved thread allocation accounting and sampling code out of the TLAB
> 3) Moved retiring of TLABs out of make_parseable (needed to support (2))
> 
> Some of that could be extracted into a separate PR if that's deemed worthwhile.
> 
> Tested with the HeapMonitor tests various TLAB sizes.
> 
> If there are anyone using these APIs it would be nice to get feedback if these changes work well for you.

This pull request has now been integrated.

Changeset: a919f6d0
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a919f6d04e5e1e3ccb123132ad945b240345dcaf
Stats:     229 lines in 15 files changed: 136 ins; 45 del; 48 mod

8356372: JVMTI heap sampling not working properly with outside TLAB allocations

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: sjohanss, sspitsyn

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

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

From stefank at openjdk.org  Thu May 22 12:41:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 May 2025 12:41:03 GMT
Subject: RFR: 8357563: Shenandoah headers leak un-prefixed defines
Message-ID: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>

We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.

This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

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

Commit messages:
 - 8357563: Shenandoah headers leak un-prefixed defines

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

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

From wkemper at openjdk.org  Thu May 22 14:27:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 May 2025 14:27:26 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <5bqnzzRuDfBwUUWDu3NozDu_HqwZF7h_WO0kL6IXoBM=.9a3cfd0e-af7d-42f5-a4d9-2c4fce93ed96@github.com>

Merges tag jdk-21.0.8+4

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

Commit messages:
 - 8297692: Avoid sending per-region GCPhaseParallel JFR events in G1ScanCollectionSetRegionClosure
 - 8352908: Open source several swing tests batch1
 - 8353475: Open source two Swing DefaultCaret tests
 - 8352684: Opensource JInternalFrame tests - series1
 - 8353320: Open source more Swing text tests
 - 8352680: Opensource few misc swing tests
 - 8352676: Opensource JMenu tests - series1
 - 8350383: Test: add more test case for string compare (UL case)
 - 8345547: test/jdk/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java fails in ubuntu22.04
 - 8345447: test/jdk/javax/swing/JToolBar/4529206/bug4529206.java fails in ubuntu22.04
 - ... and 21 more: https://git.openjdk.org/shenandoah-jdk21u/compare/38a356d3...a1e58917

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/195/files
  Stats: 12088 lines in 819 files changed: 2987 ins; 162 del; 8939 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/195.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/195/head:pull/195

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

From shade at openjdk.org  Thu May 22 14:56:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 14:56:54 GMT
Subject: RFR: 8357563: Shenandoah headers leak un-prefixed defines
In-Reply-To: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
References: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
Message-ID: <jD3aKcFx_E1pJbMp885Foc50SMdm5N2tST0E1GpeNCU=.5f2d6f40-92c5-4717-855f-0fee9458427c@github.com>

On Thu, 22 May 2025 12:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.
> 
> This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

Yes, this is fine. These should never have been in global scope, especially in the header that can easily be transitively included.

Actually, I would question even the type-casted triad, and probably a single constant would instead do. Leave it to a follow-up, if present problem blocks current development.

@kdnilsen @earthling-amzn ^

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25392#pullrequestreview-2861568514
PR Comment: https://git.openjdk.org/jdk/pull/25392#issuecomment-2901536748

From stefank at openjdk.org  Thu May 22 15:07:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 22 May 2025 15:07:54 GMT
Subject: RFR: 8357563: Shenandoah headers leak un-prefixed defines
In-Reply-To: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
References: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
Message-ID: <yn_enXbAeSWqoB0mwMfJcnLCn9Zcj9LbSCvdOWXRPMg=.93cb9fc6-325f-419d-aa84-cf192dd32166@github.com>

On Thu, 22 May 2025 12:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.
> 
> This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

FWIW, this doesn't block us, it just requires us to use a name that doesn't follow our naming convention, so if you have a better solution I'm OK with waiting for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25392#issuecomment-2901575076

From shade at openjdk.org  Thu May 22 15:16:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 May 2025 15:16:59 GMT
Subject: RFR: 8357563: Shenandoah headers leak un-prefixed defines
In-Reply-To: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
References: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
Message-ID: <ZBvhA-X5y4DgdwNZZB_H2oChYEJMHrDtOHS3ABD2wgM=.4fd3fc5e-4835-4c49-9dbf-10afc28c3a1f@github.com>

On Thu, 22 May 2025 12:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.
> 
> This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

Nah, current version is fine. Folding this triad into a single constant would likely require dealing with signed-unsigned comparisons, casts back to enums, all that jazz. This would be a good starter task for our engineers.

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

PR Comment: https://git.openjdk.org/jdk/pull/25392#issuecomment-2901614463

From kdnilsen at openjdk.org  Thu May 22 15:44:04 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 May 2025 15:44:04 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v7]
In-Reply-To: <HXNF6hxgCjc3g--Y3_b7vEo4NiD6HIMgzRiOAxFnD2U=.dcc78d5f-de84-4b35-b981-f1599cb1b4cb@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
 <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
 <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>
 <pVyMRahOQ3bMqUDlAxwRe5g9Z8My24aa0rd9pUY0O9c=.e1f34a16-ecb1-45e6-8725-55be8aedadca@github.com>
 <FUycnkJKlZt9tpL9vUhDhQA-tHhDWFaRd8-j4P3Aoug=.42f1f1d9-aa0c-4dfe-848d-8d83f7693002@github.com>
 <xzNt9J87ZmqYN1NP67CtNeAigj7h-PwDPKL3BOLAArU=.2ccb444f-b643-4cde-b451-f0cc2a827316@github.com>
 <HXNF6hxgCjc3g--Y3_b7vEo4NiD6HIMgzRiOAxFnD2U=.dcc78d5f-de84-4b35-b981-f1599cb1b4cb@github.com>
Message-ID: <whE3yeagahHqtkdscw2iXcKGUjJCrfsvrP8w2FFcssM=.881d643a-3e92-4255-9bd6-31ceaa118de4@github.com>

On Mon, 14 Apr 2025 16:38:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> i suspect performance impact is minimal.
>
> I've committed changes that endeavor to implement the suggested refactor.  Performance impact does appear to be minimal.  This broader refactoring does change behavior slightly.  In particular:
> 
> 1. We now have a better understanding of live-memory evacuated during mixed evacuations.  This allows the selection of old-candidates for mixed evacuations to be more conservative.  We'll have fewer old regions in order to honor the intended budget.
> 2. Potentially, this will result in more mixed evacuations, but each mixed evacuation should take less time.
> 3. There should be no impact on behavior of traditional Shenandoah.
> 
> On one recently completed test run, we observed the following impacts compared to tip:
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +80.69% specjbb2015/trigger_failure p=0.00000
>   Control:     58.250   (+/- 13.48  )        110
>   Test:       105.250   (+/- 33.13  )         30
> 
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> -19.46% jme/context_switch_count p=0.00176
>   Control:    117.420   (+/- 28.01  )        108
>   Test:        98.292   (+/- 32.76  )         30
> 
> Perhaps we need more data to decide whether this is "significant".

This result seems to be consistent.  The effect on traditional Shenandoah is apparently to reduce the size of traditional Shenandoah collection sets also because certain regions that would have been collected are now rejected due to "better awareness" of how much live data will need to be copied.  The amount of garbage associated with candidate regions for the young collection set is reduced by the amount of allocations above TAMS. 
 Previously, this had been erroneously reported as garbage.  This has the effect of delaying reclamation of some garbage, resulting in an increase in allocation failures on the specjbb 2025 workload.

We might argue that the original behavior was incorrect, in that it was allowing violation of the intended evacuation budget.

We apparently were getting away with this violation because we were able to flip mutator regions to collector space, and/or because evacuation waste was sufficient to accommodate the unbudgeted evacuations.

Now that we have more accurate accounting of live memory, we could perhaps slightly reduce the default evacuation waste budget if we want to claw back the losses in specjbb performance (to enable larger collection sets) as part of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2102870209

From wkemper at openjdk.org  Thu May 22 17:37:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 May 2025 17:37:56 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <5bqnzzRuDfBwUUWDu3NozDu_HqwZF7h_WO0kL6IXoBM=.9a3cfd0e-af7d-42f5-a4d9-2c4fce93ed96@github.com>
References: <5bqnzzRuDfBwUUWDu3NozDu_HqwZF7h_WO0kL6IXoBM=.9a3cfd0e-af7d-42f5-a4d9-2c4fce93ed96@github.com>
Message-ID: <1kFHgYcHt6LVV88dsQF7PgdYlF9_reWawIV02r7beEE=.28d8a72b-f2cb-44aa-951a-ee7a400b816a@github.com>

> Merges tag jdk-21.0.8+4

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/195/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/195/files/a1e58917..a1e58917

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=195&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=195&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/195.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/195/head:pull/195

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

From wkemper at openjdk.org  Thu May 22 17:37:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 May 2025 17:37:56 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <5bqnzzRuDfBwUUWDu3NozDu_HqwZF7h_WO0kL6IXoBM=.9a3cfd0e-af7d-42f5-a4d9-2c4fce93ed96@github.com>
References: <5bqnzzRuDfBwUUWDu3NozDu_HqwZF7h_WO0kL6IXoBM=.9a3cfd0e-af7d-42f5-a4d9-2c4fce93ed96@github.com>
Message-ID: <GtMUcXjdwXg5SHNamJsb7Z-1pMUdLHNFDIbC-vNdrQ8=.a7a05c7d-7f3a-4a92-9079-8b5ba46777c3@github.com>

On Thu, 22 May 2025 14:23:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.8+4

This pull request has now been integrated.

Changeset: 84c15d75
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/84c15d75aa3f4f021e8828192a5536852d3dac5b
Stats:     12088 lines in 819 files changed: 2987 ins; 162 del; 8939 mod

Merge

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

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

From xpeng at openjdk.org  Fri May 23 01:14:05 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 23 May 2025 01:14:05 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v2]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <CxdEkFc7kiZ8TXIV41H0YmDdBMnZ6SYNFh2YOL-LT8Y=.b54c5070-2664-4e1d-9d88-fcaebaca19fd@github.com>

> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
> 
> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
> 
> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
> 
> ### Test
> - [x] Test and verify the termination events in jfr for G1, Shenandoah and Parallel GC.
> - [x] Tier 1
> - [x] Tier 2

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Patch to fix the PR concerns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24676/files
  - new: https://git.openjdk.org/jdk/pull/24676/files/7b1412f3..e362b7cc

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

  Stats: 65 lines in 7 files changed: 23 ins; 24 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676

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

From xpeng at openjdk.org  Fri May 23 06:09:38 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 23 May 2025 06:09:38 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v3]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <uViJGKRO3Mqlt6nTo5DP8Rn9va88zr0AyO_de50T-0Y=.c145059e-c2a2-4d7a-b9fa-5e23591ea871@github.com>

> The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks.
> 
> Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. 
> 
> By adding this, it gives performance engineers the visibility to the termination attempts and  termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue.
> 
> ### Test
> - [x] Test and verify the termination events in jfr for G1, Shenandoah and Parallel GC.
> - [x] Tier 1
> - [x] Tier 2

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

 - Merge branch 'master' into JDK-8354555
 - Patch to fix the PR concerns
 - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask
 - Add include "workerThread.hpp"
 - Touch up
 - Move TERMINATION_EVENT_NAME_PREFIX_ASSERT to taskTerminator.cpp
 - Fix ident
 - termination_event_name must have prefix "Termination"
 - Override termination event name for remark
 - Address PR comments
 - ... and 17 more: https://git.openjdk.org/jdk/compare/9d9e41f5...5ab1c5fc

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

Changes: https://git.openjdk.org/jdk/pull/24676/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24676&range=02
  Stats: 86 lines in 9 files changed: 65 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676

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

From kbarrett at openjdk.org  Fri May 23 08:26:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 23 May 2025 08:26:53 GMT
Subject: RFR: 8357563: Shenandoah headers leak un-prefixed defines
In-Reply-To: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
References: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
Message-ID: <5Oe187YfD1o0YVwumXL2aQsmvn0YaHaJLZF9bd2P2OM=.c701cb36-5f92-4022-b66e-34053988a0e9@github.com>

On Thu, 22 May 2025 12:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.
> 
> This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25392#pullrequestreview-2863632272

From stefank at openjdk.org  Fri May 23 09:44:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 23 May 2025 09:44:55 GMT
Subject: RFR: 8357563: Shenandoah headers leak un-prefixed defines
In-Reply-To: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
References: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
Message-ID: <eq9wkFA2c_Gbvr4wOu-A6fFGdCRPjMHVEqfRMsfevKs=.a4b2d5fd-8777-4ef5-bd73-0d7b052edeab@github.com>

On Thu, 22 May 2025 12:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.
> 
> This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

Thanks for reviewing! I'll go ahead and integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25392#issuecomment-2903875809

From stefank at openjdk.org  Fri May 23 09:44:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 23 May 2025 09:44:56 GMT
Subject: Integrated: 8357563: Shenandoah headers leak un-prefixed defines
In-Reply-To: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
References: <UJCzQQwaGTqkxmz66hwzPb3XFn2QOtZ7clRKeK91Xa0=.ad123b36-dbab-478a-9fa1-e34cfda856be@github.com>
Message-ID: <6DX_5lovjExqU4gFkqwy6kviSfid6VxJZFbxnQkpYzQ=.3658b682-2ca5-4d35-b46d-b793428b5384@github.com>

On Thu, 22 May 2025 12:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We hit a compilation error in ZGC when we defined a constant NumPartitions. This happened because there is a define name NumPartitions inside shenandoahFreeSet.hpp. I propose that this (and its friends) are hid inside the ShenandoahRegionPartitions class, which is the only user of these defines. An alternative would be to prefix the define with something that is unlikely to clash with other parts of HotSpot.
> 
> This PR is my suggestion for a change to solve this so this name conflict. Does this seem like an acceptable solution, or do you want something else? Thanks!

This pull request has now been integrated.

Changeset: 68ee06f0
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68ee06f0c9ec420cb1a60e0b361971372b18b82b
Stats:     12 lines in 1 file changed: 6 ins; 6 del; 0 mod

8357563: Shenandoah headers leak un-prefixed defines

Reviewed-by: shade, kbarrett

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

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

From kdnilsen at openjdk.org  Fri May 23 16:05:58 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 16:05:58 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old
In-Reply-To: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
Message-ID: <tIUo7UyVxJ9KE0EBbwCEYkEADO9-hRap5r_RacZEHes=.ac8c2d3d-ea7a-476d-af50-d46e5ebce9dc@github.com>

On Wed, 21 May 2025 18:05:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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/jd...
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1670:
> 
>> 1668: 
>> 1669:   if (mode()->is_generational()) {
>> 1670:     // young-gen heuristics track young, bootstrap, and global GC cycle times
> 
> This seems like an unrelated change. Mixing in bootstrap and global gc cycle times is likely to increase the average time and make the heuristics more aggressive.

Good catch. I will remove this code from this PR.  (It will come back in a subsequent PR, to support adaptive old evac ratios.  There, we consolidate the accounting for all gc in the "young heuristics", but we parameterize each phase so as to not bias triggering.  Marking phase time is parameterized with bytes marked, for example,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2104904914

From kdnilsen at openjdk.org  Fri May 23 16:37:57 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 16:37:57 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old
In-Reply-To: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
Message-ID: <X5LV-WMEAaoo0WiRSyI3Cz1ddpwBGqs1CRY2flYp-04=.876e309b-bebf-47e9-bb76-94f9285a66d0@github.com>

On Wed, 21 May 2025 17:54:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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/jd...
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 206:
> 
>> 204:   old_gen->decrease_capacity(bytes_to_transfer);
>> 205:   const size_t new_size = young_gen->max_capacity();
>> 206:   log_info(gc)("Forcing transfer of %zu region(s) from %s to %s, yielding increased size: " PROPERFMT,
> 
> Can this be `gc, ergo` like the method to transfer regions to old?

Agreed.  Making this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2104996772

From xpeng at openjdk.org  Fri May 23 17:05:08 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 23 May 2025 17:05:08 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v4]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <jq238ILSRC3BhzcNIIatNHhUazuyTMoxmk9dolXwipQ=.e26d373e-059c-45ba-b841-a4f7a0209356@github.com>

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

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Fix jft test failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24676/files
  - new: https://git.openjdk.org/jdk/pull/24676/files/5ab1c5fc..fe671499

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

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

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

From xpeng at openjdk.org  Fri May 23 17:18:06 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 23 May 2025 17:18:06 GMT
Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v5]
In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com>
Message-ID: <O3NyHlH9Ql_ElwuS5MdOhc3BqL45ACIJAxpa6OWBIYs=.0013d650-eb12-4c2b-a8fb-9a77a801368c@github.com>

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

Xiaolong Peng 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 branch 'openjdk:master' into JDK-8354555
 - Fix jft test failure
 - Merge branch 'master' into JDK-8354555
 - Patch to fix the PR concerns
 - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask
 - Add include "workerThread.hpp"
 - Touch up
 - Move TERMINATION_EVENT_NAME_PREFIX_ASSERT to taskTerminator.cpp
 - Fix ident
 - termination_event_name must have prefix "Termination"
 - ... and 19 more: https://git.openjdk.org/jdk/compare/917c1546...17e3255a

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

Changes: https://git.openjdk.org/jdk/pull/24676/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24676&range=04
  Stats: 90 lines in 10 files changed: 68 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24676.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676

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

From kdnilsen at openjdk.org  Fri May 23 17:20:59 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 17:20:59 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old
In-Reply-To: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
Message-ID: <Jcc6bTG4ZsHhRvNW3jgAPAcXVGhW7YpD6XTH6O4y3iU=.194f55d8-c898-4d3a-a1e0-191b2a81de8c@github.com>

On Wed, 21 May 2025 17:55:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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/jd...
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 193:
> 
>> 191:   const size_t new_size = old_gen->max_capacity();
>> 192:   log_info(gc, ergo)("Forcing transfer of %zu region(s) from %s to %s, yielding increased size: " PROPERFMT,
>> 193:                      regions, young_gen->name(), old_gen->name(), PROPERFMTARGS(new_size));
> 
> If this is now really only used for in-place promotions, can we change the log message to indicate the region is being promoted? I think when users see messages about things being "forced" in the log, they start to wonder if young/old sizes need to adjusted.

It actually does have one other use.  I'm refactoring to distinguish the different purposes.  Replacing ShenandoahGenerationSizer log messages with log_develop_debug messages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2105079634

From kdnilsen at openjdk.org  Fri May 23 17:57:52 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 17:57:52 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old
In-Reply-To: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
Message-ID: <qfl3HQS6-0uEyjDWc8Xgssx4X7JVA0kD1z-Ra2Gf4Rw=.8a2e8c34-6e43-4c97-b495-0cec7b5dfe35@github.com>

On Wed, 21 May 2025 18:00:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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/jd...
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 298:
> 
>> 296:     if (copy == nullptr) {
>> 297:       // If we failed to allocate in LAB, we'll try a shared allocation.
>> 298: #ifdef KELVIN_ORIGINAL
> 
> This looks like debugging code? Should we back this out?

Sorry I forgot to clean this up.  Refined the comment and removed the #ifdef controls

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 279:
> 
>> 277:   static size_t setup_sizes(size_t max_heap_size);
>> 278: 
>> 279:   inline bool is_recycling() {
> 
> Is this used anywhere?

Good catch.  Removing this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2105174403
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2105175118

From kdnilsen at openjdk.org  Fri May 23 18:40:58 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 18:40:58 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old
In-Reply-To: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
Message-ID: <NSMrgfV3vNRGeKJYk72GsjJuGtB0-hk8B1Y5s_aF-g0=.f1a8b319-1a3a-4fc8-9694-104927ad6862@github.com>

On Wed, 21 May 2025 18:32:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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/jd...
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 376:
> 
>> 374:           "runs out of memory too early.")                                  \
>> 375:                                                                             \
>> 376:   product(uintx, ShenandoahOldEvacRatioPercent, 75, EXPERIMENTAL,           \
> 
> Phew, this is a lot of explanatory text and it reads like the target audience are GC developers. If we are going to expose this as a user configurable option, I think the help text should just explain how the behavior changes as this values goes up or down.  Something like:
>> Increasing this allows for more old regions in mixed collections. Decreasing this reduces the number of old regions in mixed collections. 
> 
> The first sentence makes it seem as though this is the percentage of the entire heap to reserve for old evacuations, but the next clarifies that this is the percentage of the collection set.
> 
> Question about this sentence:
>> A value of 100 allows a mixed evacuation to focus entirely on old-gen memory, allowing no young-gen regions to be collected.
> 
> With a setting of 100, would GenShen still "preselect" young regions of tenuring age with sufficient garbage into the collection set?
> 
>  I also find the name of the option slightly confusing - is it a ratio? or a percentage? Seems like it's really a percentage (though it controls the ratio of reserves used for the collection).

Thank you for honest feedback.  Way too many words.  I've pared the description back and tried to clarify the
confusion you describe.  Am also renaming to ShenandoahOldEvacPercent.  Please let me know what you think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2105223767

From kdnilsen at openjdk.org  Fri May 23 19:23:32 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 19:23:32 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old [v2]
In-Reply-To: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
Message-ID: <wKaM8kSlMPfB4ml2gGCIuU9HNqLxEoamw1UMQwz_rGI=.ec927c80-93ed-4f7e-8ef4-f255e76470ad@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 two additional commits since the last revision:

 - respond to reviewer feedback
 - Keep gc cycle times with heuristics for the relevant generation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25357/files
  - new: https://git.openjdk.org/jdk/pull/25357/files/3d55a646..ae8c83c9

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

  Stats: 135 lines in 9 files changed: 19 ins; 72 del; 44 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  Fri May 23 19:40:52 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 23 May 2025 19:40:52 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old [v2]
In-Reply-To: <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <L9dQajlNIMyFwSYckvwe23_S-hAjkLuYCFtpPCG9r6E=.41b4fbe2-4629-4cb8-9380-2adf8409b587@github.com>
Message-ID: <z-xyPADznm4muFywKGR9_50kb5qEZxdiNVzs6EHZLYY=.288156d3-c1cc-4c9d-b740-725e2ab62e5d@github.com>

On Wed, 21 May 2025 18:35:01 GMT, William Kemper <wkemper at openjdk.org> 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/shenandoahGenerationalHeap.hpp line 149:
> 
>> 147: 
>> 148:   // Transfers surplus old regions to young, or takes regions from young to satisfy old region deficit
>> 149:   TransferResult balance_generations();
> 
> Are we still using this `TransferResult` thing? Seems like we might be able to delete it with this change.

You're right.  Deleting.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2105303068

From duke at openjdk.org  Fri May 23 20:54:43 2025
From: duke at openjdk.org (Zihao Lin)
Date: Fri, 23 May 2025 20:54:43 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v7]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <tiztHtRuTMsrDXUPxefb6ckb1RUmtInrbQAdTTwd5Uk=.c98e7cfc-1811-47c0-938d-a684c022ea74@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

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

 - Merge branch 'openjdk:master' into 8344116
 - Merge branch 'openjdk:master' into 8344116
 - Fix build
 - Fix test failed
 - 8344116: C2: remove slice parameter from LoadNode::make

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24258/files
  - new: https://git.openjdk.org/jdk/pull/24258/files/3efb1c17..ea83736e

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

  Stats: 393670 lines in 4531 files changed: 146248 ins; 225477 del; 21945 mod
  Patch: https://git.openjdk.org/jdk/pull/24258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24258/head:pull/24258

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

From wkemper at openjdk.org  Fri May 23 23:45:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 May 2025 23:45:53 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old [v2]
In-Reply-To: <wKaM8kSlMPfB4ml2gGCIuU9HNqLxEoamw1UMQwz_rGI=.ec927c80-93ed-4f7e-8ef4-f255e76470ad@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <wKaM8kSlMPfB4ml2gGCIuU9HNqLxEoamw1UMQwz_rGI=.ec927c80-93ed-4f7e-8ef4-f255e76470ad@github.com>
Message-ID: <dk7JSEF-XzAeqkbzT69XpEZi54oRLyJPMwE0EdLU34w=.835bec14-0fe0-4e3b-9830-07f3344bda73@github.com>

On Fri, 23 May 2025 19:23:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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/jd...
>
> 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/shenandoah_globals.hpp line 376:

> 374:           "runs out of memory too early.")                                  \
> 375:                                                                             \
> 376:   product(uintx, ShenandoahOldEvacPercent, 75, EXPERIMENTAL,                \

This is much easier to read. Thank you for making the change!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2105525384

From wkemper at openjdk.org  Tue May 27 21:42:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 27 May 2025 21:42:56 GMT
Subject: Integrated: 8354078: Implement JEP 521: Generational Shenandoah
In-Reply-To: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
References: <2Ra5uic78TWWO2JVDnECH5Ve7kY0AeKtreLtqFQ2-4A=.0cae0e11-54c4-49eb-a7ef-cb9964ffbe03@github.com>
Message-ID: <PUdDhNU6e2NUdMZ9QIRPFU4ftZ9Ts7j832HRX4js9jE=.157d57fa-4704-4e36-8cd7-90fdf1a89322@github.com>

On Fri, 16 May 2025 17:30:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Testing:
> 
> % ./build/linux-x86_64-server-fastdebug/jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational --version
> openjdk 25 2025-09-16
> OpenJDK Runtime Environment (fastdebug build 25-make-genshen-non-experimental)
> OpenJDK 64-Bit Server VM (fastdebug build 25-make-genshen-non-experimental, mixed mode)

This pull request has now been integrated.

Changeset: 2e8b195a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e8b195a96e3b2a4ca27c64a923adc4334073128
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8354078: Implement JEP 521: Generational Shenandoah

Reviewed-by: ysr

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

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

From andrew at openjdk.org  Wed May 28 00:47:13 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 28 May 2025 00:47:13 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>

Merge jdk8u342-b06

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

Commit messages:
 - Merge jdk8u342-b06
 - 8285591: [11] add signum checks in DSA.java engineVerify

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

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/20/files
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/20/head:pull/20

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/20

From duke at openjdk.org  Wed May 28 04:22:56 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 04:22:56 GMT
Subject: Withdrawn: 8351892: GenShen: Remove enforcement of generation sizes
In-Reply-To: <F8xmi9sPA_VnQzddkxNa6paM_CVl8KYdybOWqmmqbZ0=.9b35ecc8-b0f7-48d5-a951-86c4f56a1c9c@github.com>
References: <F8xmi9sPA_VnQzddkxNa6paM_CVl8KYdybOWqmmqbZ0=.9b35ecc8-b0f7-48d5-a951-86c4f56a1c9c@github.com>
Message-ID: <l1IfmSSnOL9WBByCbZwyUppbplyzZ0SWs4bFLK3SZ44=.7258f07b-0c1e-4723-a5a4-8dbb70e58a56@github.com>

On Wed, 26 Mar 2025 23:50:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * The option to configure minimum and maximum sizes for the young generation have been combined into `ShenandoahInitYoungPercentage`.
> * The remaining functionality in `shGenerationSizer` wasn't enough to warrant being its own class, so the functionality was rolled into `shGenerationalHeap`.

This pull request has been closed without being integrated.

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

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

From ayang at openjdk.org  Wed May 28 07:22:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 28 May 2025 07:22:01 GMT
Subject: RFR: 8357944: Remove unused CollectedHeap::is_maximal_no_gc
Message-ID: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>

Removing effectively dead code/API for all GCs except G1.

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

Commit messages:
 - remove-heap-api

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

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

From andrew at openjdk.org  Wed May 28 15:16:23 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 28 May 2025 15:16:23 GMT
Subject: RFR: Merge jdk8u:master
In-Reply-To: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>
References: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>
Message-ID: <ezfWUeiQ2IoJZt6t3HjBmOZ3qkEJAzgm8KrAuiljjjE=.845840f3-9bd4-4a67-a247-e9a2f83ec2e2@github.com>

On Wed, 28 May 2025 00:43:39 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u342-b06

GHA builds will not work until [JDK-8284622](https://bugs.openjdk.org/browse/JDK-8284622) is merged in 8u362-b03

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

PR Comment: https://git.openjdk.org/shenandoah-jdk8u/pull/20#issuecomment-2916720063

From duke at openjdk.org  Thu May 29 00:40:00 2025
From: duke at openjdk.org (duke)
Date: Thu, 29 May 2025 00:40:00 GMT
Subject: Withdrawn: 8352181: Shenandoah: Evacuate thread roots after early
 cleanup
In-Reply-To: <99wc8_4LoODnc8E0fwS3VV3NTfdPJ3soau-_jaiLrGU=.ef48e18a-03f2-4863-b610-513b52e539a5@github.com>
References: <99wc8_4LoODnc8E0fwS3VV3NTfdPJ3soau-_jaiLrGU=.ef48e18a-03f2-4863-b610-513b52e539a5@github.com>
Message-ID: <PT4jE-P6SvW1t_i2i-F2itFXiOHqESJPI1Gmpzlg5Jo=.575656e7-70d1-42d4-ac73-d52155dcb35e@github.com>

On Mon, 17 Mar 2025 21:37:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Moving the evacuation of thread roots after early cleanup allows Shenandoah to recycle immediate garbage a bit sooner in the cycle.

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Thu May 29 14:27:20 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 29 May 2025 14:27:20 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <jqOhsyivlfewLIknyT_F4ZxJ3Q93PExfMvT2u9CtSB0=.98c9c442-ea27-4f66-97c6-747c4e6bc44a@github.com>

Merges tag jdk-21.0.8+5

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

Commit messages:
 - 8336587: failure_handler lldb command times out on macosx-aarch64 core file
 - 8202100: Merge vm/share/InMemoryJavaCompiler w/ jdk/test/lib/compiler/InMemoryJavaCompiler
 - 8353237: [AArch64] Incorrect result of VectorizedHashCode intrinsic on Cortex-A53
 - 8343037: Missing @since tag on JColorChooser.showDialog overload
 - 8356096: ISO 4217 Amendment 179 Update
 - 8183348: Better cleanup for jdk/test/sun/security/pkcs12/P12SecretKey.java
 - 8332252: Clean up vmTestbase/vm/share
 - 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build
 - 8353070: Clean up and open source couple AWT Graphics related tests (Part 1)
 - 8354554: Open source several clipboard tests batch1
 - ... and 13 more: https://git.openjdk.org/shenandoah-jdk21u/compare/a1e58917...432eb573

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/196/files
  Stats: 6232 lines in 840 files changed: 2755 ins; 2073 del; 1404 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/196.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/196/head:pull/196

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

From wkemper at openjdk.org  Thu May 29 19:51:45 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 29 May 2025 19:51:45 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <jqOhsyivlfewLIknyT_F4ZxJ3Q93PExfMvT2u9CtSB0=.98c9c442-ea27-4f66-97c6-747c4e6bc44a@github.com>
References: <jqOhsyivlfewLIknyT_F4ZxJ3Q93PExfMvT2u9CtSB0=.98c9c442-ea27-4f66-97c6-747c4e6bc44a@github.com>
Message-ID: <ele8d37EXRNbWFGtBsE4YSizfAU5d4xLsmLUQpgdStY=.543e913e-1598-445e-b2e4-ab6be4d340df@github.com>

> Merges tag jdk-21.0.8+5

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/196/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/196/files/432eb573..432eb573

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=196&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=196&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/196.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/196/head:pull/196

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

From wkemper at openjdk.org  Thu May 29 19:51:46 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 29 May 2025 19:51:46 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <jqOhsyivlfewLIknyT_F4ZxJ3Q93PExfMvT2u9CtSB0=.98c9c442-ea27-4f66-97c6-747c4e6bc44a@github.com>
References: <jqOhsyivlfewLIknyT_F4ZxJ3Q93PExfMvT2u9CtSB0=.98c9c442-ea27-4f66-97c6-747c4e6bc44a@github.com>
Message-ID: <bMtZVBAR9XX3tHKyCv1EG5tSCtLzgHo0C1gaqkoW7mI=.4e407e9f-cddc-46a7-8969-230a7e0a924c@github.com>

On Thu, 29 May 2025 14:23:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.8+5

This pull request has now been integrated.

Changeset: 091cab9d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/091cab9da17e720f189b4f6592e702adeb2b7abd
Stats:     6232 lines in 840 files changed: 2755 ins; 2073 del; 1404 mod

Merge

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

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

From serge.korotkov at gmail.com  Fri May 30 04:56:48 2025
From: serge.korotkov at gmail.com (Sergey Korotkov)
Date: Fri, 30 May 2025 11:56:48 +0700
Subject: C2 Jit compiler fails accessing off-heap memory via Unsafe with
 ShenandoahGC
Message-ID: <136180f2-df08-444b-8d80-63a10296a85f@gmail.com>

Hello,

Looks like there is a problem with the C2 Jit compiler that is 
reproduced with the Shenandoah GC only.  It sometimes may reorder the 
Unsafe.getLong() and Unsafe.putLong() operations so that logic of method 
is broken.  Something more or less similar was already fixed back in 
2019 as https://bugs.openjdk.org/browse/JDK-8220714.

For example such Java method would return 0L even if there is an 
non-zero long value stored in the buffer before call:

     public long run(long addr) {
         long tmp = UNSAFE.getLong(addr);

         UNSAFE.putLong(addr, 0L);

         if (dummy != null)
             System.err.println("never happen");

         return tmp;
     }

Tests show that it is important that run() is method of the inner class 
(non-static).  And dummy is field of the outer class.

Would you please look?

See more details and full reproducer below.

***

Tested on Linux Ubuntu 24.04

With releases and jdk17 nightly build:

- OpenJDK Runtime Environment (build 11.0.27+6-post-Ubuntu-0ubuntu124.04)
- OpenJDK Runtime Environment (build 17.0.15+6-Ubuntu-0ubuntu124.04)
- OpenJDK Runtime Environment (build 
17.0.16-testing+0-builds.shipilev.net-openjdk-jdk17-dev-b818-20250527-1808)
- OpenJDK Runtime Environment (build 21.0.7+6-Ubuntu-0ubuntu124.04)

Problem is reproduced with the jdk17 or jdk21, ShenandoahGC and if 
method is C2 compiled only.

Other options work fine:

   - jdk11 + any GC
   - jdk17/jdk21 + G1GC or ZGC
   - jdk17/jdk21 + ShenandoahGC + -XX:TieredStopAtLevel=3

***

Reordering is obvious from the generated assembler code.  Below are 
fragments obtained running the testcase attached.

WRONG with SenandoahGC: write is reordered to be before the read:

   # {method} {0x00007f4738401510} 'run' '(J)J' in 'Test$TestRunner'
   # this:     rsi:rsi   = 'Test$TestRunner'
   # parm0:    rdx:rdx   = long

   .... skipped

   0x00007f47e0fb0b67: mov rbx, rdx
   0x00007f47e0fb0b6a: mov qword ptr [rbx], r12   <--- write 0L to buffer
   0x00007f47e0fb0b6d: mov r8, r11
   0x00007f47e0fb0b70: shl r8, 3
   0x00007f47e0fb0b74: test byte ptr [r15 + 0x20], 1
   0x00007f47e0fb0b79: jne L0002
                L0001: mov r11d, dword ptr [r8 + 0xc]
   0x00007f47e0fb0b7f: mov rbx, qword ptr [rbx]   <--- read from buffer


CORRECT with G1GC: read goes first before the write:

   # {method} {0x000072317b401510} 'run' '(J)J' in 'Test$TestRunner'
   # this:     rsi:rsi   = 'Test$TestRunner'
   # parm0:    rdx:rdx   = long

   .... skipped

   0x0000723214faa950: mov r11, rdx
   0x0000723214faa953: mov rax, qword ptr [r11]  <---  read from buffer
   0x0000723214faa956: mov qword ptr [r11], r12  <---  write 0L to buffer

***

In the attached Test.cpp all iterations should be OK:

---------------------------
Test start
0 iter passed
1000000 iter passed
2000000 iter passed
3000000 iter passed
4000000 iter passed
5000000 iter passed
6000000 iter passed
7000000 iter passed
8000000 iter passed
9000000 iter passed
---------------------------

But with the jdk17 and Shenandoah GC it fails on one of the iteration 
(once the run() is C2 compiled):

---------------------------
Test start
0 iter passed
1000000 iter passed
2000000 iter passed
3000000 iter passed
4000000 iter passed
5000000 iter passed
Exception in thread "main" java.lang.RuntimeException: unexpected 0L in 
buffer
     at Test.test(Test.java:24)
     at Test.main(Test.java:16)
---------------------------

Thanks,
--
   Sergey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test.java
Type: text/x-java
Size: 2466 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20250530/30d444ac/Test.java>

From jsikstro at openjdk.org  Fri May 30 11:48:50 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 30 May 2025 11:48:50 GMT
Subject: RFR: 8357944: Remove unused CollectedHeap::is_maximal_no_gc
In-Reply-To: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
References: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
Message-ID: <_ihPWw3QtrzZZg3ZVgMgO6D7-bBCVdYh2-_Wi5erIvk=.eb141df4-35dd-478f-856d-efd3e8a4a243@github.com>

On Wed, 28 May 2025 07:17:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing effectively dead code/API for all GCs except G1.

Looks good. This code is quite old, but I wonder if it's also appropriate to rename `is_maximal_no_gc()` to something more descriptive, maybe `is_expandable()` and reverse the check, which I think looks better at the callers of `is_maximal_no_gc()`. Not sure if that should be done separately or not though, and I don't have strong opinions on G1 code.

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

Marked as reviewed by jsikstro (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25482#pullrequestreview-2881111569

From ayang at openjdk.org  Fri May 30 11:56:51 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 May 2025 11:56:51 GMT
Subject: RFR: 8357944: Remove unused CollectedHeap::is_maximal_no_gc
In-Reply-To: <_ihPWw3QtrzZZg3ZVgMgO6D7-bBCVdYh2-_Wi5erIvk=.eb141df4-35dd-478f-856d-efd3e8a4a243@github.com>
References: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
 <_ihPWw3QtrzZZg3ZVgMgO6D7-bBCVdYh2-_Wi5erIvk=.eb141df4-35dd-478f-856d-efd3e8a4a243@github.com>
Message-ID: <p_WpbzLlPFeBgd4apJseTXKGem0Os80R2Gw5VkivAiM=.c834b701-8125-415f-85b0-8323859e5440@github.com>

On Fri, 30 May 2025 11:45:56 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> I wonder if it's also appropriate to rename is_maximal_no_gc() to something more descriptive ...

I agree the current name is not very nice. I am leaned towards changing its return-type also: `uint num_inactive_regions() const { return _hrm.num_inactive_regions(); }`. However, I feel that discussion can get its own ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/25482#issuecomment-2922188313

From ysr at openjdk.org  Sat May 31 03:00:03 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 31 May 2025 03:00:03 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old [v2]
In-Reply-To: <wKaM8kSlMPfB4ml2gGCIuU9HNqLxEoamw1UMQwz_rGI=.ec927c80-93ed-4f7e-8ef4-f255e76470ad@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
 <wKaM8kSlMPfB4ml2gGCIuU9HNqLxEoamw1UMQwz_rGI=.ec927c80-93ed-4f7e-8ef4-f255e76470ad@github.com>
Message-ID: <lWw-FYBILxOrm0q7RyuxqrA2ZJnhIP2QFLxLv6_hH7k=.8d6b6268-5498-4626-a102-f5804a2ce021@github.com>

On Fri, 23 May 2025 19:23:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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/jd...
>
> 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.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 185:

> 183:   heap->young_generation()->set_evacuation_reserve((size_t) (young_evac_bytes * ShenandoahEvacWaste));
> 184:   heap->old_generation()->set_evacuation_reserve((size_t) (old_evac_bytes * ShenandoahOldEvacWaste));
> 185:   heap->old_generation()->set_promoted_reserve((size_t) (promo_bytes * ShenandoahPromoEvacWaste));

Note that the census from the most recent mark provides both these bits of information, but doesn't account for other criteria (i.e. liveness denseness) that go into the exclusion of certain regions (and their objects) from the collection set. Therein lies the rub,  but armed with historical numbers of each and reality, one might be able to predict this well (may be).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2117098162
PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2117103371

From andrew at openjdk.org  Sat May 31 18:08:54 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 18:08:54 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 2 new changesets
Message-ID: <c39e5e5a-bb90-421b-831d-38f64cfd469d@openjdk.org>

Changeset: a18e9043
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-06-08 01:47:13 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/a18e9043fa2a0a14098e1ec25d32577aaac6c023

8285591: [11] add signum checks in DSA.java engineVerify

Reviewed-by: sgehwolf, mbalao
Backport-of: bf3438c5dc993b96d089cabb5318bfc64a6904a3

! jdk/src/share/classes/sun/security/provider/DSA.java

Changeset: 529b42b9
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 00:39:32 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/529b42b99d0fddfb76ba0a3e2e01fd9ca1629ebe

Merge jdk8u342-b06

Added tag jdk8u342-b06 for changeset a18e9043fa



From andrew at openjdk.org  Sat May 31 18:09:03 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 18:09:03 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u342-b06 for changeset
 a18e9043
Message-ID: <319e4930-9fd1-4411-8edc-194f931dbacf@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-06-23 01:19:55 +0000

Added tag jdk8u342-b06 for changeset a18e9043fa
Changeset: a18e9043
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-06-08 01:47:13 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/a18e9043fa2a0a14098e1ec25d32577aaac6c023


From andrew at openjdk.org  Sat May 31 18:09:05 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 18:09:05 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u342-b06 for
 changeset 529b42b9
Message-ID: <495e0cd7-be2b-46b2-b713-97905966141c@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 01:09:05 +0000

Added tag shenandoah8u342-b06 for changeset 529b42b99d0
Changeset: 529b42b9
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 00:39:32 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/529b42b99d0fddfb76ba0a3e2e01fd9ca1629ebe


From andrew at openjdk.org  Sat May 31 18:09:48 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 18:09:48 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>
References: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>
Message-ID: <DLtlEjb3i1wTnzItR_KU2o5M5zyKhQ-0Fy5b0E_14cI=.006a488a-83e3-4121-bdc6-d2662e58224c@github.com>

> Merge jdk8u342-b06

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/20/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/20/files/529b42b9..529b42b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=20&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=20&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/20.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/20/head:pull/20

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/20

From iris at openjdk.org  Sat May 31 18:09:48 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 31 May 2025 18:09:48 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>
References: <ENcifGsQtwDHZ52XRYinOONjMpgtxg819rFVWW2BG30=.268c41d4-1c3e-464c-89bb-af11cbf2402b@github.com>
Message-ID: <UrVbWKwQ9HLF7LeHnEXo1zcnl95eBRb9Z34qSs_1RFo=.1a59543f-458c-4fba-8499-4276c6b599cd@github.com>

On Wed, 28 May 2025 00:43:39 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u342-b06

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/20

From andrew at openjdk.org  Sat May 31 19:26:09 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:26:09 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>

Merge jdk8u342-b07

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

Commit messages:
 - Merge jdk8u342-b07
 - 8285407: Improve Xalan supports
 - 8284370: Improve zlib usage
 - 8283190: Improve MIDI processing
 - 8281866: Enhance MethodHandle invocations
 - 8281859: Improve class compilation
 - 8272243: Improve DER parsing
 - 8209771: jdk.test.lib.Utils::runAndCheckException error
 - 8272249: Better properties of loaded Properties
 - 8277608: Address IP Addressing

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

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/21/files
  Stats: 732 lines in 22 files changed: 523 ins; 96 del; 113 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/21/head:pull/21

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/21

From andrew at openjdk.org  Sat May 31 19:32:56 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:32:56 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 10 new changesets
Message-ID: <27112894-6726-4b80-be2b-d364f3d3bec3@openjdk.org>

Changeset: 207b04f0
Branch: master
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-20 16:46:52 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/207b04f0a4ea2fa77c3fc3d0ec69a992dc78c39a

8277608: Address IP Addressing

Reviewed-by: mbalao, andrew
Backport-of: f2136e833d5bbeb9eb4e61e73774c36ff7d27cfb

! jdk/src/share/classes/java/net/HostPortrange.java
! jdk/src/share/classes/java/net/InetAddress.java
! jdk/src/share/classes/java/net/SocketPermission.java
! jdk/src/share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
! jdk/src/share/classes/sun/net/util/IPAddressUtil.java

Changeset: bcd164ef
Branch: master
Author:    Yuri Nesterenko <yan at azul.com>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-20 14:50:37 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/bcd164ef5832a825f750c30401a9cf9a4ba0b6eb

8272249: Better properties of loaded Properties

Reviewed-by: mbalao, andrew
Backport-of: f9f7e5eaf51cd4793805e50f8ba3549689d939e9

! jdk/src/share/classes/jdk/internal/util/xml/impl/Parser.java

Changeset: 33295aa9
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-07-15 04:24:40 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/33295aa9ca1e63607565a8404790706ae1e942b6

8209771: jdk.test.lib.Utils::runAndCheckException error

Backport-of: 61628526a900ce53aa212b23d1ed82ef11f2f105
Reviewed-by: mbalao

! jdk/test/lib/jdk/test/lib/Utils.java

Changeset: 1611e7dd
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-07-12 02:33:00 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1611e7dd5a72841ac052cd0d40f284b9b0e512d7

8272243: Improve DER parsing

Backport-of: ec91d4bce10cd965e8a0099f35aed8c9150f6a44
Co-authored-by: Alexey Bakhtin <abakhtin at openjdk.org>
Reviewed-by: mbalao

! jdk/src/share/classes/sun/security/util/BitArray.java
! jdk/src/share/classes/sun/security/util/DerInputBuffer.java
! jdk/src/share/classes/sun/security/util/DerInputStream.java
! jdk/test/sun/security/util/DerInputBuffer/PaddedBitString.java

Changeset: 1dafef08
Branch: master
Author:    Martin Balao <mbalao at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-03-21 07:39:37 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1dafef08cc922ee85a8e216387100dc681a5484d

8281859: Improve class compilation

Reviewed-by: andrew
Backport-of: 3ac62a66efd05d0842076dd4cfbea0e53b12630f

! hotspot/src/share/vm/ci/ciEnv.cpp

Changeset: f14e35d2
Branch: master
Author:    Martin Balao <mbalao at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-03-24 10:45:32 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/f14e35d20e1a4d0f507f05838844152f2242c6d3

8281866: Enhance MethodHandle invocations

Reviewed-by: andrew
Backport-of: d974d9da365f787f67971d88c79371c8b0769f75

! hotspot/src/share/vm/interpreter/linkResolver.cpp
! hotspot/src/share/vm/interpreter/linkResolver.hpp
! hotspot/src/share/vm/prims/methodHandles.cpp
! hotspot/src/share/vm/prims/methodHandles.hpp

Changeset: 521fcbff
Branch: master
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-25 09:18:54 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/521fcbff6cc97ee674f8a83fecd20fe5c8a36a49

8283190: Improve MIDI processing

Reviewed-by: andrew
Backport-of: e0329eb343661edd5066deb6ae5d99a742135831

! jdk/src/share/classes/com/sun/media/sound/StandardMidiFileReader.java

Changeset: 1f50bccc
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-04-20 15:50:26 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/1f50bcccf23cf2237a77e19cafed2287ee30239b

8284370: Improve zlib usage

Reviewed-by: andrew
Backport-of: 46f42c72a92ffb035e84eb8e73bd6329ef006251

! jdk/src/share/native/java/util/zip/zlib/deflate.c
! jdk/src/share/native/java/util/zip/zlib/deflate.h
! jdk/src/share/native/java/util/zip/zlib/trees.c

Changeset: 3dca446d
Branch: master
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-30 12:26:00 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc

8285407: Improve Xalan supports

Reviewed-by: mbalao, andrew
Backport-of: fd6385d8c20379c1139f64f5c90d331ad9631097

! jaxp/src/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java
! jaxp/src/com/sun/org/apache/bcel/internal/generic/ConstantPoolGen.java

Changeset: 6646316d
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 19:16:21 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6646316da220b2e40611899fc4e1d4734ee6d726

Merge jdk8u342-b07

Added tag jdk8u342-b07 for changeset 3dca446d440



From andrew at openjdk.org  Sat May 31 19:33:10 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:33:10 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u345-b00 for
 changeset 6646316d
Message-ID: <ccc2505c-5b4c-4d5c-a9f7-b4ac7bad5339@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 20:17:35 +0000

Added tag shenandoah8u345-b00 for changeset 6646316da22
Changeset: 6646316d
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 19:16:21 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6646316da220b2e40611899fc4e1d4734ee6d726


From andrew at openjdk.org  Sat May 31 19:33:07 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:33:07 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u345-b00 for changeset
 3dca446d
Message-ID: <84b6c781-f4f9-48e4-b645-e520f3b9968a@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-01 18:27:19 +0000

Added tag jdk8u345-b00 for changeset 3dca446d440
Changeset: 3dca446d
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-30 12:26:00 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc


From andrew at openjdk.org  Sat May 31 19:33:31 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:33:31 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u342-ga for
 changeset 6646316d
Message-ID: <e62854cd-93fd-45c5-81a8-16d75b0c907b@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 20:17:28 +0000

Added tag shenandoah8u342-ga for changeset 6646316da22
Changeset: 6646316d
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 19:16:21 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6646316da220b2e40611899fc4e1d4734ee6d726


From andrew at openjdk.org  Sat May 31 19:33:21 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:33:21 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u342-b07 for
 changeset 6646316d
Message-ID: <9b4651e6-2a45-4f85-b6e8-1a10c8c5d0d2@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 20:17:19 +0000

Added tag shenandoah8u342-b07 for changeset 6646316da22
Changeset: 6646316d
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 19:16:21 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6646316da220b2e40611899fc4e1d4734ee6d726


From andrew at openjdk.org  Sat May 31 19:33:15 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:33:15 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u342-b07 for changeset
 3dca446d
Message-ID: <5cb8a52c-f1a5-4142-9b3e-a15cfae9f787@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-07-15 17:50:17 +0000

Added tag jdk8u342-b07 for changeset 3dca446d440
Changeset: 3dca446d
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-30 12:26:00 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc


From andrew at openjdk.org  Sat May 31 19:33:26 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:33:26 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u342-ga for changeset
 3dca446d
Message-ID: <504efafa-2abf-4d7f-9012-2a4d7d501284@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-07-23 15:58:57 +0000

Added tag jdk8u342-ga for changeset 3dca446d440
Changeset: 3dca446d
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-30 12:26:00 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3dca446d440e55cbb7dc3555392f4520ec9ff3bc


From andrew at openjdk.org  Sat May 31 19:35:46 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:35:46 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>
References: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>
Message-ID: <wp16QvHIjYA9wd--tU_4ANNv0PSSSearYs-xtlCYJ_E=.0748e489-1308-4719-871d-10ae59b41ea8@github.com>

> Merge jdk8u342-b07

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/21/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/21/files/6646316d..6646316d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=21&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=21&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/21.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/21/head:pull/21

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/21

From andrew at openjdk.org  Sat May 31 19:35:47 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 19:35:47 GMT
Subject: RFR: Merge jdk8u:master
In-Reply-To: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>
References: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>
Message-ID: <kqbXR-Sk7JUEZD7FRF75YryrIysjBMUzetbHmmRQQ70=.e62288d7-cca6-4fd3-b2af-5907f47ee64f@github.com>

On Sat, 31 May 2025 19:22:16 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u342-b07

GHA builds will not work until [JDK-8284622](https://bugs.openjdk.org/browse/JDK-8284622) is merged in 8u362-b03

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

PR Comment: https://git.openjdk.org/shenandoah-jdk8u/pull/21#issuecomment-2925636795

From iris at openjdk.org  Sat May 31 19:35:47 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 31 May 2025 19:35:47 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>
References: <ktAISlLXy-i5B9KwJ8-a_Fssj66T9BgBRlHq1IxWz5A=.099da7b9-1b99-4c2f-b8bf-86019874a91a@github.com>
Message-ID: <id_fk8P7qkGWNAlsE-4bokzpIqd23NuSwmUGI9Iarcw=.08f123ed-e9da-4316-aab8-3effa046669a@github.com>

On Sat, 31 May 2025 19:22:16 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u342-b07

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/21

From andrew at openjdk.org  Sat May 31 22:49:25 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:49:25 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>

Merge jdk8u345-b01

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

Commit messages:
 - Merge jdk8u345-b01
 - 8290832: It is no longer possible to change "user.dir" in the JDK8
 - 8291568: Bump update version of OpenJDK: 8u345

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

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/22/files
  Stats: 69 lines in 5 files changed: 0 ins; 65 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/22/head:pull/22

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/22

From andrew at openjdk.org  Sat May 31 22:53:28 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:53:28 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 3 new changesets
Message-ID: <25863db4-ea61-49f7-9067-0ae234aaef30@openjdk.org>

Changeset: 244f98e4
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-07-30 16:46:45 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/244f98e4eb5cd16d2b8ff11b6aa98787ed7c2a10

8291568: Bump update version of OpenJDK: 8u345

Reviewed-by: phh, serb

! .jcheck/conf
! common/autoconf/version-numbers

Changeset: 2dadc2bf
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2022-07-31 04:01:56 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/2dadc2bf312d5f947e0735d5ec13c285824db31d

8290832: It is no longer possible to change "user.dir" in the JDK8

Reviewed-by: phh, andrew

! jdk/src/solaris/classes/java/io/UnixFileSystem.java
! jdk/src/windows/classes/java/io/WinNTFileSystem.java
- jdk/test/java/io/File/UserDirChangedTest.java

Changeset: e15e8105
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 20:31:07 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/e15e81056677a38c7ba05d71a8c7044d23e609e2

Merge jdk8u345-b01

Added tag jdk8u345-b01 for changeset 2dadc2bf312

! .jcheck/conf
! .jcheck/conf


From andrew at openjdk.org  Sat May 31 22:53:37 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:53:37 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u345-b01 for changeset
 2dadc2bf
Message-ID: <02b7b0d0-a5ef-4cb7-a7bd-91a5a003ffe6@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-07-31 21:37:12 +0000

Added tag jdk8u345-b01 for changeset 2dadc2bf312
Changeset: 2dadc2bf
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2022-07-31 04:01:56 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/2dadc2bf312d5f947e0735d5ec13c285824db31d


From andrew at openjdk.org  Sat May 31 22:53:39 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:53:39 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u345-b01 for
 changeset e15e8105
Message-ID: <1c2f5757-97cf-4422-acc3-4cfa4e47c549@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 21:43:45 +0000

Added tag shenandoah8u345-b01 for changeset e15e8105667
Changeset: e15e8105
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 20:31:07 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/e15e81056677a38c7ba05d71a8c7044d23e609e2


From andrew at openjdk.org  Sat May 31 22:53:45 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:53:45 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u345-ga for changeset
 2dadc2bf
Message-ID: <a36eb855-3123-4bd1-b195-deb63bcc86f6@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-08-01 17:10:48 +0000

Added tag jdk8u345-ga for changeset 2dadc2bf312
Changeset: 2dadc2bf
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2022-07-31 04:01:56 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/2dadc2bf312d5f947e0735d5ec13c285824db31d


From andrew at openjdk.org  Sat May 31 22:53:50 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:53:50 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u345-ga for
 changeset e15e8105
Message-ID: <3205e0d5-871b-405b-9e76-07f11af58e84@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 21:43:47 +0000

Added tag shenandoah8u345-ga for changeset e15e8105667
Changeset: e15e8105
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-05-31 20:31:07 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/e15e81056677a38c7ba05d71a8c7044d23e609e2


From andrew at openjdk.org  Sat May 31 22:55:46 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:55:46 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>
References: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>
Message-ID: <EXaR35mG3z8EPIlHk3jKqE-T6AcoB2B60ZJ9t569M5U=.552b3b02-8ad0-4476-8481-129c815947d4@github.com>

> Merge jdk8u345-b01

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/22/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/22/files/e15e8105..e15e8105

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=22&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk8u&pr=22&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/22/head:pull/22

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/22

From andrew at openjdk.org  Sat May 31 22:55:47 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 31 May 2025 22:55:47 GMT
Subject: RFR: Merge jdk8u:master
In-Reply-To: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>
References: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>
Message-ID: <NA8rXexO3AluTKEhBLc4XnaB5MP5VD3CIWEtxF8gcas=.c13ad680-7caf-4c85-90d9-d70ee769fce1@github.com>

On Sat, 31 May 2025 22:45:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u345-b01

GHA builds will not work until [JDK-8284622](https://bugs.openjdk.org/browse/JDK-8284622) is merged in 8u362-b03

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

PR Comment: https://git.openjdk.org/shenandoah-jdk8u/pull/22#issuecomment-2925897743

From iris at openjdk.org  Sat May 31 22:55:47 2025
From: iris at openjdk.org (Iris Clark)
Date: Sat, 31 May 2025 22:55:47 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>
References: <2A2WuMNIXsrjXBxlJRKPyNKeTOvDvdc90Su80gw1D0s=.e9ed60a1-635e-4bf4-97cb-c5e516995a18@github.com>
Message-ID: <BLeAxp83uI9eNquTdEqQjXzgKa_iypQsnXTzY0DED_4=.0ec26028-824f-4747-83f4-7e075d114f3a@github.com>

On Sat, 31 May 2025 22:45:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u345-b01

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/22