From haosun at openjdk.org  Fri Dec  1 05:24:08 2023
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 1 Dec 2023 05:24:08 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
Message-ID: <vIOl1oVXMbl6Y2oIJqsknuCxTc4ikM2sQ3xQbmI_OB8=.3b8a4cf3-87d8-450b-9952-e71463db8ce7@github.com>

On Wed, 29 Nov 2023 22:40:35 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |         |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |         |
>> | x64      |         |         |         |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |         |         |         |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1246:

> 1244:     if (_next_call_type == INVOKESTATIC || _next_call_type == INVOKESPECIAL) {
> 1245:       // Need a static call stub for transitions from compiled to interpreted.
> 1246:       C2_MacroAssembler masm(&buffer);

Hi, I encountered one build failure: JDK build **without C2** fails on Linux/AArch64.

The configure I used


--with-debug-level=release --with-jvm-features=-compiler2 --disable-precompiled-headers


The error log


=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
/usr/bin/ld: /tmp/build-release/hotspot/variant-server/libjvm/objs/jvmciCodeInstaller.o: in function `C2_MacroAssembler::C2_MacroAssembler(CodeBuffer*)':
make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
/usr/bin/ld: make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
collect2: error: ld returned 1 exit status
* For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
/usr/bin/ld: /tmp/build-release/hotspot/variant-server/libjvm/objs/jvmciCodeInstaller.o: in function `C2_MacroAssembler::C2_MacroAssembler(CodeBuffer*)':
make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
/usr/bin/ld: make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
collect2: error: ld returned 1 exit status

* All command lines available in /tmp/build-release/make-support/failure-logs.
=== End of repeated output ===


I suggest making the following change:

Suggestion:

      MacroAssembler masm(&buffer);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1411551297

From tschatzl at openjdk.org  Fri Dec  1 09:15:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 1 Dec 2023 09:15:08 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v3]
In-Reply-To: <E1dsz9pz9qPSP-npcKNgdsmJyoNG1KnduRNXGfvfLuk=.3f8cef90-6b8a-4d6b-bf57-78fdd87842f3@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <wPKk7I8G7gknAGGQhrOurDNO1ekzXk3HMxHhlW_S5oc=.ee4e09e7-b4eb-40a6-a149-7b5a30ff42f9@github.com>
 <ym4bAn9bR2uEMqltEKTgRltmBToMF0GVFIruX5CRTOM=.8209d394-bf68-4d4d-8e97-cea4a0d67c14@github.com>
 <E1dsz9pz9qPSP-npcKNgdsmJyoNG1KnduRNXGfvfLuk=.3f8cef90-6b8a-4d6b-bf57-78fdd87842f3@github.com>
Message-ID: <QQKOSBJXCD9qB3tIGlfZV1LWUfygnTcSpPbWs4Fc8LQ=.c23abd39-b531-4c89-b1a3-6165a7e07d79@github.com>

On Thu, 30 Nov 2023 10:34:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/classUnloadingContext.hpp line 63:
>> 
>>> 61: };
>>> 62: 
>>> 63: class DefaultClassUnloadingContext : public ClassUnloadingContext {
>> 
>> I don't understand why they need to be two classes, even after reading "These are the reason for the class hierarchy for...". The reference to future/other PR(s) in the description doesn't really help -- it's unclear what is *necessary* for the current PR and what is preparation for future PR(s).
>
> The base class is unnecessary for this change, but very nice to have for future changes. I'll just merge them for now, and separate them again later.

As explained in the now removed original description:


>These are the reason for the class hierarchy for `ClassUnloadingContext`: the goal is to ultimately have about this phasing (for G1):
>1. collect all dead CLDs, using the `register_unloading_class_loader_data` method *only*
>2. parallelize the stuff in `ClassLoaderData::unload()` in one way or another, adding them to the `complete_cleaning` >(parallel) phase.
>
>Particularly the split of `SystemDictionary::do_unloading` into "only" traversing the CLDs to find the dead ones and then in parallel process them in 2. above warrants a separate `ClassUnloadingContext` (to facilitate parallelism). 


I.e. the non-parallelized case does not need the necessary data structure complications and helper methods to do efficient parallel iteration. However as mentioned I removed the class hierarchy for this change as it's unnecessary for now; let's discuss this hierarchy separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1411815090

From lucy at openjdk.org  Fri Dec  1 11:09:05 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 1 Dec 2023 11:09:05 GMT
Subject: RFR: 8320807: [PPC64][ZGC] C1 generates wrong code for atomics
In-Reply-To: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
References: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
Message-ID: <UnoJ0VwEignTYO7XwM18Qb5TcLQqw6_l_vGLvOIgUs8=.b23444bc-50eb-4b26-a120-0dc1a952c855@github.com>

On Mon, 27 Nov 2023 21:52:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Debugging test failures on PPC64 in java/lang/Thread/virtual/stress/Skynet.java#ZGenerational has shown that the ldarx+stdcx_ loop for uncompressed Oops in `LIR_Assembler::atomic_op` is wrong: `__ mr(Rtmp, Robj);` is inside of the ldarx+stdcx_ loop, but must be outside of it. Repeated execution leads to wrong store value.
> In addition, zBarrierSetC1.cpp expects `cas_obj` and `xchg` to contain all necessary memory barriers. That doesn't fit to the current PPC64 design which inserts memory barriers on LIR level instead. I've changed this and moved them into the assembler code for all GCs.
> While debugging, I have optimized out an unnecessary branch in `ZBarrierSetAssembler::store_barrier_medium`.

Looks good.
Thanks for detecting and fixing this bug.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16835#pullrequestreview-1759560030

From rrich at openjdk.org  Fri Dec  1 11:47:07 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 1 Dec 2023 11:47:07 GMT
Subject: RFR: 8320807: [PPC64][ZGC] C1 generates wrong code for atomics
In-Reply-To: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
References: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
Message-ID: <MBbQbCS5fbTbEzDGD4bYN0CkikkPhtT1ATKHqH7_X44=.283fbd9d-df3f-4e04-8ac9-a77d1c403f0b@github.com>

On Mon, 27 Nov 2023 21:52:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Debugging test failures on PPC64 in java/lang/Thread/virtual/stress/Skynet.java#ZGenerational has shown that the ldarx+stdcx_ loop for uncompressed Oops in `LIR_Assembler::atomic_op` is wrong: `__ mr(Rtmp, Robj);` is inside of the ldarx+stdcx_ loop, but must be outside of it. Repeated execution leads to wrong store value.
> In addition, zBarrierSetC1.cpp expects `cas_obj` and `xchg` to contain all necessary memory barriers. That doesn't fit to the current PPC64 design which inserts memory barriers on LIR level instead. I've changed this and moved them into the assembler code for all GCs.
> While debugging, I have optimized out an unnecessary branch in `ZBarrierSetAssembler::store_barrier_medium`.

Looks good. Just two suggestions to improve comments.
Cheers, Richard.

src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp line 2603:

> 2601:   }
> 2602: 
> 2603:   // Volatile load may be followed by Unsafe CAS.

Suggestion:

  // There might be a volatile load before this Unsafe CAS.

src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp line 2984:

> 2982:   }
> 2983: 
> 2984:   // Volatile load may be followed by Unsafe OP.

Suggestion:

  // There might be a volatile load before this Unsafe OP.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16835#pullrequestreview-1759593616
PR Review Comment: https://git.openjdk.org/jdk/pull/16835#discussion_r1411967401
PR Review Comment: https://git.openjdk.org/jdk/pull/16835#discussion_r1411988559

From mdoerr at openjdk.org  Fri Dec  1 13:22:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 1 Dec 2023 13:22:39 GMT
Subject: RFR: 8320807: [PPC64][ZGC] C1 generates wrong code for atomics
 [v2]
In-Reply-To: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
References: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
Message-ID: <aEq5HHM1wqIe84fTspcIRReaCHIEF6H9nrrR1yFTXIU=.6afae5e2-8953-4074-9a24-b26c8dc65e9e@github.com>

> Debugging test failures on PPC64 in java/lang/Thread/virtual/stress/Skynet.java#ZGenerational has shown that the ldarx+stdcx_ loop for uncompressed Oops in `LIR_Assembler::atomic_op` is wrong: `__ mr(Rtmp, Robj);` is inside of the ldarx+stdcx_ loop, but must be outside of it. Repeated execution leads to wrong store value.
> In addition, zBarrierSetC1.cpp expects `cas_obj` and `xchg` to contain all necessary memory barriers. That doesn't fit to the current PPC64 design which inserts memory barriers on LIR level instead. I've changed this and moved them into the assembler code for all GCs.
> While debugging, I have optimized out an unnecessary branch in `ZBarrierSetAssembler::store_barrier_medium`.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16835/files
  - new: https://git.openjdk.org/jdk/pull/16835/files/54a0d25d..e6958e4c

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

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

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

From mdoerr at openjdk.org  Fri Dec  1 13:22:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 1 Dec 2023 13:22:41 GMT
Subject: RFR: 8320807: [PPC64][ZGC] C1 generates wrong code for atomics
In-Reply-To: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
References: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
Message-ID: <fU6HOJdqxIWKsOti2VdHuZejmmN2Ew3YEAQ9vPgH0SA=.14da1cbe-6912-4d34-821a-f115987c19ff@github.com>

On Mon, 27 Nov 2023 21:52:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Debugging test failures on PPC64 in java/lang/Thread/virtual/stress/Skynet.java#ZGenerational has shown that the ldarx+stdcx_ loop for uncompressed Oops in `LIR_Assembler::atomic_op` is wrong: `__ mr(Rtmp, Robj);` is inside of the ldarx+stdcx_ loop, but must be outside of it. Repeated execution leads to wrong store value.
> In addition, zBarrierSetC1.cpp expects `cas_obj` and `xchg` to contain all necessary memory barriers. That doesn't fit to the current PPC64 design which inserts memory barriers on LIR level instead. I've changed this and moved them into the assembler code for all GCs.
> While debugging, I have optimized out an unnecessary branch in `ZBarrierSetAssembler::store_barrier_medium`.

Thanks for the reviews! I've improved the comments as suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/16835#issuecomment-1836106556

From mdoerr at openjdk.org  Fri Dec  1 14:47:17 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 1 Dec 2023 14:47:17 GMT
Subject: Integrated: 8320807: [PPC64][ZGC] C1 generates wrong code for atomics
In-Reply-To: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
References: <v-FCLDOczU-2OY24-dq1ntRH75OUI2Soe6mOQuu8io4=.9c79f615-4766-441c-8667-3ee4307578e4@github.com>
Message-ID: <tA0EXa67FnSmK8hPn4JGLfXoH0wfFR2y47KHnqBJt58=.9b25e5ed-0ec2-47fd-864a-2f6c0477890e@github.com>

On Mon, 27 Nov 2023 21:52:53 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Debugging test failures on PPC64 in java/lang/Thread/virtual/stress/Skynet.java#ZGenerational has shown that the ldarx+stdcx_ loop for uncompressed Oops in `LIR_Assembler::atomic_op` is wrong: `__ mr(Rtmp, Robj);` is inside of the ldarx+stdcx_ loop, but must be outside of it. Repeated execution leads to wrong store value.
> In addition, zBarrierSetC1.cpp expects `cas_obj` and `xchg` to contain all necessary memory barriers. That doesn't fit to the current PPC64 design which inserts memory barriers on LIR level instead. I've changed this and moved them into the assembler code for all GCs.
> While debugging, I have optimized out an unnecessary branch in `ZBarrierSetAssembler::store_barrier_medium`.

This pull request has now been integrated.

Changeset: 3087e14c
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3087e14cde9257680f0406b11942f9cb7739cb7b
Stats:     121 lines in 4 files changed: 42 ins; 70 del; 9 mod

8320807: [PPC64][ZGC] C1 generates wrong code for atomics

Reviewed-by: lucy, rrich

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

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

From kdnilsen at openjdk.org  Fri Dec  1 15:56:13 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Dec 2023 15:56:13 GMT
Subject: RFR: 8321149: GenShen: Test for is_good_progress() following degen
 needs to sum all available memoryChange behavior of is_good_progerss
Message-ID: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>

This reduces the sensitivity of the trigger that upgrades to Full GC following a completed degenerated GC.  The change was motivated by examination of a test workload that required one more full GC and one more degenerated GC than was expected.  Upon examination of the GC log, it was determined that the extra Full GC was triggered because the mutator free set following degen was approximately 10% below the critical threshold, even though the total available memory within heap was more than three fold the critical threshold.  

Following this change, no Full GCs were required and one fewer degenerated cycle was required (which had occurred immediately following the Full GC due to the long unproductive STW the pause caused by Full GC).  P50 latency improved by 15%, and p100 latencies improved by over 100 fold.

More comprehensive testing over a broader set of workloads reveals this change is not "universally better".  Of particular concern is degradation of specjbb numbers on x86, but not aarch64, tests.  I'm inclined to believe this change represents net improvement, but it would be best to delay integration until we have a better understanding of specjbb performance issues, and how they might be impacted by this change.



   Control: shenandoah-x86-template
Experiment: fix-is-good-progress-gh-x86

                          Most impacted benchmarks |                              Most impacted metrics
-------------------------------------------------------------------------------------------------------
                               Genshen/specjbb2015 |                                         cpu_system
                                     Shenandoah/h2 |                              concurrent_evacuation
                            Genshen/diluvian_large |                             transfer_old_from_satb
                                 Shenandoah/serial |                                      critical_jops
                        Genshen/extremem-large-45g |                                      trigger_learn


                                Only in experiment |                                    Only in control
-------------------------------------------------------------------------------------------------------
                       extremem-ff/trigger_failure |            scimark.fft.small/concurrent_evacuation
                                  tomcat/cwr_total |           scimark.lu.large/concurrent_strong_roots
                    extremem-ff/degen_update_roots |          scimark.fft.small/concurrent_thread_roots
                       extremem-ff/du_thread_roots |   scimark.fft.small/concurrent_update_thread_roots
                              extremem-ff/du_total |            scimark.fft.large/concurrent_weak_roots

Shenandoah
-------------------------------------------------------------------------------------------------------
+40.97% serial/concurrent_evacuation p=0.00668
  Control:     16.703ms (+/-  6.30ms)         45
  Test:        23.547ms (+/-  6.06ms)          8

+8.77% scimark.sor.large/cpu_system p=0.04575
  Control:      2.293s  (+/-  0.29s )         60
  Test:         2.494s  (+/-  0.25s )         10

+6.02% mpegaudio/cpu_system p=0.03141
  Control:      5.712s  (+/-  0.44s )         60
  Test:         6.056s  (+/-  0.54s )         10

-11.37% h2/dacapo_metered_latency_max p=0.04808
  Control:     31.523ms (+/-  4.40ms)         60
  Test:        28.305ms (+/-  3.24ms)         10

-11.37% h2/dacapo_simple_latency_max p=0.04811
  Control:     31.523ms (+/-  4.40ms)         60
  Test:        28.305ms (+/-  3.24ms)         10

-6.67% hyperalloc_a3072_o4096/trigger_learn p=0.01965
  Control:     11.333   (+/-  0.90  )         60
  Test:        10.625   (+/-  0.67  )         10


Genshen
-------------------------------------------------------------------------------------------------------
+31.13% extremem-large-45g/transfer_old_from_satb p=0.01612
  Control:      1.444ms (+/-267.77us)         25
  Test:         1.893ms (+/-560.32us)          4

-44.61% diluvian_large/pause_degenerated_gc_n p=0.00862
  Control:     23.097s  (+/-  6.86s )         36
  Test:        15.972s  (+/-  5.04s )         11

-44.61% diluvian_large/pause_degenerated_gc_g p=0.00862
  Control:     23.097s  (+/-  6.86s )         36
  Test:        15.972s  (+/-  5.04s )         11

-13.37% crypto.signverify/pause_init_update_refs_g p=0.04082
  Control:      2.807ms (+/-728.62us)         89
  Test:         2.477ms (+/-714.60us)         20

-13.04% specjbb2015/trigger_failure p=0.04891
  Control:    122.083   (+/- 22.98  )         60
  Test:       108.000   (+/- 28.48  )         10

-11.70% specjbb2015/sla_100000_jops p=0.00312
  Control:   6284.875   (+/-517.36  )         60
  Test:      5626.500   (+/-549.73  )         10

-10.18% extremem-phased/trigger_spike p=0.01099
  Control:     32.917   (+/-  3.76  )         60
  Test:        29.875   (+/-  2.64  )         10

-8.36% specjbb2015/sla_75000_jops p=0.04222
  Control:   6005.917   (+/-539.64  )         60
  Test:      5542.625   (+/-564.13  )         10

-6.26% specjbb2015/critical_jops p=0.02604
  Control:   5202.917   (+/-348.10  )         60
  Test:      4896.500   (+/-411.36  )         10

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


Pipeline: fix-is-good-progress-gh-aarch64
 Elapsed: 8:31:03.815824

[kdnilsen at amazon.com](mailto:kdnilsen at amazon.com)  : openjdk              : fix-is-goo : 2023-11-30 23:37:57+00:00 : e62dd2 : Change behavior of is_good_progerss
[kemperw at amazon.com](mailto:kemperw at amazon.com)   : codepipeline-helpers : mainline   : 2023-11-21 10:20:23-08:00 : f42398 : Add more detail from tlab messages

b05cfa4a-66b5-4d94-81b6-35f965db87c0: Smoke: 0:00:00 Integration: 6:38:22.240000

      294: Passed
      294: Total




   Control: shenandoah-aarch64-template
Experiment: fix-is-good-progress-gh-aarch64

                          Most impacted benchmarks |                              Most impacted metrics
-------------------------------------------------------------------------------------------------------
                            Genshen/diluvian_large |                                         cpu_system
                         Shenandoah/diluvian_large |                                  trigger_threshold
                                     Genshen/xalan |                               context_switch_count
                               Genshen/specjbb2015 |                                    fu_thread_roots
                           Genshen/diluvian_medium |                                calculate_addresses


                                Only in experiment |                                    Only in control
-------------------------------------------------------------------------------------------------------
                          avrora/jhiccup_max_pause |                  scimark.lu.large/cmr_thread_roots
                  mpegaudio/concurrent_update_refs |              scimark.sparse.large/cmr_thread_roots
                crypto.rsa/concurrent_thread_roots |                    mpegaudio/concurrent_mark_roots
                    diluvian_large/dcu_unlink_clds | scimark.sparse.small/concurrent_update_thread_roots
         scimark.lu.large/pause_init_update_refs_g |                           diluvian_large/cwr_total

Shenandoah
-------------------------------------------------------------------------------------------------------
+175.00% diluvian_large/trigger_threshold p=0.00004
  Control:      1.000   (+/-  0.00  )         40
  Test:         2.750   (+/-  0.48  )         10

-20.30% jme/cpu_system p=0.01368
  Control:      0.328s  (+/-  0.06s )         40
  Test:         0.273s  (+/-  0.04s )         10


Genshen
-------------------------------------------------------------------------------------------------------
-23.83% diluvian_large/pause_degenerated_gc_n p=0.00866
  Control:     25.834s  (+/-  4.48s )         32
  Test:        20.861s  (+/-  6.63s )         13

-23.83% diluvian_large/pause_degenerated_gc_g p=0.00866
  Control:     25.834s  (+/-  4.48s )         32
  Test:        20.861s  (+/-  6.63s )         13

-8.07% diluvian_large/calculate_addresses p=0.03028
  Control:      2.854s  (+/-284.07ms)         28
  Test:         2.641s  (+/-194.48ms)         10

-6.96% diluvian_medium/cpu_system p=0.03454
  Control:      2.345s  (+/-  0.21s )         50
  Test:         2.192s  (+/-  0.19s )         10

-5.73% specjbb2015/fu_thread_roots p=0.00000
  Control:      2.346ms (+/-203.14us)        238
  Test:         2.219ms (+/-126.57us)         48

-5.29% xalan/context_switch_count p=0.00851
  Control:  24231.100   (+/-2546.76  )         50
  Test:     23013.125   (+/-972.88  )         10

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

Commit messages:
 - Change behavior of is_good_progerss

Changes: https://git.openjdk.org/shenandoah/pull/364/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=364&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321149
  Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/364.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/364/head:pull/364

PR: https://git.openjdk.org/shenandoah/pull/364

From roland at openjdk.org  Fri Dec  1 16:55:08 2023
From: roland at openjdk.org (Roland Westrelin)
Date: Fri, 1 Dec 2023 16:55:08 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?

It could be useful for diagnostic purposes. Say if a user reports a crash, one trouble shooting step could be to ask them to run with `ShenandoahLoopOptsAfterExpansion` off. This said, that never happened AFAIK. So I don't have a strong opinion. I'm also wondering if: they make an actual difference performance wise? with other changes that happened in the meantime, are they still doing anything useful?

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1836454231

From wkemper at openjdk.org  Fri Dec  1 18:14:44 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 1 Dec 2023 18:14:44 GMT
Subject: RFR: 8321149: GenShen: Test for is_good_progress() following degen
 needs to sum all available memory
In-Reply-To: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
References: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
Message-ID: <Q0SgdnjTjde9-DHpzF0kXuBj0VHE_XCC5Nz4tlUtL28=.c582f3b7-849c-42f3-9888-9bf5cb4c4c12@github.com>

On Fri, 1 Dec 2023 15:51:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This reduces the sensitivity of the trigger that upgrades to Full GC following a completed degenerated GC.  The change was motivated by examination of a test workload that required one more full GC and one more degenerated GC than was expected.  Upon examination of the GC log, it was determined that the extra Full GC was triggered because the mutator free set following degen was approximately 10% below the critical threshold, even though the total available memory within heap was more than three fold the critical threshold.  
> 
> Following this change, no Full GCs were required and one fewer degenerated cycle was required (which had occurred immediately following the Full GC due to the long unproductive STW the pause caused by Full GC).  P50 latency improved by 15%, and p100 latencies improved by over 100 fold.
> 
> More comprehensive testing over a broader set of workloads reveals this change is not "universally better".  Of particular concern is degradation of specjbb numbers on x86, but not aarch64, tests.  I'm inclined to believe this change represents net improvement, but it would be best to delay integration until we have a better understanding of specjbb performance issues, and how they might be impacted by this change.
> 
> 
> 
>    Control: shenandoah-x86-template
> Experiment: fix-is-good-progress-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                Genshen/specjbb2015 |                                         cpu_system
>                                      Shenandoah/h2 |                              concurrent_evacuation
>                             Genshen/diluvian_large |                             transfer_old_from_satb
>                                  Shenandoah/serial |                                      critical_jops
>                         Genshen/extremem-large-45g |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                        extremem-ff/trigger_failure |            scimark.fft.small/concurrent_evacuation
>                                   tomcat/cwr_total |           scimark.lu.large/concurrent_strong_roots
>                     extremem-ff/de...

src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp line 1:

> 1: /*

We need to think about what _good progress_ means... In my mind, it means the _mutators_ have enough memory to last them through a concurrent cycle. Maybe we ought to have this code evaluate the allocation rate and gc times as the heuristics do? Alternatively, we could also reduce `ShenandoahCriticalFreeThreshold` to achieve a similar end? Or, for generational mode, we should look at how much memory the degenerated cycle made available in the _young_ generation?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/364#discussion_r1412432036

From kdnilsen at openjdk.org  Fri Dec  1 23:53:21 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 1 Dec 2023 23:53:21 GMT
Subject: RFR: 8321149: GenShen: Test for is_good_progress() following degen
 needs to sum all available memory
In-Reply-To: <Q0SgdnjTjde9-DHpzF0kXuBj0VHE_XCC5Nz4tlUtL28=.c582f3b7-849c-42f3-9888-9bf5cb4c4c12@github.com>
References: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
 <Q0SgdnjTjde9-DHpzF0kXuBj0VHE_XCC5Nz4tlUtL28=.c582f3b7-849c-42f3-9888-9bf5cb4c4c12@github.com>
Message-ID: <j47SsZ7eMi5csGVffM39fOq3uW4cmeapJRpAHTepvfI=.47053840-44ad-4331-a1bc-1b2a7a82cb3f@github.com>

On Fri, 1 Dec 2023 18:12:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This reduces the sensitivity of the trigger that upgrades to Full GC following a completed degenerated GC.  The change was motivated by examination of a test workload that required one more full GC and one more degenerated GC than was expected.  Upon examination of the GC log, it was determined that the extra Full GC was triggered because the mutator free set following degen was approximately 10% below the critical threshold, even though the total available memory within heap was more than three fold the critical threshold.  
>> 
>> Following this change, no Full GCs were required and one fewer degenerated cycle was required (which had occurred immediately following the Full GC due to the long unproductive STW the pause caused by Full GC).  P50 latency improved by 15%, and p100 latencies improved by over 100 fold.
>> 
>> More comprehensive testing over a broader set of workloads reveals this change is not "universally better".  Of particular concern is degradation of specjbb numbers on x86, but not aarch64, tests.  I'm inclined to believe this change represents net improvement, but it would be best to delay integration until we have a better understanding of specjbb performance issues, and how they might be impacted by this change.
>> 
>> 
>> 
>>    Control: shenandoah-x86-template
>> Experiment: fix-is-good-progress-gh-x86
>> 
>>                           Most impacted benchmarks |                              Most impacted metrics
>> -------------------------------------------------------------------------------------------------------
>>                                Genshen/specjbb2015 |                                         cpu_system
>>                                      Shenandoah/h2 |                              concurrent_evacuation
>>                             Genshen/diluvian_large |                             transfer_old_from_satb
>>                                  Shenandoah/serial |                                      critical_jops
>>                         Genshen/extremem-large-45g |                                      trigger_learn
>> 
>> 
>>                                 Only in experiment |                                    Only in control
>> -------------------------------------------------------------------------------------------------------
>>                        extremem-ff/trigger_failure |            scimark.fft.small/concurrent_evacuation
>>                                   tomcat/cwr_total |           scimark.lu.large/concurrent...
>
> src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp line 1:
> 
>> 1: /*
> 
> We need to think about what _good progress_ means... In my mind, it means the _mutators_ have enough memory to last them through a concurrent cycle. Maybe we ought to have this code evaluate the allocation rate and gc times as the heuristics do? Alternatively, we could also reduce `ShenandoahCriticalFreeThreshold` to achieve a similar end? Or, for generational mode, we should look at how much memory the degenerated cycle made available in the _young_ generation?

Thanks.  These are good insights.  I will explore further.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/364#discussion_r1412669834

From kdnilsen at openjdk.org  Sat Dec  2 00:40:16 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 2 Dec 2023 00:40:16 GMT
Subject: RFR: 8321149: GenShen: Test for is_good_progress() following degen
 needs to sum all available memory
In-Reply-To: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
References: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
Message-ID: <E6IhHimUgqnw1_XH1wWNWNWz9HvZWGC_P3QDZku-l68=.e1db3405-c278-4d90-9251-33366c0ad5ea@github.com>

On Fri, 1 Dec 2023 15:51:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This reduces the sensitivity of the trigger that upgrades to Full GC following a completed degenerated GC.  The change was motivated by examination of a test workload that required one more full GC and one more degenerated GC than was expected.  Upon examination of the GC log, it was determined that the extra Full GC was triggered because the mutator free set following degen was approximately 10% below the critical threshold, even though the total available memory within heap was more than three fold the critical threshold.  
> 
> Following this change, no Full GCs were required and one fewer degenerated cycle was required (which had occurred immediately following the Full GC due to the long unproductive STW the pause caused by Full GC).  P50 latency improved by 15%, and p100 latencies improved by over 100 fold.
> 
> More comprehensive testing over a broader set of workloads reveals this change is not "universally better".  Of particular concern is degradation of specjbb numbers on x86, but not aarch64, tests.  I'm inclined to believe this change represents net improvement, but it would be best to delay integration until we have a better understanding of specjbb performance issues, and how they might be impacted by this change.
> 
> 
> 
>    Control: shenandoah-x86-template
> Experiment: fix-is-good-progress-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                Genshen/specjbb2015 |                                         cpu_system
>                                      Shenandoah/h2 |                              concurrent_evacuation
>                             Genshen/diluvian_large |                             transfer_old_from_satb
>                                  Shenandoah/serial |                                      critical_jops
>                         Genshen/extremem-large-45g |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                        extremem-ff/trigger_failure |            scimark.fft.small/concurrent_evacuation
>                                   tomcat/cwr_total |           scimark.lu.large/concurrent_strong_roots
>                     extremem-ff/de...

I'm going back to the drawing board on this one...

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

PR Comment: https://git.openjdk.org/shenandoah/pull/364#issuecomment-1836960846

From kdnilsen at openjdk.org  Sat Dec  2 00:40:16 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 2 Dec 2023 00:40:16 GMT
Subject: Withdrawn: 8321149: GenShen: Test for is_good_progress() following
 degen needs to sum all available memory
In-Reply-To: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
References: <FCe1LUAS1UG6t09dgOORU9NxR38v83owGI_TpcoxtoM=.482c7dd6-10d6-4959-8a42-29c07918e170@github.com>
Message-ID: <axJHBSHlAiGghKYol1IohTw2kTq2RrxvBzb0oI1o5Kg=.98ced141-d801-4b45-8130-a579b75b1779@github.com>

On Fri, 1 Dec 2023 15:51:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This reduces the sensitivity of the trigger that upgrades to Full GC following a completed degenerated GC.  The change was motivated by examination of a test workload that required one more full GC and one more degenerated GC than was expected.  Upon examination of the GC log, it was determined that the extra Full GC was triggered because the mutator free set following degen was approximately 10% below the critical threshold, even though the total available memory within heap was more than three fold the critical threshold.  
> 
> Following this change, no Full GCs were required and one fewer degenerated cycle was required (which had occurred immediately following the Full GC due to the long unproductive STW the pause caused by Full GC).  P50 latency improved by 15%, and p100 latencies improved by over 100 fold.
> 
> More comprehensive testing over a broader set of workloads reveals this change is not "universally better".  Of particular concern is degradation of specjbb numbers on x86, but not aarch64, tests.  I'm inclined to believe this change represents net improvement, but it would be best to delay integration until we have a better understanding of specjbb performance issues, and how they might be impacted by this change.
> 
> 
> 
>    Control: shenandoah-x86-template
> Experiment: fix-is-good-progress-gh-x86
> 
>                           Most impacted benchmarks |                              Most impacted metrics
> -------------------------------------------------------------------------------------------------------
>                                Genshen/specjbb2015 |                                         cpu_system
>                                      Shenandoah/h2 |                              concurrent_evacuation
>                             Genshen/diluvian_large |                             transfer_old_from_satb
>                                  Shenandoah/serial |                                      critical_jops
>                         Genshen/extremem-large-45g |                                      trigger_learn
> 
> 
>                                 Only in experiment |                                    Only in control
> -------------------------------------------------------------------------------------------------------
>                        extremem-ff/trigger_failure |            scimark.fft.small/concurrent_evacuation
>                                   tomcat/cwr_total |           scimark.lu.large/concurrent_strong_roots
>                     extremem-ff/de...

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah/pull/364

From tschatzl at openjdk.org  Mon Dec  4 07:56:04 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 4 Dec 2023 07:56:04 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v5]
In-Reply-To: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
Message-ID: <CwzzzfQ58XxXfnDqObrMcxcYAV7EvPzcugocjA8JX2Q=.fc2e9fe3-773a-447b-8654-a5c0c0092d21@github.com>

> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
> 
> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
> 
> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
> 
> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
> 
> Upcoming changes will
> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
> 
> Please also first looking into the (small) PR this depends on.
> 
> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
> 
> Testing: tier1-7
> 
> Thanks,
>   Thomas

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

 - Merge branch 'master' into 8317809-sorted-insertion-of-free-blobs
 - remove trailing whitespace
 - fix indentation after recent commit
 - Address ayang/iwalulya review comments, remove inheritance in ClassUnloadingContext for now as unnecessary for this change, use iterators, other review comments
 - Merge branch 'master' into mergeme
 - iwalulya review, naming
 - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
   
   Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
   GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
   
   The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
   this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
   insertion to allow for concurrent users for the lock to progress.
   
   Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
   CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
   towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
   
   Upcoming changes will
   * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
     reduce code purging time for the STW collectors.
   * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
   * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
     parallelism
   * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
   * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
 - Only run test case on debug VMs, sufficient
 - 8320331 g1 full gc "during" verification accesses half-unloaded metadata

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

Changes: https://git.openjdk.org/jdk/pull/16759/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16759&range=04
  Stats: 474 lines in 28 files changed: 347 ins; 83 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/16759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16759/head:pull/16759

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

From shade at openjdk.org  Mon Dec  4 08:22:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 4 Dec 2023 08:22:46 GMT
Subject: Integrated: 8321120: Shenandoah: Remove ShenandoahElasticTLAB flag
In-Reply-To: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>
References: <P8f66OTqbmkHO6YapjCxgX-LWR8cJOnpsK_KsckBZCo=.70d0af35-f36d-4e8b-aa86-b3f110ca7925@github.com>
Message-ID: <_41KszjxJh2oN8zr4F09pC57VosIQjSqsdK_7r7WQBg=.e0b34729-cfdd-4df1-9120-6578a80dcd72@github.com>

On Thu, 30 Nov 2023 15:50:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have added `ShenandoahElasticTLAB` a long time ago, to provide the escape hatch if elastic TLABs would misbehave. We have been running with elastic TLABs for years without problems. Taking care of elastic/non-elastic TLAB allocs adds to technical debt. 
> 
> Additional testing:
>   - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 93b9235f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93b9235f19dab2a0c08ba8a1afcc82ee71be4c0b
Stats:     92 lines in 5 files changed: 0 ins; 87 del; 5 mod

8321120: Shenandoah: Remove ShenandoahElasticTLAB flag

Reviewed-by: kdnilsen, ysr

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

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

From shade at openjdk.org  Mon Dec  4 08:23:41 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 4 Dec 2023 08:23:41 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
 <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
Message-ID: <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>

On Fri, 1 Dec 2023 16:52:45 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> > More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> It could be useful for diagnostic purposes. Say if a user reports a crash, one trouble shooting step could be to ask them to run with `ShenandoahLoopOptsAfterExpansion` off. This said, that never happened AFAIK. So I don't have a strong opinion. I'm also wondering if: they make an actual difference performance wise? with other changes that happened in the meantime, are they still doing anything useful?

I think we want to keep the flag list from growing, and this is one of the steps of culling the flags we do not need anymore. I cannot remember a case when this flag was useful either. I think long-term we want to switch to late barrier insertion anyway, which would render this flag obsolete. We can remove the flag when that happens, if you prefer.

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1838046406

From ayang at openjdk.org  Mon Dec  4 09:11:41 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Dec 2023 09:11:41 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v4]
In-Reply-To: <2_ONmN3qxsdTIEJMbQhE82nBn10l_RnZm5-DZAmQn2I=.9ad49c74-3721-4299-8a9e-b8c1973eb494@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <2_ONmN3qxsdTIEJMbQhE82nBn10l_RnZm5-DZAmQn2I=.9ad49c74-3721-4299-8a9e-b8c1973eb494@github.com>
Message-ID: <jjEeqgvIEfGA2OVuC26Dr1S29yQRaU9eCL2RGaWNqd4=.7934afac-f0b8-412b-beba-1c9f803f9462@github.com>

On Thu, 30 Nov 2023 11:38:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> Please also first looking into the (small) PR this depends on.
>> 
>> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
>> 
>> Testing: tier1-7
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove trailing whitespace
>  - fix indentation after recent commit
>  - Address ayang/iwalulya review comments, remove inheritance in ClassUnloadingContext for now as unnecessary for this change, use iterators, other review comments

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1686:

> 1684:   // Unload Klasses, String, Code Cache, etc.
> 1685:   if (ClassUnloadingWithConcurrentMark) {
> 1686:     _g1h->unload_classes_and_code("Class Unloading", &is_alive, _gc_timer_cm);

Kind of preexisting: I'd not expect find "Class Unloading" inside `weak_refs_work()`. Its caller level is more reasonable, IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1410762799

From ayang at openjdk.org  Mon Dec  4 09:11:47 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Dec 2023 09:11:47 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v5]
In-Reply-To: <CwzzzfQ58XxXfnDqObrMcxcYAV7EvPzcugocjA8JX2Q=.fc2e9fe3-773a-447b-8654-a5c0c0092d21@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <CwzzzfQ58XxXfnDqObrMcxcYAV7EvPzcugocjA8JX2Q=.fc2e9fe3-773a-447b-8654-a5c0c0092d21@github.com>
Message-ID: <rfn5tdlG-ycznoOuh8Gew_uAbpMgx8UAIroko-rpQH0=.873b1225-7c5a-4e83-bd37-a49b512d0f92@github.com>

On Mon, 4 Dec 2023 07:56:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> Please also first looking into the (small) PR this depends on.
>> 
>> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
>> 
>> Testing: tier1-7
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into 8317809-sorted-insertion-of-free-blobs
>  - remove trailing whitespace
>  - fix indentation after recent commit
>  - Address ayang/iwalulya review comments, remove inheritance in ClassUnloadingContext for now as unnecessary for this change, use iterators, other review comments
>  - Merge branch 'master' into mergeme
>  - iwalulya review, naming
>  - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>    
>    Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
>    GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>    
>    The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
>    this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
>    insertion to allow for concurrent users for the lock to progress.
>    
>    Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
>    CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
>    towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>    
>    Upcoming changes will
>    * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
>      reduce code purging time for the STW collectors.
>    * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>    * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
>      parallelism
>    * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>    * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>  - Only run test case on debug VMs, sufficient
>  - 8320331 g1 full gc "during" verification accesses half-unloa...

src/hotspot/share/gc/shared/classUnloadingContext.hpp line 38:

> 36:   static ClassUnloadingContext* _context;
> 37: 
> 38:   ClassLoaderData* volatile _cld_head;

I don't get why `ClassLoaderData* volatile _cld_head;` needs to be inside `ClassUnloadingContext`. What's the motivation for the change to files in `src/hotspot/share/classfile/`? Seems that they have nothing to do with other fields inside this class, which are for sort-before-free of nmethods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1413566268

From tschatzl at openjdk.org  Mon Dec  4 11:15:41 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 4 Dec 2023 11:15:41 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v4]
In-Reply-To: <jjEeqgvIEfGA2OVuC26Dr1S29yQRaU9eCL2RGaWNqd4=.7934afac-f0b8-412b-beba-1c9f803f9462@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <2_ONmN3qxsdTIEJMbQhE82nBn10l_RnZm5-DZAmQn2I=.9ad49c74-3721-4299-8a9e-b8c1973eb494@github.com>
 <jjEeqgvIEfGA2OVuC26Dr1S29yQRaU9eCL2RGaWNqd4=.7934afac-f0b8-412b-beba-1c9f803f9462@github.com>
Message-ID: <Ej54UY_Ki-8cEjOEe3duKTkCYHs71nwdVFu4oUoyiBw=.7ac150de-7b32-4474-b930-fe524df830ec@github.com>

On Thu, 30 Nov 2023 14:36:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove trailing whitespace
>>  - fix indentation after recent commit
>>  - Address ayang/iwalulya review comments, remove inheritance in ClassUnloadingContext for now as unnecessary for this change, use iterators, other review comments
>
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1686:
> 
>> 1684:   // Unload Klasses, String, Code Cache, etc.
>> 1685:   if (ClassUnloadingWithConcurrentMark) {
>> 1686:     _g1h->unload_classes_and_code("Class Unloading", &is_alive, _gc_timer_cm);
> 
> Kind of preexisting: I'd not expect find "Class Unloading" inside `weak_refs_work()`. Its caller level is more reasonable, IMO.

So what is your suggestion here?
In some way CLDs and nmethods are weak references, so I can see reason for the original placement, but since it's a fairly large chunk of functionality one might expect it at a higher level.
If so, I can move it in a separate patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1413725314

From tschatzl at openjdk.org  Mon Dec  4 11:15:46 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 4 Dec 2023 11:15:46 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v5]
In-Reply-To: <rfn5tdlG-ycznoOuh8Gew_uAbpMgx8UAIroko-rpQH0=.873b1225-7c5a-4e83-bd37-a49b512d0f92@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <CwzzzfQ58XxXfnDqObrMcxcYAV7EvPzcugocjA8JX2Q=.fc2e9fe3-773a-447b-8654-a5c0c0092d21@github.com>
 <rfn5tdlG-ycznoOuh8Gew_uAbpMgx8UAIroko-rpQH0=.873b1225-7c5a-4e83-bd37-a49b512d0f92@github.com>
Message-ID: <E7-yy8bYTkhyuyYbI2EZKWUGxhss9BiX2ZuX66_Z7Lk=.26bac7b3-4fad-470d-9f65-e09dcf77f4b2@github.com>

On Mon, 4 Dec 2023 09:08:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Merge branch 'master' into 8317809-sorted-insertion-of-free-blobs
>>  - remove trailing whitespace
>>  - fix indentation after recent commit
>>  - Address ayang/iwalulya review comments, remove inheritance in ClassUnloadingContext for now as unnecessary for this change, use iterators, other review comments
>>  - Merge branch 'master' into mergeme
>>  - iwalulya review, naming
>>  - 8317809 Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>>    
>>    Introduce a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading.
>>    GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>>    
>>    The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform
>>    this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every
>>    insertion to allow for concurrent users for the lock to progress.
>>    
>>    Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing
>>    CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared
>>    towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>>    
>>    Upcoming changes will
>>    * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly
>>      reduce code purging time for the STW collectors.
>>    * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>>    * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better
>>      parallelism
>>    * G1: move some signifcant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>>    * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>>  - Only run test case on debug VMs, sufficient
>>  ...
>
> src/hotspot/share/gc/shared/classUnloadingContext.hpp line 38:
> 
>> 36:   static ClassUnloadingContext* _context;
>> 37: 
>> 38:   ClassLoaderData* volatile _cld_head;
> 
> I don't get why `ClassLoaderData* volatile _cld_head;` needs to be inside `ClassUnloadingContext`. What's the motivation for the change to files in `src/hotspot/share/classfile/`? Seems that they have nothing to do with other fields inside this class, which are for sort-before-free of nmethods.

This change introduces a `ClassUnloadingContext`, not a `NmethodUnloadingContext`, and class (and nmethod) unloading consists of both (unloaded) class handling and (unloaded) nmethod handling.
I did not want to first introduce a `NmethodUnloadingContext` that will soon be changed to the `ClassUnloadingContext` anyway as for easier parallel access to the CLDs a bit later.
A `ClassUnloadingContext` without handling CLDs seems odd, and just fixing the nmethod stuff only seems just busywork for both the author and the reviewers later (for the sake of having minimal patches).

However if you insist on changing this, I can remove the CLD handling and rename everything now and later again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1413723381

From tschatzl at openjdk.org  Mon Dec  4 12:39:59 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 4 Dec 2023 12:39:59 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
Message-ID: <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>

> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
> 
> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
> 
> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
> 
> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
> 
> Upcoming changes will
> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
> 
> Please also first looking into the (small) PR this depends on.
> 
> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
> 
> Testing: tier1-7
> 
> Thanks,
>   Thomas

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

  ayang review: move class unloading outside of weak_refs_work

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16759/files
  - new: https://git.openjdk.org/jdk/pull/16759/files/f8ddc131..4afd996a

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

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

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

From ayang at openjdk.org  Mon Dec  4 13:00:46 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 4 Dec 2023 13:00:46 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
Message-ID: <vBx_MECfaaMzUjUakuuucrMuGo93QkFQd5XV-yvreS4=.c44d9bef-e161-442f-99e6-25c36e448667@github.com>

On Mon, 4 Dec 2023 12:39:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> Please also first looking into the (small) PR this depends on.
>> 
>> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
>> 
>> Testing: tier1-7
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review: move class unloading outside of weak_refs_work

Only one minor & subjective comment.

src/hotspot/share/gc/shared/classUnloadingContext.hpp line 69:

> 67:   void register_unlinked_nmethod(nmethod* nm);
> 68:   void purge_nmethods();
> 69:   void free_code_blobs();

I feel this is exposing too much detail, especially when the adjacent API just combines them.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16759#pullrequestreview-1762337991
PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1413833775

From tschatzl at openjdk.org  Mon Dec  4 13:55:41 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 4 Dec 2023 13:55:41 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
Message-ID: <ep1ZuufxqgoPVh2v85j4RX0eVG5eF6DFDRN1VzvIaoc=.a3942052-15ce-4597-a0ed-a24c907c9c38@github.com>

On Mon, 4 Dec 2023 12:39:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> Please also first looking into the (small) PR this depends on.
>> 
>> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
>> 
>> Testing: tier1-7
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review: move class unloading outside of weak_refs_work

Fwiw, to put this change in a bit more context: it  is part of a series of changes to improve class unloading performance back to pre-jdk21 levels (and better).

The basic plan:

* this change, [JDK-8317809](https://bugs.openjdk.org/browse/JDK-8317809), that improves nmethod sorting/free list handling (and introduces the ClassUnloadingContext)

* [JDK-8317007](https://bugs.openjdk.org/browse/JDK-8317007) that allows bulk unregistering of nmethods instead of (slow) per-nmethod unregistering (also out for review)

With the above two changes, Remark pause time should be <= before removal of the code root sweeper (lots of changes went in already that improved time taken for various parts of the class/code unloading).

I am planning the following follow-ups in the next few months (after FC time will be spent on bugfixing, and holidays coming up):

* (for G1) move out several parts of class unloading into the concurrent phase, at least this will include
    - bulk nmethod unregistering ([JDK-8317007](https://bugs.openjdk.org/browse/JDK-8317007))
    - nmethod code blob freeing (this change)
    - metaspace unloading

Not necessarily in a single change; this basically halves g1 remark pause times again in my testing.

* split up and parallelize ClassLoaderData unloading; currently with this change, when registering CLDs CLD->unload() is immediately called as before. However this is wasteful as most of that method can either be "obviously" parallelized or made so that other tasks can run in parallel.
So the plan is that class unloading (`SystemDictionary::do_unloading`) will be split into a part that iterates only over the CLD list to determine dead ones, and a parallel part. 

There are no CR/PRs out for these latter two items, but hopefully this will short of making everything concurrent keep class/code unloading times low enough for some time.

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

PR Comment: https://git.openjdk.org/jdk/pull/16759#issuecomment-1838687260

From roland at openjdk.org  Mon Dec  4 14:16:40 2023
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 4 Dec 2023 14:16:40 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
 <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
 <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>
Message-ID: <8yB2OpjTUTHG6E1Wb_Ry5F9HuMinHSY-yt-2eDSB3zw=.8878b365-2275-4227-a8fe-058c6cb7cebe@github.com>

On Mon, 4 Dec 2023 08:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think we want to keep the flag list from growing, and this is one of the steps of culling the flags we do not need anymore. I cannot remember a case when this flag was useful either.

Ok. Then.

> I think long-term we want to switch to late barrier insertion anyway, which would render this flag obsolete.

They seem to be different things to me. Having the ability to optimize the barrier after it's expanded or inserted seems like a useful thing to have in any case. Is there evidence that late barrier insertion would solve existing issues?

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1838723895

From shade at openjdk.org  Mon Dec  4 15:47:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 4 Dec 2023 15:47:37 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <8yB2OpjTUTHG6E1Wb_Ry5F9HuMinHSY-yt-2eDSB3zw=.8878b365-2275-4227-a8fe-058c6cb7cebe@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
 <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
 <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>
 <8yB2OpjTUTHG6E1Wb_Ry5F9HuMinHSY-yt-2eDSB3zw=.8878b365-2275-4227-a8fe-058c6cb7cebe@github.com>
Message-ID: <9wc8yRtwoi-AmBI_kEQOJSwXnDRzlQaBVSOA8GpVO84=.9f60a36f-c26e-4e1f-b2cb-050780ed5ff6@github.com>

On Mon, 4 Dec 2023 14:13:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> > I think long-term we want to switch to late barrier insertion anyway, which would render this flag obsolete.
> 
> They seem to be different things to me. Having the ability to optimize the barrier after it's expanded or inserted seems like a useful thing to have in any case. Is there evidence that late barrier insertion would solve existing issues?

I thought late barrier insertion basically avoids dealing with any optimizer questions, as we insert the barriers close to emit. So if we are to do late barrier insertion, we don't need the bulk of barrier optimization code? Maybe I misunderstand where late barrier insertion fits in C2.

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1838919728

From roland at openjdk.org  Mon Dec  4 15:55:40 2023
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 4 Dec 2023 15:55:40 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <9wc8yRtwoi-AmBI_kEQOJSwXnDRzlQaBVSOA8GpVO84=.9f60a36f-c26e-4e1f-b2cb-050780ed5ff6@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
 <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
 <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>
 <8yB2OpjTUTHG6E1Wb_Ry5F9HuMinHSY-yt-2eDSB3zw=.8878b365-2275-4227-a8fe-058c6cb7cebe@github.com>
 <9wc8yRtwoi-AmBI_kEQOJSwXnDRzlQaBVSOA8GpVO84=.9f60a36f-c26e-4e1f-b2cb-050780ed5ff6@github.com>
Message-ID: <Q5fv7OhPpgFkx72U0OWaoBqc---tCmjACHnOgyUKcUo=.c207b086-3ec9-4938-ba8a-36a67104bd66@github.com>

On Mon, 4 Dec 2023 15:45:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I thought late barrier insertion basically avoids dealing with any optimizer questions, as we insert the barriers close to emit. So if we are to do late barrier insertion, we don't need the bulk of barrier optimization code? Maybe I misunderstand where late barrier insertion fits in C2.

But the flag you're removing controls optimizations of the barrier code once expanded. For instance:
1)

a' = barrier(a);
b' = barrier(b);

is expanded to:
2)

if (heap_stable) {
  a' = a;
}  else {
  a' = slow_case(a);
}
if (heap_stable) {
  b' = b;
}  else {
  b' = slow_case(b);
}

which is then optimized under the `ShenandoahLoopOptsAfterExpansion` flag to:
3)

if (heap_stable) {
  a' = a;
  b' = b;
}  else {
  a' = slow_case(a);
  b' = slow_case(b);
}

Late insertion gives 2) without 1) but it doesn't give you 3). Depending where insertion happens (I haven't looked at zgc code) you could still do 3) next or it would be too late.

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1838935805

From iwalulya at openjdk.org  Tue Dec  5 10:17:36 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 5 Dec 2023 10:17:36 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
Message-ID: <6SIvBc11xioUfOBp7ywrO5T1wbE3yvwo6kCLXfYVz6c=.2284c684-38d3-436e-9bf0-34a662a5a73f@github.com>

On Mon, 4 Dec 2023 12:39:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> Please also first looking into the (small) PR this depends on.
>> 
>> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
>> 
>> Testing: tier1-7
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review: move class unloading outside of weak_refs_work

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16759#pullrequestreview-1764645335

From tschatzl at openjdk.org  Tue Dec  5 10:40:57 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 5 Dec 2023 10:40:57 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <vBx_MECfaaMzUjUakuuucrMuGo93QkFQd5XV-yvreS4=.c44d9bef-e161-442f-99e6-25c36e448667@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
 <vBx_MECfaaMzUjUakuuucrMuGo93QkFQd5XV-yvreS4=.c44d9bef-e161-442f-99e6-25c36e448667@github.com>
Message-ID: <3gKHRtjSjtbzvd3oXVu6w5axjWfSg9CDLVO53OipxTM=.373a814d-fc5c-41e4-86af-b8f133b6e255@github.com>

On Mon, 4 Dec 2023 12:57:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ayang review: move class unloading outside of weak_refs_work
>
> Only one minor & subjective comment.

Thanks @albertnetymk @walulyai for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/16759#issuecomment-1840480439

From tschatzl at openjdk.org  Tue Dec  5 10:40:59 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 5 Dec 2023 10:40:59 GMT
Subject: Integrated: 8317809: Insertion of free code blobs into code cache can
 be very slow during class unloading
In-Reply-To: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
Message-ID: <vzu0LW9VadA0B1Xe5YTkYEKaPhITgK_KN9jvaGb27dA=.e69e5757-d7d9-4227-898e-ce3fbbecc748@github.com>

On Tue, 21 Nov 2023 11:03:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
> 
> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
> 
> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
> 
> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
> 
> Upcoming changes will
> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
> 
> Please also first looking into the (small) PR this depends on.
> 
> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
> 
> Testing: tier1-7
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 30817b74
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30817b742300f10f566e6aee3a8c1f8af4ab3083
Stats:     483 lines in 28 files changed: 352 ins; 87 del; 44 mod

8317809: Insertion of free code blobs into code cache can be very slow during class unloading

Reviewed-by: iwalulya, ayang

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

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

From kdnilsen at openjdk.org  Tue Dec  5 14:46:24 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Dec 2023 14:46:24 GMT
Subject: RFR: 8321401: GenShen: Each mutator must see FullGC before throwing
 OOM
Message-ID: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>

Require each thread to observe unproductive Full GC before it throws OOM exception.

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

Commit messages:
 - Fix test and remove conditionally compiled redundant code
 - Require full gc before throwing out-of-memory

Changes: https://git.openjdk.org/shenandoah/pull/365/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=365&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321401
  Stats: 15 lines in 2 files changed: 2 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/365.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/365/head:pull/365

PR: https://git.openjdk.org/shenandoah/pull/365

From kdnilsen at openjdk.org  Tue Dec  5 14:51:34 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Dec 2023 14:51:34 GMT
Subject: RFR: 8321401: GenShen: Each mutator must see FullGC before
 throwing OOM [v2]
In-Reply-To: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>
References: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>
Message-ID: <BGjXwg5ii6NEGhB7zcuGUAxuS9HIPl_P-3aq-1NJ2I8=.63371d97-3ebe-4918-9325-2b134a81454a@github.com>

> Require each thread to observe unproductive Full GC before it throws OOM exception.

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

  Fixup comment

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/365/files
  - new: https://git.openjdk.org/shenandoah/pull/365/files/92b814f3..6d6f16db

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

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

PR: https://git.openjdk.org/shenandoah/pull/365

From coleenp at openjdk.org  Tue Dec  5 15:50:59 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 5 Dec 2023 15:50:59 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
Message-ID: <oUFBDsltTslCD1wtUe378o-v56BmFoJAkoOZNcwO0_U=.7596433d-b05f-48ef-9fb4-ede7cde3a8a3@github.com>

On Mon, 4 Dec 2023 12:39:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Insert code blobs in a sorted fashion to exploit the finger-optimization when adding, making this procedure O(n) instead of O(n^2)
>> 
>> Introduces a globally available ClassUnloadingContext that contains common methods pertaining to class and code unloading. GCs may use it to efficiently manage unlinked class loader datas and nmethods to allow use of common methods (unlink/merge).
>> 
>> The steps typically are registering a new to be unlinked CLD/nmethod, and then purge its memory later. STW collectors perform this work in one big chunk taking the CodeCache_lock, for the entire duration, while concurrent collectors lock/unlock for every insertion to allow for concurrent users for the lock to progress.
>> 
>> Some care has been taken to stay consistent with an "unloading = unlinking + purge" scheme; however particularly the existing CLD handling API (still) mixes unlinking and purging in its CLD::unload() call. To simplify this change that is mostly geared towards separating nmethod unlinking from purging, to make code blob freeing O(n) instead of O(n^2).
>> 
>> Upcoming changes will
>> * separate nmethod unregistering from nmethod purging to allow doing that in bulk (for the STW collectors); that can significantly reduce code purging time for the STW collectors.
>> * better name the second stage of unlinking (called "cleaning" throughout, e.g. the work done in `G1CollectedHeap::complete_cleaning`)
>> * untangle CLD unlinking and what's called "cleaning" now to allow moving more stuff into the second unlinking stage for better parallelism
>> * G1: move some significant tasks from the remark pause to concurrent (unregistering nmethods, freeing code blobs and cld/metaspace purging)
>> * Maybe move Serial/Parallel GC metaspace purging closer to other unlinking/purging code to keep things local and allow easier logging.
>> 
>> Please also first looking into the (small) PR this depends on.
>> 
>> The crash on linux-x86 is fixed by PR#16766 which I split out for quicker reviews.
>> 
>> Testing: tier1-7
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review: move class unloading outside of weak_refs_work

src/hotspot/share/gc/shared/classUnloadingContext.cpp line 91:

> 89:     cld->classes_do(f);
> 90:   }
> 91: }

I don't understand why CLDG specific methods were moved here.  They should be unaware of nmethod purging. and these 4 methods don't have any nmethod purging in them either and are specific to the CLDG implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1415844874

From cslucas at openjdk.org  Tue Dec  5 16:57:59 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 5 Dec 2023 16:57:59 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v4]
In-Reply-To: <vIOl1oVXMbl6Y2oIJqsknuCxTc4ikM2sQ3xQbmI_OB8=.3b8a4cf3-87d8-450b-9952-e71463db8ce7@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <h1AmMexga4JM1boU-1EEIk0dX_7EHkxk9RD8V9myD9s=.b736a16c-09fd-4854-94b5-a488cb86f4e1@github.com>
 <vIOl1oVXMbl6Y2oIJqsknuCxTc4ikM2sQ3xQbmI_OB8=.3b8a4cf3-87d8-450b-9952-e71463db8ce7@github.com>
Message-ID: <Ny-0AJyX1peLL-86cc6l8rV25wo1iuJCZWHh-v6wFvc=.bf22abca-111e-4a47-94f2-325e332ac024@github.com>

On Fri, 1 Dec 2023 03:07:33 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1246:
> 
>> 1244:     if (_next_call_type == INVOKESTATIC || _next_call_type == INVOKESPECIAL) {
>> 1245:       // Need a static call stub for transitions from compiled to interpreted.
>> 1246:       C2_MacroAssembler masm(&buffer);
> 
> Hi, I encountered one build failure: JDK build **without C2** fails on Linux/AArch64.
> 
> The configure I used
> 
> 
> --with-debug-level=release --with-jvm-features=-compiler2 --disable-precompiled-headers
> 
> 
> The error log
> 
> 
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
> /usr/bin/ld: /tmp/build-release/hotspot/variant-server/libjvm/objs/jvmciCodeInstaller.o: in function `C2_MacroAssembler::C2_MacroAssembler(CodeBuffer*)':
> make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
> /usr/bin/ld: make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
> collect2: error: ld returned 1 exit status
> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
> /usr/bin/ld: /tmp/build-release/hotspot/variant-server/libjvm/objs/jvmciCodeInstaller.o: in function `C2_MacroAssembler::C2_MacroAssembler(CodeBuffer*)':
> make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
> /usr/bin/ld: make/hotspot/src/hotspot/share/opto/c2_MacroAssembler.hpp:38: undefined reference to `vtable for C2_MacroAssembler'
> collect2: error: ld returned 1 exit status
> 
> * All command lines available in /tmp/build-release/make-support/failure-logs.
> === End of repeated output ===
> 
> 
> I suggest making the following change:
> 
> Suggestion:
> 
>       MacroAssembler masm(&buffer);

Thank you for catch @shqking !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1415982687

From cslucas at openjdk.org  Tue Dec  5 16:57:55 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 5 Dec 2023 16:57:55 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v5]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <gm5YKoexr2Yx6AWr2yUFJ1gfcVEVJYk6nu4mgqbYWZA=.07310b7f-a913-48d1-a85b-702f5244fa63@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision:

  Fix build, copyright dates, m4 files.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16484/files
  - new: https://git.openjdk.org/jdk/pull/16484/files/afe48fe7..d950806f

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

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

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

From tschatzl at openjdk.org  Tue Dec  5 18:49:52 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 5 Dec 2023 18:49:52 GMT
Subject: RFR: 8317809: Insertion of free code blobs into code cache can be
 very slow during class unloading [v6]
In-Reply-To: <oUFBDsltTslCD1wtUe378o-v56BmFoJAkoOZNcwO0_U=.7596433d-b05f-48ef-9fb4-ede7cde3a8a3@github.com>
References: <_dcFF70_w7IXSjb6w-HuHCBkPyS3a6NlzejtqdfdYnM=.74e0f9df-eca3-49b0-be68-2d5824c16003@github.com>
 <td1rPLzUuBd8x2PHO1IZtSmUE1vpNgs5Cwg14ehwfoU=.511a638c-3874-4d6a-b48b-c662459a24ec@github.com>
 <oUFBDsltTslCD1wtUe378o-v56BmFoJAkoOZNcwO0_U=.7596433d-b05f-48ef-9fb4-ede7cde3a8a3@github.com>
Message-ID: <a9cLJixrDTdpG-eBJlHcWtiiLCw1uiGVdm2_j3Fp6xg=.0a4ecfab-212f-445c-ad68-d6d33103bee8@github.com>

On Tue, 5 Dec 2023 15:47:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ayang review: move class unloading outside of weak_refs_work
>
> src/hotspot/share/gc/shared/classUnloadingContext.cpp line 91:
> 
>> 89:     cld->classes_do(f);
>> 90:   }
>> 91: }
> 
> I don't understand why CLDG specific methods were moved here.  They should be unaware of nmethod purging. and these 4 methods don't have any nmethod purging in them either and are specific to the CLDG implementation.

The idea is to have GC take control how the unloading CLDs are stored/which data structure it is going to use to manage them to ultimately allow more control about class unloading for parallelization.

Which on the one hand makes pauses shorter (for stw collectors), and on the other hand decreases the time the CLDG_lock is held (not sure it is nice that the concurrent collectors currently may hold that one for ~100ms in my test...).

I believe having the linked list of unloading CLDs embedded in the CLDs for use by the GC not only seems wrong (i.e. it's a GC data structure located in runtime code) but is also very limiting (need to have one for all, fixed singly linked list).

This change moves knowledge of how unloading CLDs are managed to GC area - runtime code just tells GC that a particular CLD is unloading.
(Currently the `ClassUnloadingContext` also calls the `unload` method during registration to keep current functionality, but the plan is to separate the step of registration and actual unloading to allow custom handling of the second part; the registering, although it's still walking a singly linked list, is comparatively fast).

These four methods provide a thin abstraction over the CLDs that are unloading (that runtime doesn't need and should not worry about imo).

With that in place it is possible to slice the actual unloading work into phases according to dependencies (depending on GC if desired), potentially overlapping with other existing phases in collectors already allowing that (e.g. the parallel code unloading, but that is only an implementation detail to reduce overall parallel phases), or even moving some of that work sometime else (the `CLD::unload()` method unfortunately currently may do some memory freeing too).

However most time is spent in notifying various components which can be parallelized (at least parallelize the different types of notifications).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16759#discussion_r1416139587

From shade at openjdk.org  Tue Dec  5 18:51:36 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Dec 2023 18:51:36 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Q5fv7OhPpgFkx72U0OWaoBqc---tCmjACHnOgyUKcUo=.c207b086-3ec9-4938-ba8a-36a67104bd66@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
 <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
 <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>
 <8yB2OpjTUTHG6E1Wb_Ry5F9HuMinHSY-yt-2eDSB3zw=.8878b365-2275-4227-a8fe-058c6cb7cebe@github.com>
 <9wc8yRtwoi-AmBI_kEQOJSwXnDRzlQaBVSOA8GpVO84=.9f60a36f-c26e-4e1f-b2cb-050780ed5ff6@github.com>
 <Q5fv7OhPpgFkx72U0OWaoBqc---tCmjACHnOgyUKcUo=.c207b086-3ec9-4938-ba8a-36a67104bd66@github.com>
Message-ID: <DKNK9szv0PKSSg8eMy19bWzumxbNXQm76qSkx3mE1So=.ec8f11cd-09ab-459a-b2d6-d25ebe40053c@github.com>

On Mon, 4 Dec 2023 15:52:53 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> > I thought late barrier insertion basically avoids dealing with any optimizer questions, as we insert the barriers close to emit. So if we are to do late barrier insertion, we don't need the bulk of barrier optimization code? Maybe I misunderstand where late barrier insertion fits in C2.
> 
> But the flag you're removing controls optimizations of the barrier code once expanded.

Ah, yes. The late insertion relies on assumption that the barrier is somehow lightweight to not require post-insertion optimization. That might not be true for Shenandoah (and G1) barriers.

Anyway, would you like to keep the flag in, or should we integrate this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1841419106

From shade at openjdk.org  Tue Dec  5 19:53:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Dec 2023 19:53:44 GMT
Subject: RFR: 8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers flag
Message-ID: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>

We have flipped `ShenandoahSuspendibleWorkers` to true in [JDK-8305403](https://bugs.openjdk.org/browse/JDK-8305403), and backported it back to 17.0.8. We seem to be in consensus that turning this flag off would likely to cause correctness issues:
  https://github.com/openjdk/jdk/pull/13309#discussion_r1160934484

So we might as well remove this flag altogether.

Additional testing:
 - [ ] `hotspot_gc_shenandoah`

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

Commit messages:
 - Fix

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

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

From kdnilsen at openjdk.org  Tue Dec  5 20:36:41 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Dec 2023 20:36:41 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before throwing
 OOM
Message-ID: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>

Require each thread to observe unproductive Full GC before it throws OOM exception.

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

Commit messages:
 - Require each thread to see full GC before throwing OOM

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

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

From ysr at openjdk.org  Tue Dec  5 23:30:35 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Dec 2023 23:30:35 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
Message-ID: <JQQeOzD9J3Nku1uYAV1KiRfctZTz_nGB_5gv6VMxqsQ=.c815c558-dc6a-496d-b391-d5cab209adf3@github.com>

On Tue, 5 Dec 2023 20:30:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Require each thread to observe unproductive Full GC before it throws OOM exception.

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

> 883:     // This will notify the collector to start a cycle, but will raise
> 884:     // an OOME to the mutator if the last Full GCs have not made progress.
> 885:     if (result == nullptr && !req.is_lab_alloc() && get_gc_no_progress_count() > ShenandoahNoProgressThreshold) {

Does this render `ShenandoahNoProgressThreshold` a dead option?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1416398792

From wkemper at openjdk.org  Tue Dec  5 23:40:36 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 5 Dec 2023 23:40:36 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
Message-ID: <q2qPJMexIW6h8JFbaSzYvgrZuO-VGNsoEJO4WW3bS3M=.0fb3366f-2f45-402d-9430-e8f04a244af5@github.com>

On Tue, 5 Dec 2023 20:30:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Require each thread to observe unproductive Full GC before it throws OOM exception.

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

> 883:     // This will notify the collector to start a cycle, but will raise
> 884:     // an OOME to the mutator if the last Full GCs have not made progress.
> 885:     if (result == nullptr && !req.is_lab_alloc() && get_gc_no_progress_count() > ShenandoahNoProgressThreshold) {

We need to be careful here. This essentially backs out the fix for:
* https://bugs.openjdk.org/browse/JDK-8316632
* https://bugs.openjdk.org/browse/JDK-8314935

For the original change, I ran tier1, tier2 and tier3 tests with Shenandoah enabled on x86 and aarch64, per @shipilev 's request (https://github.com/openjdk/jdk/pull/15852#issuecomment-1729099298).

make test TEST="tier1 tier2 tier3" TEST_VM_OPTS="-XX:+UseShenandoahGC" CONF=fastdebug

These tests, specifically,  will likely timeout without this check:

make test TEST="runtime/reflect/ReflectOutOfMemoryError.java gc/InfiniteList.java runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java compiler/uncommontrap/TestDeoptOOM.java" TEST_VM_OPTS="-Xlog:gc*=info:file=/tmp/oome.log -XX:+UseShenandoahGC" JTREG="REPEAT_COUNT=50" CONF=fastdebug

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1416404947

From shade at openjdk.org  Wed Dec  6 14:10:01 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 14:10:01 GMT
Subject: RFR: 8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers flag
 [v2]
In-Reply-To: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
References: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
Message-ID: <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>

> We have flipped `ShenandoahSuspendibleWorkers` to true in [JDK-8305403](https://bugs.openjdk.org/browse/JDK-8305403), and backported it back to 17.0.8. We seem to be in consensus that turning this flag off would likely to cause correctness issues:
>   https://github.com/openjdk/jdk/pull/13309#discussion_r1160934484
> 
> So we might as well remove this flag altogether.
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

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

 - Merge branch 'master' into JDK-8321410-shenandoah-suspendible-workers
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16984/files
  - new: https://git.openjdk.org/jdk/pull/16984/files/0370357f..3e0a580e

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

  Stats: 31526 lines in 319 files changed: 9148 ins; 21344 del; 1034 mod
  Patch: https://git.openjdk.org/jdk/pull/16984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16984/head:pull/16984

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

From kdnilsen at openjdk.org  Wed Dec  6 14:16:42 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 14:16:42 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <JQQeOzD9J3Nku1uYAV1KiRfctZTz_nGB_5gv6VMxqsQ=.c815c558-dc6a-496d-b391-d5cab209adf3@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
 <JQQeOzD9J3Nku1uYAV1KiRfctZTz_nGB_5gv6VMxqsQ=.c815c558-dc6a-496d-b391-d5cab209adf3@github.com>
Message-ID: <k2ZZbX81gT7ww6COumsCJpdpHBNvJyMEA-ZAZs-noOw=.f3a5bf7f-9334-44d0-8348-59ba02601aab@github.com>

On Tue, 5 Dec 2023 23:28:18 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Require each thread to observe unproductive Full GC before it throws OOM exception.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 885:
> 
>> 883:     // This will notify the collector to start a cycle, but will raise
>> 884:     // an OOME to the mutator if the last Full GCs have not made progress.
>> 885:     if (result == nullptr && !req.is_lab_alloc() && get_gc_no_progress_count() > ShenandoahNoProgressThreshold) {
> 
> Does this render `ShenandoahNoProgressThreshold` a dead option?

Good point.  It is no longer relevant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1417391908

From shade at openjdk.org  Wed Dec  6 14:16:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 14:16:49 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers [v2]
In-Reply-To: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
Message-ID: <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>

> See bug for rationale.
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`

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

 - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
 - Reinstate the .cpp policy code
 - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
 - No dynamic GC workers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16878/files
  - new: https://git.openjdk.org/jdk/pull/16878/files/56d597be..e5826b15

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

  Stats: 85136 lines in 1765 files changed: 39360 ins; 39156 del; 6620 mod
  Patch: https://git.openjdk.org/jdk/pull/16878.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16878/head:pull/16878

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

From kdnilsen at openjdk.org  Wed Dec  6 14:16:50 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 14:16:50 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers [v2]
In-Reply-To: <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
 <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
Message-ID: <9uUyltcRLs6culCIRl6du_O3IY56egv6EsjO-RZsUPQ=.132127b3-3b47-4d46-b131-e6997a7be2ba@github.com>

On Wed, 6 Dec 2023 14:13:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for rationale.
>> 
>> Additional testing:
>>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - Reinstate the .cpp policy code
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - No dynamic GC workers

This does conflict with my changes, but I'd be glad to rebase my code on this foundation.  This is simpler and more sensible.

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

Marked as reviewed by kdnilsen (no project role).

PR Review: https://git.openjdk.org/jdk/pull/16878#pullrequestreview-1757886141

From shade at openjdk.org  Wed Dec  6 14:16:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 14:16:52 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers
In-Reply-To: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
Message-ID: <eBQ0wnpfA0A08yKYf2JEUkT9yDUZPvqJIAwBXID6yF4=.bc4b78af-e3a5-4925-8b1f-d370789feb89@github.com>

On Wed, 29 Nov 2023 11:01:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for rationale.
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`

Right, that makes sense. I'll rework the patch a bit to still allow _some_ policy adjustments without relying on shared policy.

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

PR Comment: https://git.openjdk.org/jdk/pull/16878#issuecomment-1832404059

From kdnilsen at openjdk.org  Wed Dec  6 15:36:52 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 15:36:52 GMT
Subject: RFR: 8321401: GenShen: Each mutator must see FullGC before
 throwing OOM [v3]
In-Reply-To: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>
References: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>
Message-ID: <cZTg1ZIcfdbpxzKJdKWheqp7My-75bHwVudtvF-j2LQ=.f64182d2-7981-44c3-a52c-416803579c77@github.com>

> Require each thread to observe unproductive Full GC before it throws OOM exception.

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

  Remove ShenandoahNoProgressThreshold
  
  With this change, this command-line option has no effect.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/365/files
  - new: https://git.openjdk.org/shenandoah/pull/365/files/6d6f16db..bbff38a3

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

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

PR: https://git.openjdk.org/shenandoah/pull/365

From kdnilsen at openjdk.org  Wed Dec  6 15:39:41 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 15:39:41 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <k2ZZbX81gT7ww6COumsCJpdpHBNvJyMEA-ZAZs-noOw=.f3a5bf7f-9334-44d0-8348-59ba02601aab@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
 <JQQeOzD9J3Nku1uYAV1KiRfctZTz_nGB_5gv6VMxqsQ=.c815c558-dc6a-496d-b391-d5cab209adf3@github.com>
 <k2ZZbX81gT7ww6COumsCJpdpHBNvJyMEA-ZAZs-noOw=.f3a5bf7f-9334-44d0-8348-59ba02601aab@github.com>
Message-ID: <rV-jS4-9jgCwpLSn7cTGQx3KHuaEiBKp9b9tzPhufLE=.21483385-6d4f-4ae2-b415-07a65e1b4580@github.com>

On Wed, 6 Dec 2023 14:13:35 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 885:
>> 
>>> 883:     // This will notify the collector to start a cycle, but will raise
>>> 884:     // an OOME to the mutator if the last Full GCs have not made progress.
>>> 885:     if (result == nullptr && !req.is_lab_alloc() && get_gc_no_progress_count() > ShenandoahNoProgressThreshold) {
>> 
>> Does this render `ShenandoahNoProgressThreshold` a dead option?
>
> Good point.  It is no longer relevant.

I'll remove that option for coherency in this PR.   Still need to resolve the question of too-much-time for OOM, mentioned below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1417523732

From kdnilsen at openjdk.org  Wed Dec  6 15:39:43 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 15:39:43 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <q2qPJMexIW6h8JFbaSzYvgrZuO-VGNsoEJO4WW3bS3M=.0fb3366f-2f45-402d-9430-e8f04a244af5@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
 <q2qPJMexIW6h8JFbaSzYvgrZuO-VGNsoEJO4WW3bS3M=.0fb3366f-2f45-402d-9430-e8f04a244af5@github.com>
Message-ID: <lQCmaA-oUgqWrZcpRBg7kbmQ9_9hoF8iGwUJ_TGr_z8=.23cf38e9-a34e-4b3a-a459-d53493baeb9e@github.com>

On Tue, 5 Dec 2023 23:38:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Require each thread to observe unproductive Full GC before it throws OOM exception.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 885:
> 
>> 883:     // This will notify the collector to start a cycle, but will raise
>> 884:     // an OOME to the mutator if the last Full GCs have not made progress.
>> 885:     if (result == nullptr && !req.is_lab_alloc() && get_gc_no_progress_count() > ShenandoahNoProgressThreshold) {
> 
> We need to be careful here. This essentially backs out the fix for:
> * https://bugs.openjdk.org/browse/JDK-8316632
> * https://bugs.openjdk.org/browse/JDK-8314935
> 
> For the original change, I ran tier1, tier2 and tier3 tests with Shenandoah enabled on x86 and aarch64, per @shipilev 's request (https://github.com/openjdk/jdk/pull/15852#issuecomment-1729099298).
> 
> make test TEST="tier1 tier2 tier3" TEST_VM_OPTS="-XX:+UseShenandoahGC" CONF=fastdebug
> 
> These tests, specifically,  will likely timeout without this check:
> 
> make test TEST="runtime/reflect/ReflectOutOfMemoryError.java gc/InfiniteList.java runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java compiler/uncommontrap/TestDeoptOOM.java" TEST_VM_OPTS="-Xlog:gc*=info:file=/tmp/oome.log -XX:+UseShenandoahGC" JTREG="REPEAT_COUNT=50" CONF=fastdebug

I'll run these tests and report the results.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1417525665

From roland at openjdk.org  Wed Dec  6 15:44:39 2023
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 6 Dec 2023 15:44:39 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <i7yPMdHF6uoyiref_FcfIP9nYSIb6uTKn-LeZJ8-PwA=.2cd48187-c859-4ce2-be6e-246d30439dd8@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

Marked as reviewed by roland (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16908#pullrequestreview-1767912880

From roland at openjdk.org  Wed Dec  6 15:44:42 2023
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 6 Dec 2023 15:44:42 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <DKNK9szv0PKSSg8eMy19bWzumxbNXQm76qSkx3mE1So=.ec8f11cd-09ab-459a-b2d6-d25ebe40053c@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
 <_PWNVaUyOIoUREKSS3D3ru2-GnCSzpZDoMdaYiwpIIY=.7a2dcf93-b7b3-4488-92fb-ae734e5b0d95@github.com>
 <HLJD-jPAVDPrQQ-IBBq5LAlhFTfvhbFp98wrySQBuCs=.c3fa6ef3-9233-41a5-a695-4e8586174dd0@github.com>
 <8yB2OpjTUTHG6E1Wb_Ry5F9HuMinHSY-yt-2eDSB3zw=.8878b365-2275-4227-a8fe-058c6cb7cebe@github.com>
 <9wc8yRtwoi-AmBI_kEQOJSwXnDRzlQaBVSOA8GpVO84=.9f60a36f-c26e-4e1f-b2cb-050780ed5ff6@github.com>
 <Q5fv7OhPpgFkx72U0OWaoBqc---tCmjACHnOgyUKcUo=.c207b086-3ec9-4938-ba8a-36a67104bd66@github.com>
 <DKNK9szv0PKSSg8eMy19bWzumxbNXQm76qSkx3mE1So=.ec8f11cd-09ab-459a-b2d6-d25ebe40053c@github.com>
Message-ID: <I8UsEWzM_3EodShNXrtzFK9OKgWIi4ItUGiIZJAUNtY=.eccc80fe-9370-4512-bf5e-ee1cf503bbe0@github.com>

On Tue, 5 Dec 2023 18:49:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Anyway, would you like to keep the flag in, or should we integrate this PR?

I'm fine with the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1843140749

From kdnilsen at openjdk.org  Wed Dec  6 16:31:53 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 16:31:53 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <lQCmaA-oUgqWrZcpRBg7kbmQ9_9hoF8iGwUJ_TGr_z8=.23cf38e9-a34e-4b3a-a459-d53493baeb9e@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
 <q2qPJMexIW6h8JFbaSzYvgrZuO-VGNsoEJO4WW3bS3M=.0fb3366f-2f45-402d-9430-e8f04a244af5@github.com>
 <lQCmaA-oUgqWrZcpRBg7kbmQ9_9hoF8iGwUJ_TGr_z8=.23cf38e9-a34e-4b3a-a459-d53493baeb9e@github.com>
Message-ID: <TCXfF--mKngbCptNfehDKk_wg8IiMl7Gm5ry5cLaO-k=.6d5b25ab-76bc-4819-950c-817bc4344d7c@github.com>

On Wed, 6 Dec 2023 15:36:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 885:
>> 
>>> 883:     // This will notify the collector to start a cycle, but will raise
>>> 884:     // an OOME to the mutator if the last Full GCs have not made progress.
>>> 885:     if (result == nullptr && !req.is_lab_alloc() && get_gc_no_progress_count() > ShenandoahNoProgressThreshold) {
>> 
>> We need to be careful here. This essentially backs out the fix for:
>> * https://bugs.openjdk.org/browse/JDK-8316632
>> * https://bugs.openjdk.org/browse/JDK-8314935
>> 
>> For the original change, I ran tier1, tier2 and tier3 tests with Shenandoah enabled on x86 and aarch64, per @shipilev 's request (https://github.com/openjdk/jdk/pull/15852#issuecomment-1729099298).
>> 
>> make test TEST="tier1 tier2 tier3" TEST_VM_OPTS="-XX:+UseShenandoahGC" CONF=fastdebug
>> 
>> These tests, specifically,  will likely timeout without this check:
>> 
>> make test TEST="runtime/reflect/ReflectOutOfMemoryError.java gc/InfiniteList.java runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java compiler/uncommontrap/TestDeoptOOM.java" TEST_VM_OPTS="-Xlog:gc*=info:file=/tmp/oome.log -XX:+UseShenandoahGC" JTREG="REPEAT_COUNT=50" CONF=fastdebug
>
> I'll run these tests and report the results.

For the four explicit tests, 50 runs each, all passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1417622364

From kdnilsen at openjdk.org  Wed Dec  6 16:31:55 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Dec 2023 16:31:55 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <TCXfF--mKngbCptNfehDKk_wg8IiMl7Gm5ry5cLaO-k=.6d5b25ab-76bc-4819-950c-817bc4344d7c@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
 <q2qPJMexIW6h8JFbaSzYvgrZuO-VGNsoEJO4WW3bS3M=.0fb3366f-2f45-402d-9430-e8f04a244af5@github.com>
 <lQCmaA-oUgqWrZcpRBg7kbmQ9_9hoF8iGwUJ_TGr_z8=.23cf38e9-a34e-4b3a-a459-d53493baeb9e@github.com>
 <TCXfF--mKngbCptNfehDKk_wg8IiMl7Gm5ry5cLaO-k=.6d5b25ab-76bc-4819-950c-817bc4344d7c@github.com>
Message-ID: <6oAqAKQLPZUZwNiHbR-lKFnbZHvvJZYkXMJWskEpvCg=.b1d6f83e-e9b8-4ca5-a289-70460078a206@github.com>

On Wed, 6 Dec 2023 16:25:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I'll run these tests and report the results.
>
> For the four explicit tests, 50 runs each, all passed.

Am wondering if there might have been some other compounding issue, since resolved, that contributed to the original issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1417626100

From wkemper at openjdk.org  Wed Dec  6 16:53:39 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Dec 2023 16:53:39 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <6oAqAKQLPZUZwNiHbR-lKFnbZHvvJZYkXMJWskEpvCg=.b1d6f83e-e9b8-4ca5-a289-70460078a206@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
 <q2qPJMexIW6h8JFbaSzYvgrZuO-VGNsoEJO4WW3bS3M=.0fb3366f-2f45-402d-9430-e8f04a244af5@github.com>
 <lQCmaA-oUgqWrZcpRBg7kbmQ9_9hoF8iGwUJ_TGr_z8=.23cf38e9-a34e-4b3a-a459-d53493baeb9e@github.com>
 <TCXfF--mKngbCptNfehDKk_wg8IiMl7Gm5ry5cLaO-k=.6d5b25ab-76bc-4819-950c-817bc4344d7c@github.com>
 <6oAqAKQLPZUZwNiHbR-lKFnbZHvvJZYkXMJWskEpvCg=.b1d6f83e-e9b8-4ca5-a289-70460078a206@github.com>
Message-ID: <vqMH_KGGg7wFxAv62so1cQrt1Dvtgtci-kSraqIBWlo=.5060deae-7042-4f5e-bfbc-fd2e729b65bf@github.com>

On Wed, 6 Dec 2023 16:28:28 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> For the four explicit tests, 50 runs each, all passed.
>
> Am wondering if there might have been some other compounding issue, since resolved, that contributed to the original issue.

Okay, thanks for the additional testing. In this case, we should also remove the `ShenandoahNoProgressThreshold` flag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16985#discussion_r1417658766

From shade at openjdk.org  Wed Dec  6 17:34:35 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 17:34:35 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <BkyYrlXtrWBW618pyQ9TVsyzZa-feLFfQgOY3PLTQxQ=.7348e85c-5206-48d7-b0b1-af72cece0d5e@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

Looking for blessing from @rkennke as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1843350229

From shade at openjdk.org  Wed Dec  6 17:35:37 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 17:35:37 GMT
Subject: RFR: 8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers flag
 [v2]
In-Reply-To: <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>
References: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
 <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>
Message-ID: <nhY-a4kgKNLKpIvkVor1pavIFCP-YxqyrLBqAVqLyxs=.28f8bdcc-d20e-497e-aa64-af21747d4098@github.com>

On Wed, 6 Dec 2023 14:10:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have flipped `ShenandoahSuspendibleWorkers` to true in [JDK-8305403](https://bugs.openjdk.org/browse/JDK-8305403), and backported it back to 17.0.8. We seem to be in consensus that turning this flag off would likely to cause correctness issues:
>>   https://github.com/openjdk/jdk/pull/13309#discussion_r1160934484
>> 
>> So we might as well remove this flag altogether.
>> 
>> Additional testing:
>>  - [x] `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8321410-shenandoah-suspendible-workers
>  - Fix

Looking for blessing from @rkennke as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/16984#issuecomment-1843352657

From wkemper at openjdk.org  Wed Dec  6 19:58:35 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Dec 2023 19:58:35 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers [v2]
In-Reply-To: <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
 <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
Message-ID: <_1Htgja_azwLm70ZhRxuKK5yV0XbVO0pNkPt6e-PCDA=.8d19d709-cb66-4bb5-abee-cf325b6dc687@github.com>

On Wed, 6 Dec 2023 14:16:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for rationale.
>> 
>> Additional testing:
>>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - Reinstate the .cpp policy code
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - No dynamic GC workers

Marked as reviewed by wkemper (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/16878#pullrequestreview-1768509686

From rkennke at openjdk.org  Wed Dec  6 20:16:38 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 6 Dec 2023 20:16:38 GMT
Subject: RFR: 8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers flag
 [v2]
In-Reply-To: <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>
References: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
 <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>
Message-ID: <-19lIb_rpCq7aEXckFs-FPMZt5sElABtD5JAbWgRoS0=.bf8b824e-eec9-403d-9ffc-8274d56472cb@github.com>

On Wed, 6 Dec 2023 14:10:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have flipped `ShenandoahSuspendibleWorkers` to true in [JDK-8305403](https://bugs.openjdk.org/browse/JDK-8305403), and backported it back to 17.0.8. We seem to be in consensus that turning this flag off would likely to cause correctness issues:
>>   https://github.com/openjdk/jdk/pull/13309#discussion_r1160934484
>> 
>> So we might as well remove this flag altogether.
>> 
>> Additional testing:
>>  - [x] `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8321410-shenandoah-suspendible-workers
>  - Fix

Yes it is a correctness issue, let's get rid of the flag.

I believe that you could also replace ShenandoahSuspendibleThreadSet* with just regular SuspendibleThreadSet*.

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16984#pullrequestreview-1768538629

From rkennke at openjdk.org  Wed Dec  6 20:21:37 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 6 Dec 2023 20:21:37 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <m8iBH01Qg25klp-4VbD_TiO8Fy1UjemHQziC5zTRKA8=.0585d38c-bec4-48e7-8fb8-c4760545a422@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

Seems ok to remove the flag, but not sure if the optimization pass is still useful at all? It might be a left-over from pre-LRB and not do anything useful? (I don't know that, I haven't checked, but it could be)

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16908#pullrequestreview-1768547290

From ysr at openjdk.org  Wed Dec  6 20:24:37 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 6 Dec 2023 20:24:37 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers [v2]
In-Reply-To: <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
 <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
Message-ID: <uIrT1oidQHrstlPAgkXls7d4NxONwIRcj41o5Qv9fF4=.934eaad0-2f90-42af-933b-2269d60b5bf1@github.com>

On Wed, 6 Dec 2023 14:16:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for rationale.
>> 
>> Additional testing:
>>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - Reinstate the .cpp policy code
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - No dynamic GC workers

Reviewed!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16878#pullrequestreview-1768551188

From shade at openjdk.org  Wed Dec  6 21:19:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 21:19:44 GMT
Subject: RFR: 8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers flag
 [v2]
In-Reply-To: <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>
References: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
 <jUS34Eas0m6fUPuoZZOt15vT31TkLe5CtNQ9QV9SuYE=.4f51509e-c25b-4121-a9e3-748b124c66d3@github.com>
Message-ID: <FXL6t_bCwn4nAYAZL6g33UdyiIHIkGdEteX1kA3Rpaw=.a57f1f13-0d7d-4c82-92b1-82c794773d9d@github.com>

On Wed, 6 Dec 2023 14:10:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have flipped `ShenandoahSuspendibleWorkers` to true in [JDK-8305403](https://bugs.openjdk.org/browse/JDK-8305403), and backported it back to 17.0.8. We seem to be in consensus that turning this flag off would likely to cause correctness issues:
>>   https://github.com/openjdk/jdk/pull/13309#discussion_r1160934484
>> 
>> So we might as well remove this flag altogether.
>> 
>> Additional testing:
>>  - [x] `hotspot_gc_shenandoah`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8321410-shenandoah-suspendible-workers
>  - Fix

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16984#issuecomment-1843704071

From shade at openjdk.org  Wed Dec  6 21:19:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 21:19:46 GMT
Subject: Integrated: 8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers
 flag
In-Reply-To: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
References: <dErysouMYkIKXWGf9yxCnI0JoS1qPkX8xb2e6VLofCE=.8e4c6b07-0a76-483c-82d7-ad1e78b474d0@github.com>
Message-ID: <_CIa-YLyPVjpixKvO-R22TYFDUGaoZgyxGu4zHd4wrk=.829c59f7-afea-4849-b6e3-9d9ea965f486@github.com>

On Tue, 5 Dec 2023 19:47:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have flipped `ShenandoahSuspendibleWorkers` to true in [JDK-8305403](https://bugs.openjdk.org/browse/JDK-8305403), and backported it back to 17.0.8. We seem to be in consensus that turning this flag off would likely to cause correctness issues:
>   https://github.com/openjdk/jdk/pull/13309#discussion_r1160934484
> 
> So we might as well remove this flag altogether.
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: 2830dd2a
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2830dd2a7d3b933fbddca64ca0ac7a91e7ab0775
Stats:     40 lines in 6 files changed: 0 ins; 33 del; 7 mod

8321410: Shenandoah: Remove ShenandoahSuspendibleWorkers flag

Reviewed-by: rkennke

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

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

From shade at openjdk.org  Wed Dec  6 21:22:43 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 21:22:43 GMT
Subject: RFR: 8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion
 flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <0sM-y3lB6TW6iAhaIOJbA1zQGRPjNvjeKe_0cu29fw0=.27ee70a8-3fa7-4d10-bb11-0c401ee645c3@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16908#issuecomment-1843705358

From shade at openjdk.org  Wed Dec  6 21:22:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 6 Dec 2023 21:22:44 GMT
Subject: Integrated: 8321122: Shenandoah: Remove
 ShenandoahLoopOptsAfterExpansion flag
In-Reply-To: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
References: <Qx1RiCM0aLTjBwDMNJvHiBBBceXMFmsJ-QtA0CdkdzE=.06c7276c-d9d1-44fc-bdac-24fd2727d16d@github.com>
Message-ID: <Kwmx7LCZG5OwAaqhjzNMIFvFNPDax0ZsGRdOkjs6X10=.0678b707-6a4b-4e08-847f-c3805c36f0cc@github.com>

On Thu, 30 Nov 2023 16:00:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> More flags cleanup. `ShenandoahLoopOptsAfterExpansion` was added long time ago to gate more aggressive barrier optimizations in C2. It was default since then. There seem to be no reason to keep it as the flag. Just checking, @rwestrel -- you don't need it anymore, right?
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: b02fc868
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b02fc8681e57d75b5e05ce98216c53ff4d1e3b5d
Stats:     18 lines in 2 files changed: 5 ins; 11 del; 2 mod

8321122: Shenandoah: Remove ShenandoahLoopOptsAfterExpansion flag

Reviewed-by: kdnilsen, roland, rkennke

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

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

From shade at openjdk.org  Thu Dec  7 09:36:44 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Dec 2023 09:36:44 GMT
Subject: RFR: 8320969: Shenandoah: Enforce stable number of GC workers [v2]
In-Reply-To: <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
 <-BNpjrXyRpuAVDceEf1xu0jTJK1dhxBNw22HuXwaDjs=.1cbe5133-b6bb-4558-bb75-65091052b696@github.com>
Message-ID: <SbbVRVq-es_Sr0SndGe6Xwa2rGol6eZuc1k4JlPvxK8=.01391c93-3396-44f3-8bca-043bee3f49eb@github.com>

On Wed, 6 Dec 2023 14:16:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See bug for rationale.
>> 
>> Additional testing:
>>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - Reinstate the .cpp policy code
>  - Merge branch 'master' into JDK-8320969-shenandoah-stable-gc-workers
>  - No dynamic GC workers

All right, thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/16878#issuecomment-1844995137

From shade at openjdk.org  Thu Dec  7 09:36:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Dec 2023 09:36:46 GMT
Subject: Integrated: 8320969: Shenandoah: Enforce stable number of GC workers
In-Reply-To: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
References: <54bP7p1EQWWE8YXN94AlKVabtJUOFpw-wZ7fXOmxG_0=.7ad5f3d4-fe36-4ea3-8e38-0561020cc043@github.com>
Message-ID: <VCQIt2ouQjmTF55vcbbnXnK2n7rGaxAv4O3ML2NxZ0s=.6539473d-5f06-4caa-b720-6cc40709ba50@github.com>

On Wed, 29 Nov 2023 11:01:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for rationale.
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3}` with `-XX:+UseShenandoahGC`

This pull request has now been integrated.

Changeset: 656b4462
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/656b4462895da51765e473d425c87f920a30c891
Stats:     138 lines in 5 files changed: 10 ins; 110 del; 18 mod

8320969: Shenandoah: Enforce stable number of GC workers

Reviewed-by: kdnilsen, wkemper, ysr

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

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

From wkemper at openjdk.org  Thu Dec  7 14:17:45 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 7 Dec 2023 14:17:45 GMT
Subject: RFR: Merge openjdk/jdk:master [v4]
In-Reply-To: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
References: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
Message-ID: <kFADvn4CNYNVWY4UK6iOiqHdlazNz--jLNi_E1YgZN4=.6fe9c5f9-2ab2-4ee3-9d07-4aedaf296713@github.com>

> Merges tag jdk-22+26

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

 - 8320945: problemlist tests failing on latest Windows 11 update
   
   Reviewed-by: lmesnik
 - 8210410: Refactor java.util.Currency:i18n shell tests to plain java tests
   
   Reviewed-by: naoto, lancea
 - 8320942: Only set openjdk-target when cross compiling linux-aarch64
   
   Reviewed-by: ihse, erikj
 - 8320937: support latest VS2022 MSC_VER in abstract_vm_version.cpp
   
   Reviewed-by: dholmes, shade
 - 8319444: Unhelpful failure output in TestLegalNotices
   
   Reviewed-by: hannesw, jjg
 - 8313816: Accessing jmethodID might lead to spurious crashes
   
   Reviewed-by: coleenp
 - 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support
   
   Reviewed-by: wkemper, kdnilsen, rkennke
 - 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes
   
   Reviewed-by: jlahoda, vromero
 - 8320940: Fix typo in java.lang.Double
   
   Reviewed-by: rriggs, iris, shade, lancea, bpb
 - 8320907: Shenandoah: Remove ShenandoahSelfFixing flag
   
   Reviewed-by: wkemper, zgu, kdnilsen, rkennke
 - ... and 102 more: https://git.openjdk.org/shenandoah/compare/e47cf611...ea6e92ed

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

Changes: https://git.openjdk.org/shenandoah/pull/363/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=363&range=03
  Stats: 16460 lines in 646 files changed: 11110 ins; 3130 del; 2220 mod
  Patch: https://git.openjdk.org/shenandoah/pull/363.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/363/head:pull/363

PR: https://git.openjdk.org/shenandoah/pull/363

From kdnilsen at openjdk.org  Fri Dec  8 00:00:11 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 8 Dec 2023 00:00:11 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM [v2]
In-Reply-To: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
Message-ID: <SIzK8Dx8RU3hN8g9WXvDlCjXt5kDZMvExoNi-8yeeac=.b097e0dd-f8c9-4771-8acf-500e83372cea@github.com>

> Require each thread to observe unproductive Full GC before it throws OOM exception.

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

  Track GC utilization and implement gc_overhead_limit_was_exceeded

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16985/files
  - new: https://git.openjdk.org/jdk/pull/16985/files/8d0515b7..c80c049e

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

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

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

From wkemper at openjdk.org  Fri Dec  8 00:16:48 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 8 Dec 2023 00:16:48 GMT
Subject: RFR: Merge openjdk/jdk:master [v5]
In-Reply-To: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
References: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
Message-ID: <vhTRLgWfXju_DitoUdBF8IEBb4EQb1DnspBDIDOzu-4=.883d67fd-d408-4edb-9cff-a2009afe75f7@github.com>

> Merges tag jdk-22+26

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

 - Use max capacity, rather than soft max when computing runway
 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-22+26
 - 8320945: problemlist tests failing on latest Windows 11 update
   
   Reviewed-by: lmesnik
 - 8210410: Refactor java.util.Currency:i18n shell tests to plain java tests
   
   Reviewed-by: naoto, lancea
 - 8320942: Only set openjdk-target when cross compiling linux-aarch64
   
   Reviewed-by: ihse, erikj
 - 8320937: support latest VS2022 MSC_VER in abstract_vm_version.cpp
   
   Reviewed-by: dholmes, shade
 - 8319444: Unhelpful failure output in TestLegalNotices
   
   Reviewed-by: hannesw, jjg
 - 8313816: Accessing jmethodID might lead to spurious crashes
   
   Reviewed-by: coleenp
 - 8320877: Shenandoah: Remove ShenandoahUnloadClassesFrequency support
   
   Reviewed-by: wkemper, kdnilsen, rkennke
 - 8320806: Augment test/langtools/tools/javac/versions/Versions.java for JDK 22 language changes
   
   Reviewed-by: jlahoda, vromero
 - ... and 104 more: https://git.openjdk.org/shenandoah/compare/2618aa69...99df412f

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

Changes: https://git.openjdk.org/shenandoah/pull/363/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=363&range=04
  Stats: 16463 lines in 648 files changed: 11110 ins; 3132 del; 2221 mod
  Patch: https://git.openjdk.org/shenandoah/pull/363.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/363/head:pull/363

PR: https://git.openjdk.org/shenandoah/pull/363

From kdnilsen at openjdk.org  Fri Dec  8 03:47:48 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 8 Dec 2023 03:47:48 GMT
Subject: RFR: 8321401: Shenandoah: Each mutator must see FullGC before
 throwing OOM [v3]
In-Reply-To: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
References: <jzpS8fYST4b25_uCFtdPqVivmkc7jsn2rr4qrFKK684=.5bf3b4dd-71df-4a30-99c0-d508e246b570@github.com>
Message-ID: <nnJESXsoYL67tkRdfH3TTIO3Aywv__AemTJfAr54P4I=.5c032b22-7f9a-4b0d-94f6-1f2ed9bfa0bd@github.com>

> Require each thread to observe unproductive Full GC before it throws OOM exception.

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

  Fix several bugs for GCU limit exceeded implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16985/files
  - new: https://git.openjdk.org/jdk/pull/16985/files/c80c049e..89aa26fe

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

  Stats: 32 lines in 3 files changed: 23 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/16985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16985/head:pull/16985

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

From wkemper at openjdk.org  Fri Dec  8 17:22:06 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 8 Dec 2023 17:22:06 GMT
Subject: RFR: 8321605: GenShen: Old generation reference process is never reset
Message-ID: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>

Shenandoah's reference processor workers keep state in thread local variables that need to be `reset` during init mark. Prior to this change, this was not happening for the old generation - resulting in an accumulation of counters.

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

Commit messages:
 - Reset old gen reference processor thread locals when bootstrapping old marking

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

PR: https://git.openjdk.org/shenandoah/pull/367

From kdnilsen at openjdk.org  Fri Dec  8 19:44:08 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 8 Dec 2023 19:44:08 GMT
Subject: RFR: 8321605: GenShen: Old generation reference process is never
 reset
In-Reply-To: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
References: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
Message-ID: <fbID4447weHq31iYnmZQD86DX_RRpz9oMf4Portq3fE=.a765f3e3-48f4-489f-8955-57a137244faf@github.com>

On Fri, 8 Dec 2023 17:17:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah's reference processor workers keep state in thread local variables that need to be `reset` during init mark. Prior to this change, this was not happening for the old generation - resulting in an accumulation of counters.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/367#pullrequestreview-1773050939

From ysr at openjdk.org  Fri Dec  8 19:44:10 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 8 Dec 2023 19:44:10 GMT
Subject: RFR: 8321605: GenShen: Old generation reference process is never
 reset
In-Reply-To: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
References: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
Message-ID: <YAjN2tLVyAYnVpS5Ia40IaxwHzxiLydgKYx7EM0Lm1M=.b442e44e-4dd6-4dfb-b792-16c248871744@github.com>

On Fri, 8 Dec 2023 17:17:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah's reference processor workers keep state in thread local variables that need to be `reset` during init mark. Prior to this change, this was not happening for the old generation - resulting in an accumulation of counters.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 688:

> 686:     ShenandoahInitMarkUpdateRegionStateClosure cl;
> 687:     heap->parallel_heap_region_iterate(&cl);
> 688:     heap->old_generation()->ref_processor()->reset_thread_locals();

Why don't we reset the thread locals in the else arm as well?

Is there a less error-prone way of doing this at the time that a new GC cycle that will do discovery is set up?

I realize my questions may be a bit naive as I don't have a full understanding of how the reference processor's state/initialization is handled overall.

For example, we do a bunch of reference processor related stuff further below at line 699. Why not reset the state of thread locals there instead? Would that miss someting?

If I look at the places where this state is reset elsewhere, it seems to occur in the same places where the policy is initialized. If that's done at each cycle that'll do ref-proc, may be that's always the place to reset state/counts?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/367#discussion_r1420949117

From ysr at openjdk.org  Fri Dec  8 19:44:12 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 8 Dec 2023 19:44:12 GMT
Subject: RFR: 8321605: GenShen: Old generation reference process is never
 reset
In-Reply-To: <YAjN2tLVyAYnVpS5Ia40IaxwHzxiLydgKYx7EM0Lm1M=.b442e44e-4dd6-4dfb-b792-16c248871744@github.com>
References: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
 <YAjN2tLVyAYnVpS5Ia40IaxwHzxiLydgKYx7EM0Lm1M=.b442e44e-4dd6-4dfb-b792-16c248871744@github.com>
Message-ID: <Oo1B_-HlnlJjcUfeuoRuKQSZ33o5vfwSUSmcv88wtDQ=.d71b9b9b-c8f8-4c55-8cb0-8576080ba610@github.com>

On Fri, 8 Dec 2023 19:38:54 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah's reference processor workers keep state in thread local variables that need to be `reset` during init mark. Prior to this change, this was not happening for the old generation - resulting in an accumulation of counters.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 688:
> 
>> 686:     ShenandoahInitMarkUpdateRegionStateClosure cl;
>> 687:     heap->parallel_heap_region_iterate(&cl);
>> 688:     heap->old_generation()->ref_processor()->reset_thread_locals();
> 
> Why don't we reset the thread locals in the else arm as well?
> 
> Is there a less error-prone way of doing this at the time that a new GC cycle that will do discovery is set up?
> 
> I realize my questions may be a bit naive as I don't have a full understanding of how the reference processor's state/initialization is handled overall.
> 
> For example, we do a bunch of reference processor related stuff further below at line 699. Why not reset the state of thread locals there instead? Would that miss someting?
> 
> If I look at the places where this state is reset elsewhere, it seems to occur in the same places where the policy is initialized. If that's done at each cycle that'll do ref-proc, may be that's always the place to reset state/counts?

I see now that this resets the old generation's reference processor. I suspect this is a consequence of the way in which old and young are being handled. A cleaner separation of the two for the generational case might help in the future, and avoid the current more error-prone structure.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/367#discussion_r1420959847

From wkemper at openjdk.org  Fri Dec  8 20:50:57 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 8 Dec 2023 20:50:57 GMT
Subject: RFR: 8321605: GenShen: Old generation reference process is never
 reset
In-Reply-To: <Oo1B_-HlnlJjcUfeuoRuKQSZ33o5vfwSUSmcv88wtDQ=.d71b9b9b-c8f8-4c55-8cb0-8576080ba610@github.com>
References: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
 <YAjN2tLVyAYnVpS5Ia40IaxwHzxiLydgKYx7EM0Lm1M=.b442e44e-4dd6-4dfb-b792-16c248871744@github.com>
 <Oo1B_-HlnlJjcUfeuoRuKQSZ33o5vfwSUSmcv88wtDQ=.d71b9b9b-c8f8-4c55-8cb0-8576080ba610@github.com>
Message-ID: <Kw4_iNyDj5EORQMt2dbrosAIIUrkKllNS5x8mhqfd_k=.68b62269-9738-4f47-9e49-674ddd538291@github.com>

On Fri, 8 Dec 2023 19:41:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 688:
>> 
>>> 686:     ShenandoahInitMarkUpdateRegionStateClosure cl;
>>> 687:     heap->parallel_heap_region_iterate(&cl);
>>> 688:     heap->old_generation()->ref_processor()->reset_thread_locals();
>> 
>> Why don't we reset the thread locals in the else arm as well?
>> 
>> Is there a less error-prone way of doing this at the time that a new GC cycle that will do discovery is set up?
>> 
>> I realize my questions may be a bit naive as I don't have a full understanding of how the reference processor's state/initialization is handled overall.
>> 
>> For example, we do a bunch of reference processor related stuff further below at line 699. Why not reset the state of thread locals there instead? Would that miss someting?
>> 
>> If I look at the places where this state is reset elsewhere, it seems to occur in the same places where the policy is initialized. If that's done at each cycle that'll do ref-proc, may be that's always the place to reset state/counts?
>
> I see now that this resets the old generation's reference processor. I suspect this is a consequence of the way in which old and young are being handled. A cleaner separation of the two for the generational case might help in the future, and avoid the current more error-prone structure.

I agree, the "bootstrap" cycle for the old generation is poorly modeled.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/367#discussion_r1421012978

From wkemper at openjdk.org  Fri Dec  8 20:50:57 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 8 Dec 2023 20:50:57 GMT
Subject: Integrated: 8321605: GenShen: Old generation reference process is
 never reset
In-Reply-To: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
References: <QhDmfYT2kGy_nHvH5beHGLEhqcflYBMXSuc9IKNWi7c=.271ddd0a-05f2-45fc-a0d4-a01ac55e27a0@github.com>
Message-ID: <1MzNd3c7Odf9gTIL0lnvHuphLx7w0wP2tAhgAAG2Cl8=.feaffe05-4e60-4db4-88b2-8a27dc43e1c8@github.com>

On Fri, 8 Dec 2023 17:17:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah's reference processor workers keep state in thread local variables that need to be `reset` during init mark. Prior to this change, this was not happening for the old generation - resulting in an accumulation of counters.

This pull request has now been integrated.

Changeset: 2458f136
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/2458f13684d9c2665c7c86dffcc23a24d1e73797
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8321605: GenShen: Old generation reference process is never reset

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.org/shenandoah/pull/367

From rkennke at openjdk.org  Mon Dec 11 16:59:51 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 11 Dec 2023 16:59:51 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v56]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <i_O9PgV1g15AMOlCYFl6TsBia1nmcyRtvEL4uSOvjKY=.034daf39-1a2a-4250-bb05-1e17b5cfde76@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -...

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

 - Merge branch 'master' into JDK-8305896
 - Merge remote-tracking branch 'upstream/master' into JDK-8305896
 - Fix build
 - Merge remote-tracking branch 'upstream/master' into JDK-8305896
 - Merge remote-tracking branch 'upstream/master' into JDK-8305896
 - Merge branch 'master' into JDK-8305896
 - Various cleanups
 - Some @shipilev comments from downstream review
 - Further templatize Serial GC's adjust_pointers()
 - Merge branch 'master' into JDK-8305896
 - ... and 113 more: https://git.openjdk.org/jdk/compare/3c6459e1...d67b42f5

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

Changes: https://git.openjdk.org/jdk/pull/13582/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13582&range=55
  Stats: 1203 lines in 39 files changed: 1079 ins; 10 del; 114 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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

From stefank at openjdk.org  Mon Dec 11 19:37:44 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 11 Dec 2023 19:37:44 GMT
Subject: RFR: 8321812: Update GC tests to use execute[Limited]TestJava
Message-ID: <SJsjlVy1S72d43Mmr2NmOGXChAAGzgc1O4KZ_YrFXEI=.2bb94c0e-1fe2-4537-bbe8-0b498bfcb1ed@github.com>

A lot of our tests use a multi-step recipe to spawn and wait for a process. Here's an example

    ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(
         "-XX:-UseTLAB",
         "-XX:+UnlockDiagnosticVMOptions",
         "-XX:+VerifyDuringStartup",
         "-Xlog:gc+verify=debug",
         "-version");
    OutputAnalyzer output = new OutputAnalyzer(pb.start());
    ... do something with output and wait for the process to complete ...


These are the steps involved:

1) Create a `ProcessBuilder`
2) Call `ProcessBuilder::start`
3) Create an `OutputAnalyzer`
4) Perform an operation that finally waits for the process to, at least partially, complete (OutputAnalyzer::getOutput, OutputAnalyzer::shouldHaveExitValue(), and more).

Almost all our tests could be converted to use a single call to `ProcessTools.executeTestJava` (or `executeLimitedTestJava`), which spawns the process, makes sure that it has fully completed, and then returns a filled-in OutputAnalyzer to the caller. The above example would become:


    OutputAnalyzer output = ProcessTools.executeTestJava(
         "-XX:-UseTLAB",
         "-XX:+UnlockDiagnosticVMOptions",
         "-XX:+VerifyDuringStartup",
         "-Xlog:gc+verify=debug",
         "-version");


I propose that we make this change in the GC tests, to make our code simpler and hopefully easier to read.

Note: There's a few changes to the throws statements because some ProcessTools APIs throws IOException while others throw Exception.

Testing: I've done testing on a similar set of changes, but I'm going to run the appropriate, final tests while this is being considered/reviewed.

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

Depends on: https://git.openjdk.org/jdk/pull/17049

Commit messages:
 - 8321812: Update GC tests to use execute[Limited]TestJava

Changes: https://git.openjdk.org/jdk/pull/17067/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321812
  Stats: 665 lines in 131 files changed: 32 ins; 216 del; 417 mod
  Patch: https://git.openjdk.org/jdk/pull/17067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17067/head:pull/17067

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

From wkemper at openjdk.org  Tue Dec 12 17:15:24 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 12 Dec 2023 17:15:24 GMT
Subject: RFR: Merge openjdk/jdk:master [v6]
In-Reply-To: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
References: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
Message-ID: <sFbAGZDUFu6nnOo9PVIUcr31bJmhOpQjgtmjOW59fGM=.3eadc3b4-2217-46f1-914a-3b98099d3b70@github.com>

> Merges tag jdk-22+26

William Kemper has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Use API for version of jtreg used to build jdk21"
   
   This reverts commit 4cbbf23918a2297bed0008906c5342f47aab0de7.
 - Use API for version of jtreg used to build jdk21

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/363/files
  - new: https://git.openjdk.org/shenandoah/pull/363/files/99df412f..e65e8f9e

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

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

PR: https://git.openjdk.org/shenandoah/pull/363

From wkemper at openjdk.org  Tue Dec 12 22:25:53 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 12 Dec 2023 22:25:53 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
References: <QZyAbveBx3_fVR4LqFtj1XTKJ17fQglpGcmB08AtxjU=.fc1dc224-5e49-4741-a9c6-9ab326d40d85@github.com>
Message-ID: <_c9FY05HRhWDQC1yD6FxyOfK8RYyAYQVedhO8G5djFM=.d9e72476-e2c5-436f-8eb3-96af1805f317@github.com>

On Thu, 30 Nov 2023 14:10:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+26

This pull request has now been integrated.

Changeset: 0a0562a5
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/0a0562a5303e656c0d01a49b3d3d8e015d5b5e87
Stats:     16463 lines in 648 files changed: 11110 ins; 3132 del; 2221 mod

Merge

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

PR: https://git.openjdk.org/shenandoah/pull/363

From wkemper at openjdk.org  Tue Dec 12 22:43:25 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 12 Dec 2023 22:43:25 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <TnqjRkmbQqeRDPFffdnUWoiWsAQbldIkyuZpaImyXM0=.f01edde8-be4a-4281-8b1b-01c1fee41166@github.com>

Merges tag jdk-22+27

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

Commit messages:
 - 8319313: G1: Rename G1EvacFailureInjector appropriately
 - 8320370: NMT: Change MallocMemorySnapshot to simplify code.
 - 8321223: Implementation of Scoped Values (Second Preview)
 - 8321001: RISC-V: C2 SignumVF
 - 8316454: JFR break locale settings
 - 8321470: ThreadLocal.nextHashCode can be static final
 - 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access)
 - 8321505: JFR: Update views
 - 8321519: Typo in exception message
 - 8320805: JFR: Create view for deprecated methods
 - ... and 133 more: https://git.openjdk.org/shenandoah/compare/ea6e92ed...86f9b3f5

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

Changes: https://git.openjdk.org/shenandoah/pull/368/files
  Stats: 88230 lines in 1720 files changed: 41554 ins; 40178 del; 6498 mod
  Patch: https://git.openjdk.org/shenandoah/pull/368.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/368/head:pull/368

PR: https://git.openjdk.org/shenandoah/pull/368

From wkemper at openjdk.org  Tue Dec 12 22:54:47 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 12 Dec 2023 22:54:47 GMT
Subject: RFR: 8321937: GenShen: Sync up 21u based repo
Message-ID: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>

Backport recent Shenandoah changes

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

Commit messages:
 - Use API for version of jtreg used to build jdk21
 - 8316226: GenShen: Consider forcing auto-tenure age to be greater than 1
 - 8320336: GenShen: Reduce proactive humongous defragmentation efforts
 - 8320112: GenShen: Improve end of process report
 - 8320119: GenShen: Correct misspellings of parsable
 - 8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC
 - 8319931: GenShen: Increase no progress threshold for TestThreadFailure
 - 8319867: GenShen: Make old regions parsable at end of concurrent cycles
 - 8318462: [GenShen] Prevent unsafe access to displaced mark-word
 - 8319671: GenShen: Old marking may encounter invalid pointers in SATB buffers
 - ... and 3 more: https://git.openjdk.org/shenandoah-jdk21u/compare/57fb4b2b...0afff542

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/4/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=4&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321937
  Stats: 925 lines in 38 files changed: 438 ins; 225 del; 262 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/4.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/4/head:pull/4

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

From wkemper at openjdk.org  Wed Dec 13 01:14:54 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 01:14:54 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <TnqjRkmbQqeRDPFffdnUWoiWsAQbldIkyuZpaImyXM0=.f01edde8-be4a-4281-8b1b-01c1fee41166@github.com>
References: <TnqjRkmbQqeRDPFffdnUWoiWsAQbldIkyuZpaImyXM0=.f01edde8-be4a-4281-8b1b-01c1fee41166@github.com>
Message-ID: <PBtzN8ugSrb2CCsvwes3x76RLjx6Lc34BAmRzOHAZr0=.b7790e16-04e7-47dc-a723-839d3fec907c@github.com>

> Merges tag jdk-22+27

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

 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-22+27
 - 8319313: G1: Rename G1EvacFailureInjector appropriately
   
   Reviewed-by: mli, iwalulya, ayang
 - 8320370: NMT: Change MallocMemorySnapshot to simplify code.
   
   Reviewed-by: stuefe, gziemski, stefank
 - 8321223: Implementation of Scoped Values (Second Preview)
   
   Reviewed-by: psandoz, mcimadamore
 - 8321001: RISC-V: C2 SignumVF
   8321002: RISC-V: C2 SignumVD
   
   Reviewed-by: fyang
 - 8316454: JFR break locale settings
   
   Reviewed-by: mgronlun
 - 8321470: ThreadLocal.nextHashCode can be static final
   
   Reviewed-by: shade, jpai
 - 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access)
   
   Reviewed-by: pminborg
 - 8321505: JFR: Update views
   
   Reviewed-by: mgronlun
 - 8321519: Typo in exception message
   
   Reviewed-by: jpai
 - ... and 134 more: https://git.openjdk.org/shenandoah/compare/0a0562a5...0b638103

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

Changes: https://git.openjdk.org/shenandoah/pull/368/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=368&range=01
  Stats: 88269 lines in 1722 files changed: 41555 ins; 40212 del; 6502 mod
  Patch: https://git.openjdk.org/shenandoah/pull/368.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/368/head:pull/368

PR: https://git.openjdk.org/shenandoah/pull/368

From ysr at openjdk.org  Wed Dec 13 01:36:02 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 13 Dec 2023 01:36:02 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails with
 divide-by-zero
Message-ID: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>

The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.

**Testing:**
- [ ] GHA
- [ ] code pipeline testing
- [ ] specjbb with SOEP=default,0,100 to verify that the issue is fixed

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

Commit messages:
 - jcheck trailing white-space.
 - Merge branch 'master' into tenure_budget_8314599
 - Fix another case where divide-by-zero could occur when
 - Fix divide-by-zero when ShenandoahOldEvacRatioPercent==100; minor

Changes: https://git.openjdk.org/shenandoah/pull/369/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=369&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321939
  Stats: 172 lines in 3 files changed: 62 ins; 68 del; 42 mod
  Patch: https://git.openjdk.org/shenandoah/pull/369.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/369/head:pull/369

PR: https://git.openjdk.org/shenandoah/pull/369

From ysr at openjdk.org  Wed Dec 13 01:39:47 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 13 Dec 2023 01:39:47 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
Message-ID: <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>

> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
> 
> **Testing:**
> - [ ] GHA
> - [ ] code pipeline testing
> - [ ] specjbb with SOEP=default,0,100 to verify that the issue is fixed

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Fix a scope issue with a local variable.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/369/files
  - new: https://git.openjdk.org/shenandoah/pull/369/files/7166147f..03e55dee

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

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

PR: https://git.openjdk.org/shenandoah/pull/369

From wkemper at openjdk.org  Wed Dec 13 16:53:22 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 16:53:22 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <PBtzN8ugSrb2CCsvwes3x76RLjx6Lc34BAmRzOHAZr0=.b7790e16-04e7-47dc-a723-839d3fec907c@github.com>
References: <TnqjRkmbQqeRDPFffdnUWoiWsAQbldIkyuZpaImyXM0=.f01edde8-be4a-4281-8b1b-01c1fee41166@github.com>
 <PBtzN8ugSrb2CCsvwes3x76RLjx6Lc34BAmRzOHAZr0=.b7790e16-04e7-47dc-a723-839d3fec907c@github.com>
Message-ID: <FLf8QDLAViotDY3MfNxH1PCrHBNFrJacvViVvJi3WZU=.0399f8bc-5b77-487e-a043-c11eff3d548d@github.com>

On Wed, 13 Dec 2023 01:14:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-22+27
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 144 commits:
> 
>  - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-22+27
>  - 8319313: G1: Rename G1EvacFailureInjector appropriately
>    
>    Reviewed-by: mli, iwalulya, ayang
>  - 8320370: NMT: Change MallocMemorySnapshot to simplify code.
>    
>    Reviewed-by: stuefe, gziemski, stefank
>  - 8321223: Implementation of Scoped Values (Second Preview)
>    
>    Reviewed-by: psandoz, mcimadamore
>  - 8321001: RISC-V: C2 SignumVF
>    8321002: RISC-V: C2 SignumVD
>    
>    Reviewed-by: fyang
>  - 8316454: JFR break locale settings
>    
>    Reviewed-by: mgronlun
>  - 8321470: ThreadLocal.nextHashCode can be static final
>    
>    Reviewed-by: shade, jpai
>  - 8321467: MemorySegment.setString(long, String, Charset) throws IAE(Misaligned access)
>    
>    Reviewed-by: pminborg
>  - 8321505: JFR: Update views
>    
>    Reviewed-by: mgronlun
>  - 8321519: Typo in exception message
>    
>    Reviewed-by: jpai
>  - ... and 134 more: https://git.openjdk.org/shenandoah/compare/0a0562a5...0b638103

Single test failure in tier3, looks unrelated to Shenandoah.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/368#issuecomment-1854324380

From wkemper at openjdk.org  Wed Dec 13 16:53:24 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 16:53:24 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <TnqjRkmbQqeRDPFffdnUWoiWsAQbldIkyuZpaImyXM0=.f01edde8-be4a-4281-8b1b-01c1fee41166@github.com>
References: <TnqjRkmbQqeRDPFffdnUWoiWsAQbldIkyuZpaImyXM0=.f01edde8-be4a-4281-8b1b-01c1fee41166@github.com>
Message-ID: <1wlQyMRhG0hyg8JLA5IuWraQx8a46Mg2H0EGafc0sSI=.80a32000-0ca3-4361-b2ba-0edefaab0893@github.com>

On Tue, 12 Dec 2023 22:38:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-22+27

This pull request has now been integrated.

Changeset: ba3f619a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/ba3f619a6962e5f94a1fcd72ed48f4138229f361
Stats:     88269 lines in 1722 files changed: 41555 ins; 40212 del; 6502 mod

Merge

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

PR: https://git.openjdk.org/shenandoah/pull/368

From wkemper at openjdk.org  Wed Dec 13 16:56:02 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 16:56:02 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <CHbuoaKl9AHDRK_BAZqfNfM_Mme2vuXjHB9SHNIVrkU=.0bf025c6-6d44-4473-ad90-57307fa2fb48@github.com>
References: <CHbuoaKl9AHDRK_BAZqfNfM_Mme2vuXjHB9SHNIVrkU=.0bf025c6-6d44-4473-ad90-57307fa2fb48@github.com>
Message-ID: <79LsBTDjdfRrxCjWtGbnOBwFA1CmWdj-b9w2RaNpcSg=.22fa2ba3-9ff2-422a-9bcd-9bf92d62754e@github.com>

> Merge tip of jdk21u

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. The pull request contains two additional commits since the last revision:

 - Merge 'openjdk-21u/master' into 'shenandoah-jdk21u/master'
 - 8320913: GenShen: Bootstrap 21u backports repo
   
   Reviewed-by: ysr, kdnilsen

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/2/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/2/files/7c145a52..7c145a52

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

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

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

From wkemper at openjdk.org  Wed Dec 13 16:56:04 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 16:56:04 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <CHbuoaKl9AHDRK_BAZqfNfM_Mme2vuXjHB9SHNIVrkU=.0bf025c6-6d44-4473-ad90-57307fa2fb48@github.com>
References: <CHbuoaKl9AHDRK_BAZqfNfM_Mme2vuXjHB9SHNIVrkU=.0bf025c6-6d44-4473-ad90-57307fa2fb48@github.com>
Message-ID: <-_WdDOUlLLfJfw1OwTaIeDAgnJBji6L01U1TFkRfTtQ=.cc6ab936-a10b-441a-99f8-5ca0a3ff026b@github.com>

On Wed, 29 Nov 2023 21:59:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merge tip of jdk21u

This pull request has now been integrated.

Changeset: 4609d721
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/4609d72106788cdc85d419fb2e35bf597e6f8995
Stats:     17927 lines in 348 files changed: 11041 ins; 1810 del; 5076 mod

Merge

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

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

From wkemper at openjdk.org  Wed Dec 13 17:08:48 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 17:08:48 GMT
Subject: RFR: 8321937: GenShen: Sync up 21u based repo [v2]
In-Reply-To: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
References: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
Message-ID: <urB7Uvt5JnLn8KiiCsDK1y3tW1vpdn2_kCIPShttD90=.99e018e2-41a5-454b-9183-782c4d2b193d@github.com>

> Backport recent Shenandoah changes

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. The pull request contains 14 additional commits since the last revision:

 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into merge-shen-master-into-shen-21
 - Use API for version of jtreg used to build jdk21
 - 8316226: GenShen: Consider forcing auto-tenure age to be greater than 1
   
   Reviewed-by: wkemper, kdnilsen
 - 8320336: GenShen: Reduce proactive humongous defragmentation efforts
   
   Reviewed-by: wkemper, ysr
 - 8320112: GenShen: Improve end of process report
   
   Reviewed-by: kdnilsen
 - 8320119: GenShen: Correct misspellings of parsable
   
   Reviewed-by: kdnilsen, ysr
 - 8319342: GenShen: Reset the count of degenerated cycles in a row following Full GC
   
   Reviewed-by: wkemper, ysr
 - 8319931: GenShen: Increase no progress threshold for TestThreadFailure
   
   Reviewed-by: kdnilsen
 - 8319867: GenShen: Make old regions parsable at end of concurrent cycles
   
   Reviewed-by: kdnilsen, ysr
 - 8318462: [GenShen] Prevent unsafe access to displaced mark-word
   
   Reviewed-by: kdnilsen, wkemper, ysr
 - ... and 4 more: https://git.openjdk.org/shenandoah-jdk21u/compare/9b613688...555c581a

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/4/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/4/files/0afff542..555c581a

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

  Stats: 17927 lines in 348 files changed: 11041 ins; 1810 del; 5076 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/4.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/4/head:pull/4

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

From wkemper at openjdk.org  Wed Dec 13 20:37:14 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 20:37:14 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <wpi_XcMnnYfanQKjDnIlrM2i9Hl9ENHO534k5eCBexE=.4a1828d9-07aa-455e-bd1a-d8fb1108b5f2@github.com>

Merges tag jdk-23+1

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

Commit messages:
 - 8319413: Start of release updates for JDK 23

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

Changes: https://git.openjdk.org/shenandoah/pull/370/files
  Stats: 4872 lines in 98 files changed: 4828 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/shenandoah/pull/370.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/370/head:pull/370

PR: https://git.openjdk.org/shenandoah/pull/370

From kdnilsen at openjdk.org  Wed Dec 13 21:23:12 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Dec 2023 21:23:12 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
Message-ID: <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>

On Wed, 13 Dec 2023 01:39:47 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
>> 
>> **Testing:**
>> - [x] GHA
>> - [ ] code pipeline testing
>> - [ ] specjbb with SOEP=default,0,100 to verify that the issue is fixed
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a scope issue with a local variable.

Marked as reviewed by kdnilsen (Committer).

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 269:

> 267:   //            SOEP/100 = OE/TE
> 268:   //                     = OE/(OE+YE)
> 269:   //  => SOEP/(100-SOEP) = OE/((OE+YE)-OE)

I get lost at this step.  Here's how I see the algebra from this point forward:
  (OE + YE) * SOEP == 100 OE         (multiply both sides by 100 (OE + YE)
  YE * SOEP = 100 OE - SOEP * OE (subtract SOEP * OE from both sides)
  YE * SOEP = OE * (100 - SOEP)
  OE = YE * SOEP / (100 - SOEP)
  
  (we agree on final result.  I just don't follow the justification for step at line 269.  maybe you can explain that line better?)

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

> 1204:   //                     = OE/YE
> 1205:   //  =>              OE = YE*SOEP/(100-SOEP)
> 1206: 

Same comment as above, regarding the algebra steps.

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

> 1240:   const bool doing_promotions = promo_load > 0;
> 1241:   if (doing_promotions) {
> 1242:     // We're only promoting and we have a maximum bound on the amount to be promoted

With reference to the preceding comment, we should probably add an assert here: assert(!doing_mixed, "Don't do mixed and promotions in the same cycle")

Or maybe this is no longer true.  It doesn't have to be true.  The code that follows seems to suggest this is no longer true.  It was a simplification at some point in the implementation history.  If it is no longer true, let's remove that comment.

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

PR Review: https://git.openjdk.org/shenandoah/pull/369#pullrequestreview-1780476196
PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425876097
PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425879329
PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425893069

From ysr at openjdk.org  Wed Dec 13 21:46:24 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 13 Dec 2023 21:46:24 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
Message-ID: <jlZ9Yr2uRd3BHPrEu6ZzaHaqnQ6gzumhIZO09EVQt3Q=.2a8bbe07-44ae-4639-b038-0bd4794027db@github.com>

On Wed, 13 Dec 2023 20:56:19 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a scope issue with a local variable.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 269:
> 
>> 267:   //            SOEP/100 = OE/TE
>> 268:   //                     = OE/(OE+YE)
>> 269:   //  => SOEP/(100-SOEP) = OE/((OE+YE)-OE)
> 
> I get lost at this step.  Here's how I see the algebra from this point forward:
>   (OE + YE) * SOEP == 100 OE         (multiply both sides by 100 (OE + YE)
>   YE * SOEP = 100 OE - SOEP * OE (subtract SOEP * OE from both sides)
>   YE * SOEP = OE * (100 - SOEP)
>   OE = YE * SOEP / (100 - SOEP)
>   
>   (we agree on final result.  I just don't follow the justification for step at line 269.  maybe you can explain that line better?)

ah, yes, I used the so-called "componendo-dividendo" rule from middle school, in this instantiation of the more general schema:

If a/b = c/d, then a/(b-a) = c/(d-c)

It is perhaps not very well-known in modern ratio-proportion pedagogy in grade-school, but is very useful for quick arithemtic.

https://hsm.stackexchange.com/questions/7544/etymology-of-some-terms-used-in-ratio-and-proportion-in-old-algebra-textbooks

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425916254

From wkemper at openjdk.org  Wed Dec 13 21:47:37 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Dec 2023 21:47:37 GMT
Subject: RFR: 8321937: GenShen: Sync up 21u based repo [v3]
In-Reply-To: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
References: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
Message-ID: <tPGb_Exjoac7WW5j0CYR6MnBExrUgH2ukrcu-CJZMWk=.951a65c4-db07-48f9-873d-7d995b5e6c95@github.com>

> Backport recent Shenandoah changes

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

  Remove use of option which has not been backported yet

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/4/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/4/files/555c581a..b6415bdd

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

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

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

From ysr at openjdk.org  Wed Dec 13 21:58:23 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 13 Dec 2023 21:58:23 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <jlZ9Yr2uRd3BHPrEu6ZzaHaqnQ6gzumhIZO09EVQt3Q=.2a8bbe07-44ae-4639-b038-0bd4794027db@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
 <jlZ9Yr2uRd3BHPrEu6ZzaHaqnQ6gzumhIZO09EVQt3Q=.2a8bbe07-44ae-4639-b038-0bd4794027db@github.com>
Message-ID: <rufumBRiSOA4TBvILZJaQd7ZarDrhkJMLgiRT1Tvxvg=.9e63328b-a8e4-4188-90c8-5a45bfa8a637@github.com>

On Wed, 13 Dec 2023 21:43:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 269:
>> 
>>> 267:   //            SOEP/100 = OE/TE
>>> 268:   //                     = OE/(OE+YE)
>>> 269:   //  => SOEP/(100-SOEP) = OE/((OE+YE)-OE)
>> 
>> I get lost at this step.  Here's how I see the algebra from this point forward:
>>   (OE + YE) * SOEP == 100 OE         (multiply both sides by 100 (OE + YE)
>>   YE * SOEP = 100 OE - SOEP * OE (subtract SOEP * OE from both sides)
>>   YE * SOEP = OE * (100 - SOEP)
>>   OE = YE * SOEP / (100 - SOEP)
>>   
>>   (we agree on final result.  I just don't follow the justification for step at line 269.  maybe you can explain that line better?)
>
> ah, yes, I used the so-called "componendo-dividendo" rule from middle school, in this instantiation of the more general schema:
> 
> If a/b = c/d, then a/(b-a) = c/(d-c)
> 
> It is perhaps not very well-known in modern ratio-proportion pedagogy in grade-school, but is very useful for quick arithemtic.
> 
> https://hsm.stackexchange.com/questions/7544/etymology-of-some-terms-used-in-ratio-and-proportion-in-old-algebra-textbooks

I'll add the justification in the comment.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425924525

From ysr at openjdk.org  Wed Dec 13 21:58:23 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 13 Dec 2023 21:58:23 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
Message-ID: <AL6G6hjwSfkcGRkXo7gIVWR1UTxyz5Q21kMmW6cQ7H8=.aa6e39fa-b9dd-43ea-8b8c-b15c9ac2befd@github.com>

On Wed, 13 Dec 2023 21:16:08 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a scope issue with a local variable.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1242:
> 
>> 1240:   const bool doing_promotions = promo_load > 0;
>> 1241:   if (doing_promotions) {
>> 1242:     // We're only promoting and we have a maximum bound on the amount to be promoted
> 
> With reference to the preceding comment, we should probably add an assert here: assert(!doing_mixed, "Don't do mixed and promotions in the same cycle")
> 
> Or maybe this is no longer true.  It doesn't have to be true.  The code that follows seems to suggest this is no longer true.  It was a simplification at some point in the implementation history.  If it is no longer true, let's remove that comment.

I believe you are right. The comment appears obsolete. I'll check/confirm and delete the comment. Thanks!

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425925729

From kdnilsen at openjdk.org  Wed Dec 13 22:05:11 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Dec 2023 22:05:11 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <rufumBRiSOA4TBvILZJaQd7ZarDrhkJMLgiRT1Tvxvg=.9e63328b-a8e4-4188-90c8-5a45bfa8a637@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
 <jlZ9Yr2uRd3BHPrEu6ZzaHaqnQ6gzumhIZO09EVQt3Q=.2a8bbe07-44ae-4639-b038-0bd4794027db@github.com>
 <rufumBRiSOA4TBvILZJaQd7ZarDrhkJMLgiRT1Tvxvg=.9e63328b-a8e4-4188-90c8-5a45bfa8a637@github.com>
Message-ID: <WE1Xajl0uVwo-SHSj7tSh_CZqyHhCmjpH7YsX6QSC_8=.d7324f69-e72d-45fc-bc08-ce26b3be958d@github.com>

On Wed, 13 Dec 2023 21:54:06 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> ah, yes, I used the so-called "componendo-dividendo" rule from middle school, in this instantiation of the more general schema:
>> 
>> If a/b = c/d, then a/(b-a) = c/(d-c)
>> 
>> It is perhaps not very well-known in modern ratio-proportion pedagogy in grade-school, but is very useful for quick arithemtic.
>> 
>> https://hsm.stackexchange.com/questions/7544/etymology-of-some-terms-used-in-ratio-and-proportion-in-old-algebra-textbooks
>
> I'll add the justification in the comment.

Thanks.  Your recollection of middle-school math is better than mine...  :)

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1425931096

From wkemper at openjdk.org  Thu Dec 14 19:20:00 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Dec 2023 19:20:00 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run
Message-ID: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>

Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

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

Commit messages:
 - Merge remote-tracking branch 'shenandoah/master' into reduce-old-starvation
 - Merge remote-tracking branch 'shenandoah/master' into reduce-old-starvation
 - Experiment with a minimum old marking increment

Changes: https://git.openjdk.org/shenandoah/pull/371/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321816
  Stats: 20 lines in 3 files changed: 19 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/371.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/371/head:pull/371

PR: https://git.openjdk.org/shenandoah/pull/371

From wkemper at openjdk.org  Thu Dec 14 19:25:51 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Dec 2023 19:25:51 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint
Message-ID: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>

Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

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

Commit messages:
 - Fix whitespace
 - Sync gc state with threads on VM thread
 - Synchronize gc state with java threads once, when exiting safepoint

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

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

From kdnilsen at openjdk.org  Thu Dec 14 19:32:17 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 14 Dec 2023 19:32:17 GMT
Subject: RFR: 8321937: GenShen: Sync up 21u based repo [v3]
In-Reply-To: <tPGb_Exjoac7WW5j0CYR6MnBExrUgH2ukrcu-CJZMWk=.951a65c4-db07-48f9-873d-7d995b5e6c95@github.com>
References: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
 <tPGb_Exjoac7WW5j0CYR6MnBExrUgH2ukrcu-CJZMWk=.951a65c4-db07-48f9-873d-7d995b5e6c95@github.com>
Message-ID: <IEW7_hufMK9vhc2ciJtpN2eRifVg0Aj8qtTWPkENjFQ=.8483484e-9adc-4ab4-97b4-261a0970f9e2@github.com>

On Wed, 13 Dec 2023 21:47:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Backport recent Shenandoah changes
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove use of option which has not been backported yet

Thanks for wading through all these diffs.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/4#pullrequestreview-1782562933

From kdnilsen at openjdk.org  Thu Dec 14 19:33:17 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 14 Dec 2023 19:33:17 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run
In-Reply-To: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
Message-ID: <4_IpPiVZ5sqTlWz6qjEVlnmzBNf0Bv-JwY2MQuWvAPg=.d764f8c3-c74c-47f6-bf10-77dc5bcec234@github.com>

On Thu, 14 Dec 2023 19:11:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/371#pullrequestreview-1782564672

From kdnilsen at openjdk.org  Thu Dec 14 19:36:38 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 14 Dec 2023 19:36:38 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <YZirJs4-c8FFiPbgYAQ02tY44ydtvtBGhCyWgPhsyRc=.2e7cdcec-9ee8-4a99-8cd5-6bf529c63e03@github.com>

On Thu, 14 Dec 2023 19:14:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

Am wondering if we measure any improvement in time-at-safepoints for workloads with large number of threads?

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

Marked as reviewed by kdnilsen (no project role).

PR Review: https://git.openjdk.org/jdk/pull/17112#pullrequestreview-1782569774

From cslucas at openjdk.org  Thu Dec 14 19:44:09 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 14 Dec 2023 19:44:09 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
Message-ID: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>

> # Description
> 
> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
> 
> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
> 
> # Help Needed for Testing
> 
> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
> 
> # Testing status
> 
> ## tier1
> 
> |          |   Win   |   Mac   |  Linux  |
> |----------|---------|---------|---------|
> | ARM64    |         |         |         |
> | ARM32    |         |         |         |
> | x86      |         |         |         |
> | x64      |         |         |         |
> | PPC64    |         |         |         |
> | S390x    |         |         |         |
> | RiscV    |         |         |         |

Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge with origin/master
 - Fix build, copyright dates, m4 files.
 - Fix merge
 - Catch up with master branch.
   
   Merge remote-tracking branch 'origin/master' into reuse-macroasm
 - Some inst_mark fixes; Catch up with master.
 - Catch up with changes on master
 - Reuse same C2_MacroAssembler object to emit instructions.

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

Changes: https://git.openjdk.org/jdk/pull/16484/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16484&range=05
  Stats: 2446 lines in 61 files changed: 106 ins; 434 del; 1906 mod
  Patch: https://git.openjdk.org/jdk/pull/16484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16484/head:pull/16484

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

From wkemper at openjdk.org  Thu Dec 14 22:36:35 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Dec 2023 22:36:35 GMT
Subject: Integrated: 8321937: GenShen: Sync up 21u based repo
In-Reply-To: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
References: <De3yOreb8RuEaj55K54vHmHm1U1m2umJ6G6HIl8kkRY=.1148bf7b-396c-4411-a268-da6111c7be26@github.com>
Message-ID: <gmPwRJKxuMbvhBfYqlWplcGo5clglIez7ksVmlQgve4=.ba92beea-28ea-4b4a-b065-036c8be09f5c@github.com>

On Fri, 8 Dec 2023 21:53:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Backport recent Shenandoah changes

This pull request has now been integrated.

Changeset: f680de9a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/f680de9a39ec699208e68600a854de849d321e21
Stats:     924 lines in 37 files changed: 438 ins; 225 del; 261 mod

8321937: GenShen: Sync up 21u based repo

Reviewed-by: kdnilsen

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

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

From luhenry at openjdk.org  Fri Dec 15 01:49:41 2023
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 15 Dec 2023 01:49:41 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <tKNfncBEMPLO9_GqV_9h3YusTDnDZHh4ZlfkXcwxoU4=.175868b2-eb52-4325-86d9-68a6e160d064@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |         |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |         |
>> | x64      |         |         |         |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |         |         |         |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

I've verified it works on riscv64, passing hotspot tier1 and tier2 tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1857140962

From ysr at openjdk.org  Fri Dec 15 08:40:37 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 08:40:37 GMT
Subject: RFR: 8322150: [GenShen] TestPeriodicGC fails with
 "Generational mode: Should have periodic young GC in logs"
Message-ID: <L-DQXBrcn-vh_FV9W4wttDm7wtZMzdC9HtCt5QKdzCk=.efd14563-0f9f-4d68-a1b6-5043d15020cd@github.com>

8322150: [GenShen] TestPeriodicGC fails with "Generational mode: Should have periodic young GC in logs"

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

Commit messages:
 - Merge branch 'master' into should_unload_classes
 - JDK-8322150 should_unload_classes should return true only if a metaspace

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

PR: https://git.openjdk.org/shenandoah/pull/372

From ysr at openjdk.org  Fri Dec 15 09:19:37 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 09:19:37 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v3]
In-Reply-To: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
Message-ID: <WIKRV9fmUsfUNntfj6PX0nSkOCcTL-C1SW-9jXrBbf8=.7e64e0c6-7e89-441d-85bd-aeebf038aad1@github.com>

> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
> 
> **Testing:**
> - [x] GHA
> - [ ] code pipeline testing
> - [x] specjbb with SOEP=default,0,100 to verify that the issue is fixed

Y. Srinivas Ramakrishna 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 ten additional commits since the last revision:

 - Merge branch 'should_unload_classes' into tenure_budget_8314599
 - Merge branch 'master' into should_unload_classes
 - JDK-8322150 should_unload_classes should return true only if a metaspace
   oom has been signalled, and other conditions are met.
 - Merge branch 'master' into tenure_budget_8314599
 - Fix a scope issue with a local variable.
 - jcheck trailing white-space.
 - Merge branch 'master' into tenure_budget_8314599
 - Fix another case where divide-by-zero could occur when
   ShenandoahOldEvacRatioPercent is set to 100. Some slight refactoring in
   the method.
 - Fix divide-by-zero when ShenandoahOldEvacRatioPercent==100; minor
   refactor & modification of documentation of flag

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/369/files
  - new: https://git.openjdk.org/shenandoah/pull/369/files/03e55dee..67318a30

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

  Stats: 88271 lines in 1723 files changed: 41556 ins; 40212 del; 6503 mod
  Patch: https://git.openjdk.org/shenandoah/pull/369.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/369/head:pull/369

PR: https://git.openjdk.org/shenandoah/pull/369

From ysr at openjdk.org  Fri Dec 15 09:24:15 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 09:24:15 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v3]
In-Reply-To: <WIKRV9fmUsfUNntfj6PX0nSkOCcTL-C1SW-9jXrBbf8=.7e64e0c6-7e89-441d-85bd-aeebf038aad1@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <WIKRV9fmUsfUNntfj6PX0nSkOCcTL-C1SW-9jXrBbf8=.7e64e0c6-7e89-441d-85bd-aeebf038aad1@github.com>
Message-ID: <LAF1lVOmPBZUaO4Kv4FkN895QT0KeIHAeRAM0f6TPgs=.1ba59cb4-23f4-47cc-b043-d2ed1d4da2c3@github.com>

On Fri, 15 Dec 2023 09:19:37 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
>> 
>> **Testing:**
>> - [x] GHA
>> - [ ] code pipeline testing
>> - [x] specjbb with SOEP=default,0,100 to verify that the issue is fixed
>
> Y. Srinivas Ramakrishna 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 ten additional commits since the last revision:
> 
>  - Merge branch 'should_unload_classes' into tenure_budget_8314599
>  - Merge branch 'master' into should_unload_classes
>  - JDK-8322150 should_unload_classes should return true only if a metaspace
>    oom has been signalled, and other conditions are met.
>  - Merge branch 'master' into tenure_budget_8314599
>  - Fix a scope issue with a local variable.
>  - jcheck trailing white-space.
>  - Merge branch 'master' into tenure_budget_8314599
>  - Fix another case where divide-by-zero could occur when
>    ShenandoahOldEvacRatioPercent is set to 100. Some slight refactoring in
>    the method.
>  - Fix divide-by-zero when ShenandoahOldEvacRatioPercent==100; minor
>    refactor & modification of documentation of flag

This PR is blocked until PR https://github.com/openjdk/shenandoah/pull/372 integrates.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 1:

> 1: /*

Please ignore the changes in this file for now. It'll go away once the fix for the linked ticket https://bugs.openjdk.org/browse/JDK-8322150 is committed. This PR is blocked until that ticet's PR is committed.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/369#issuecomment-1857546018
PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1427743546

From ysr at openjdk.org  Fri Dec 15 16:35:15 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 16:35:15 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run
In-Reply-To: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
Message-ID: <2KWP95bvJ9D7WXDPM0_eg6AKoqHWlxk7PK9kZhYxSZE=.acfba3ce-7b6c-43f7-8822-2b2c5a5dd523@github.com>

On Thu, 14 Dec 2023 19:11:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

Looks generally good, but a couple of clarification/documentation requests/questions.

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 79:

> 77:         }
> 78:       } else {
> 79:         if (should_start_young()) {

1. Could you explain (and document) why we don't do the same check `should_start_young` also at line 88 further below, _then_ `start_young_cycle`, where we find the control thread in the mode `servicing_old`?
2. The split of the roles of checks between the control points of this loop and the heuristics, and the actual requests to start a cycle look like they could do with a bit of clean up for consistency. At the current time (not as a result of your current change), the checks and the actions are scattered over a few routines so that reasoning about their correctness (or their behaviour) can be a bit challenging. This latter clean-up can, however, wait for the future.

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.hpp line 91:

> 89:   bool request_concurrent_gc(ShenandoahGenerationType generation);
> 90: 
> 91:   bool should_start_young();

Please add a brief line of documentation.

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

PR Review: https://git.openjdk.org/shenandoah/pull/371#pullrequestreview-1784487189
PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1428177814
PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1428178613

From ysr at openjdk.org  Fri Dec 15 16:52:40 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 16:52:40 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <2YbhDiO35Y6hAbuZwTaaUDWyC5av3ArrQLwZgtcIkhY=.39c627e5-21fc-49e7-aff6-5295833c58fa@github.com>

On Thu, 14 Dec 2023 19:14:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

This seems reasonable. How many unnecessary state change distributions to threads do we save from this, so as to quantify the savings?

It would seem as if, as a verification mechanism that no state changes were dropped from distribution, it might be a good idea to assert in both prologue and epilogue of ShenandoahHeap stop-world ops that the `_gc_state_changed` flag is false, indicating that the last state change was "consumed and distributed" by any stop-world op?

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

PR Review: https://git.openjdk.org/jdk/pull/17112#pullrequestreview-1784520403

From wkemper at openjdk.org  Fri Dec 15 17:29:38 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 17:29:38 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <7XBwU6CWI5uLBUVhZwqcd2K8RSMKyCFqc9GYXWU2CW8=.93723fbc-2975-40da-8cc0-4f2b3b70dc0b@github.com>

On Thu, 14 Dec 2023 19:14:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

This instrumentation isn't included in this PR, but it shows how often GC state changes in a typical cycle:

[40.118s][31676][info ][gc,start    ] GC(1) Pause Init Mark (unload classes)
[40.118s][31676][info ][gc          ] GC(1) GC state = 22
[40.118s][31676][info ][gc          ] GC(1) Pause Init Mark (unload classes) 0.119ms
[41.646s][31676][info ][gc,start    ] GC(1) Pause Final Mark (unload classes)
[41.646s][31676][info ][gc          ] GC(1) GC state = 0
[41.646s][31676][info ][gc          ] GC(1) GC state = 10
[41.648s][31676][info ][gc          ] GC(1) GC state = 14
[41.648s][31676][info ][gc          ] GC(1) GC state = 15
[41.648s][31676][info ][gc          ] GC(1) Pause Final Mark (unload classes) 2.324ms
[42.774s][31676][info ][gc,start    ] GC(1) Pause Init Update Refs
[42.774s][31676][info ][gc          ] GC(1) GC state = 11
[42.774s][31676][info ][gc          ] GC(1) GC state = 1
[42.774s][31676][info ][gc          ] GC(1) GC state = 9
[42.774s][31676][info ][gc          ] GC(1) Pause Init Update Refs 0.108ms
[43.040s][31676][info ][gc,start    ] GC(1) Pause Final Update Refs
[43.040s][31676][info ][gc          ] GC(1) GC state = 1
[43.040s][31676][info ][gc          ] GC(1) GC state = 0
[43.040s][31676][info ][gc          ] GC(1) Pause Final Update Refs 0.162ms

And for some degenerated cycles, many of these changes may happen on the same safepoint:

[60.839s][31676][info ][gc,start       ] GC(17) Pause Degenerated GC (Mark)
[61.417s][31676][info ][gc             ] GC(17) GC state = 0
[62.291s][31676][info ][gc             ] GC(17) GC state = 4
[62.291s][31676][info ][gc             ] GC(17) GC state = 5
[62.309s][31676][info ][gc             ] GC(17) GC state = 1
[62.309s][31676][info ][gc             ] GC(17) GC state = 1
[62.309s][31676][info ][gc             ] GC(17) GC state = 9
[63.372s][31676][info ][gc             ] GC(17) GC state = 1
[63.372s][31676][info ][gc             ] GC(17) GC state = 0
[63.373s][31676][info ][gc             ] GC(17) Pause Degenerated GC (Mark) 31103M->24719M(32768M) 2534.356ms

I can add the assertions you described in the prologue and epilogue methods. For what it's worth, changes to the gc state already assert the changes occur on a safepoint.

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

PR Comment: https://git.openjdk.org/jdk/pull/17112#issuecomment-1858231413

From cslucas at openjdk.org  Fri Dec 15 18:21:47 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 15 Dec 2023 18:21:47 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <tKNfncBEMPLO9_GqV_9h3YusTDnDZHh4ZlfkXcwxoU4=.175868b2-eb52-4325-86d9-68a6e160d064@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <tKNfncBEMPLO9_GqV_9h3YusTDnDZHh4ZlfkXcwxoU4=.175868b2-eb52-4325-86d9-68a6e160d064@github.com>
Message-ID: <vN_z8R5nOV_2l7EbIYfyuouHqCgOad5SpvGK33c-4u8=.48cfc7b5-3c8f-4110-9952-f774b5f2db28@github.com>

On Fri, 15 Dec 2023 01:47:26 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> I've verified it works on riscv64, passing hotspot tier1 and tier2 tests.

Thank you for testing @luhenry . Which OS did you run the tests?

@offamitkumar, @TheRealMDoerr  - can you please re-run the tests on the platforms convenient for you?

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1858306441

From wkemper at openjdk.org  Fri Dec 15 18:31:44 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 18:31:44 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <wpi_XcMnnYfanQKjDnIlrM2i9Hl9ENHO534k5eCBexE=.4a1828d9-07aa-455e-bd1a-d8fb1108b5f2@github.com>
References: <wpi_XcMnnYfanQKjDnIlrM2i9Hl9ENHO534k5eCBexE=.4a1828d9-07aa-455e-bd1a-d8fb1108b5f2@github.com>
Message-ID: <BmEfogW9LbLdGhFvFZ_cuZkEVaJV5qovT8zF6cLzv8A=.a4c8aac9-c349-4bf1-99a4-7d06c3f089f2@github.com>

> Merges tag jdk-23+1

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/pull/370/files
  - new: https://git.openjdk.org/shenandoah/pull/370/files/519ecd35..519ecd35

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

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

PR: https://git.openjdk.org/shenandoah/pull/370

From wkemper at openjdk.org  Fri Dec 15 18:31:46 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 18:31:46 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <wpi_XcMnnYfanQKjDnIlrM2i9Hl9ENHO534k5eCBexE=.4a1828d9-07aa-455e-bd1a-d8fb1108b5f2@github.com>
References: <wpi_XcMnnYfanQKjDnIlrM2i9Hl9ENHO534k5eCBexE=.4a1828d9-07aa-455e-bd1a-d8fb1108b5f2@github.com>
Message-ID: <QhJVDLBEVA-mWGOi-3pXgMDT4p51NpGtI8zC1IU_FE4=.3249f258-c3fa-4280-aa92-586081e7c457@github.com>

On Wed, 13 Dec 2023 20:32:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-23+1

This pull request has now been integrated.

Changeset: 0c6c5e4d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/0c6c5e4d5b5bab3b62769cbfb86ea8dd28a347a8
Stats:     4872 lines in 98 files changed: 4828 ins; 0 del; 44 mod

Merge

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

PR: https://git.openjdk.org/shenandoah/pull/370

From luhenry at openjdk.org  Fri Dec 15 18:33:43 2023
From: luhenry at openjdk.org (Ludovic Henry)
Date: Fri, 15 Dec 2023 18:33:43 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <vN_z8R5nOV_2l7EbIYfyuouHqCgOad5SpvGK33c-4u8=.48cfc7b5-3c8f-4110-9952-f774b5f2db28@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <tKNfncBEMPLO9_GqV_9h3YusTDnDZHh4ZlfkXcwxoU4=.175868b2-eb52-4325-86d9-68a6e160d064@github.com>
 <vN_z8R5nOV_2l7EbIYfyuouHqCgOad5SpvGK33c-4u8=.48cfc7b5-3c8f-4110-9952-f774b5f2db28@github.com>
Message-ID: <OSi2HYWvnvrkDeBPL_hedTetULMqa5ktViMgnlQ70Zk=.a08ae6e6-0dd5-487e-81f5-9f1bd05ed6ed@github.com>

On Fri, 15 Dec 2023 18:19:02 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Which OS did you run the tests?

I ran it on Linux. Ubuntu 22.04 to be specific. Right now, riscv64 is only supported on Linux (no macOS or Windows for RISC-V in sight).

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1858319485

From wkemper at openjdk.org  Fri Dec 15 18:40:24 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 18:40:24 GMT
Subject: RFR: 8322219: GenShen: GHA for shenandoah repo should run all
 shenandoah jtreg tests
Message-ID: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>

GHA for shenandoah repo should run all shenandoah jtreg tests

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

Commit messages:
 - GHA for shenandoah repo should run all shenandoah jtreg tests

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

PR: https://git.openjdk.org/shenandoah/pull/373

From ysr at openjdk.org  Fri Dec 15 18:40:24 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 18:40:24 GMT
Subject: RFR: 8322219: GenShen: GHA for shenandoah repo should run all
 shenandoah jtreg tests
In-Reply-To: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>
References: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>
Message-ID: <7b7uHjBE8UDxAuW4cyNeMl_jrSbDWJhp7sCOwKGSVjA=.6a3a0655-239c-459d-974c-582452f08635@github.com>

On Fri, 15 Dec 2023 18:34:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

> GHA for shenandoah repo should run all shenandoah jtreg tests

Thank you, thank you!!

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/373#pullrequestreview-1784723134

From wkemper at openjdk.org  Fri Dec 15 19:20:50 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 19:20:50 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint [v2]
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <JunjoTDW2ofF90T7WZWcLQGYIay9Lu-kDrT7-nryzaU=.98f086f9-930a-4c6c-b7b4-5125f207dde6@github.com>

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

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

  Extra assertions that gc state synchronization is correct

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17112/files
  - new: https://git.openjdk.org/jdk/pull/17112/files/91a5cee4..93d0f4e3

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

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

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

From wkemper at openjdk.org  Fri Dec 15 19:29:11 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 19:29:11 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run
In-Reply-To: <2KWP95bvJ9D7WXDPM0_eg6AKoqHWlxk7PK9kZhYxSZE=.acfba3ce-7b6c-43f7-8822-2b2c5a5dd523@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <2KWP95bvJ9D7WXDPM0_eg6AKoqHWlxk7PK9kZhYxSZE=.acfba3ce-7b6c-43f7-8822-2b2c5a5dd523@github.com>
Message-ID: <C9HoG7IJZDuLfnJlslDzy1NCOtdYzdaI_DwhD2a4K7c=.e33df9e4-de3a-4b1d-87e0-153f8d0047c8@github.com>

On Fri, 15 Dec 2023 16:29:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 79:
> 
>> 77:         }
>> 78:       } else {
>> 79:         if (should_start_young()) {
> 
> 1. Could you explain (and document) why we don't do the same check `should_start_young` also at line 88 further below, _then_ `start_young_cycle`, where we find the control thread in the mode `servicing_old`?
> 2. The split of the roles of checks (`should_start_..`)  between here and the heuristics, and the actual requests/actions (`start_..` or `request_`) to start a cycle look like they could do with a bit of clean up for consistency & uniformity. At the current time (although not as a result of your current change), the checks and the actions are scattered over a few routines so that reasoning about their correctness (or their behaviour) can be a bit challenging. This latter clean-up can, however, wait for the future.

Good catch. I published this PR prematurely.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1428395269

From wkemper at openjdk.org  Fri Dec 15 20:10:14 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 20:10:14 GMT
Subject: RFR: 8322219: GenShen: GHA for shenandoah repo should run all
 shenandoah jtreg tests
In-Reply-To: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>
References: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>
Message-ID: <fiTVTpxKFSQNmzGo1I1Wy4Mw686H3AV3_ppyDfifYdU=.1af771a0-4466-489e-a0f7-6bf86e49d966@github.com>

On Fri, 15 Dec 2023 18:34:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

> GHA for shenandoah repo should run all shenandoah jtreg tests

I don't think the actions will run theses changes from a PR (might not be safe). We won't know if they worked until after this PR is on master.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/373#issuecomment-1858429561

From wkemper at openjdk.org  Fri Dec 15 20:13:21 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 20:13:21 GMT
Subject: Integrated: 8322219: GenShen: GHA for shenandoah repo should run all
 shenandoah jtreg tests
In-Reply-To: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>
References: <ZZpUjM-SkaKmxerffbNvenMK3WfxMpfE5NpdjhUTErY=.44ba4f31-86f9-40c1-9491-e372e55ce6ab@github.com>
Message-ID: <ofadlYVPB4hdrQIeipfzNkJNMEsumTv1-RpJd49HskA=.44a12dbf-df72-4741-85c6-0598243dd153@github.com>

On Fri, 15 Dec 2023 18:34:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

> GHA for shenandoah repo should run all shenandoah jtreg tests

This pull request has now been integrated.

Changeset: 490ed34e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/490ed34edd5c99aa132c0faa351da2ad5ae59577
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8322219: GenShen: GHA for shenandoah repo should run all shenandoah jtreg tests

Reviewed-by: ysr

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

PR: https://git.openjdk.org/shenandoah/pull/373

From ysr at openjdk.org  Fri Dec 15 20:41:38 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Dec 2023 20:41:38 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint [v2]
In-Reply-To: <JunjoTDW2ofF90T7WZWcLQGYIay9Lu-kDrT7-nryzaU=.98f086f9-930a-4c6c-b7b4-5125f207dde6@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
 <JunjoTDW2ofF90T7WZWcLQGYIay9Lu-kDrT7-nryzaU=.98f086f9-930a-4c6c-b7b4-5125f207dde6@github.com>
Message-ID: <GBaDVwnkMFdjZU2aWGNUR_TL6qO24SrN53_Wzszr6oY=.0ad1d38e-2c31-4f21-95c3-1b74d0f4c635@github.com>

On Fri, 15 Dec 2023 19:20:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extra assertions that gc state synchronization is correct

Looks good; thanks for the data and for the extra verification checks.
?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17112#pullrequestreview-1784889900

From wkemper at openjdk.org  Fri Dec 15 21:07:53 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Dec 2023 21:07:53 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint [v3]
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <G94DF7RZbfAQt4RB4w5l1aBRJ5ER9el-8JEgT_T5RIE=.9bd850ba-8486-49bb-95cb-1cde9f2f1aa2@github.com>

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

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

  Mark all appropriate methods in class as override

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17112/files
  - new: https://git.openjdk.org/jdk/pull/17112/files/93d0f4e3..d1a4a692

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

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

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

From ysr at openjdk.org  Sat Dec 16 03:22:33 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 16 Dec 2023 03:22:33 GMT
Subject: RFR: 8322242: [GenShen] TestAllocObjects#generational fails with
 "Unrecognized VM option 'ShenandoahSuspendibleWorkers'"
Message-ID: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>

JDK-8322242

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

Commit messages:
 - JDK-8322242 ShenandoahSuspendibleWorkers was removed in JDK-8321410 in

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

PR: https://git.openjdk.org/shenandoah/pull/374

From amitkumar at openjdk.org  Sat Dec 16 05:05:43 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Sat, 16 Dec 2023 05:05:43 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission
In-Reply-To: <yMm8dccKyhmu3glz-hLgP8V81EYvwFASjEUItwKGlHI=.692202d3-87e0-4c0e-9daf-1b4df9af36b9@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <yMm8dccKyhmu3glz-hLgP8V81EYvwFASjEUItwKGlHI=.692202d3-87e0-4c0e-9daf-1b4df9af36b9@github.com>
Message-ID: <Dz7JboYxdUGDNp9RB4BZ-WF0W1b0NY4kK67zNWeWoY0=.ecd40213-e618-4e29-8249-7ff0bd4f52fb@github.com>

On Wed, 8 Nov 2023 04:34:03 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> `s390x` also run into assert failure: `assert(masm->inst_mark() == nullptr) failed: should be.`
> 
> 
> V  [libjvm.so+0xfb0938]  PhaseOutput::fill_buffer(C2_MacroAssembler*, unsigned int*)+0x2370  (output.cpp:1812)
> V  [libjvm.so+0xfb21ce]  PhaseOutput::Output()+0xcae  (output.cpp:362)
> V  [libjvm.so+0x6a90a8]  Compile::Code_Gen()+0x460  (compile.cpp:2989)
> V  [libjvm.so+0x6ad848]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1738  (compile.cpp:887)
> V  [libjvm.so+0x4fb932]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x14a  (c2compiler.cpp:119)
> V  [libjvm.so+0x6b81a2]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd9a  (compileBroker.cpp:2282)
> V  [libjvm.so+0x6b8eaa]  CompileBroker::compiler_thread_loop()+0x5a2  (compileBroker.cpp:1943)

>@offamitkumar, @TheRealMDoerr - can you please re-run the tests on the platforms convenient for you?

I run build for fastdebug & release VMs and tier1 test for fastdebug VM. Everything seems good.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1858721643

From aph at openjdk.org  Sat Dec 16 12:46:42 2023
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 16 Dec 2023 12:46:42 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <WuvDLbobtN3-lZfrXoYmijo0VSAriwB-gT42aSqZHKw=.f9c33756-dfa6-45d4-9c1e-2796df6ad362@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

It seems odd to me that this substantial and complex patch lacks any justification. As far as I can tell, the decision to make class MacroAssembler very lightweight so that new instances could be created as needed was deliberate. Why change now? Is it performance, or something else?

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1858810100

From kdnilsen at openjdk.org  Sat Dec 16 16:58:08 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 16 Dec 2023 16:58:08 GMT
Subject: RFR: 8322242: [GenShen] TestAllocObjects#generational fails with
 "Unrecognized VM option 'ShenandoahSuspendibleWorkers'"
In-Reply-To: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>
References: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>
Message-ID: <REQghVxtAENHK7XnzP4bha_rixQJmijkRC9npgm3yEw=.14eb883a-f2e5-443c-8adf-5505d8ed78d5@github.com>

On Sat, 16 Dec 2023 03:13:43 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> JDK-8322242

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/374#pullrequestreview-1785238688

From tschatzl at openjdk.org  Mon Dec 18 13:48:40 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 18 Dec 2023 13:48:40 GMT
Subject: RFR: 8321812: Update GC tests to use execute[Limited]TestJava
In-Reply-To: <SJsjlVy1S72d43Mmr2NmOGXChAAGzgc1O4KZ_YrFXEI=.2bb94c0e-1fe2-4537-bbe8-0b498bfcb1ed@github.com>
References: <SJsjlVy1S72d43Mmr2NmOGXChAAGzgc1O4KZ_YrFXEI=.2bb94c0e-1fe2-4537-bbe8-0b498bfcb1ed@github.com>
Message-ID: <4ZuCe-VPcSt2TfFr9Fm9XbcNoAbDBvhw78pZb7dW2hM=.c8a211c2-fd6d-45fb-84fa-e2780148e440@github.com>

On Mon, 11 Dec 2023 19:31:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> A lot of our tests use a multi-step recipe to spawn and wait for a process. Here's an example
> 
>     ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(
>          "-XX:-UseTLAB",
>          "-XX:+UnlockDiagnosticVMOptions",
>          "-XX:+VerifyDuringStartup",
>          "-Xlog:gc+verify=debug",
>          "-version");
>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>     ... do something with output and wait for the process to complete ...
> 
> 
> These are the steps involved:
> 
> 1) Create a `ProcessBuilder`
> 2) Call `ProcessBuilder::start`
> 3) Create an `OutputAnalyzer`
> 4) Perform an operation that finally waits for the process to, at least partially, complete (OutputAnalyzer::getOutput, OutputAnalyzer::shouldHaveExitValue(), and more).
> 
> Almost all our tests could be converted to use a single call to `ProcessTools.executeTestJava` (or `executeLimitedTestJava`), which spawns the process, makes sure that it has fully completed, and then returns a filled-in OutputAnalyzer to the caller. The above example would become:
> 
> 
>     OutputAnalyzer output = ProcessTools.executeTestJava(
>          "-XX:-UseTLAB",
>          "-XX:+UnlockDiagnosticVMOptions",
>          "-XX:+VerifyDuringStartup",
>          "-Xlog:gc+verify=debug",
>          "-version");
> 
> 
> I propose that we make this change in the GC tests, to make our code simpler and hopefully easier to read.
> 
> Note: There's a few changes to the throws statements because some ProcessTools APIs throws IOException while others throw Exception.
> 
> Testing: I've done testing on a similar set of changes, but I'm going to run the appropriate, final tests while this is being considered/reviewed.

Marked as reviewed by tschatzl (Reviewer).

test/hotspot/jtreg/gc/arguments/GCArguments.java line 101:

> 99:         return ProcessTools.executeTestJava(withDefaults(arguments));
> 100:     }
> 101: 

Suggestion:

test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java line 184:

> 182:         }
> 183: 
> 184:         OutputAnalyzer output =  ProcessTools.executeLimitedTestJava(

Suggestion:

        OutputAnalyzer output = ProcessTools.executeLimitedTestJava(

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

PR Review: https://git.openjdk.org/jdk/pull/17067#pullrequestreview-1786908880
PR Review Comment: https://git.openjdk.org/jdk/pull/17067#discussion_r1430152105
PR Review Comment: https://git.openjdk.org/jdk/pull/17067#discussion_r1430158652

From mdoerr at openjdk.org  Mon Dec 18 14:46:42 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 18 Dec 2023 14:46:42 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <YoPSDVx7YdqcJ2UE-kjiHnq9BjNlhae8OWnm2eiGWAc=.cf6ab991-bdcf-44a8-ab61-5c9b3151e4fe@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

Seems to work on PPC64, now. I agree with Andrew. It should be clear what the benefits are.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1860685005

From ysr at openjdk.org  Mon Dec 18 16:34:23 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 18 Dec 2023 16:34:23 GMT
Subject: RFR: 8322242: [GenShen] TestAllocObjects#generational fails with
 "Unrecognized VM option 'ShenandoahSuspendibleWorkers'"
In-Reply-To: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>
References: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>
Message-ID: <ZjkyQmEHz13W_VZowxhBMzJR83z5B0FCbBjpfo88Ghg=.8862ab17-eb10-47b4-8637-fced7b223816@github.com>

On Sat, 16 Dec 2023 03:13:43 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> JDK-8322242

There are failures in hs/all_shenandoah as these tests just started being run. These will be separately addressed as they are not related to the changes in this PR.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/374#issuecomment-1860974964

From ysr at openjdk.org  Mon Dec 18 16:34:23 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 18 Dec 2023 16:34:23 GMT
Subject: Integrated: 8322242: [GenShen] TestAllocObjects#generational fails
 with "Unrecognized VM option 'ShenandoahSuspendibleWorkers'"
In-Reply-To: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>
References: <rE4b-R0rNEZ4E7QJkVWeWZ6QQtYZ7yx4z-msda0Dm8w=.1e5ac430-0930-4184-87d2-6761f4253d61@github.com>
Message-ID: <oCS8w1ms8w0A10dE7lG2d0n8WsOFPIkUs_5il_PG3tg=.10691409-f9e1-44d9-a5d8-4cd5bc3bae22@github.com>

On Sat, 16 Dec 2023 03:13:43 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> JDK-8322242

This pull request has now been integrated.

Changeset: da2b9ed1
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/da2b9ed1520b6c152e019f7c333095b27c48d8cf
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8322242: [GenShen] TestAllocObjects#generational fails with "Unrecognized VM option 'ShenandoahSuspendibleWorkers'"

ShenandoahSuspendibleWorkers was removed in JDK-8321410 in openjdk/jdk tip, but this version of the flag, which is present only in tests in genshen was missed in the merge from upstream. With this removal there are no other instances of this flag in the code or tests.

**Testing:** Verified that the test passes with the offending flag/test removed.

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.org/shenandoah/pull/374

From cslucas at openjdk.org  Mon Dec 18 18:19:43 2023
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 18 Dec 2023 18:19:43 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <WuvDLbobtN3-lZfrXoYmijo0VSAriwB-gT42aSqZHKw=.f9c33756-dfa6-45d4-9c1e-2796df6ad362@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <WuvDLbobtN3-lZfrXoYmijo0VSAriwB-gT42aSqZHKw=.f9c33756-dfa6-45d4-9c1e-2796df6ad362@github.com>
Message-ID: <xrzeVWCY-JIDpOAE5IEGFfU1cZSDNpmPvPOq13J29zU=.e0285dee-a67f-4c90-99b4-3dde63e17aa3@github.com>

On Sat, 16 Dec 2023 12:44:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> It seems odd to me that this substantial and complex patch lacks any justification. As far as I can tell, the decision to make class MacroAssembler very lightweight so that new instances could be created as needed was deliberate. Why change now? Is it performance, or something else?

@theRealAph , @TheRealMDoerr - I just picked a JBS work item that seemed important (P3..) and started working on it. To me the refactoring made a lot of sense as well - why just create thousands of objects if just a few would do.

If this is something that doesn't need to be done, please let me know. It already took substantial effort as you said.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1861244791

From wkemper at openjdk.org  Mon Dec 18 19:28:50 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Dec 2023 19:28:50 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint [v4]
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <LGVZGih8KskrWIGVf67zXNODyusod6tGlZchhrubN4w=.860ed9fc-29c1-4656-a1b5-7653af458e04@github.com>

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

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

  Initialize new _gc_state_changed member.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17112/files
  - new: https://git.openjdk.org/jdk/pull/17112/files/d1a4a692..eb6f3fdf

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

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

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

From mdoerr at openjdk.org  Mon Dec 18 20:22:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 18 Dec 2023 20:22:44 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <4Gr1LLsOrG-7sJDE0mlR_x9QxrvQBMFzDe-atrmFAPs=.bf32dd9d-0abc-4de1-8ab7-3f12377e5098@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

Cleanup is not bad. Fewer objects and a bit shorter code at some places are an advantage.
Maybe Vladimir had some more reasons in mind when filing the issue. It's linked to https://bugs.openjdk.org/browse/JDK-8239472. It'd be nice if you or Vladimir could add a bit of motivation to the description of the PR or the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1861538259

From wkemper at openjdk.org  Tue Dec 19 00:12:46 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Dec 2023 00:12:46 GMT
Subject: Integrated: 8321815: Shenandoah: gc state should be synchronized to
 java threads only once per safepoint
In-Reply-To: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
Message-ID: <J5nzkwD-sUeHhWcGBq4rt2oMI0Z9lRKMCCNBhGiNvZo=.d13d9273-8eed-4739-8c62-ea71db149618@github.com>

On Thu, 14 Dec 2023 19:14:07 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.

This pull request has now been integrated.

Changeset: 808a0392
Author:    William Kemper <wkemper at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/808a03927c153581cbece93a4f5a4f8242b61ef5
Stats:     41 lines in 5 files changed: 32 ins; 1 del; 8 mod

8321815: Shenandoah: gc state should be synchronized to java threads only once per safepoint

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Tue Dec 19 00:41:19 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Dec 2023 00:41:19 GMT
Subject: RFR: 8322347: GenShen: Run shenandoah tier2 and tier3 tests separately
 in GHA
Message-ID: <5zZw7K2xJgUuaVCrqzPpUFzGK-cHnL6RlSC074rZUB4=.06409313-885a-4e2d-ac51-c4280644863a@github.com>

The Shenandoah tier1 tests already run as part of the gc tier1 tests, so running all Shenandoah tiers repeats them. Running tier2 and tier3 tests separately should have them run in parallel and decrease overall time for GHA to complete.

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

Commit messages:
 - Run shenandoah tier2 and tier3 tests in parallel

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

PR: https://git.openjdk.org/shenandoah/pull/375

From ysr at openjdk.org  Tue Dec 19 00:45:11 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 19 Dec 2023 00:45:11 GMT
Subject: RFR: 8322347: GenShen: Run shenandoah tier2 and tier3 tests
 separately in GHA
In-Reply-To: <5zZw7K2xJgUuaVCrqzPpUFzGK-cHnL6RlSC074rZUB4=.06409313-885a-4e2d-ac51-c4280644863a@github.com>
References: <5zZw7K2xJgUuaVCrqzPpUFzGK-cHnL6RlSC074rZUB4=.06409313-885a-4e2d-ac51-c4280644863a@github.com>
Message-ID: <Ri3Mgz9RuEPUh07FcINO99R5oFdDAnkWOmqXearI7F8=.79b08774-fa89-4c2c-8b64-fbd5f64b8cb6@github.com>

On Tue, 19 Dec 2023 00:37:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The Shenandoah tier1 tests already run as part of the gc tier1 tests, so running all Shenandoah tiers repeats them. Running tier2 and tier3 tests separately should have them run in parallel and decrease overall time for GHA to complete.

Thank you!

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/375#pullrequestreview-1787920371

From wkemper at openjdk.org  Tue Dec 19 00:45:23 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Dec 2023 00:45:23 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v2]
In-Reply-To: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
Message-ID: <1-KglzcGszyk6AfifCL1iXUXf3BPO9hWY8qm2LtNFe4=.fd9b1208-9cfb-4d9d-b582-07b05f0daebd@github.com>

> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

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

  Make the line between heuristics and regulator more clear

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/371/files
  - new: https://git.openjdk.org/shenandoah/pull/371/files/4b96c106..8a40a397

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

  Stats: 73 lines in 4 files changed: 28 ins; 27 del; 18 mod
  Patch: https://git.openjdk.org/shenandoah/pull/371.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/371/head:pull/371

PR: https://git.openjdk.org/shenandoah/pull/371

From wkemper at openjdk.org  Tue Dec 19 00:50:08 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Dec 2023 00:50:08 GMT
Subject: Integrated: 8322347: GenShen: Run shenandoah tier2 and tier3 tests
 separately in GHA
In-Reply-To: <5zZw7K2xJgUuaVCrqzPpUFzGK-cHnL6RlSC074rZUB4=.06409313-885a-4e2d-ac51-c4280644863a@github.com>
References: <5zZw7K2xJgUuaVCrqzPpUFzGK-cHnL6RlSC074rZUB4=.06409313-885a-4e2d-ac51-c4280644863a@github.com>
Message-ID: <usnatcZPq8k2AplSt2HIt9zGLUYu7PXx7zpRBkLFoPQ=.beb61b84-2b7e-4a52-b603-91955ff8f0ed@github.com>

On Tue, 19 Dec 2023 00:37:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The Shenandoah tier1 tests already run as part of the gc tier1 tests, so running all Shenandoah tiers repeats them. Running tier2 and tier3 tests separately should have them run in parallel and decrease overall time for GHA to complete.

This pull request has now been integrated.

Changeset: b415cec7
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/b415cec7f1728f17a838a3711ac462b1717424d1
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8322347: GenShen: Run shenandoah tier2 and tier3 tests separately in GHA

Reviewed-by: ysr

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

PR: https://git.openjdk.org/shenandoah/pull/375

From shade at openjdk.org  Tue Dec 19 12:03:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Dec 2023 12:03:50 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint [v4]
In-Reply-To: <LGVZGih8KskrWIGVf67zXNODyusod6tGlZchhrubN4w=.860ed9fc-29c1-4656-a1b5-7653af458e04@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
 <LGVZGih8KskrWIGVf67zXNODyusod6tGlZchhrubN4w=.860ed9fc-29c1-4656-a1b5-7653af458e04@github.com>
Message-ID: <j3E8X0zC9B1Zz-DZgkWdLuPJF2h2O2jr0SjNAr6llac=.b2b51264-205d-4158-b529-66ef70ab9bc2@github.com>

On Mon, 18 Dec 2023 19:28:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize new _gc_state_changed member.

(Late for the party here!)

The idea looks good, but there are two minor problems with it:

 1. Thread-local gc-state is supposed to be used from the barriers. This is why we can coalesce the thread-local gc-state within a safepoint, as long as we have the proper setup after the safepoint. However, I think it is a happy accident that we don't poll thread-local gc-state from current native barrier code, and thread-local gc-state is only used by java threads. If we ever did access from non-java (gc) threads, this would subtly break GC within e.g. final-mark vmop.
 2. It is fairly weird that now `ShenandoahHeap::set_gc_state_all_threads` does the actual modification, while `ShenandoahHeap::set_gc_state_mask` does not! The names of the methods do not highlight the difference in semantics.

I guess we can hit two birds with one stone if we rename the methods to mention java threads and record/set split, and assert that non-java threads do not touch the `ShenandoahThreadLocalData::_gc_state`. Something like `SH::set_gc_state` (changes the global, sets the propagation flag) and `SH::propagate_gc_state_java_threads` (propagates global to thread-local java threads)?

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

PR Review: https://git.openjdk.org/jdk/pull/17112#pullrequestreview-1788724371

From wkemper at openjdk.org  Tue Dec 19 18:00:55 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Dec 2023 18:00:55 GMT
Subject: RFR: 8321815: Shenandoah: gc state should be synchronized to java
 threads only once per safepoint [v4]
In-Reply-To: <LGVZGih8KskrWIGVf67zXNODyusod6tGlZchhrubN4w=.860ed9fc-29c1-4656-a1b5-7653af458e04@github.com>
References: <xVMsjfS4LYO8vuAG4oSHrgB39jetUSzSj4bDPCbIrYY=.70cd17e6-3969-4d8a-8953-218a45a62fc1@github.com>
 <LGVZGih8KskrWIGVf67zXNODyusod6tGlZchhrubN4w=.860ed9fc-29c1-4656-a1b5-7653af458e04@github.com>
Message-ID: <RioOz9bxGOELH6W5K_O-RLaQ1P8u_-9dvdheO-KyhFE=.4654d10e-579a-4f61-a279-8d9158f640e2@github.com>

On Mon, 18 Dec 2023 19:28:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Presently, every change to the gc change is distributed to all java threads. The gc state is only changed on safepoints. For applications with a very large number of java threads this may increase time on the safepoint. It would be better to synchronize the gc state only once per safepoint.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initialize new _gc_state_changed member.

I'll open a new PR to rename these methods and add an assert that non-java threads never touch the thread local copy of gc state.

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

PR Comment: https://git.openjdk.org/jdk/pull/17112#issuecomment-1863241621

From kvn at openjdk.org  Tue Dec 19 19:03:51 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 19 Dec 2023 19:03:51 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <4Gr1LLsOrG-7sJDE0mlR_x9QxrvQBMFzDe-atrmFAPs=.bf32dd9d-0abc-4de1-8ab7-3f12377e5098@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <4Gr1LLsOrG-7sJDE0mlR_x9QxrvQBMFzDe-atrmFAPs=.bf32dd9d-0abc-4de1-8ab7-3f12377e5098@github.com>
Message-ID: <6oWKE1GfvYTKQzDEptukFLwdxm1hTWOsMoieglnJgbg=.375a0b2a-fccb-4c18-b85f-4d831129d6e2@github.com>

On Mon, 18 Dec 2023 20:19:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> Cleanup is not bad. Fewer objects and a bit shorter code at some places are an advantage.
> Maybe Vladimir had some more reasons in mind when filing the issue. It's linked to https://bugs.openjdk.org/browse/JDK-8239472. It'd be nice if you or Vladimir could add a bit of motivation to the description of the PR or the JBS issue.

@TheRealMDoerr  motivation is to reduce memory consumption and speed up C2. `C2_MacroAssembler`  is based on `ResourceObj` which allocates in compiler arena. Each small  `C2_MacroAssembler masm()` will add allocation to arena until we finish compilation. Also speedup because we don't need to do such allocations.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1863321348

From wkemper at openjdk.org  Tue Dec 19 21:46:54 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Dec 2023 21:46:54 GMT
Subject: RFR: 8322503: Shenandoah: Clarify gc state usage
Message-ID: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>

This is a follow up to https://github.com/openjdk/jdk/pull/17112.

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

Commit messages:
 - Rename gc state methods for clarity, assert that only java threads use thread local copy of gc state

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

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

From mdoerr at openjdk.org  Wed Dec 20 11:13:51 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 20 Dec 2023 11:13:51 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <g2_SBnj80r-46uBWFvWRfgvAL3USKCVxnO70sUHDj0I=.94aefeb5-a394-4d02-8bdf-0fec278dc343@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

Thanks for the explanation! Makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1864290083

From kvn at openjdk.org  Wed Dec 20 19:26:43 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 20 Dec 2023 19:26:43 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <eGmzCp6jZHXiG0fuTh1Z-e7P74nV90AT0iq0_owoPxA=.957917a3-3e2d-4c75-bb95-c181e35a7b48@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

src/hotspot/cpu/x86/x86_32.ad line 1541:

> 1539:   // in the MacroAssembler. Should go away once all "instruct" are
> 1540:   // patched to emit bytes only using methods in MacroAssembler.
> 1541:   enc_class SetInstMark %{

Do you have separate RFE for that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1433098730

From kvn at openjdk.org  Wed Dec 20 20:04:54 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 20 Dec 2023 20:04:54 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
Message-ID: <8ZkfLag-QKsU8stjY8amUxO_0-yTr8SlXOSh6nhQ1PM=.6efb1eef-b8a9-437a-9a1f-f5aa74009f0f@github.com>

On Thu, 14 Dec 2023 19:44:09 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> # Description
>> 
>> Please review this PR with a patch to re-use the same C2_MacroAssembler object to emit all instructions in the same compilation unit.
>> 
>> Overall, the change is pretty simple. However, due to the renaming of the variable to access C2_MacroAssembler, from `_masm.` to `masm->`, and also some method prototype changes, the patch became quite large.
>> 
>> # Help Needed for Testing
>> 
>> I don't have access to all platforms necessary to test this. I hope some other folks can help with testing on `S390`, `RISC-V` and `PPC`.
>> 
>> # Testing status
>> 
>> ## tier1
>> 
>> |          |   Win   |   Mac   |  Linux  |
>> |----------|---------|---------|---------|
>> | ARM64    |         |    ?     |         |
>> | ARM32    |         |         |         |
>> | x86      |         |         |    ?     |
>> | x64      |         |         |     ?    |
>> | PPC64    |         |         |         |
>> | S390x    |         |         |         |
>> | RiscV    |    n/a     |    n/a     |    ?     |
>
> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge with origin/master
>  - Fix build, copyright dates, m4 files.
>  - Fix merge
>  - Catch up with master branch.
>    
>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>  - Some inst_mark fixes; Catch up with master.
>  - Catch up with changes on master
>  - Reuse same C2_MacroAssembler object to emit instructions.

This looks good. Thank you for such detail work. I will run our testing.

src/hotspot/cpu/x86/assembler_x86.cpp line 4248:

> 4246: void Assembler::vpermb(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 4247:   assert(VM_Version::supports_avx512_vbmi(), "");
> 4248:   InstructionMark im(this);

May be add short comment why you need `InstructionMark` in these instructions but not in others.

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

PR Review: https://git.openjdk.org/jdk/pull/16484#pullrequestreview-1791577633
PR Review Comment: https://git.openjdk.org/jdk/pull/16484#discussion_r1433133251

From kvn at openjdk.org  Wed Dec 20 20:13:49 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 20 Dec 2023 20:13:49 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <xrzeVWCY-JIDpOAE5IEGFfU1cZSDNpmPvPOq13J29zU=.e0285dee-a67f-4c90-99b4-3dde63e17aa3@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <WuvDLbobtN3-lZfrXoYmijo0VSAriwB-gT42aSqZHKw=.f9c33756-dfa6-45d4-9c1e-2796df6ad362@github.com>
 <xrzeVWCY-JIDpOAE5IEGFfU1cZSDNpmPvPOq13J29zU=.e0285dee-a67f-4c90-99b4-3dde63e17aa3@github.com>
Message-ID: <iwxpPTBhreNc-5JWT780coVWa0W2iakfI6JXSxV-y3I=.98a6a70f-78a8-4f5e-b8af-82208eccffba@github.com>

On Mon, 18 Dec 2023 18:16:45 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> It seems odd to me that this substantial and complex patch lacks any justification. As far as I can tell, the decision to make class MacroAssembler very lightweight so that new instances could be created as needed was deliberate. Why change now? Is it performance, or something else?
>
> @theRealAph , @TheRealMDoerr - I just picked a JBS work item that seemed important (P3..) and started working on it. To me the refactoring made a lot of sense as well - why just create thousands of objects if just a few would do.
> 
> If this is something that doesn't need to be done, please let me know. It already took substantial effort as you said.

@JohnTortugo please, merge latest JDK. Patch did not apply for RISC-V sources (x_riscv.ad and z_riscv.ad).

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1865069941

From ysr at openjdk.org  Wed Dec 20 22:06:37 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 20 Dec 2023 22:06:37 GMT
Subject: RFR: 8322503: Shenandoah: Clarify gc state usage
In-Reply-To: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
References: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
Message-ID: <TTA7xYftV9Teb5BUGWDTBc0VfcRwhP0CmT0MOyQLvPs=.3c605275-a6c2-4d26-a713-c2d5db567588@github.com>

On Tue, 19 Dec 2023 21:41:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a follow up to https://github.com/openjdk/jdk/pull/17112.

Marked as reviewed by ysr (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 301:

> 299:   char gc_state() const;
> 300:   void propagate_gc_state_to_java_threads();
> 301:   bool has_gc_state_changed() const { return _gc_state_changed; }

The name changes per @shipilev look good. If we have a sentence of documentation in the header file for each of these methods, that makes things even clearer (and is not subject to limitations on the length of the method name :-)

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

PR Review: https://git.openjdk.org/jdk/pull/17163#pullrequestreview-1791732278
PR Review Comment: https://git.openjdk.org/jdk/pull/17163#discussion_r1433228905

From duke at openjdk.org  Wed Dec 20 23:20:58 2023
From: duke at openjdk.org (duke)
Date: Wed, 20 Dec 2023 23:20:58 GMT
Subject: Withdrawn: 8317466: Enable interpreter oopMapCache for concurrent GCs
In-Reply-To: <dS_92JFN-F9Jizw_KWx1T7EoHQeo6n01CzNV19Xu_iQ=.81a01ca0-0308-4951-9bbf-7bfdd565bdbd@github.com>
References: <dS_92JFN-F9Jizw_KWx1T7EoHQeo6n01CzNV19Xu_iQ=.81a01ca0-0308-4951-9bbf-7bfdd565bdbd@github.com>
Message-ID: <xRu3v-g4rVFUM577Dns6xjDTWGD87OvjXIgiMBr8cW0=.c1c38dc6-b4fb-466a-a07a-98b33634ef07@github.com>

On Fri, 6 Oct 2023 13:25:27 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Interpreter oop maps are computed lazily during GC root scan and they are expensive to compute.
> 
> GCs uses a small hash table per instance class to cache computed oop maps during STW root scan, but not for concurrent root scan.
> 
> This patch is intended to enable `OopMapCache` for concurrent GCs.
> 
> Test:
>   tier1 and tier2 fastdebug and release on MacOSX, Linux 86_84 and Linux 86_32.

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Wed Dec 20 23:27:29 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 20 Dec 2023 23:27:29 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v3]
In-Reply-To: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
Message-ID: <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>

> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

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

  Only start global cycles when metaspace is out of memory

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/371/files
  - new: https://git.openjdk.org/shenandoah/pull/371/files/8a40a397..25de1177

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

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

PR: https://git.openjdk.org/shenandoah/pull/371

From wkemper at openjdk.org  Wed Dec 20 23:36:12 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 20 Dec 2023 23:36:12 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v3]
In-Reply-To: <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
Message-ID: <BbW4-wlwRV2lL8mI4EgCVDYpZCpRKu8P4gmGxGg8Fiw=.ba76d5be-0738-4e0a-a965-70703d73ee0a@github.com>

On Wed, 20 Dec 2023 23:27:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only start global cycles when metaspace is out of memory

The difference between `ShenandoahMinimumOldMarkTimeMs=10` and `ShenandoahMinimumOldMarkTimeMs=100` is not so great, but the effect is notable with `ShenandoahMinimumOldMarkTimeMs=`1000`.

### -XX:ShenandoahMinimumOldMarkTimeMs=1000


1000/genshen/specjbb2015/1/specjbb2015.jvm.log     6 Completed Old GCs (2.39%)
1000/genshen/specjbb2015/1/specjbb2015.jvm.log       8 mixed
1000/genshen/specjbb2015/1/specjbb2015.jvm.log       2 interruptions
--
1000/genshen/specjbb2015/2/specjbb2015.jvm.log     7 Completed Old GCs (2.49%)
1000/genshen/specjbb2015/2/specjbb2015.jvm.log      10 mixed
1000/genshen/specjbb2015/2/specjbb2015.jvm.log       3 interruptions


### -XX:ShenandoahMinimumOldMarkTimeMs=100

100/genshen/specjbb2015/1/specjbb2015.jvm.log     7 Completed Old GCs (1.91%)
100/genshen/specjbb2015/1/specjbb2015.jvm.log       8 mixed
100/genshen/specjbb2015/1/specjbb2015.jvm.log      24 interruptions
--
100/genshen/specjbb2015/2/specjbb2015.jvm.log     6 Completed Old GCs (2.39%)
100/genshen/specjbb2015/2/specjbb2015.jvm.log       6 mixed
100/genshen/specjbb2015/2/specjbb2015.jvm.log       8 interruptions


### -XX:ShenandoahMinimumOldMarkTimeMs=10

10/genshen/specjbb2015/1/specjbb2015.jvm.log     6 Completed Old GCs (2.91%)
10/genshen/specjbb2015/1/specjbb2015.jvm.log       6 mixed
10/genshen/specjbb2015/1/specjbb2015.jvm.log       7 interruptions
--
10/genshen/specjbb2015/2/specjbb2015.jvm.log     7 Completed Old GCs (2.50%)
10/genshen/specjbb2015/2/specjbb2015.jvm.log       7 mixed
10/genshen/specjbb2015/2/specjbb2015.jvm.log      14 interruptions

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

PR Comment: https://git.openjdk.org/shenandoah/pull/371#issuecomment-1865275806

From wkemper at openjdk.org  Wed Dec 20 23:54:00 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 20 Dec 2023 23:54:00 GMT
Subject: RFR: 8322503: Shenandoah: Clarify gc state usage [v2]
In-Reply-To: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
References: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
Message-ID: <Iqha2JABNbwTZtFDL3J1SE_q5mKkhweVlzYM5M36Ynk=.271455dc-8892-42ce-b4fb-5cb1e9105a3c@github.com>

> This is a follow up to https://github.com/openjdk/jdk/pull/17112.

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

  Add comments to gc state methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17163/files
  - new: https://git.openjdk.org/jdk/pull/17163/files/13fe4565..49ad3452

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

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

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

From kdnilsen at openjdk.org  Thu Dec 21 00:08:13 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 21 Dec 2023 00:08:13 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v3]
In-Reply-To: <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
Message-ID: <5IJG9nBAZvmUwoHrv9-wboM7OxvoOHBvSyBWMS1zdRU=.7733d112-720d-453d-afca-d9f19775a855@github.com>

On Wed, 20 Dec 2023 23:27:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only start global cycles when metaspace is out of memory

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah/pull/371#pullrequestreview-1791914373

From wkemper at openjdk.org  Thu Dec 21 00:25:09 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 00:25:09 GMT
Subject: RFR: 8322503: Shenandoah: Clarify gc state usage [v2]
In-Reply-To: <Iqha2JABNbwTZtFDL3J1SE_q5mKkhweVlzYM5M36Ynk=.271455dc-8892-42ce-b4fb-5cb1e9105a3c@github.com>
References: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
 <Iqha2JABNbwTZtFDL3J1SE_q5mKkhweVlzYM5M36Ynk=.271455dc-8892-42ce-b4fb-5cb1e9105a3c@github.com>
Message-ID: <OcsYxl7GvCzaxfHqWv4vk0ESxSM0FzRajrG99gaM1XM=.4f19972c-d093-4670-9179-80ae6692bd23@github.com>

On Wed, 20 Dec 2023 23:54:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This is a follow up to https://github.com/openjdk/jdk/pull/17112.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments to gc state methods

Added comments to new methods and synced up with tip to see if it addresses GHA build failure on macosx.

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

PR Comment: https://git.openjdk.org/jdk/pull/17163#issuecomment-1865307929

From wkemper at openjdk.org  Thu Dec 21 00:25:09 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 00:25:09 GMT
Subject: RFR: 8322503: Shenandoah: Clarify gc state usage [v3]
In-Reply-To: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
References: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
Message-ID: <JSwgTPN2ZTMi_Wcpqvj5pqMhIM4jCIDcr-6h4IbI6hE=.dbd14520-e4fd-4a2f-9390-b50ed15dd9cc@github.com>

> This is a follow up to https://github.com/openjdk/jdk/pull/17112.

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. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into sync-gc-state-followup
 - Add comments to gc state methods
 - Rename gc state methods for clarity, assert that only java threads use thread local copy of gc state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17163/files
  - new: https://git.openjdk.org/jdk/pull/17163/files/49ad3452..db146b84

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

  Stats: 298 lines in 19 files changed: 209 ins; 53 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/17163.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17163/head:pull/17163

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

From wkemper at openjdk.org  Thu Dec 21 00:29:19 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 00:29:19 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v4]
In-Reply-To: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
Message-ID: <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>

> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

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

  Update stale comment

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/371/files
  - new: https://git.openjdk.org/shenandoah/pull/371/files/25de1177..b065e623

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

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

PR: https://git.openjdk.org/shenandoah/pull/371

From ysr at openjdk.org  Thu Dec 21 01:48:14 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 21 Dec 2023 01:48:14 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v4]
In-Reply-To: <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>
Message-ID: <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>

On Thu, 21 Dec 2023 00:29:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update stale comment

A few comments for your consideration.

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 67:

> 65: }
> 66: 
> 67: void ShenandoahRegulatorThread::regulate_young_and_old_cycles() {

I am wondering if it might not be simpler and clearer to write this method as:


...
while (!should_terminate()) {
  switch (mode) {
     case SCT::none : {
        // no collection is in progress
        // 1. check and start a global collection if needed
        if (should_unload_classes() && start_global_cycle()) {
          log_info...
        } else if (start_old_cycle()) {
           log_info...
        } else if (start_young_cycle()) {
           log_info...
        }
        break;
     }
     case SCT::servicing_old: {
         if (start_young_cycle()) {
           log_info...
         }
         break;
      }
      default: // fall through
   }
   // sleep a tad before next check; sleep duration inversely proportional to allocation rate
   regulator_sleep();   // My worry is that heuristics says wait for old increment and we sleep longer than that? May be that's not an issue?
}
...


The rest of the checks etc. seem already to be done in the `start_...` methods from what I can tell.

I may have missed some subtlety though.

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 182:

> 180: }
> 181: 
> 182: bool ShenandoahRegulatorThread::should_unload_classes() {

I'd rename this to:

`should_start_metaspace_gc()`

to avoid confusion with similarly named method in other classes (heuristics) with a different semantics.

Relatedly, do we still need the second check in this method?


bool ShenandoahHeuristics::should_unload_classes() {
  if (!can_unload_classes()) return false;
  if (has_metaspace_oom()) return true;
  return ClassUnloadingWithConcurrentMark;
}


If not, it can be simplified to `return can_unload_classes() && ClassUnloadingWithConcurrentMark;`

I do believe, we should write a line documenting the intended semantics of `should_unload_classes()` in all these places because there ay otherwise be some confusion about what the truth modality "should" really means.

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

PR Review: https://git.openjdk.org/shenandoah/pull/371#pullrequestreview-1791966142
PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433342277
PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433344949

From ysr at openjdk.org  Thu Dec 21 01:48:14 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 21 Dec 2023 01:48:14 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v3]
In-Reply-To: <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
Message-ID: <hVUQAFUu8lClr8Q37XKqvmHvRPNdEE3mVVIyIPwsDQ4=.606e183b-9c53-462c-aafc-5ee665a4f497@github.com>

On Wed, 20 Dec 2023 23:27:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only start global cycles when metaspace is out of memory

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.hpp line 80:

> 78:   bool start_global_cycle();
> 79: 
> 80:   bool should_unload_classes();

Could you also please write a 1-line documentation comment for this as well?

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433326071

From wkemper at openjdk.org  Thu Dec 21 03:11:12 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 03:11:12 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v4]
In-Reply-To: <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>
 <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>
Message-ID: <SyWtkPL-mBR6w85OX76gZK0OXRCI-q7IHIGRmyFBW_4=.ead31885-df01-45df-a550-43c92f351cba@github.com>

On Thu, 21 Dec 2023 01:30:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update stale comment
>
> src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 67:
> 
>> 65: }
>> 66: 
>> 67: void ShenandoahRegulatorThread::regulate_young_and_old_cycles() {
> 
> I am wondering if it might not be simpler and clearer to write this method as:
> 
> 
> ...
> while (!should_terminate()) {
>   switch (mode) {
>      case SCT::none : {
>         // no collection is in progress
>         // 1. check and start a global collection if needed
>         if (should_unload_classes() && start_global_cycle()) {
>           log_info...
>         } else if (start_old_cycle()) {
>            // 2. else check and start an old cycle
>            log_info...
>         } else if (start_young_cycle()) {
>             // 3. else check and start a young cycle
>            log_info...
>         }
>         break;
>      }
>      case SCT::servicing_old: {
>          // if an old collection is in progress, check if a young
>          // collection is needed. We can't start a global collection
>          // in this state, even if one is needed.
>          if (start_young_cycle()) {
>            log_info...
>          }
>          break;
>       }
>       default: // fall through
>    }
>    // sleep a tad before next check; sleep duration inversely proportional to allocation rate
>    regulator_sleep();   // My worry is that heuristics says wait for old increment and we sleep longer than that? May be that's not an issue?
> }
> ...
> 
> 
> The rest of the checks etc. seem already to be done in the `start_...` methods from what I can tell.
> 
> I may have missed some subtlety though.

When regulating young and old cycles (i.e., generational mode), the regulator overrides the global heuristics decision to start a global cycle. In other modes, whether or not to unload classes is decided _after_ a cycle is started. However, the generational mode can only unload classes in a _global_ cycle, so we use the oom in metaspace to _trigger_ a global cycle (even if the global heuristic would not otherwise trigger a cycle).

The other subtlety here is that old cycles are only started when a young cycle wants to run. Each old cycle is preceded by a young "bootstrap" cycle, so the young heuristic trigger is still satisfied. This was meant to avoid the situation where old cycles are triggered shortly after a young cycle - which runs an unproductive "bootstrap" cycle. This is why we check the young heuristic and then the old heuristic before starting an old cycle.

Your comment about starting a global cycle (to unload classes) even during an old cycle is interesting though. There's no specific reason why we couldn't interrupt and abandon the old cycle in this case, but I think that's a change for another PR.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433404818

From wkemper at openjdk.org  Thu Dec 21 03:11:12 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 03:11:12 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v3]
In-Reply-To: <hVUQAFUu8lClr8Q37XKqvmHvRPNdEE3mVVIyIPwsDQ4=.606e183b-9c53-462c-aafc-5ee665a4f497@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <SDPRPAZgDrD_q0NzBn0jI3QQYnWb44f5mn50mUUByW4=.003bc236-dedc-409e-91b5-b59dfaacc3ac@github.com>
 <hVUQAFUu8lClr8Q37XKqvmHvRPNdEE3mVVIyIPwsDQ4=.606e183b-9c53-462c-aafc-5ee665a4f497@github.com>
Message-ID: <p8p24z7z1JSmDuJDL6B63B7WLvVIZNeqH8CUApRrKl4=.eb2b17d8-fc2e-4247-af5b-755666959ee6@github.com>

On Thu, 21 Dec 2023 01:04:47 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Only start global cycles when metaspace is out of memory
>
> src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.hpp line 80:
> 
>> 78:   bool start_global_cycle();
>> 79: 
>> 80:   bool should_unload_classes();
> 
> Could you also please write a 1-line documentation comment for this as well?

Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433404377

From wkemper at openjdk.org  Thu Dec 21 03:14:07 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 03:14:07 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v4]
In-Reply-To: <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>
 <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>
Message-ID: <bW6d8m_9w__TSCQfYbvfw7pr4s0lLljeudD5yZZpuT0=.f16d620f-cda4-4b0d-abfa-7660d0a2f065@github.com>

On Thu, 21 Dec 2023 01:34:38 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update stale comment
>
> src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 182:
> 
>> 180: }
>> 181: 
>> 182: bool ShenandoahRegulatorThread::should_unload_classes() {
> 
> I'd rename this to:
> 
> `should_start_metaspace_gc()`
> 
> to avoid confusion with similarly named method in other classes (heuristics) with a different semantics.
> 
> Relatedly, do we still need the second check in this method?
> 
> 
> bool ShenandoahHeuristics::should_unload_classes() {
>   if (!can_unload_classes()) return false;
>   if (has_metaspace_oom()) return true;
>   return ClassUnloadingWithConcurrentMark;
> }
> 
> 
> If not, it can be simplified to `return can_unload_classes() && ClassUnloadingWithConcurrentMark;`
> 
> I do believe, we should write a line documenting the intended semantics of `should_unload_classes()` in all these places because there ay otherwise be some confusion about what the truth modality "should" really means.

I'll add comments to `should_unload_classes`, but I don't want to change the implementation. This method is used by other Shenandoah modes. As I think on it, I'm going to make the regulator honor any class unloading restrictions before starting a fruitless cycle that won't unload anything.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433406832

From wkemper at openjdk.org  Thu Dec 21 03:26:09 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 03:26:09 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v4]
In-Reply-To: <SyWtkPL-mBR6w85OX76gZK0OXRCI-q7IHIGRmyFBW_4=.ead31885-df01-45df-a550-43c92f351cba@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>
 <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>
 <SyWtkPL-mBR6w85OX76gZK0OXRCI-q7IHIGRmyFBW_4=.ead31885-df01-45df-a550-43c92f351cba@github.com>
Message-ID: <JC6T1gdeLMsMjxmAuV78Gt8Ze-E8Y28u0EB102getU0=.2e53253a-815a-4d94-9c56-216ee81228eb@github.com>

On Thu, 21 Dec 2023 03:08:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 67:
>> 
>>> 65: }
>>> 66: 
>>> 67: void ShenandoahRegulatorThread::regulate_young_and_old_cycles() {
>> 
>> I am wondering if it might not be simpler and clearer to write this method as:
>> 
>> 
>> ...
>> while (!should_terminate()) {
>>   switch (mode) {
>>      case SCT::none : {
>>         // no collection is in progress
>>         // 1. check and start a global collection if needed
>>         if (should_unload_classes() && start_global_cycle()) {
>>           log_info...
>>         } else if (start_old_cycle()) {
>>            // 2. else check and start an old cycle
>>            log_info...
>>         } else if (start_young_cycle()) {
>>             // 3. else check and start a young cycle
>>            log_info...
>>         }
>>         break;
>>      }
>>      case SCT::servicing_old: {
>>          // if an old collection is in progress, check if a young
>>          // collection is needed. We can't start a global collection
>>          // in this state, even if one is needed.
>>          if (start_young_cycle()) {
>>            log_info...
>>          }
>>          break;
>>       }
>>       default: // fall through
>>    }
>>    // sleep a tad before next check; sleep duration inversely proportional to allocation rate
>>    regulator_sleep();   // My worry is that heuristics says wait for old increment and we sleep longer than that? May be that's not an issue?
>> }
>> ...
>> 
>> 
>> The rest of the checks etc. seem already to be done in the `start_...` methods from what I can tell.
>> 
>> I may have missed some subtlety though.
>
> When regulating young and old cycles (i.e., generational mode), the regulator overrides the global heuristics decision to start a global cycle. In other modes, whether or not to unload classes is decided _after_ a cycle is started. However, the generational mode can only unload classes in a _global_ cycle, so we use the oom in metaspace to _trigger_ a global cycle (even if the global heuristic would not otherwise trigger a cycle).
> 
> The other subtlety here is that old cycles are only started when a young cycle wants to run. Each old cycle is preceded by a young "bootstrap" cycle, so the young heuristic trigger is still satisfied. This was meant to avoid the situation where old cycles are triggered shortly after a young cycle - which runs an unproductive "bootstrap" cycle. This is why we check the young heuristic and then the old heuristic before starting an old cycle.
> 
> Your comment about starting a global cycle (to unload classes) even during an old cycle is interesting though. There's no specific reason why we couldn't interrupt and abandon the old cycle in this case, but I think that's a change for another PR.

I'm not too worried about the regulator's sleep method. The new flag introduces a delay if an old cycle is running, but the delay to start a young cycle because the regulator thread was sleeping is unchanged. Note that the feature can also be disabled by setting `ShenandoahMinimumOldMarkTimeMs` to zero.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1433415130

From wkemper at openjdk.org  Thu Dec 21 03:54:19 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 03:54:19 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v5]
In-Reply-To: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
Message-ID: <k3p0vwjwwvsN_KMlHEgsFyFkTFNKUftWLIBOb8O4TUE=.fd21b3dd-5c63-48c5-9538-9f1f79bb1c73@github.com>

> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.

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

  Improve comments, don't run fruitless global cycles

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/371/files
  - new: https://git.openjdk.org/shenandoah/pull/371/files/b065e623..e09a0054

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

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

PR: https://git.openjdk.org/shenandoah/pull/371

From aph at openjdk.org  Thu Dec 21 09:44:52 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 21 Dec 2023 09:44:52 GMT
Subject: RFR: JDK-8241503: C2: Share MacroAssembler between mach nodes
 during code emission [v6]
In-Reply-To: <g2_SBnj80r-46uBWFvWRfgvAL3USKCVxnO70sUHDj0I=.94aefeb5-a394-4d02-8bdf-0fec278dc343@github.com>
References: <ExCrwPns55nw2P62UI3vzSVTmFCh3dzJq7u3Kugp9EA=.c20cd86c-2c16-4869-ba7f-76f2a53821d0@github.com>
 <B5hp17WOakZK2Hdv4Sr940K05ZBHWOMft8pRd0QdQ1k=.a44e1c19-92a6-4317-91a5-b3e928afb3f6@github.com>
 <g2_SBnj80r-46uBWFvWRfgvAL3USKCVxnO70sUHDj0I=.94aefeb5-a394-4d02-8bdf-0fec278dc343@github.com>
Message-ID: <OyW3-G8zqCZxArr8ViTwp37EIFxnnkvD5Adk3szSeDw=.54184a8f-05ef-4513-8545-afacdb4a453f@github.com>

On Wed, 20 Dec 2023 11:11:07 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Cesar Soares Lucas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge with origin/master
>>  - Fix build, copyright dates, m4 files.
>>  - Fix merge
>>  - Catch up with master branch.
>>    
>>    Merge remote-tracking branch 'origin/master' into reuse-macroasm
>>  - Some inst_mark fixes; Catch up with master.
>>  - Catch up with changes on master
>>  - Reuse same C2_MacroAssembler object to emit instructions.
>
> Thanks for the explanation! Makes sense.

> @TheRealMDoerr motivation is to reduce memory consumption and speed up C2. `C2_MacroAssembler` is based on `ResourceObj` which allocates in compiler arena. Each small `C2_MacroAssembler masm()` will add allocation to arena until we finish compilation. Also speedup because we don't need to do such allocations.

I see. I updated the bug entry because we need an audit trail for such decisions.

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

PR Comment: https://git.openjdk.org/jdk/pull/16484#issuecomment-1865950233

From wkemper at openjdk.org  Thu Dec 21 14:14:25 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Dec 2023 14:14:25 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <FAhhrFO9H-x-CeTUPibx6tzBHH312qDByBKp1-4heBM=.b244a31f-7973-4640-8659-367bd66c92b1@github.com>

Merges tag jdk-23+2

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

Commit messages:
 - 8321565: [REDO] Heap dump does not contain virtual Thread stack references
 - 8321400: java/foreign/TestStubAllocFailure.java fails with code cache exhaustion
 - 8321973: Parallel: Remove unused methods in AdaptiveSizePolicy
 - 8321808: G1: Use unsigned type for non-negative G1 flags
 - 8293622: Cleanup use of G1ConcRefinementThreads
 - 8321515: ARM32: Move method resolution information out of the cpCache properly
 - 8321279: Implement hashCode() in Heap-X-Buffer.java.template
 - 8321825: Remove runtime/CompressedOops/CompressedClassPointers.java from the ProblemList
 - 8321474: TestAutoCreateSharedArchiveUpgrade.java should be updated with JDK 21
 - 8321557: Move SOURCE line verification for OracleJDK out of OpenJDK
 - ... and 47 more: https://git.openjdk.org/shenandoah/compare/519ecd35...cf948548

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

Changes: https://git.openjdk.org/shenandoah/pull/376/files
  Stats: 13526 lines in 174 files changed: 10537 ins; 2375 del; 614 mod
  Patch: https://git.openjdk.org/shenandoah/pull/376.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/376/head:pull/376

PR: https://git.openjdk.org/shenandoah/pull/376

From ysr at openjdk.org  Thu Dec 21 21:16:15 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 21 Dec 2023 21:16:15 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v4]
In-Reply-To: <JC6T1gdeLMsMjxmAuV78Gt8Ze-E8Y28u0EB102getU0=.2e53253a-815a-4d94-9c56-216ee81228eb@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <_xBZv26_KtMW4wSZvyJ6F_hTmfXu877L-NJ4B5xNFvw=.a03de588-ad45-4ff8-b6d1-60dca26141e0@github.com>
 <OtELrjm62JQEB3-_XpXqsrrR9qC7__k2wlOx45f2bVU=.a8609017-5361-4f42-ab8e-b5ae6fc6d7ae@github.com>
 <SyWtkPL-mBR6w85OX76gZK0OXRCI-q7IHIGRmyFBW_4=.ead31885-df01-45df-a550-43c92f351cba@github.com>
 <JC6T1gdeLMsMjxmAuV78Gt8Ze-E8Y28u0EB102getU0=.2e53253a-815a-4d94-9c56-216ee81228eb@github.com>
Message-ID: <DXfHKxEBrB4hEooWUrNcTTGLDhZpEocwS8aTKHOpC0o=.3eca5130-fd75-41ff-858c-4b1b0a85efb2@github.com>

On Thu, 21 Dec 2023 03:23:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> When regulating young and old cycles (i.e., generational mode), the regulator overrides the global heuristics decision to start a global cycle. In other modes, whether or not to unload classes is decided _after_ a cycle is started. However, the generational mode can only unload classes in a _global_ cycle, so we use the oom in metaspace to _trigger_ a global cycle (even if the global heuristic would not otherwise trigger a cycle).
>> 
>> The other subtlety here is that old cycles are only started when a young cycle wants to run. Each old cycle is preceded by a young "bootstrap" cycle, so the young heuristic trigger is still satisfied. This was meant to avoid the situation where old cycles are triggered shortly after a young cycle - which runs an unproductive "bootstrap" cycle. This is why we check the young heuristic and then the old heuristic before starting an old cycle.
>> 
>> Your comment about starting a global cycle (to unload classes) even during an old cycle is interesting though. There's no specific reason why we couldn't interrupt and abandon the old cycle in this case, but I think that's a change for another PR.
>
> I'm not too worried about the regulator's sleep method. The new flag introduces a delay if an old cycle is running, but the delay to start a young cycle because the regulator thread was sleeping is unchanged. Note that the feature can also be disabled by setting `ShenandoahMinimumOldMarkTimeMs` to zero.

Thanks for the clarifications here and for the extra documentation comments. Yes, I'd missed the subtleties here, which are important to document. Thanks for that!

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/371#discussion_r1434517984

From ysr at openjdk.org  Thu Dec 21 21:25:19 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 21 Dec 2023 21:25:19 GMT
Subject: RFR: 8321816: GenShen: Provide a minimum amount of time for an old
 collection to run [v5]
In-Reply-To: <k3p0vwjwwvsN_KMlHEgsFyFkTFNKUftWLIBOb8O4TUE=.fd21b3dd-5c63-48c5-9538-9f1f79bb1c73@github.com>
References: <Y039qA34p4BTjIDx0kdvN-NTGATfW3qy_GOyvRMvWU8=.87af94f7-6fc4-4f69-b640-255ebae32ac9@github.com>
 <k3p0vwjwwvsN_KMlHEgsFyFkTFNKUftWLIBOb8O4TUE=.fd21b3dd-5c63-48c5-9538-9f1f79bb1c73@github.com>
Message-ID: <0LeeeXay6wpaFbPnfHeuIFcAWwKCpl845XySgue_VxQ=.8ca5494c-e429-4bbf-8fa1-c92dea3a3b66@github.com>

On Thu, 21 Dec 2023 03:54:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Young collections are allowed to interrupt old collections. Under heavy load, this may result in starvation of old collections - which may in turn lead to even more memory pressure on the young generation. Adding a minimum guaranteed amount of time for the old gc to make progress will help avoid this situation.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments, don't run fruitless global cycles

Thanks for the clarifying documentation comments & the changes.

Looks good to me! ?

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/371#pullrequestreview-1793689320

From stefank at openjdk.org  Fri Dec 22 12:46:01 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 22 Dec 2023 12:46:01 GMT
Subject: RFR: 8321812: Update GC tests to use execute[Limited]TestJava [v2]
In-Reply-To: <SJsjlVy1S72d43Mmr2NmOGXChAAGzgc1O4KZ_YrFXEI=.2bb94c0e-1fe2-4537-bbe8-0b498bfcb1ed@github.com>
References: <SJsjlVy1S72d43Mmr2NmOGXChAAGzgc1O4KZ_YrFXEI=.2bb94c0e-1fe2-4537-bbe8-0b498bfcb1ed@github.com>
Message-ID: <QeppfONYgi0J0bFq2y8C5fGFPCrxenY7k5GYI9azGbo=.f5ea66d5-35be-4841-a21f-465cd4ca71a5@github.com>

> A lot of our tests use a multi-step recipe to spawn and wait for a process. Here's an example
> 
>     ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(
>          "-XX:-UseTLAB",
>          "-XX:+UnlockDiagnosticVMOptions",
>          "-XX:+VerifyDuringStartup",
>          "-Xlog:gc+verify=debug",
>          "-version");
>     OutputAnalyzer output = new OutputAnalyzer(pb.start());
>     ... do something with output and wait for the process to complete ...
> 
> 
> These are the steps involved:
> 
> 1) Create a `ProcessBuilder`
> 2) Call `ProcessBuilder::start`
> 3) Create an `OutputAnalyzer`
> 4) Perform an operation that finally waits for the process to, at least partially, complete (OutputAnalyzer::getOutput, OutputAnalyzer::shouldHaveExitValue(), and more).
> 
> Almost all our tests could be converted to use a single call to `ProcessTools.executeTestJava` (or `executeLimitedTestJava`), which spawns the process, makes sure that it has fully completed, and then returns a filled-in OutputAnalyzer to the caller. The above example would become:
> 
> 
>     OutputAnalyzer output = ProcessTools.executeTestJava(
>          "-XX:-UseTLAB",
>          "-XX:+UnlockDiagnosticVMOptions",
>          "-XX:+VerifyDuringStartup",
>          "-Xlog:gc+verify=debug",
>          "-version");
> 
> 
> I propose that we make this change in the GC tests, to make our code simpler and hopefully easier to read.
> 
> Note: There's a few changes to the throws statements because some ProcessTools APIs throws IOException while others throw Exception.
> 
> Testing: I've done testing on a similar set of changes, but I'm going to run the appropriate, final tests while this is being considered/reviewed.

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

  Whitespace fixes
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17067/files
  - new: https://git.openjdk.org/jdk/pull/17067/files/2a38c88c..8b088ed7

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

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

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

From ysr at openjdk.org  Thu Dec 28 00:49:30 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 00:49:30 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v4]
In-Reply-To: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
Message-ID: <HrrjnD8y1Wlw1MbRJT49wp6y-mrvClAvKIoX-u7HXB0=.144eff97-9628-48cf-b1e5-9a4b7983f18f@github.com>

> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
> 
> **Testing:**
> - [x] GHA
> - [x] code pipeline testing (TestPeriodicGC fails without the unrelated fix in https://github.com/openjdk/shenandoah/pull/372)
> - [x] specjbb with SOEP=default,0,100 to verify that the issue is fixed

Y. Srinivas Ramakrishna 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 12 additional commits since the last revision:

 - Backout e780d3bd33ab217543c78891fa50498001637f85
 - Merge branch 'master' into tenure_budget_8314599
 - Merge branch 'master' into tenure_budget_8314599
 - Merge branch 'should_unload_classes' into tenure_budget_8314599
 - Merge branch 'master' into should_unload_classes
 - JDK-8322150 should_unload_classes should return true only if a metaspace
   oom has been signalled, and other conditions are met.
 - Merge branch 'master' into tenure_budget_8314599
 - Fix a scope issue with a local variable.
 - jcheck trailing white-space.
 - Merge branch 'master' into tenure_budget_8314599
 - ... and 2 more: https://git.openjdk.org/shenandoah/compare/111f9cbd...a290be10

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/369/files
  - new: https://git.openjdk.org/shenandoah/pull/369/files/67318a30..a290be10

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

  Stats: 4889 lines in 101 files changed: 4838 ins; 6 del; 45 mod
  Patch: https://git.openjdk.org/shenandoah/pull/369.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/369/head:pull/369

PR: https://git.openjdk.org/shenandoah/pull/369

From ysr at openjdk.org  Thu Dec 28 00:49:34 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 00:49:34 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v3]
In-Reply-To: <WIKRV9fmUsfUNntfj6PX0nSkOCcTL-C1SW-9jXrBbf8=.7e64e0c6-7e89-441d-85bd-aeebf038aad1@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <WIKRV9fmUsfUNntfj6PX0nSkOCcTL-C1SW-9jXrBbf8=.7e64e0c6-7e89-441d-85bd-aeebf038aad1@github.com>
Message-ID: <FzYLpNl90SZZZZQx3D7mBNovMUU3ri6cwxYATYovDV0=.0ef23721-cc24-4cb7-876d-d5228538491c@github.com>

On Fri, 15 Dec 2023 09:19:37 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] code pipeline testing (TestPeriodicGC fails without the unrelated fix in https://github.com/openjdk/shenandoah/pull/372)
>> - [x] specjbb with SOEP=default,0,100 to verify that the issue is fixed
>
> Y. Srinivas Ramakrishna 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 ten additional commits since the last revision:
> 
>  - Merge branch 'should_unload_classes' into tenure_budget_8314599
>  - Merge branch 'master' into should_unload_classes
>  - JDK-8322150 should_unload_classes should return true only if a metaspace
>    oom has been signalled, and other conditions are met.
>  - Merge branch 'master' into tenure_budget_8314599
>  - Fix a scope issue with a local variable.
>  - jcheck trailing white-space.
>  - Merge branch 'master' into tenure_budget_8314599
>  - Fix another case where divide-by-zero could occur when
>    ShenandoahOldEvacRatioPercent is set to 100. Some slight refactoring in
>    the method.
>  - Fix divide-by-zero when ShenandoahOldEvacRatioPercent==100; minor
>    refactor & modification of documentation of flag

Converting to a draft until all failures are resolved satisfactorily.

This PR can be landed once the PR associated with JDK-8321816 integrates; the failures in GHA here have all been investigated and are either fixed by 8321816 or the result of changes from tip.

This PR is ready to commit in its current state.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/369#issuecomment-1858110308
PR Comment: https://git.openjdk.org/shenandoah/pull/369#issuecomment-1870719247

From ysr at openjdk.org  Thu Dec 28 01:04:32 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:04:32 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v5]
In-Reply-To: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
Message-ID: <KVzcfJzzrsUJ_vUYrwXt70P4_wIMx_j-dtecYs5xNAM=.42514cff-9e85-4967-9458-e2d46b47c176@github.com>

> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
> 
> **Testing:**
> - [x] GHA
> - [x] code pipeline testing (TestPeriodicGC fails without the unrelated fix in https://github.com/openjdk/shenandoah/pull/372)
> - [x] specjbb with SOEP=default,0,100 to verify that the issue is fixed

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Changes stemming from Kelvin's review.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/369/files
  - new: https://git.openjdk.org/shenandoah/pull/369/files/a290be10..87d45d5a

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

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

PR: https://git.openjdk.org/shenandoah/pull/369

From ysr at openjdk.org  Thu Dec 28 01:04:34 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:04:34 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <WE1Xajl0uVwo-SHSj7tSh_CZqyHhCmjpH7YsX6QSC_8=.d7324f69-e72d-45fc-bc08-ce26b3be958d@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
 <jlZ9Yr2uRd3BHPrEu6ZzaHaqnQ6gzumhIZO09EVQt3Q=.2a8bbe07-44ae-4639-b038-0bd4794027db@github.com>
 <rufumBRiSOA4TBvILZJaQd7ZarDrhkJMLgiRT1Tvxvg=.9e63328b-a8e4-4188-90c8-5a45bfa8a637@github.com>
 <WE1Xajl0uVwo-SHSj7tSh_CZqyHhCmjpH7YsX6QSC_8=.d7324f69-e72d-45fc-bc08-ce26b3be958d@github.com>
Message-ID: <zf4bTcOZ-Ooj6S8D3t2Q1XoYHYWImBfCMZ6nbMUsHho=.b5d4b7b8-4ce5-4904-9ba5-5b5ab0ae0ed7@github.com>

On Wed, 13 Dec 2023 22:02:18 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I'll add the justification in the comment.
>
> Thanks.  Your recollection of middle-school math is better than mine...  :)

Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1437311537

From ysr at openjdk.org  Thu Dec 28 01:04:39 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:04:39 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <AL6G6hjwSfkcGRkXo7gIVWR1UTxyz5Q21kMmW6cQ7H8=.aa6e39fa-b9dd-43ea-8b8c-b15c9ac2befd@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
 <AL6G6hjwSfkcGRkXo7gIVWR1UTxyz5Q21kMmW6cQ7H8=.aa6e39fa-b9dd-43ea-8b8c-b15c9ac2befd@github.com>
Message-ID: <Ktse_05mVIrtO5qzoa-c8BBpPOkzawW7ajCJbbyOy48=.030c8001-3e0f-41d8-b318-d84ba6cbff81@github.com>

On Wed, 13 Dec 2023 21:55:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1242:
>> 
>>> 1240:   const bool doing_promotions = promo_load > 0;
>>> 1241:   if (doing_promotions) {
>>> 1242:     // We're only promoting and we have a maximum bound on the amount to be promoted
>> 
>> With reference to the preceding comment, we should probably add an assert here: assert(!doing_mixed, "Don't do mixed and promotions in the same cycle")
>> 
>> Or maybe this is no longer true.  It doesn't have to be true.  The code that follows seems to suggest this is no longer true.  It was a simplification at some point in the implementation history.  If it is no longer true, let's remove that comment.
>
> I believe you are right. The comment appears obsolete. I'll check/confirm and delete the comment. Thanks!

Done

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1437311446

From ysr at openjdk.org  Thu Dec 28 01:04:37 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:04:37 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v2]
In-Reply-To: <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <ky0Zi6byUUUDXPY2atEcBfZF386Dcp0ScHf-Cg__TP4=.d04eeb0d-576b-4257-a593-348afa3fd4ff@github.com>
 <ZtGBbnkgnNy8IMnWOn3Xs5X1bG0XcjaP0XisQVMj1EY=.43410db7-d67b-4409-8bc3-77ba96119c1b@github.com>
Message-ID: <J3F4W6wGs4h7YAQRxTIQPWt9f4cQ-zlagtZVlK0a2ZA=.8934bd2c-9a85-4f62-a51b-df2c8b4e58bb@github.com>

On Wed, 13 Dec 2023 21:00:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a scope issue with a local variable.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1206:
> 
>> 1204:   //                     = OE/YE
>> 1205:   //  =>              OE = YE*SOEP/(100-SOEP)
>> 1206: 
> 
> Same comment as above, regarding the algebra steps.

Done.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1437311503

From ysr at openjdk.org  Thu Dec 28 01:08:11 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:08:11 GMT
Subject: Withdrawn: 8322150: [GenShen] TestPeriodicGC fails with
 "Generational mode: Should have periodic young GC in logs"
In-Reply-To: <L-DQXBrcn-vh_FV9W4wttDm7wtZMzdC9HtCt5QKdzCk=.efd14563-0f9f-4d68-a1b6-5043d15020cd@github.com>
References: <L-DQXBrcn-vh_FV9W4wttDm7wtZMzdC9HtCt5QKdzCk=.efd14563-0f9f-4d68-a1b6-5043d15020cd@github.com>
Message-ID: <dQcZPyMLuOXjAStW_SMSEJN6Xxkk1QvXxV7-5Re73U8=.0f800107-9a61-46ab-8f55-adb970ef33cb@github.com>

On Fri, 15 Dec 2023 08:33:41 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> 8322150: [GenShen] TestPeriodicGC fails with "Generational mode: Should have periodic young GC in logs"

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah/pull/372

From ysr at openjdk.org  Thu Dec 28 01:15:11 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:15:11 GMT
Subject: RFR: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero [v3]
In-Reply-To: <LAF1lVOmPBZUaO4Kv4FkN895QT0KeIHAeRAM0f6TPgs=.1ba59cb4-23f4-47cc-b043-d2ed1d4da2c3@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
 <WIKRV9fmUsfUNntfj6PX0nSkOCcTL-C1SW-9jXrBbf8=.7e64e0c6-7e89-441d-85bd-aeebf038aad1@github.com>
 <LAF1lVOmPBZUaO4Kv4FkN895QT0KeIHAeRAM0f6TPgs=.1ba59cb4-23f4-47cc-b043-d2ed1d4da2c3@github.com>
Message-ID: <WhYEwJhMdKiJRsBFprb1wqIr7rNFv1ayCzz63WhzdFY=.9b94abfc-011c-4004-ac09-e1d84bc14d46@github.com>

On Fri, 15 Dec 2023 09:19:46 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'should_unload_classes' into tenure_budget_8314599
>>  - Merge branch 'master' into should_unload_classes
>>  - JDK-8322150 should_unload_classes should return true only if a metaspace
>>    oom has been signalled, and other conditions are met.
>>  - Merge branch 'master' into tenure_budget_8314599
>>  - Fix a scope issue with a local variable.
>>  - jcheck trailing white-space.
>>  - Merge branch 'master' into tenure_budget_8314599
>>  - Fix another case where divide-by-zero could occur when
>>    ShenandoahOldEvacRatioPercent is set to 100. Some slight refactoring in
>>    the method.
>>  - Fix divide-by-zero when ShenandoahOldEvacRatioPercent==100; minor
>>    refactor & modification of documentation of flag
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 1:
> 
>> 1: /*
> 
> Please ignore the changes in this file for now. It'll go away once the fix for the linked ticket https://bugs.openjdk.org/browse/JDK-8322150 is committed. This PR is blocked until that ticet's PR is committed.

This was backed out in a subsequent commit, so is not present in the final commit, as promised in previous comment.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/369#discussion_r1437314114

From ysr at openjdk.org  Thu Dec 28 01:15:11 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Dec 2023 01:15:11 GMT
Subject: Integrated: 8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails
 with divide-by-zero
In-Reply-To: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
References: <wHGFWbbaI8kRSZfT_jv3T18lPa9qFNczcLyOF6XLuS8=.30b4b2b9-7bc4-458f-a5e4-b09af872ade3@github.com>
Message-ID: <d4JRRZ7XldrgkRvGRjy48g_W_uv-e-NZ9VNSK2hNoW8=.86836561-d889-4aa6-96c7-1e388cefc27a@github.com>

On Wed, 13 Dec 2023 00:47:44 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> The code that used the option ShenandoahOldEvacRatioPercent (SOEP) didn't correctly deal with the extremal setting of 100. Corrected the error and did some light refactoring in the vicinity, getting rid of some dead variables, adding documentation, and assertions. Also modified slightly the documentation of the option.
> 
> **Testing:**
> - [x] GHA
> - [x] code pipeline testing (TestPeriodicGC fails without the unrelated fix in https://github.com/openjdk/shenandoah/pull/372)
> - [x] specjbb with SOEP=default,0,100 to verify that the issue is fixed

This pull request has now been integrated.

Changeset: 2c77c16e
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/2c77c16ef32d95f59a631e4a51836f4d6ccf4d39
Stats:     173 lines in 3 files changed: 62 ins; 68 del; 43 mod

8321939: [GenShen] ShenandoahOldEvacRatioPercent=100 fails with divide-by-zero

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.org/shenandoah/pull/369

From gli at openjdk.org  Thu Dec 28 13:00:40 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 28 Dec 2023 13:00:40 GMT
Subject: RFR: 8322503: Shenandoah: Clarify gc state usage [v3]
In-Reply-To: <JSwgTPN2ZTMi_Wcpqvj5pqMhIM4jCIDcr-6h4IbI6hE=.dbd14520-e4fd-4a2f-9390-b50ed15dd9cc@github.com>
References: <ydd3aTDIr8kEpgjfewAROT-IWV-7zgKIECXJyMeQOno=.4686dc19-a11c-465f-b021-fb4889da29c6@github.com>
 <JSwgTPN2ZTMi_Wcpqvj5pqMhIM4jCIDcr-6h4IbI6hE=.dbd14520-e4fd-4a2f-9390-b50ed15dd9cc@github.com>
Message-ID: <9x6KY7yZbAwtjo7wBGzQvhYxfjV24GAXXL8gdGX2-L0=.1185fc49-b4e9-4745-b2a5-cb72d4d7d964@github.com>

On Thu, 21 Dec 2023 00:25:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This is a follow up to https://github.com/openjdk/jdk/pull/17112.
>
> 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. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into sync-gc-state-followup
>  - Add comments to gc state methods
>  - Rename gc state methods for clarity, assert that only java threads use thread local copy of gc state

Looks good.

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

Marked as reviewed by gli (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17163#pullrequestreview-1798050576

From wkemper at openjdk.org  Thu Dec 28 14:15:23 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Dec 2023 14:15:23 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <ZqH_PEBFx-9w64jym8yEy7XI10kJHdfaAm3xYVhwrs4=.6f7fc973-0ec6-4fee-ba49-ed69c2c0c14c@github.com>

Merges tag jdk-23+3

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

Commit messages:
 - 8319548: Unexpected internal name for Filler array klass causes error in VisualVM
 - 8321972: test runtime/Unsafe/InternalErrorTest.java timeout on linux-riscv64 platform
 - 8322078: ZipSourceCache.testKeySourceMapping() test fails with The process cannot access the file because it is being used by another process
 - 8321017: Record in JFR that IEEE rounding mode was corrupted by loading a library
 - 8322141: SequenceInputStream.transferTo should not return as soon as Long.MAX_VALUE bytes have been transferred
 - 8322543: Parallel: Remove unused _major_pause_old_slope_counter
 - 8187634: keystore.getCertificateAlias(cert) returns original alias, inconsistent with fix of JDK-6483657
 - 8322377: Parallel: Remove unused arg in adjust_promo_for_pause_time and adjust_eden_for_pause_time
 - 8322364: Parallel: Remove unused SizePolicyTrueValues enum members
 - 8322417: Console read line with zero out should zero out when throwing exception
 - ... and 116 more: https://git.openjdk.org/shenandoah/compare/519ecd35...05745e3f

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

Changes: https://git.openjdk.org/shenandoah/pull/377/files
  Stats: 16951 lines in 422 files changed: 12695 ins; 2850 del; 1406 mod
  Patch: https://git.openjdk.org/shenandoah/pull/377.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/377/head:pull/377

PR: https://git.openjdk.org/shenandoah/pull/377