From shade at openjdk.java.net  Wed Sep  1 13:35:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Sep 2021 13:35:27 GMT
Subject: RFR: Fix ShenandoahFullGC worker stats handling
Message-ID: <lkzf2T_NPx8Duwq6GgguKRV-Iu7pYZfuTtZipAu3xfA=.52f70898-d44d-4b5e-8f18-582261a56fb5@github.com>

Current Windows builds fail like this:


c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): error C2131: expression did not evaluate to a constant
c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): note: failure was caused by a read of a variable outside its lifetime
c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): note: see usage of 'num_workers'
c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): error C2131: expression did not evaluate to a constant
c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): note: failure was caused by a read of a variable outside its lifetime
c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): note: see usage of 'num_workers'
make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/buildbot/worker/build-shenandoah-jdkx-windows/build/build/windows-x86_64-server-fastdebug/hotspot/variant-server/libjvm/objs/shenandoahFullGC.obj] Error 1


Instead of doing auto-alloc with worker count that is unknown at compile time, use resource area for allocations.

Additional testing:
 - [x] Linux x86_64 `hotspot_gc_shenandoah`
 - [x] Windows x86_64 build

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/shenandoah/pull/62/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=62&range=00
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/62/head:pull/62

PR: https://git.openjdk.java.net/shenandoah/pull/62

From zgu at openjdk.java.net  Wed Sep  1 13:35:27 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Sep 2021 13:35:27 GMT
Subject: RFR: Fix ShenandoahFullGC worker stats handling
In-Reply-To: <lkzf2T_NPx8Duwq6GgguKRV-Iu7pYZfuTtZipAu3xfA=.52f70898-d44d-4b5e-8f18-582261a56fb5@github.com>
References: <lkzf2T_NPx8Duwq6GgguKRV-Iu7pYZfuTtZipAu3xfA=.52f70898-d44d-4b5e-8f18-582261a56fb5@github.com>
Message-ID: <v_oh_dGAUBtgapavT9qI7tLPE8p7toIwGM3hb3GEPu4=.25b87877-bb07-41c3-8766-99c413649f19@github.com>

On Wed, 1 Sep 2021 10:24:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current Windows builds fail like this:
> 
> 
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): error C2131: expression did not evaluate to a constant
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): note: failure was caused by a read of a variable outside its lifetime
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): note: see usage of 'num_workers'
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): error C2131: expression did not evaluate to a constant
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): note: failure was caused by a read of a variable outside its lifetime
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): note: see usage of 'num_workers'
> make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/buildbot/worker/build-shenandoah-jdkx-windows/build/build/windows-x86_64-server-fastdebug/hotspot/variant-server/libjvm/objs/shenandoahFullGC.obj] Error 1
> 
> 
> Instead of doing auto-alloc with worker count that is unknown at compile time, use resource area for allocations.
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Windows x86_64 build

Good to me.

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

Marked as reviewed by zgu (Committer).

PR: https://git.openjdk.java.net/shenandoah/pull/62

From wkemper at openjdk.java.net  Wed Sep  1 21:03:13 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 1 Sep 2021 21:03:13 GMT
Subject: RFR: Fix misuse of atomic flag
Message-ID: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>

This change fixes an assert that GC isn't cancelled in the middle of a safepoint. The assert was triggered during the tier2 test: `TestJNIGlobalRefs`. The test uses the _aggressive_ heuristic which runs GC's back to back. The atomic `_preemption_allowed` variable was being misused in a non-atomic way which could lead to the regulator thread cancelling GC after the control thread has gone to the final mark safepoint.

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

Commit messages:
 - Merge branch 'shenandoah' into fix-regulator-cancel-gc
 - Fix misuse of atomic variables

Changes: https://git.openjdk.java.net/shenandoah/pull/63/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=63&range=00
  Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/63/head:pull/63

PR: https://git.openjdk.java.net/shenandoah/pull/63

From zgu at openjdk.java.net  Wed Sep  1 23:48:49 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Sep 2021 23:48:49 GMT
Subject: RFR: Fix misuse of atomic flag
In-Reply-To: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>
References: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>
Message-ID: <HkHwC-SMb07r8_hrLRYv9C5sCgPIP_UYE5TgQeLGf9g=.57e03688-5663-4e0c-ac52-ccb4999119b1@github.com>

On Wed, 1 Sep 2021 20:56:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change fixes an assert that GC isn't cancelled in the middle of a safepoint. The assert was triggered during the tier2 test: `TestJNIGlobalRefs`. The test uses the _aggressive_ heuristic which runs GC's back to back. The atomic `_preemption_allowed` variable was being misused in a non-atomic way which could lead to the regulator thread cancelling GC after the control thread has gone to the final mark safepoint.

Looks good.

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

Marked as reviewed by zgu (Committer).

PR: https://git.openjdk.java.net/shenandoah/pull/63

From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 03:39:27 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 03:39:27 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
Message-ID: <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>

On Tue, 31 Aug 2021 13:27:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
>> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
>> 
>> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
>> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
>> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
>> 
>> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
>> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
>> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579
>
> I think forwardee installation is better done with `acq_rel`, given that two GC threads may try to install it, and the failing thread should consume/acquire the other forwardee. Not sure the `OrderAccess::release` provides the same semantics. I have updated #2496 with more discussion and implementation.

@shipilev Here is the specjbb2015 result. opt1 is `acq_rel`, opt2 is `OrderAccess::release`

baseline_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31247, max-jOPS = 30168, critical-jOPS = 20319
baseline_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 20986
baseline_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 30168, critical-jOPS = 21053
opt1_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29140, critical-jOPS = 16247
opt1_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29140, critical-jOPS = 18131
opt1_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29483, critical-jOPS = 15928
opt2_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32788, max-jOPS = 30168, critical-jOPS = 22622
opt2_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22462
opt2_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 33186, max-jOPS = 30168, critical-jOPS = 22845

It seems `OrderAccess::release` performs better than `acq_rel`.
I notice that you have implemented `acquire` in getting forwardee in https://github.com/openjdk/jdk/pull/2496/, so I guess the `acq` here in `acq_rel` of forwardee installation is redundant? Given the specjbb result, I prefer to use `OrderAccess::release` here in forwardee installation. It only serves as storestore barrier on AArch64 and it doesn't provide the same semantics as you have mentioned above about consume/acquire the other forwardee.

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

PR: https://git.openjdk.java.net/jdk/pull/5299

From gnu.andrew at redhat.com  Thu Sep  2 04:22:39 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 2 Sep 2021 05:22:39 +0100
Subject: [RFR] [8u] 8u312-b01 Upstream Sync
Message-ID: <YTBRj5YXGK1t7xEI@hex.discworld.ac.uk>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u312-b01:
  - JDK-7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection
  - JDK-8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime
  - JDK-8027154: [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
  - JDK-8035001: TEST_BUG: the retry logic in RMID.start() should check that the subprocess hasn't terminated
  - JDK-8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser
  - JDK-8042557: compiler/uncommontrap/TestSpecTrapClassUnloading.java fails with: GC triggered before VM initialization completed
  - JDK-8054118: java/net/ipv6tests/UdpTest.java failed intermittently
  - JDK-8065215: Print warning summary at end of configure
  - JDK-8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object
  - JDK-8079891: Store configure log in $BUILD/configure.log
  - JDK-8080082: configure fails if you create an empty directory and then run configure from it
  - JDK-8086003: Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing
  - JDK-8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address
  - JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get
  - JDK-8166673: The new implementation of Robot.waitForIdle() may hang
  - JDK-8170467: (reflect) Optimize SignatureParser's use of StringBuilders
  - JDK-8196181: sun/java2d/GdiRendering/InsetClipping.java fails
  - JDK-8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore
  - JDK-8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error
  - JDK-8214418: half-closed SSLEngine status may cause application dead loop
  - JDK-8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11
  - JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr
  - JDK-8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4
  - JDK-8231222: fix pkcs11 P11_DEBUG guarded native traces
  - JDK-8238567: SoftMainMixer.processAudioBuffers(): Wrong handling of stoppedMixers
  - JDK-8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print
  - JDK-8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93)
  - JDK-8248901: Signed immediate support in .../share/assembler.hpp is broken.
  - JDK-8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
  - JDK-8262000: jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParallelScavenge.java failed with "OutOfMemoryError: Java heap space"
  - JDK-8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames()
  - JDK-8263311: Watch registry changes for remote printers update instead of polling
  - JDK-8265238: [8u] [macos] build failure in OpenJDK8u after JDK-8211301 in older xcode
  - JDK-8265978: make test should look for more locations when searching for exit code
  - JDK-8269810: [8u] Update generated_configure.sh after JDK-8250876 backport
  - JDK-8269953: config.log is not in build directory after 8u backport of JDK-8079891
  - JDK-8271466: StackGap test fails on aarch64 due to "-m64"

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags                                |    3 +
 b/common/autoconf/basics.m4              |   32 ++++++++++++++--
 b/common/autoconf/configure              |   11 ++---
 b/common/autoconf/configure.ac           |   12 ++----
 b/common/autoconf/generated-configure.sh |   62 +++++++++++++++++++++++++------
 b/common/autoconf/help.m4                |   20 +++++++++-
 b/make/Main.gmk                          |    8 +++-
 7 files changed, 116 insertions(+), 32 deletions(-)

diffstat for corba
 b/.hgtags |    3 +++
 1 file changed, 3 insertions(+)

diffstat for jaxp
 b/.hgtags |    3 +++
 1 file changed, 3 insertions(+)

diffstat for jaxws
 b/.hgtags |    3 +++
 1 file changed, 3 insertions(+)

diffstat for langtools
 b/.hgtags |    3 +++
 1 file changed, 3 insertions(+)

diffstat for nashorn
 b/.hgtags |    3 +++
 1 file changed, 3 insertions(+)

diffstat for jdk
 b/.hgtags                                                                              |    3 
 b/src/macosx/native/sun/awt/AWTWindow.m                                                |    5 
 b/src/share/classes/com/sun/crypto/provider/PBES2Parameters.java                       |  105 +++---
 b/src/share/classes/com/sun/media/sound/SoftMainMixer.java                             |    6 
 b/src/share/classes/java/net/URL.java                                                  |   29 +
 b/src/share/classes/java/net/URLStreamHandler.java                                     |   21 -
 b/src/share/classes/javax/swing/JComboBox.java                                         |   18 -
 b/src/share/classes/sun/awt/SunToolkit.java                                            |   21 -
 b/src/share/classes/sun/reflect/generics/parser/SignatureParser.java                   |  110 ++----
 b/src/share/classes/sun/security/pkcs11/P11AEADCipher.java                             |   11 
 b/src/share/classes/sun/security/pkcs11/P11Digest.java                                 |    4 
 b/src/share/classes/sun/security/pkcs11/P11Mac.java                                    |    2 
 b/src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java                            |  134 ++++----
 b/src/share/classes/sun/security/ssl/Ciphertext.java                                   |    2 
 b/src/share/classes/sun/security/ssl/PreSharedKeyExtension.java                        |    2 
 b/src/share/classes/sun/security/ssl/SSLEngineImpl.java                                |   15 
 b/src/share/classes/sun/security/ssl/SSLSessionContextImpl.java                        |    9 
 b/src/share/classes/sun/security/ssl/ServerHello.java                                  |    5 
 b/src/share/classes/sun/security/ssl/TransportContext.java                             |    8 
 b/src/share/classes/sun/security/util/Cache.java                                       |   29 +
 b/src/share/classes/sun/security/x509/AlgorithmId.java                                 |   91 ++---
 b/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c                           |   22 -
 b/src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c                             |   44 ++
 b/src/share/native/sun/security/pkcs11/wrapper/p11_general.c                           |    9 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c                           |   12 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c                          |    8 
 b/src/share/native/sun/security/pkcs11/wrapper/p11_util.c                              |  113 ++++--
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11gcm2.h                            |   55 +++
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h                               |    4 
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h                         |    5 
 b/src/solaris/native/sun/security/pkcs11/wrapper/p11_md.h                              |    5 
 b/src/windows/classes/sun/print/PrintServiceLookupProvider.java                        |  109 ------
 b/src/windows/native/sun/security/pkcs11/wrapper/p11_md.h                              |    5 
 b/src/windows/native/sun/windows/WPrinterJob.cpp                                       |   68 +++-
 b/src/windows/native/sun/windows/awt_PrintControl.cpp                                  |    3 
 b/test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java              |   40 +-
 b/test/java/awt/Robot/WaitForIdleSyncroizedOnString/WaitForIdleSyncroizedOnString.java |   63 +++
 b/test/java/net/MulticastSocket/TestInterfaces.java                                    |   13 
 b/test/java/net/ipv6tests/Tests.java                                                   |    9 
 b/test/java/rmi/testlibrary/JavaVM.java                                                |   22 -
 b/test/java/rmi/testlibrary/RMID.java                                                  |   59 ++-
 b/test/javax/swing/JComboBox/8072767/bug8072767.java                                   |  111 ++++++
 b/test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java   |   76 ----
 b/test/jdk/jfr/event/gc/detailed/ExecuteOOMApp.java                                    |    4 
 b/test/sun/java2d/GdiRendering/InsetClipping.java                                      |   22 -
 b/test/sun/security/lib/cacerts/VerifyCACerts.java                                     |    2 
 b/test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java                            |   14 
 b/test/sun/security/pkcs12/PBES2Encoding.java                                          |  129 +++++++
 b/test/sun/security/pkcs12/WrongPBES2.java                                             |  163 ++++++++++
 b/test/sun/security/x509/AlgorithmId/OidTableInit.java                                 |   76 ++++
 50 files changed, 1286 insertions(+), 609 deletions(-)

diffstat for hotspot
 b/.hgtags                                                    |    3 
 b/src/cpu/sparc/vm/assembler_sparc.hpp                       |    7 
 b/src/share/vm/asm/assembler.hpp                             |   39 ++--
 b/src/share/vm/runtime/arguments.cpp                         |    6 
 b/src/share/vm/runtime/globals.hpp                           |    6 
 b/src/share/vm/utilities/debug.hpp                           |    3 
 b/src/share/vm/utilities/vmError.cpp                         |   42 ++--
 b/test/compiler/uncommontrap/TestSpecTrapClassUnloading.java |    4 
 b/test/runtime/CompressedOops/CompressedClassPointers.java   |    6 
 b/test/runtime/ErrorHandling/ErrorFileRedirectTest.java      |  105 +++++++++++
 b/test/runtime/StackGap/testme.sh                            |    5 
 11 files changed, 186 insertions(+), 40 deletions(-)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at openjdk.java.net  Thu Sep  2 07:38:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 07:38:56 GMT
Subject: RFR: Fix misuse of atomic flag
In-Reply-To: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>
References: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>
Message-ID: <j3LPS_UCmRpin5iy6u4Jd3ZGaDuX1-SGc3elcYY71MI=.f547c748-b28c-47b8-b501-fe231ee8ea2b@github.com>

On Wed, 1 Sep 2021 20:56:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change fixes an assert that GC isn't cancelled in the middle of a safepoint. The assert was triggered during the tier2 test: `TestJNIGlobalRefs`. The test uses the _aggressive_ heuristic which runs GC's back to back. The atomic `_preemption_allowed` variable was being misused in a non-atomic way which could lead to the regulator thread cancelling GC after the control thread has gone to the final mark safepoint.

Marked as reviewed by shade (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/63

From shade at openjdk.java.net  Thu Sep  2 07:41:02 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 07:41:02 GMT
Subject: Integrated: Fix ShenandoahFullGC worker stats handling
In-Reply-To: <lkzf2T_NPx8Duwq6GgguKRV-Iu7pYZfuTtZipAu3xfA=.52f70898-d44d-4b5e-8f18-582261a56fb5@github.com>
References: <lkzf2T_NPx8Duwq6GgguKRV-Iu7pYZfuTtZipAu3xfA=.52f70898-d44d-4b5e-8f18-582261a56fb5@github.com>
Message-ID: <E5vEBd_OWoRyZaXofsNvYtxa13w-owyqAryh-4Fm9LU=.83e1a17c-bab8-41c4-833a-f144726e58da@github.com>

On Wed, 1 Sep 2021 10:24:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current Windows builds fail like this:
> 
> 
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): error C2131: expression did not evaluate to a constant
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): note: failure was caused by a read of a variable outside its lifetime
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1074): note: see usage of 'num_workers'
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): error C2131: expression did not evaluate to a constant
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): note: failure was caused by a read of a variable outside its lifetime
> c:\buildbot\worker\build-shenandoah-jdkx-windows\build\src\hotspot\share\gc\shenandoah\shenandoahFullGC.cpp(1075): note: see usage of 'num_workers'
> make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/buildbot/worker/build-shenandoah-jdkx-windows/build/build/windows-x86_64-server-fastdebug/hotspot/variant-server/libjvm/objs/shenandoahFullGC.obj] Error 1
> 
> 
> Instead of doing auto-alloc with worker count that is unknown at compile time, use resource area for allocations.
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Windows x86_64 build

This pull request has now been integrated.

Changeset: 0a72c50d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/0a72c50d2847b387135a92a3ac3b6a87bf88d308
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

Fix ShenandoahFullGC worker stats handling

Reviewed-by: zgu

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

PR: https://git.openjdk.java.net/shenandoah/pull/62

From shade at redhat.com  Thu Sep  2 07:43:14 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 09:43:14 +0200
Subject: [RFR] [8u] 8u312-b01 Upstream Sync
In-Reply-To: <YTBRj5YXGK1t7xEI@hex.discworld.ac.uk>
References: <YTBRj5YXGK1t7xEI@hex.discworld.ac.uk>
Message-ID: <52a3bace-87d0-fb7a-7923-e357406bb672@redhat.com>

On 9/2/21 6:22 AM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jaxws/merge.changeset

Look trivially good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jdk/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/hotspot/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/nashorn/merge.changeset

Look trivially fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/root/merge.changeset

Looks fine.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From shade at openjdk.java.net  Thu Sep  2 10:56:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 10:56:44 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v10]
In-Reply-To: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
Message-ID: <2njoOMmi_-cpJX7cNcVhH2Z8b5aZxi8icbw5RGt_IMg=.08a21ecd-dd98-4727-a495-8525b46b5bd1@github.com>

> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
> 
> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
> 
> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
> 
> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
> 
> Before:
> 
> 
> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
> 
> 
> After:
> 
> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 `tier1` with Shenandoah
>  - [x] Linux AArch64 `tier1` with Shenandoah

Aleksey Shipilev 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 JDK-8261492-shenandoah-forwardee-memord
 - Doing acquires on most paths, and relaxed on the path that matters: heap update
 - Even more discussion
 - Additional discussion and corner cases
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - Add TODO
 - "acquire" is too slow on aarch64, and does not seem neccessary anyway
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - 8261492: Shenandoah: reconsider forwardee accesses memory ordering

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

Changes: https://git.openjdk.java.net/jdk/pull/2496/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2496&range=09
  Stats: 174 lines in 13 files changed: 104 ins; 30 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2496.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2496/head:pull/2496

PR: https://git.openjdk.java.net/jdk/pull/2496

From wkemper at openjdk.java.net  Thu Sep  2 15:41:34 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 2 Sep 2021 15:41:34 GMT
Subject: Integrated: Fix misuse of atomic flag
In-Reply-To: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>
References: <bzofiIfMnxsepkqNZ-am6X0xUwvU-gqdKa8W2zv9lUc=.dbf8322e-6665-400a-9949-50386ff962f1@github.com>
Message-ID: <qM9JUht1fE3x_TsyJ_JZcOvgq4jV6i0lqk-qgDQeaJ8=.83759f78-5871-4a1a-a836-d00580e6a073@github.com>

On Wed, 1 Sep 2021 20:56:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change fixes an assert that GC isn't cancelled in the middle of a safepoint. The assert was triggered during the tier2 test: `TestJNIGlobalRefs`. The test uses the _aggressive_ heuristic which runs GC's back to back. The atomic `_preemption_allowed` variable was being misused in a non-atomic way which could lead to the regulator thread cancelling GC after the control thread has gone to the final mark safepoint.

This pull request has now been integrated.

Changeset: f01e568c
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/f01e568c5ba92bdd2ac023fe73c16bd714db8e04
Stats:     13 lines in 2 files changed: 9 ins; 0 del; 4 mod

Fix misuse of atomic flag

Reviewed-by: zgu, shade

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

PR: https://git.openjdk.java.net/shenandoah/pull/63

From shade at openjdk.java.net  Thu Sep  2 16:06:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 16:06:45 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v11]
In-Reply-To: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
Message-ID: <d48UorB5acC36n36zS7Ky0hFOArniVDdMi5a80s4OT4=.7581eef2-5724-4c19-8190-a1c8d53746c8@github.com>

> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
> 
> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
> 
> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
> 
> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
> 
> Before:
> 
> 
> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
> 
> 
> After:
> 
> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 `tier1` with Shenandoah
>  - [x] Linux AArch64 `tier1` with Shenandoah

Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:

 - More natural order of arguments
 - Move the fwdptr-related updaters to ShenandoahForwarding
 - Avoid acq_rel that is promoted to seq_cst on ARM <8.3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2496/files
  - new: https://git.openjdk.java.net/jdk/pull/2496/files/0dacba04..40941bfc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2496&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2496&range=09-10

  Stats: 193 lines in 8 files changed: 116 ins; 67 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2496.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2496/head:pull/2496

PR: https://git.openjdk.java.net/jdk/pull/2496

From shade at openjdk.java.net  Thu Sep  2 16:40:21 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 16:40:21 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
 <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>
Message-ID: <asVE-SiNkfTBH-YeXdjTk6vitxcmI02jFcpncwrMqSg=.d50837af-c07f-465a-b39d-d1c92a6e8eb3@github.com>

On Thu, 2 Sep 2021 03:36:05 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> It seems `OrderAccess::release` performs better than `acq_rel`.

Interesting result, thanks. I think that's because on current ARM 8.2 `acq_rel` is effectively `seq_cst`, which is stronger than `release`. ARM 8.3 introduces the RCpc atomics that are weaker, but we are not there yet. Anyhow, in #2496, I tried to do the acquire conditionally now, leaving only `release` CAS to hopefully avoid this pitfall.

I also think that PR now subsumes this one: it does conditionally relaxed heap updates, while leaving "release" for self-healing paths that might run concurrently during evacuation. Would you mind testing #2496 instead? Maybe also #2496 + `OrderAccess::release` variant to see if we even need it now performance-wise? If you agree, I would suggest closing this PR and moving the rest of the work under #2496.

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

PR: https://git.openjdk.java.net/jdk/pull/5299

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 03:41:31 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 03:41:31 GMT
Subject: Withdrawn: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
Message-ID: <hq4bwAmuK2SgV0we1uGgUy7vvu-hI-ZPPT8_Uihu87o=.0828b06d-9b69-4aff-95d8-f5a7a63b4be0@github.com>

On Mon, 30 Aug 2021 11:08:22 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
> 
> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
> 
> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5299

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 03:41:31 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 03:41:31 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <asVE-SiNkfTBH-YeXdjTk6vitxcmI02jFcpncwrMqSg=.d50837af-c07f-465a-b39d-d1c92a6e8eb3@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
 <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>
 <asVE-SiNkfTBH-YeXdjTk6vitxcmI02jFcpncwrMqSg=.d50837af-c07f-465a-b39d-d1c92a6e8eb3@github.com>
Message-ID: <A8Q2PA-MpNg7cYcWKTRby8ihioeGzeeFmO5PJp9-2UY=.6db8881d-39b6-4487-bd9e-683dfa7fdce5@github.com>

On Thu, 2 Sep 2021 16:28:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev Here is the specjbb2015 result. opt1 is `acq_rel`, opt2 is `OrderAccess::release`
>> 
>> baseline_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31247, max-jOPS = 30168, critical-jOPS = 20319
>> baseline_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 20986
>> baseline_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 30168, critical-jOPS = 21053
>> opt1_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29140, critical-jOPS = 16247
>> opt1_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29140, critical-jOPS = 18131
>> opt1_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29483, critical-jOPS = 15928
>> opt2_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32788, max-jOPS = 30168, critical-jOPS = 22622
>> opt2_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22462
>> opt2_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 33186, max-jOPS = 30168, critical-jOPS = 22845
>> 
>> It seems `OrderAccess::release` performs better than `acq_rel`.
>> I notice that you have implemented `acquire` in getting forwardee in https://github.com/openjdk/jdk/pull/2496/, so I guess the `acq` here in `acq_rel` of forwardee installation is redundant? Given the specjbb result, I prefer to use `OrderAccess::release` here in forwardee installation. It only serves as storestore barrier on AArch64 and it doesn't provide the same semantics as you have mentioned above about consume/acquire the other forwardee.
>
>> It seems `OrderAccess::release` performs better than `acq_rel`.
> 
> Interesting result, thanks. I think that's because on current ARM 8.2 `acq_rel` is effectively `seq_cst`, which is stronger than `release`. ARM 8.3 introduces the RCpc atomics that are weaker, but we are not there yet. Anyhow, in #2496, I tried to do the acquire conditionally now, leaving only `release` CAS to hopefully avoid this pitfall.
> 
> I also think that PR now subsumes this one: it does conditionally relaxed heap updates, while leaving "release" for self-healing paths that might run concurrently during evacuation. Would you mind testing #2496 instead? Maybe also #2496 + `OrderAccess::release` variant to see if we even need it now performance-wise? If you agree, I would suggest closing this PR and moving the rest of the work under #2496.

@shipilev Sure, let's discuss under https://github.com/openjdk/jdk/pull/2496 and I will try testing its performance. Thanks for your suggestions.

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

PR: https://git.openjdk.java.net/jdk/pull/5299

From gnu.andrew at redhat.com  Sat Sep  4 01:26:42 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 4 Sep 2021 02:26:42 +0100
Subject: [RFR] [8u] 8u312-b01 Upstream Sync
In-Reply-To: <52a3bace-87d0-fb7a-7923-e357406bb672@redhat.com>
References: <YTBRj5YXGK1t7xEI@hex.discworld.ac.uk>
 <52a3bace-87d0-fb7a-7923-e357406bb672@redhat.com>
Message-ID: <YTLLUiGjabIBKgKL@hex.discworld.ac.uk>

On 09:43 Thu 02 Sep     , Aleksey Shipilev wrote:
> On 9/2/21 6:22 AM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jaxws/merge.changeset
> 
> Look trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/jdk/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/hotspot/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/nashorn/merge.changeset
> 
> Look trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b01/root/merge.changeset
> 
> Looks fine.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks. Pushed.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at openjdk.java.net  Mon Sep  6 11:13:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 11:13:51 GMT
Subject: RFR: 8273378: Shenandoah: Remove the remaining uses of os::is_MP
Message-ID: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>

JDK-8188764 removed many uses of `os::is_MP`, effectively defaulting it to `true`, but some Shenandoah code still has it. This is a simple omission. All current uses on x86 already imply lock prefix, so this is a cleanup, and not a functional change.

Additional testing:
 - [x] Linux x86_64 `hotspot_gc_shenandoah`

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/5378

From aph at openjdk.java.net  Mon Sep  6 12:08:43 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 6 Sep 2021 12:08:43 GMT
Subject: RFR: 8273378: Shenandoah: Remove the remaining uses of os::is_MP
In-Reply-To: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
References: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
Message-ID: <hD8SSs5aD_nSrqK5bLdxup0uXMyYPchI_Fm4-U97DCI=.d70d25ed-3a41-44b8-a5e3-75d37c07ad01@github.com>

On Mon, 6 Sep 2021 11:03:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8188764 removed many uses of `os::is_MP`, effectively defaulting it to `true`, but some Shenandoah code still has it. This is a simple omission. All current uses on x86 already imply lock prefix, so this is a cleanup, and not a functional change.
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`

Marked as reviewed by aph (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5378

From zgu at openjdk.java.net  Mon Sep  6 14:26:38 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 6 Sep 2021 14:26:38 GMT
Subject: RFR: 8273378: Shenandoah: Remove the remaining uses of os::is_MP
In-Reply-To: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
References: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
Message-ID: <xVfOfDqcegNo1ueoBL55EDeHjBy8WxIFFdBA0B2p0r8=.74a0e416-06d2-46fd-896b-ce9bb3b1bb1d@github.com>

On Mon, 6 Sep 2021 11:03:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8188764 removed many uses of `os::is_MP`, effectively defaulting it to `true`, but some Shenandoah code still has it. This is a simple omission. All current uses on x86 already imply lock prefix, so this is a cleanup, and not a functional change.
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5378

From shade at openjdk.java.net  Mon Sep  6 16:03:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 16:03:36 GMT
Subject: RFR: 8273378: Shenandoah: Remove the remaining uses of os::is_MP
In-Reply-To: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
References: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
Message-ID: <xIUSdZLVtUGHB5__-qRIMqz93EGRJZbxnR72hivo_Ok=.f9794237-958e-4b03-8dd5-9f82ddc73ac8@github.com>

On Mon, 6 Sep 2021 11:03:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8188764 removed many uses of `os::is_MP`, effectively defaulting it to `true`, but some Shenandoah code still has it. This is a simple omission. All current uses on x86 already imply lock prefix, so this is a cleanup, and not a functional change.
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`

Thank you, GHA tests are green, so I am integrating.

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

PR: https://git.openjdk.java.net/jdk/pull/5378

From shade at openjdk.java.net  Mon Sep  6 16:03:37 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 16:03:37 GMT
Subject: Integrated: 8273378: Shenandoah: Remove the remaining uses of
 os::is_MP
In-Reply-To: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
References: <YxRgic5m25zh6nR4FTQb-UcRyey-HGb0juXKHQwe4RY=.6df36615-ffa8-4df7-bb9b-e5e74745bfad@github.com>
Message-ID: <iMWUIF6riU2I-8vNy9-4-5UducR7d7X4aPOm8CGdwGs=.3a8214e2-3fbd-4672-b9a9-e37c69638c48@github.com>

On Mon, 6 Sep 2021 11:03:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8188764 removed many uses of `os::is_MP`, effectively defaulting it to `true`, but some Shenandoah code still has it. This is a simple omission. All current uses on x86 already imply lock prefix, so this is a cleanup, and not a functional change.
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`

This pull request has now been integrated.

Changeset: fc546d6d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fc546d6de9a3ed33cf4b04e24e62714332b069cb
Stats:     9 lines in 1 file changed: 6 ins; 3 del; 0 mod

8273378: Shenandoah: Remove the remaining uses of os::is_MP

Reviewed-by: aph, zgu

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

PR: https://git.openjdk.java.net/jdk/pull/5378

From github.com+39413832+weixlu at openjdk.java.net  Tue Sep  7 06:20:39 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Tue, 7 Sep 2021 06:20:39 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
 <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
Message-ID: <_cmSjYRldX4qwVo8b-esOjzfMwiW9fLR1l6Zr9-7eEc=.b220343c-cfc8-49d0-98fc-1dde5dc25c08@github.com>

On Tue, 31 Aug 2021 13:24:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add TODO
>
> More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.

@shipilev Hi, I have tested this pull request as well as this pull request + `OrderAccess::release();` on specjbb 2015 on AArch64 (Kunpeng 920). Maybe there is a slight improvement on critical-jOPS? Here is the result.

numactl --cpubind=1 --membind=1 ${build}/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -Xmx100g  -Xms75g -Xlog:gc*:gclog_${build}_${i} -jar specjbb2015.jar -m COMPOSITE

base_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 28797, critical-jOPS = 21801
base_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 30168, critical-jOPS = 21513
base_3:RUN RESULT: hbIR (max attempted) = 41119, hbIR (settled) = 34282, max-jOPS = 28783, critical-jOPS = 21516
OrderAccess_release_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29483, critical-jOPS = 21979
OrderAccess_release_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29483, critical-jOPS = 22096
OrderAccess_release_3:RUN RESULT: hbIR (max attempted) = 41119, hbIR (settled) = 34282, max-jOPS = 30017, critical-jOPS = 22929

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

PR: https://git.openjdk.java.net/jdk/pull/2496

From shade at openjdk.java.net  Tue Sep  7 08:36:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 08:36:41 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
 <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
Message-ID: <uCo4Uu-RlYKbnSUXQHzMT8Nb2tIkuALPtQCFhAfn6_c=.5e6e1ebc-43f7-4972-9cbb-907f3299a372@github.com>

On Tue, 31 Aug 2021 13:24:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add TODO
>
> More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.

> @shipilev Hi, I have tested this pull request as well as this pull request + `OrderAccess::release();` on specjbb 2015 on AArch64 (Kunpeng 920). Maybe there is a slight improvement on critical-jOPS? Here is the result.

Thanks for testing. So explicit barrier does seem to result in a slight bump in critical-jOPS.

I assume "base" results are this PR? If so, do you have performance results for the current master? In other words, it would be interesting to see three results: baseline (current master), this PR, and this PR + `OrderAccess::release()`.

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

PR: https://git.openjdk.java.net/jdk/pull/2496

From wkemper at openjdk.java.net  Wed Sep  8 19:00:59 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 8 Sep 2021 19:00:59 GMT
Subject: RFR: Enable remembered set verification during global collections
Message-ID: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>

There are two sets of changes here:
 * Fixes to the verifier itself to enable remembered set verification during global collection
 * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection

These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.

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

Commit messages:
 - Merge branch 'earthling-master' into verify-rset-during-global-gc
 - Merge branch 'shenandoah' into verify-rset-during-global-gc
 - Coalesce and fill old objects after final mark in a global collect
 - Only verify first object on next card when last object spans cards
 - Fix infinite loop scenario and invalid limit in verifier
 - Use safe offset when card runs past region top
 - Also use mark context when verifying rset at init mark for global collects
 - Do not read past top of region when looking for last object in card
 - Restore temporary register
 - Preserve and restore original element count for card table barrier
 - ... and 3 more: https://git.openjdk.java.net/shenandoah/compare/f01e568c...d75a315d

Changes: https://git.openjdk.java.net/shenandoah/pull/64/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=64&range=00
  Stats: 132 lines in 8 files changed: 65 ins; 32 del; 35 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/64.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/64/head:pull/64

PR: https://git.openjdk.java.net/shenandoah/pull/64

From kdnilsen at openjdk.java.net  Wed Sep  8 21:45:48 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 8 Sep 2021 21:45:48 GMT
Subject: RFR: Enable remembered set verification during global collections
In-Reply-To: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
Message-ID: <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>

On Wed, 8 Sep 2021 18:55:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are two sets of changes here:
>  * Fixes to the verifier itself to enable remembered set verification during global collection
>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
> 
> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.

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

> 1042: void ShenandoahConcurrentGC::op_global_coalesce_and_fill() {
> 1043:   ShenandoahHeap* const heap = ShenandoahHeap::heap();
> 1044:   ShenandoahGlobalCoalesceAndFill coalesce;

It looks like this is iterating over all old regions.  Not clear to me how we avoid coalescing and filling the regions that are part of the collection set.   I think our intent was to not coalesce-and-fill regions in the collection set.

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

> 2200:         } else if (r->affiliation() == ShenandoahRegionAffiliation::OLD_GENERATION) {
> 2201:           if (_heap->active_generation()->generation_mode() == GLOBAL) {
> 2202:             _heap->marked_object_oop_iterate(r, &cl, update_watermark);

In the original code, we used the same iterator over marked objects for both coalescing and filling and for updating references.  That is "more efficient" than this new approach in that we make one pass instead of two over all objects in all heap regions.  I understand that there was a bug in how that is implemented, apparently, because this new version of the code has fewer crashes than the original.  Nevertheless, would like to have a comment here that suggests we might explore a way to consolidate the efforts at some future time, especially if we detect performance regressions with this new approach.

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

> 2637:         while (obj_addr < t) {
> 2638:           oop obj = oop(obj_addr);
> 2639:           // ctx->is_marked() returns true if mark bit set or if obj above TAMS.

The reason original comment said "TAMS not relevant here" is because this verification occurs at init_mark.  There have been no allocations above TAMS at this execution point.  (Or if there is, maybe add a comment to explain how that comes to be.)

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

> 2655:             HeapWord* tams = ctx->top_at_mark_start(r);
> 2656:             if (obj_addr >= tams) {
> 2657:               obj_addr += obj->size();

Were you actually seeing obj_addr >= tams here?  I'd be inclined to replace your new code with an assert(obj_addr < tams).  Or provide comments to explain.

src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 293:

> 291:         // ShenandoahHeapRegion::global_oop_iterate_and_fill_dead.  We could either mark all live memory as dirty, or could
> 292:         // use the GLOBAL update-refs scanning of pointers to determine precisely which cards to flag as dirty.
> 293:         if (GENERATION == YOUNG && heap->is_in_old(p)) {

I think I had added the heap->is_in(p) test because some program was sending in a non-heap value which was causing an assertion failure in is_in_old(p) during DEBUG builds (that have assertions enabled).  Maybe need to test this patch with FAST_DEBUG just to be sure we're ok with code as now written.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 956:

> 954: 
> 955:   // Return true iff this object is "properly" registered.
> 956:   bool verify_registration(HeapWord* address, ShenandoahMarkingContext* ctx);

There's some trickery with the value of the ctx argument that should probably be described in the API comment.  In particular, ctx is non-null iff the the marking context is "valid" for the purposes of finding live objects within old-gen memory.  It is not valid if we are doing a young collection while old-gen is concurrently marking.  When ctx is NULL, it is required that the old-gen memory has been coalesced and filled.  During mixed evacuations, we rely upon ctx within old-gen because we know that a new old-gen concurrent mark cannot begin until the previously selected evacuation candidates have all been collected.  We don't bother to coalesce-and-fill the collection candidates, but they may be scanned multiple times by young-gen (mixed) remembered set scanning while we are waiting for these candidate regions to be collected.  It's not clear to me that this patch honors all of these behaviors.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 547:

> 545:     }
> 546:   } else {
> 547:     // This is a mixed evacuation: rely on mark bits to identify which objects need to be properly registered

Maybe this comment is too restrictive.  I think the new idea is that we use ctx != nullptr for both mixed evac and for GLOBAL collections.  Am I right about this?

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 555:

> 553:       oop obj = cast_to_oop(base_addr + offset);
> 554:       ShenandoahHeapRegion* region = heap->heap_region_containing(obj);
> 555:       HeapWord* tams = ctx->top_at_mark_start(region);

Think you can move both these lines outside the loop, because we're not crossing region boundaries here.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From kdnilsen at openjdk.java.net  Wed Sep  8 21:45:50 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 8 Sep 2021 21:45:50 GMT
Subject: RFR: Enable remembered set verification during global collections
In-Reply-To: <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
Message-ID: <tqGiyqYY7EshpRfXRUgxIDN-63DuwpkLlHgj4r2NkCQ=.7b6140a4-1e3a-4bc1-a710-443267bead54@github.com>

On Wed, 8 Sep 2021 20:55:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> There are two sets of changes here:
>>  * Fixes to the verifier itself to enable remembered set verification during global collection
>>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
>> 
>> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2657:
> 
>> 2655:             HeapWord* tams = ctx->top_at_mark_start(r);
>> 2656:             if (obj_addr >= tams) {
>> 2657:               obj_addr += obj->size();
> 
> Were you actually seeing obj_addr >= tams here?  I'd be inclined to replace your new code with an assert(obj_addr < tams).  Or provide comments to explain.

If we verify remset while old marking is "ongoing", ctx is not "reliable".  In that case, I had been arranging for ctx to equal NULL with the understanding that obj->size() would get me to the next (possibly coalesced and filled) object within old-gen.  I don't yet follow the logic for how you can always rely on ctx being not NULL here.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Wed Sep  8 22:00:21 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 8 Sep 2021 22:00:21 GMT
Subject: RFR: Enable remembered set verification during global collections
In-Reply-To: <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
Message-ID: <WXFNjb5etct6tsZ935zg_GACpS8mVpG3vdOVMWBFgO4=.c5bbfb98-3ab1-47ae-b050-180dfce2b108@github.com>

On Wed, 8 Sep 2021 20:36:05 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> There are two sets of changes here:
>>  * Fixes to the verifier itself to enable remembered set verification during global collection
>>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
>> 
>> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1044:
> 
>> 1042: void ShenandoahConcurrentGC::op_global_coalesce_and_fill() {
>> 1043:   ShenandoahHeap* const heap = ShenandoahHeap::heap();
>> 1044:   ShenandoahGlobalCoalesceAndFill coalesce;
> 
> It looks like this is iterating over all old regions.  Not clear to me how we avoid coalescing and filling the regions that are part of the collection set.   I think our intent was to not coalesce-and-fill regions in the collection set.

The `ShenandoahGlobalCoalesceAndFill` closure only acts on old active, non-humongous regions.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Wed Sep  8 22:04:41 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 8 Sep 2021 22:04:41 GMT
Subject: RFR: Enable remembered set verification during global collections
In-Reply-To: <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
Message-ID: <UCyJG0NOD-ArmW29QAdAGv9X_OrnXgCYrE6w4GO3jrM=.409f0f00-d8e2-4b3b-9683-123f700454f0@github.com>

On Wed, 8 Sep 2021 20:50:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> There are two sets of changes here:
>>  * Fixes to the verifier itself to enable remembered set verification during global collection
>>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
>> 
>> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2202:
> 
>> 2200:         } else if (r->affiliation() == ShenandoahRegionAffiliation::OLD_GENERATION) {
>> 2201:           if (_heap->active_generation()->generation_mode() == GLOBAL) {
>> 2202:             _heap->marked_object_oop_iterate(r, &cl, update_watermark);
> 
> In the original code, we used the same iterator over marked objects for both coalescing and filling and for updating references.  That is "more efficient" than this new approach in that we make one pass instead of two over all objects in all heap regions.  I understand that there was a bug in how that is implemented, apparently, because this new version of the code has fewer crashes than the original.  Nevertheless, would like to have a comment here that suggests we might explore a way to consolidate the efforts at some future time, especially if we detect performance regressions with this new approach.

I'll try putting the 'fill-after-final-mark' on the code path that skips updates references and restoring this code. That way, we'll do one or the other, but not both.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2639:
> 
>> 2637:         while (obj_addr < t) {
>> 2638:           oop obj = oop(obj_addr);
>> 2639:           // ctx->is_marked() returns true if mark bit set or if obj above TAMS.
> 
> The reason original comment said "TAMS not relevant here" is because this verification occurs at init_mark.  There have been no allocations above TAMS at this execution point.  (Or if there is, maybe add a comment to explain how that comes to be.)

Will restore original comment.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Wed Sep  8 22:15:25 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 8 Sep 2021 22:15:25 GMT
Subject: RFR: Enable remembered set verification during global collections
In-Reply-To: <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
Message-ID: <dz2oCrojZCKlBd2io66Gl3xbGo1eRega_Oe12XuKaAU=.24bce378-1591-4811-a52d-3e17172c71b2@github.com>

On Wed, 8 Sep 2021 21:08:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> There are two sets of changes here:
>>  * Fixes to the verifier itself to enable remembered set verification during global collection
>>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
>> 
>> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.
>
> src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 293:
> 
>> 291:         // ShenandoahHeapRegion::global_oop_iterate_and_fill_dead.  We could either mark all live memory as dirty, or could
>> 292:         // use the GLOBAL update-refs scanning of pointers to determine precisely which cards to flag as dirty.
>> 293:         if (GENERATION == YOUNG && heap->is_in_old(p)) {
> 
> I think I had added the heap->is_in(p) test because some program was sending in a non-heap value which was causing an assertion failure in is_in_old(p) during DEBUG builds (that have assertions enabled).  Maybe need to test this patch with FAST_DEBUG just to be sure we're ok with code as now written.

I changed the implementation of `is_in_old` to first test for `is_in` in an earlier patch.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 956:
> 
>> 954: 
>> 955:   // Return true iff this object is "properly" registered.
>> 956:   bool verify_registration(HeapWord* address, ShenandoahMarkingContext* ctx);
> 
> There's some trickery with the value of the ctx argument that should probably be described in the API comment.  In particular, ctx is non-null iff the the marking context is "valid" for the purposes of finding live objects within old-gen memory.  It is not valid if we are doing a young collection while old-gen is concurrently marking.  When ctx is NULL, it is required that the old-gen memory has been coalesced and filled.  During mixed evacuations, we rely upon ctx within old-gen because we know that a new old-gen concurrent mark cannot begin until the previously selected evacuation candidates have all been collected.  We don't bother to coalesce-and-fill the collection candidates, but they may be scanned multiple times by young-gen (mixed) remembered set scanning while we are waiting for these candidate regions to be collected.  It's not clear to me that this patch honors all of these behaviors.

This method is called from the other rset verify methods (init-mark, update-references, after-full-gc). Here I've just made it take the `ctx` computed in the caller (rather than re-selecting it in the called method). The size parameter was unused.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 547:
> 
>> 545:     }
>> 546:   } else {
>> 547:     // This is a mixed evacuation: rely on mark bits to identify which objects need to be properly registered
> 
> Maybe this comment is too restrictive.  I think the new idea is that we use ctx != nullptr for both mixed evac and for GLOBAL collections.  Am I right about this?

Yes, I'll update the comment to include global collections.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 555:
> 
>> 553:       oop obj = cast_to_oop(base_addr + offset);
>> 554:       ShenandoahHeapRegion* region = heap->heap_region_containing(obj);
>> 555:       HeapWord* tams = ctx->top_at_mark_start(region);
> 
> Think you can move both these lines outside the loop, because we're not crossing region boundaries here.

Okay, wasn't sure if cards would always be aligned with regions.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Wed Sep  8 22:15:23 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 8 Sep 2021 22:15:23 GMT
Subject: RFR: Enable remembered set verification during global collections
In-Reply-To: <tqGiyqYY7EshpRfXRUgxIDN-63DuwpkLlHgj4r2NkCQ=.7b6140a4-1e3a-4bc1-a710-443267bead54@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
 <tqGiyqYY7EshpRfXRUgxIDN-63DuwpkLlHgj4r2NkCQ=.7b6140a4-1e3a-4bc1-a710-443267bead54@github.com>
Message-ID: <to1fazGNus4qy3-SM_MylEPCVinuMeZwJ_CkAPFI0qs=.eeb856c8-26f0-4223-847f-206de5b867b6@github.com>

On Wed, 8 Sep 2021 21:02:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2657:
>> 
>>> 2655:             HeapWord* tams = ctx->top_at_mark_start(r);
>>> 2656:             if (obj_addr >= tams) {
>>> 2657:               obj_addr += obj->size();
>> 
>> Were you actually seeing obj_addr >= tams here?  I'd be inclined to replace your new code with an assert(obj_addr < tams).  Or provide comments to explain.
>
> If we verify remset while old marking is "ongoing", ctx is not "reliable".  In that case, I had been arranging for ctx to equal NULL with the understanding that obj->size() would get me to the next (possibly coalesced and filled) object within old-gen.  I don't yet follow the logic for how you can always rely on ctx being not NULL here.

If `ctx` is NULL, we'll have gone into the other path and used `obj->size()` to advance `obj_addr`. I'll add an assert that `obj_addr` is below TAMS during the init-mark verification.  We only verify the remembered set during a mixed evacuation or global collect (as of this change). In both cases there should be no concurrent marking of old (I'll add an assert for this also).

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Thu Sep  9 00:30:43 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 00:30:43 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v2]
In-Reply-To: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
Message-ID: <z-oqPrQIpeV_DpJpmJnBzlsOpN4m-1HFq3C8jmOOu9I=.3093d20d-f8d5-4d2a-9a9d-ec7ccc578c6d@github.com>

> There are two sets of changes here:
>  * Fixes to the verifier itself to enable remembered set verification during global collection
>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
> 
> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.

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

  Simplify object iteration and respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/64/files
  - new: https://git.openjdk.java.net/shenandoah/pull/64/files/d75a315d..c9c23a44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=64&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=64&range=00-01

  Stats: 38 lines in 2 files changed: 3 ins; 19 del; 16 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/64.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/64/head:pull/64

PR: https://git.openjdk.java.net/shenandoah/pull/64

From pliden at openjdk.java.net  Thu Sep  9 12:15:18 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 12:15:18 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread()
Message-ID: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>

I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.

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

Commit messages:
 - 8273545: Remove Thread::is_GC_task_thread()

Changes: https://git.openjdk.java.net/jdk/pull/5442/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5442&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273545
  Stats: 22 lines in 12 files changed: 0 ins; 16 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5442.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5442/head:pull/5442

PR: https://git.openjdk.java.net/jdk/pull/5442

From stefank at openjdk.java.net  Thu Sep  9 12:25:03 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 9 Sep 2021 12:25:03 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread()
In-Reply-To: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
Message-ID: <YD6XgecYmwTNGX2RleX4iBQC67GnKAYXdRjfLjdHneI=.c79d45e1-5a9e-4e5e-bfd8-478843d6e32d@github.com>

On Thu, 9 Sep 2021 12:07:18 GMT, Per Liden <pliden at openjdk.org> wrote:

> I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.

Looks good

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

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5442

From coleenp at openjdk.java.net  Thu Sep  9 12:36:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 9 Sep 2021 12:36:59 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread()
In-Reply-To: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
Message-ID: <b7mfrLMBNh_ZZdQDz56SkGorsHe8Tu63kqV2ANRkJao=.248b7d0e-602e-484a-901a-d249f35e5f5c@github.com>

On Thu, 9 Sep 2021 12:07:18 GMT, Per Liden <pliden at openjdk.org> wrote:

> I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.

Looks good to me.  So Worker threads could always do operations during a safepoint?  They're NamedThreads so they can run across safepoints?  Thanks.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5442

From pliden at openjdk.java.net  Thu Sep  9 13:19:01 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 13:19:01 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread()
In-Reply-To: <b7mfrLMBNh_ZZdQDz56SkGorsHe8Tu63kqV2ANRkJao=.248b7d0e-602e-484a-901a-d249f35e5f5c@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
 <b7mfrLMBNh_ZZdQDz56SkGorsHe8Tu63kqV2ANRkJao=.248b7d0e-602e-484a-901a-d249f35e5f5c@github.com>
Message-ID: <WldAQ7Cw-9BWfW59p-xjBVkTczDEuoU5hkRuqumP0e8=.d95e12bb-1e97-49c2-8592-b0afe1c430b4@github.com>

On Thu, 9 Sep 2021 12:33:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looks good to me. So Worker threads could always do operations during a safepoint? They're NamedThreads so they can run across safepoints? Thanks.

What a worker thread can and can not do with regards to safepoints depends on the GC, and what WorkGang instance in that GC. In other words, there's no strong connection between the two that is true for all GCs and all WorkGangs.

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

PR: https://git.openjdk.java.net/jdk/pull/5442

From pliden at openjdk.java.net  Thu Sep  9 13:42:29 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 13:42:29 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread() [v2]
In-Reply-To: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
Message-ID: <Fn39Yc1ZfTPP3Gnk2ZkfCDFNBz_a18QcjXbF-GZvsVc=.8e4fde6f-8f3e-4218-b56b-2563115fda3f@github.com>

> I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.

Per Liden has updated the pull request incrementally with one additional commit since the last revision:

  Updated gtests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5442/files
  - new: https://git.openjdk.java.net/jdk/pull/5442/files/ca94d767..0165c4a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5442&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5442&range=00-01

  Stats: 6 lines in 5 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5442.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5442/head:pull/5442

PR: https://git.openjdk.java.net/jdk/pull/5442

From shade at openjdk.java.net  Thu Sep  9 13:52:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 13:52:06 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread() [v2]
In-Reply-To: <Fn39Yc1ZfTPP3Gnk2ZkfCDFNBz_a18QcjXbF-GZvsVc=.8e4fde6f-8f3e-4218-b56b-2563115fda3f@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
 <Fn39Yc1ZfTPP3Gnk2ZkfCDFNBz_a18QcjXbF-GZvsVc=.8e4fde6f-8f3e-4218-b56b-2563115fda3f@github.com>
Message-ID: <iUbrwfbEW22ofRMgK-9btQe4tjZS3ok2EFcU-okNiVY=.87c39542-01d9-41b0-b2b8-7fa815628d16@github.com>

On Thu, 9 Sep 2021 13:42:29 GMT, Per Liden <pliden at openjdk.org> wrote:

>> I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated gtests

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5442

From shade at openjdk.java.net  Thu Sep  9 15:36:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 15:36:56 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <wDnapzeNsWQFDBWwwyl5fncAlOOgXD2bGDTR1xqPGuc=.63d2878c-fa2f-4eae-bbb8-3ffe6c1f2d40@github.com>
References: <wDnapzeNsWQFDBWwwyl5fncAlOOgXD2bGDTR1xqPGuc=.63d2878c-fa2f-4eae-bbb8-3ffe6c1f2d40@github.com>
Message-ID: <Y-mK_LWgr_GpDiFEaOi_zi9JTM42jSKLkqfoCtwC8AI=.8fa2183a-1a47-4983-bbb9-a1493aa42e2c@github.com>

On Wed, 8 Sep 2021 21:31:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a great big merge from upstream openjdk. No conflicts outside of `gc/shenandoah`. Most of the conflicts were around the closures that had a class template parameter for string duplication changes (we've added a template parameter for generation to most of the same).

All right. YOLO! Please integrate.

jcheck complains about the whitespace, need to fix that before integration.

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

Marked as reviewed by shade (Committer).

PR: https://git.openjdk.java.net/shenandoah/pull/65

From wkemper at openjdk.java.net  Thu Sep  9 15:36:55 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 15:36:55 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <wDnapzeNsWQFDBWwwyl5fncAlOOgXD2bGDTR1xqPGuc=.63d2878c-fa2f-4eae-bbb8-3ffe6c1f2d40@github.com>

This is a great big merge from upstream openjdk. No conflicts outside of `gc/shenandoah`. Most of the conflicts were around the closures that had a class template parameter for string duplication changes (we've added a template parameter for generation to most of the same).

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

Commit messages:
 - Remove extraneous whitespace
 - Merge branch 'shenandoah' into incremental-upstream-merge
 - Fix misuse of atomic flag
 - Fix ShenandoahFullGC worker stats handling
 - Merge branch 'openjdk-master' into incremental-upstream-merge
 - Merge branch 'openjdk-master' into incremental-upstream-merge
 - Fix naked cast to opp
 - Merge branch 'shenandoah' into incremental-upstream-merge
 - Add generational full gc support
 - Fix misuse of atomic variables
 - ... and 100 more: https://git.openjdk.java.net/shenandoah/compare/df05b4d1...47583456

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

Changes: https://git.openjdk.java.net/shenandoah/pull/65/files
  Stats: 11334 lines in 132 files changed: 10342 ins; 419 del; 573 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/65.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/65/head:pull/65

PR: https://git.openjdk.java.net/shenandoah/pull/65

From wkemper at openjdk.java.net  Thu Sep  9 15:39:11 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 15:39:11 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <wDnapzeNsWQFDBWwwyl5fncAlOOgXD2bGDTR1xqPGuc=.63d2878c-fa2f-4eae-bbb8-3ffe6c1f2d40@github.com>
References: <wDnapzeNsWQFDBWwwyl5fncAlOOgXD2bGDTR1xqPGuc=.63d2878c-fa2f-4eae-bbb8-3ffe6c1f2d40@github.com>
Message-ID: <rXW9i39obh0aWvClPIZGKAzWq4yDyWImfBSEqNKVSsY=.22f1091f-5879-4452-bf2b-98d4e4a6e902@github.com>

On Wed, 8 Sep 2021 21:31:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a great big merge from upstream openjdk. No conflicts outside of `gc/shenandoah`. Most of the conflicts were around the closures that had a class template parameter for string duplication changes (we've added a template parameter for generation to most of the same).

This pull request has now been integrated.

Changeset: ad15b6b5
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/ad15b6b5b69d688d36105aec54e88e888e493547
Stats:     1512334 lines in 15857 files changed: 780720 ins; 667300 del; 64314 mod

Merge openjdk/jdk:master

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/shenandoah/pull/65

From wkemper at openjdk.java.net  Thu Sep  9 17:29:49 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 17:29:49 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v3]
In-Reply-To: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
Message-ID: <qSkdCYQfcvIhNjmt5wDY0GP2RaDwMVFobhY95nEDXtk=.d5840820-1eb9-4cc6-809f-226a4c4ec546@github.com>

> There are two sets of changes here:
>  * Fixes to the verifier itself to enable remembered set verification during global collection
>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
> 
> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.

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

 - Merge branch 'shenandoah' into verify-rset-during-global-gc
 - Simplify object iteration and respond to review feedback.
 - Merge branch 'earthling-master' into verify-rset-during-global-gc
 - Merge branch 'shenandoah' into verify-rset-during-global-gc
 - Coalesce and fill old objects after final mark in a global collect
 - Only verify first object on next card when last object spans cards
 - Fix infinite loop scenario and invalid limit in verifier
 - Use safe offset when card runs past region top
 - Also use mark context when verifying rset at init mark for global collects
 - Do not read past top of region when looking for last object in card
 - ... and 5 more: https://git.openjdk.java.net/shenandoah/compare/ad15b6b5...7136de8c

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

Changes: https://git.openjdk.java.net/shenandoah/pull/64/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=64&range=02
  Stats: 143 lines in 8 files changed: 60 ins; 44 del; 39 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/64.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/64/head:pull/64

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Thu Sep  9 17:45:06 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 17:45:06 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v3]
In-Reply-To: <UCyJG0NOD-ArmW29QAdAGv9X_OrnXgCYrE6w4GO3jrM=.409f0f00-d8e2-4b3b-9683-123f700454f0@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
 <UCyJG0NOD-ArmW29QAdAGv9X_OrnXgCYrE6w4GO3jrM=.409f0f00-d8e2-4b3b-9683-123f700454f0@github.com>
Message-ID: <-OLNBdESQV2e6X1U6artfeNVjWgLepCuqY_43cnwhRw=.ab3181e5-60d6-429f-9019-68d539e996f1@github.com>

On Wed, 8 Sep 2021 22:00:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2202:
>> 
>>> 2200:         } else if (r->affiliation() == ShenandoahRegionAffiliation::OLD_GENERATION) {
>>> 2201:           if (_heap->active_generation()->generation_mode() == GLOBAL) {
>>> 2202:             _heap->marked_object_oop_iterate(r, &cl, update_watermark);
>> 
>> In the original code, we used the same iterator over marked objects for both coalescing and filling and for updating references.  That is "more efficient" than this new approach in that we make one pass instead of two over all objects in all heap regions.  I understand that there was a bug in how that is implemented, apparently, because this new version of the code has fewer crashes than the original.  Nevertheless, would like to have a comment here that suggests we might explore a way to consolidate the efforts at some future time, especially if we detect performance regressions with this new approach.
>
> I'll try putting the 'fill-after-final-mark' on the code path that skips updates references and restoring this code. That way, we'll do one or the other, but not both.

After thinking about this, I'd rather do it on a separate PR. We'd still want to fill before update references when `ShenandoahVerify` is enabled.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Thu Sep  9 17:45:07 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 17:45:07 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v3]
In-Reply-To: <to1fazGNus4qy3-SM_MylEPCVinuMeZwJ_CkAPFI0qs=.eeb856c8-26f0-4223-847f-206de5b867b6@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
 <tqGiyqYY7EshpRfXRUgxIDN-63DuwpkLlHgj4r2NkCQ=.7b6140a4-1e3a-4bc1-a710-443267bead54@github.com>
 <to1fazGNus4qy3-SM_MylEPCVinuMeZwJ_CkAPFI0qs=.eeb856c8-26f0-4223-847f-206de5b867b6@github.com>
Message-ID: <CvUrOvaur5qGjhaSaGxmRAX1epBmQB7vNtlc3TKXCYI=.92eac023-e46e-416a-b350-9dce7ff7f374@github.com>

On Wed, 8 Sep 2021 22:05:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> If we verify remset while old marking is "ongoing", ctx is not "reliable".  In that case, I had been arranging for ctx to equal NULL with the understanding that obj->size() would get me to the next (possibly coalesced and filled) object within old-gen.  I don't yet follow the logic for how you can always rely on ctx being not NULL here.
>
> If `ctx` is NULL, we'll have gone into the other path and used `obj->size()` to advance `obj_addr`. I'll add an assert that `obj_addr` is below TAMS during the init-mark verification.  We only verify the remembered set during a mixed evacuation or global collect (as of this change). In both cases there should be no concurrent marking of old (I'll add an assert for this also).

I was able to simplify this (and similar code in a few other places) because we've previously checked if the object is marked (which would return true for an object above TAMS).

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From pliden at openjdk.java.net  Thu Sep  9 19:23:11 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 19:23:11 GMT
Subject: Integrated: 8273545: Remove Thread::is_GC_task_thread()
In-Reply-To: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
Message-ID: <uHxu_9EuT1cCPsEJLa-m0Uf0JIq5eEaV0gWjsMTBWF0=.00cc03b1-a6f9-4f01-9f31-7bfb9e87c120@github.com>

On Thu, 9 Sep 2021 12:07:18 GMT, Per Liden <pliden at openjdk.org> wrote:

> I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.

This pull request has now been integrated.

Changeset: 185eacac
Author:    Per Liden <pliden at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/185eacacdde9de12936520a1cda847f7e541c62f
Stats:     28 lines in 17 files changed: 0 ins; 18 del; 10 mod

8273545: Remove Thread::is_GC_task_thread()

Reviewed-by: stefank, coleenp, shade

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

PR: https://git.openjdk.java.net/jdk/pull/5442

From pliden at openjdk.java.net  Thu Sep  9 19:23:10 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 19:23:10 GMT
Subject: RFR: 8273545: Remove Thread::is_GC_task_thread() [v2]
In-Reply-To: <Fn39Yc1ZfTPP3Gnk2ZkfCDFNBz_a18QcjXbF-GZvsVc=.8e4fde6f-8f3e-4218-b56b-2563115fda3f@github.com>
References: <AFppTSTOBnpt2DiU7WriuMWDy6l7iG9qFqSorV2JwrM=.7836bb84-95a2-4b19-86eb-b868f6c74f42@github.com>
 <Fn39Yc1ZfTPP3Gnk2ZkfCDFNBz_a18QcjXbF-GZvsVc=.8e4fde6f-8f3e-4218-b56b-2563115fda3f@github.com>
Message-ID: <QvHl25CbTIIMKbiEjQ9y7zi8c1swkxVzFn_SSwb809s=.cc0c4406-ce88-4fc0-b710-faff095f9ce8@github.com>

On Thu, 9 Sep 2021 13:42:29 GMT, Per Liden <pliden at openjdk.org> wrote:

>> I propose we remove Thread::is_GC_task_thread(). It's used only in two places (one in ZGC, and one assert in ParallelGC), and those two uses can be replaced by calls to is_Worker_thread() instead. Removing is_GC_task_thread() also allows us to clean out some stuff from WorkGang/GangWorker.
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated gtests

Thanks all for reviewing!

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

PR: https://git.openjdk.java.net/jdk/pull/5442

From kdnilsen at openjdk.java.net  Thu Sep  9 20:30:48 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 9 Sep 2021 20:30:48 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v3]
In-Reply-To: <-OLNBdESQV2e6X1U6artfeNVjWgLepCuqY_43cnwhRw=.ab3181e5-60d6-429f-9019-68d539e996f1@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <J0EB9map9DwiPI6I7YoLnx4KFHX_HUV9ZBBWdvwSoTA=.49adc71a-ec3b-427b-b592-a806fca35f73@github.com>
 <UCyJG0NOD-ArmW29QAdAGv9X_OrnXgCYrE6w4GO3jrM=.409f0f00-d8e2-4b3b-9683-123f700454f0@github.com>
 <-OLNBdESQV2e6X1U6artfeNVjWgLepCuqY_43cnwhRw=.ab3181e5-60d6-429f-9019-68d539e996f1@github.com>
Message-ID: <wkdZR3ibrFQP1f481VY3ffPfPobyZR0E9yZYpZnc8jI=.24af3edd-9adb-4859-847c-204fa8262580@github.com>

On Thu, 9 Sep 2021 17:41:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I'll try putting the 'fill-after-final-mark' on the code path that skips updates references and restoring this code. That way, we'll do one or the other, but not both.
>
> After thinking about this, I'd rather do it on a separate PR. We'd still want to fill before update references when `ShenandoahVerify` is enabled.

Thanks.  This sounds good.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From kdnilsen at openjdk.java.net  Thu Sep  9 20:34:43 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 9 Sep 2021 20:34:43 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v3]
In-Reply-To: <qSkdCYQfcvIhNjmt5wDY0GP2RaDwMVFobhY95nEDXtk=.d5840820-1eb9-4cc6-809f-226a4c4ec546@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <qSkdCYQfcvIhNjmt5wDY0GP2RaDwMVFobhY95nEDXtk=.d5840820-1eb9-4cc6-809f-226a4c4ec546@github.com>
Message-ID: <qj4G-tLUBtqs58FgUrmb-o-4SAeAkOvCJPwsFO51i1Y=.5b8907d5-8086-4570-98bd-dc745a0b23d0@github.com>

On Thu, 9 Sep 2021 17:29:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are two sets of changes here:
>>  * Fixes to the verifier itself to enable remembered set verification during global collection
>>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
>> 
>> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'shenandoah' into verify-rset-during-global-gc
>  - Simplify object iteration and respond to review feedback.
>  - Merge branch 'earthling-master' into verify-rset-during-global-gc
>  - Merge branch 'shenandoah' into verify-rset-during-global-gc
>  - Coalesce and fill old objects after final mark in a global collect
>  - Only verify first object on next card when last object spans cards
>  - Fix infinite loop scenario and invalid limit in verifier
>  - Use safe offset when card runs past region top
>  - Also use mark context when verifying rset at init mark for global collects
>  - Do not read past top of region when looking for last object in card
>  - ... and 5 more: https://git.openjdk.java.net/shenandoah/compare/ad15b6b5...7136de8c

Marked as reviewed by kdnilsen (Committer).

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

> 2643:             obj_addr += obj->size();
> 2644:           } else {
> 2645:             // This object is not live so we don'top verify dirty cards contained therein

typo here in the comment.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Thu Sep  9 21:12:58 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 21:12:58 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v4]
In-Reply-To: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
Message-ID: <-q5WLuSxc0DSeAH4yxcxsoKpJnYr5J4yojkfGqSs14M=.4f29e963-88f7-4d62-8ef1-269339e80a6f@github.com>

> There are two sets of changes here:
>  * Fixes to the verifier itself to enable remembered set verification during global collection
>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
> 
> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.

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

  Fix typo in comment

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/64/files
  - new: https://git.openjdk.java.net/shenandoah/pull/64/files/7136de8c..6e8b7922

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=64&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=64&range=02-03

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Thu Sep  9 21:13:11 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 21:13:11 GMT
Subject: RFR: Enable remembered set verification during global collections
 [v3]
In-Reply-To: <qj4G-tLUBtqs58FgUrmb-o-4SAeAkOvCJPwsFO51i1Y=.5b8907d5-8086-4570-98bd-dc745a0b23d0@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
 <qSkdCYQfcvIhNjmt5wDY0GP2RaDwMVFobhY95nEDXtk=.d5840820-1eb9-4cc6-809f-226a4c4ec546@github.com>
 <qj4G-tLUBtqs58FgUrmb-o-4SAeAkOvCJPwsFO51i1Y=.5b8907d5-8086-4570-98bd-dc745a0b23d0@github.com>
Message-ID: <G4HQAaklex5cLRR7NN33ONvFibjyo_LRATMv9SjgW-I=.abcaa35a-d027-4928-9341-d982595189df@github.com>

On Thu, 9 Sep 2021 20:28:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'shenandoah' into verify-rset-during-global-gc
>>  - Simplify object iteration and respond to review feedback.
>>  - Merge branch 'earthling-master' into verify-rset-during-global-gc
>>  - Merge branch 'shenandoah' into verify-rset-during-global-gc
>>  - Coalesce and fill old objects after final mark in a global collect
>>  - Only verify first object on next card when last object spans cards
>>  - Fix infinite loop scenario and invalid limit in verifier
>>  - Use safe offset when card runs past region top
>>  - Also use mark context when verifying rset at init mark for global collects
>>  - Do not read past top of region when looking for last object in card
>>  - ... and 5 more: https://git.openjdk.java.net/shenandoah/compare/ad15b6b5...7136de8c
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2645:
> 
>> 2643:             obj_addr += obj->size();
>> 2644:           } else {
>> 2645:             // This object is not live so we don'top verify dirty cards contained therein
> 
> typo here in the comment.

Fixed, thanks.

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From wkemper at openjdk.java.net  Thu Sep  9 21:17:28 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Sep 2021 21:17:28 GMT
Subject: Integrated: Enable remembered set verification during global
 collections
In-Reply-To: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
References: <uniCZT-Xf6OzbCDCx0tKWvl7n2jqlAJY8MbEMdM1OmM=.8577c9d0-ea5e-47ff-ac28-553da86c952b@github.com>
Message-ID: <_WnoIkhUwMzioEwkbXkuK5yf2Mo4w7xr6LqvNdutPq4=.eec54b3c-6bdd-488b-bb37-11e678d6da33@github.com>

On Wed, 8 Sep 2021 18:55:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are two sets of changes here:
>  * Fixes to the verifier itself to enable remembered set verification during global collection
>  * Fixes to prevent the remembered set scan from parsing unmarked objects after a global collection
> 
> These changes pass the dacapo suite with `-XX:+ShenandoahVerify` and pass the shenandoah tier1 tests.

This pull request has now been integrated.

Changeset: aa7ff7c1
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/aa7ff7c1102a1813486e74091f126f4eee103679
Stats:     143 lines in 8 files changed: 60 ins; 44 del; 39 mod

Enable remembered set verification during global collections

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/64

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep 10 02:33:03 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 10 Sep 2021 02:33:03 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <uCo4Uu-RlYKbnSUXQHzMT8Nb2tIkuALPtQCFhAfn6_c=.5e6e1ebc-43f7-4972-9cbb-907f3299a372@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
 <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
 <uCo4Uu-RlYKbnSUXQHzMT8Nb2tIkuALPtQCFhAfn6_c=.5e6e1ebc-43f7-4972-9cbb-907f3299a372@github.com>
Message-ID: <nykRAo-vua9e7-u5zWfy7WVb1th3UWCfxT2KOJPs-4c=.87b09244-7dd2-4095-86ca-6ae5487a8bac@github.com>

On Tue, 7 Sep 2021 08:33:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.
>
>> @shipilev Hi, I have tested this pull request as well as this pull request + `OrderAccess::release();` on specjbb 2015 on AArch64 (Kunpeng 920). Maybe there is a slight improvement on critical-jOPS? Here is the result.
> 
> Thanks for testing. So explicit barrier does seem to result in a slight bump in critical-jOPS.
> 
> I assume "base" results are this PR? If so, do you have performance results for the current master? In other words, it would be interesting to see three results: baseline (current master), this PR, and this PR + `OrderAccess::release()`.

@shipilev Yes, ?base? means this PR in my previous comment. Here is the result of the current master(i.e. revert all commits in this PR). It seems master performs better, so the cost of ?acquire? may be really high as you have said.

master_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 23053
master_2:RUN RESULT: hbIR (max attempted) = 41119, hbIR (settled) = 34282, max-jOPS = 30017, critical-jOPS = 23092
master_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22383

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

PR: https://git.openjdk.java.net/jdk/pull/2496

From shade at openjdk.java.net  Fri Sep 10 07:44:58 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Sep 2021 07:44:58 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <uCo4Uu-RlYKbnSUXQHzMT8Nb2tIkuALPtQCFhAfn6_c=.5e6e1ebc-43f7-4972-9cbb-907f3299a372@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
 <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
 <uCo4Uu-RlYKbnSUXQHzMT8Nb2tIkuALPtQCFhAfn6_c=.5e6e1ebc-43f7-4972-9cbb-907f3299a372@github.com>
Message-ID: <bN29__wPY1ryV8d9uuuOXhcyBmntQkDIAUoX3S7sRiI=.b6b8a9bc-7075-4469-99eb-195e67a2feb3@github.com>

On Tue, 7 Sep 2021 08:33:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.
>
>> @shipilev Hi, I have tested this pull request as well as this pull request + `OrderAccess::release();` on specjbb 2015 on AArch64 (Kunpeng 920). Maybe there is a slight improvement on critical-jOPS? Here is the result.
> 
> Thanks for testing. So explicit barrier does seem to result in a slight bump in critical-jOPS.
> 
> I assume "base" results are this PR? If so, do you have performance results for the current master? In other words, it would be interesting to see three results: baseline (current master), this PR, and this PR + `OrderAccess::release()`.

> @shipilev Yes, ?base? means this PR in my previous comment. Here is the result of the current master(i.e. revert all commits in this PR). It seems master performs better, so the cost of ?acquire? may be really high as you have said.

(sighs) Thanks for testing. Do you have spare cycles to verify that "acquire" is indeed the culprit for this? It would be simple to check: replace all `mark_acquire()` to just `mark()` in this PR. I am somewhat sure that would not break things very much for the test runs.

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

PR: https://git.openjdk.java.net/jdk/pull/2496

From pliden at openjdk.java.net  Fri Sep 10 12:49:17 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 10 Sep 2021 12:49:17 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread()
Message-ID: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>

`Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.

It would be reasonable to think that code like this would be correct:


  if (thread->is_ConcurrentGC_thread()) {
    conc_thread = static_cast<ConcurrentGCThread*>(thread);
    ...
  }


but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.

I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.

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

Commit messages:
 - 8273597: Rectify Thread::is_ConcurrentGC_thread()

Changes: https://git.openjdk.java.net/jdk/pull/5463/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5463&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273597
  Stats: 53 lines in 17 files changed: 6 ins; 26 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5463/head:pull/5463

PR: https://git.openjdk.java.net/jdk/pull/5463

From stefank at openjdk.java.net  Fri Sep 10 13:48:39 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 10 Sep 2021 13:48:39 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread()
In-Reply-To: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
Message-ID: <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>

On Fri, 10 Sep 2021 12:39:14 GMT, Per Liden <pliden at openjdk.org> wrote:

> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
> 
> It would be reasonable to think that code like this would be correct:
> 
> 
>   if (thread->is_ConcurrentGC_thread()) {
>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>     ...
>   }
> 
> 
> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
> 
> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.

Thanks for cleaning this up.

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

> 1561:   DEBUG_ONLY(bool called_by_gc = Universe::heap()->is_gc_active() ||
> 1562:                                  Thread::current()->is_ConcurrentGC_thread() ||
> 1563:                                  Thread::current()->is_Worker_thread();)

Three places use the same condition. Did you consider creating a helper function?

src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 122:

> 120:     _old_pool(NULL),
> 121:     _workers("GC Thread",
> 122:              ParallelGCThreads) { }

Consider moving this up to the line above, like the G1 code.

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

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5463

From coleenp at openjdk.java.net  Fri Sep 10 14:37:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 14:37:59 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread()
In-Reply-To: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
Message-ID: <-e2FC1G1xRjJP9pJtKgQV3AhyIfdrtG72Isk3K-Gnng=.956fb2cc-17be-4292-ba20-6a66881be603@github.com>

On Fri, 10 Sep 2021 12:39:14 GMT, Per Liden <pliden at openjdk.org> wrote:

> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
> 
> It would be reasonable to think that code like this would be correct:
> 
> 
>   if (thread->is_ConcurrentGC_thread()) {
>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>     ...
>   }
> 
> 
> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
> 
> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.

Nice cleanup.  One comment and suggestion.

src/hotspot/share/gc/z/zCollectedHeap.cpp line 84:

> 82:   virtual void do_thread(Thread* thread) {
> 83:     if (thread->is_ConcurrentGC_thread()) {
> 84:       static_cast<ConcurrentGCThread*>(thread)->stop();

Should you have a cast function like JavaThread does  ?
  static JavaThread* cast(Thread* t) {
    assert(t->is_Java_thread(), "incorrect cast to JavaThread");
    return static_cast<JavaThread*>(t);
  }

At one point @dholmes replaced all the thread->as_Java_thread() with JavaThread::cast() so this would be consistent with that and nice.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From coleenp at openjdk.java.net  Fri Sep 10 14:38:00 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 14:38:00 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread()
In-Reply-To: <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>
Message-ID: <zBhsUdUUdhNFEa1KHy-4Xa8QOLWDokNcQKAjSH9s8gI=.844e5627-dd03-4101-8ba3-e3f47c5fb050@github.com>

On Fri, 10 Sep 2021 13:42:27 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
>> 
>> It would be reasonable to think that code like this would be correct:
>> 
>> 
>>   if (thread->is_ConcurrentGC_thread()) {
>>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>>     ...
>>   }
>> 
>> 
>> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
>> 
>> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.
>
> src/hotspot/share/code/nmethod.cpp line 1563:
> 
>> 1561:   DEBUG_ONLY(bool called_by_gc = Universe::heap()->is_gc_active() ||
>> 1562:                                  Thread::current()->is_ConcurrentGC_thread() ||
>> 1563:                                  Thread::current()->is_Worker_thread();)
> 
> Three places use the same condition. Did you consider creating a helper function?

I wonder if adding a helper function would encourage people to think they're the same again.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From coleenp at openjdk.java.net  Fri Sep 10 15:33:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 15:33:07 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint
Message-ID: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>

This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
Tests run tier1-8.

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

Commit messages:
 - 8273300: Check Mutex ranking during a safepoint

Changes: https://git.openjdk.java.net/jdk/pull/5467/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273300
  Stats: 43 lines in 13 files changed: 1 ins; 18 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5467/head:pull/5467

PR: https://git.openjdk.java.net/jdk/pull/5467

From eosterlund at openjdk.java.net  Fri Sep 10 16:23:53 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 10 Sep 2021 16:23:53 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <pzzeCpG58W_rYkiq4Js8H4lYLetQJUe5dQmFfpd8ibs=.645e5fbe-ca75-445e-a73e-c96434e3eb51@github.com>

On Fri, 10 Sep 2021 15:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5467

From wkemper at openjdk.java.net  Fri Sep 10 16:26:32 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 10 Sep 2021 16:26:32 GMT
Subject: RFR: Remove log message that could access an out of bounds region
Message-ID: <oJV1MSK3bpcIoD9JD9F8zig_E3JK_KE_eSHgzDI7k6o=.c94a8fde-440a-44ae-81bb-8d6a726c0eba@github.com>

The message attempts to reference the region containing the top of the plab. When the plab is full and is at the end of the last region in the heap, there will be no containing region. Doesn't seem worth the trouble to special case for a debug message.

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

Commit messages:
 - Remove log message that could access an out of bounds region

Changes: https://git.openjdk.java.net/shenandoah/pull/66/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=66&range=00
  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/66.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/66/head:pull/66

PR: https://git.openjdk.java.net/shenandoah/pull/66

From coleenp at openjdk.java.net  Fri Sep 10 17:06:57 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 17:06:57 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <yuvzql1WqXlJ7HjT5GwHZy6utn8Ul8l5NveTfQf6Vag=.9192f565-3403-4d53-b36b-a4e095dbcff4@github.com>

On Fri, 10 Sep 2021 15:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

Thanks Erik!

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From kdnilsen at openjdk.java.net  Fri Sep 10 17:52:36 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 10 Sep 2021 17:52:36 GMT
Subject: RFR: Remove log message that could access an out of bounds region
In-Reply-To: <oJV1MSK3bpcIoD9JD9F8zig_E3JK_KE_eSHgzDI7k6o=.c94a8fde-440a-44ae-81bb-8d6a726c0eba@github.com>
References: <oJV1MSK3bpcIoD9JD9F8zig_E3JK_KE_eSHgzDI7k6o=.c94a8fde-440a-44ae-81bb-8d6a726c0eba@github.com>
Message-ID: <230zu6GACpNRtAm48sbiXg-sjqIUez7roEsPYVBZOvA=.bd3cf5bc-74a4-4304-8bdb-c214f2f64d2d@github.com>

On Fri, 10 Sep 2021 16:19:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The message attempts to reference the region containing the top of the plab. When the plab is full and is at the end of the last region in the heap, there will be no containing region. Doesn't seem worth the trouble to special case for a debug message.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/66

From zgu at openjdk.java.net  Fri Sep 10 18:26:06 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 10 Sep 2021 18:26:06 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support multi-threaded
 heap dump
Message-ID: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>

At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.

 JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.

Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.

Test:

- [x] hotspot_gc_shenandoah
- [x] tier1 with Shenandoah GC

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

Commit messages:
 - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Changes: https://git.openjdk.java.net/jdk/pull/5473/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5473&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273559
  Stats: 206 lines in 6 files changed: 161 ins; 11 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5473/head:pull/5473

PR: https://git.openjdk.java.net/jdk/pull/5473

From wkemper at openjdk.java.net  Fri Sep 10 18:32:16 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 10 Sep 2021 18:32:16 GMT
Subject: Integrated: Remove log message that could access an out of bounds
 region
In-Reply-To: <oJV1MSK3bpcIoD9JD9F8zig_E3JK_KE_eSHgzDI7k6o=.c94a8fde-440a-44ae-81bb-8d6a726c0eba@github.com>
References: <oJV1MSK3bpcIoD9JD9F8zig_E3JK_KE_eSHgzDI7k6o=.c94a8fde-440a-44ae-81bb-8d6a726c0eba@github.com>
Message-ID: <-r7iM6DrFOVI48H9wdrlDWxjLEydZvPPjW7hdQdDrhQ=.3cd8ad83-205b-4c24-89f9-f4b6d04d0696@github.com>

On Fri, 10 Sep 2021 16:19:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The message attempts to reference the region containing the top of the plab. When the plab is full and is at the end of the last region in the heap, there will be no containing region. Doesn't seem worth the trouble to special case for a debug message.

This pull request has now been integrated.

Changeset: 40174b8f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/40174b8f5be10d991c8e322b2ad38b954f769779
Stats:     6 lines in 1 file changed: 0 ins; 6 del; 0 mod

Remove log message that could access an out of bounds region

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/66

From coleenp at openjdk.java.net  Fri Sep 10 21:15:29 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 21:15:29 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v2]
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <2yiIxm7CaiJf3_wiiYcuQjbRNFauGO0MJoJGUphSmR0=.29fe408e-8707-402f-8e3c-5366aff3a8cc@github.com>

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix Shenandoah mismerge

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5467/files
  - new: https://git.openjdk.java.net/jdk/pull/5467/files/13355972..dcb03c3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From dholmes at openjdk.java.net  Sun Sep 12 22:36:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 12 Sep 2021 22:36:48 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v2]
In-Reply-To: <2yiIxm7CaiJf3_wiiYcuQjbRNFauGO0MJoJGUphSmR0=.29fe408e-8707-402f-8e3c-5366aff3a8cc@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <2yiIxm7CaiJf3_wiiYcuQjbRNFauGO0MJoJGUphSmR0=.29fe408e-8707-402f-8e3c-5366aff3a8cc@github.com>
Message-ID: <0fzRARQKdoAbSLHq_SaKs698DuGgRWMkCUI4omDmurk=.acb1126f-5b41-46ad-a022-74eabffdb71f@github.com>

On Fri, 10 Sep 2021 21:15:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
>> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
>> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
>> Tests run tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Shenandoah mismerge

Hi Coleen,

The core change seems clean and simple, but the fanout of the ranking changes is far less clear and some of this looks like it could/should be separated out - see comments below.

If I see a lock with a rank service-1, then should I infer that lock can be acquired while the service (or notification) lock is held? And that if lock A is service-1 and lock B is service-2, then B can be acquired while holding A?

Thanks,
David

src/hotspot/share/memory/universe.cpp line 125:

> 123: LatestMethodCache* Universe::_do_stack_walk_cache     = NULL;
> 124: 
> 125: bool Universe::_verify_in_progress                    = false;

This cleanup seems completely unrelated to your mutex change and is best left to a separate cleanup RFE.

src/hotspot/share/memory/universe.cpp line 1116:

> 1114:   }
> 1115:   if (should_verify_subset(Verify_CodeCache)) {
> 1116:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);

Is this needed to allow the new rankings to work? And is this enabled by the _verify_in_progress change? If so I'd rather see all of that related stuff changed first in a separate RFE that can easily be independently backported.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From shade at openjdk.java.net  Mon Sep 13 08:58:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 08:58:52 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <4UD4Fgl1VmQ1pG2cL_rOmaO5j163s5LvFilUOIFgaCw=.7d4c1b28-11f1-4dbc-9edc-986085431517@github.com>

On Fri, 10 Sep 2021 18:17:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

Looks fine to me with minor nits.

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp line 124:

> 122: 
> 123: public:
> 124:   ShenandoahClassLoaderDataRoots(ShenandoahPhaseTimings::Phase phase, uint n_workers, bool heapdump);

Can we call the new parameter `heap_iteration`? This would match the `ShenandoahHeapIterationRootScanner` name. I could also imagine that iteration is used for something else than a heap dump (maybe JFR/JVMTI heap walk for profiling/debugging?).

test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java line 156:

> 154:         }
> 155:     }
> 156: }

Newline is missing.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5473

From sgehwolf at openjdk.java.net  Mon Sep 13 10:11:50 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 13 Sep 2021 10:11:50 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <88HP7CdhnW6Bj6pQ2tQ2HnzfxJOm8fIbsZ-IKJLX2Gc=.89170242-6aea-4a36-afc1-d5808027964f@github.com>

On Fri, 10 Sep 2021 18:17:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 263:

> 261:    assert(Thread::current()->is_VM_thread(), "Only by VM thread");
> 262:    // Must use _claim_none to avoid interfering with concurrent CLDG iteration
> 263:    CLDToOopClosure clds(oops, ClassLoaderData::_claim_other);

Nit: Update/remove comment? `Must use _claim_none ...` seems to conflict with code.

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From pliden at openjdk.java.net  Mon Sep 13 12:07:17 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 12:07:17 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
Message-ID: <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>

> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
> 
> It would be reasonable to think that code like this would be correct:
> 
> 
>   if (thread->is_ConcurrentGC_thread()) {
>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>     ...
>   }
> 
> 
> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
> 
> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.

Per Liden has updated the pull request incrementally with two additional commits since the last revision:

 - Fix constructor call
 - Add ConcurrentGCThread::cast()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5463/files
  - new: https://git.openjdk.java.net/jdk/pull/5463/files/91e70702..fd645dd3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5463&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5463&range=00-01

  Stats: 9 lines in 3 files changed: 6 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5463/head:pull/5463

PR: https://git.openjdk.java.net/jdk/pull/5463

From pliden at openjdk.java.net  Mon Sep 13 12:13:48 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 12:13:48 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
Message-ID: <as7YQGvVvpWzDsTCyGdDt_HLKeh8B8m3LxhAv9oHyTU=.0f2c6e89-7daa-4736-9006-171d6b5668eb@github.com>

On Mon, 13 Sep 2021 12:07:17 GMT, Per Liden <pliden at openjdk.org> wrote:

>> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
>> 
>> It would be reasonable to think that code like this would be correct:
>> 
>> 
>>   if (thread->is_ConcurrentGC_thread()) {
>>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>>     ...
>>   }
>> 
>> 
>> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
>> 
>> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.
>
> Per Liden has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix constructor call
>  - Add ConcurrentGCThread::cast()

Updated PR with requested changes.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From pliden at openjdk.java.net  Mon Sep 13 12:13:49 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 12:13:49 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <zBhsUdUUdhNFEa1KHy-4Xa8QOLWDokNcQKAjSH9s8gI=.844e5627-dd03-4101-8ba3-e3f47c5fb050@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>
 <zBhsUdUUdhNFEa1KHy-4Xa8QOLWDokNcQKAjSH9s8gI=.844e5627-dd03-4101-8ba3-e3f47c5fb050@github.com>
Message-ID: <CEwagIGY5oyYLt2Rmsa4Zz3aQDWom-YPCuN5aifTDWQ=.7656a3e5-0cfe-4bc4-97b9-038f324d76fa@github.com>

On Fri, 10 Sep 2021 14:30:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1563:
>> 
>>> 1561:   DEBUG_ONLY(bool called_by_gc = Universe::heap()->is_gc_active() ||
>>> 1562:                                  Thread::current()->is_ConcurrentGC_thread() ||
>>> 1563:                                  Thread::current()->is_Worker_thread();)
>> 
>> Three places use the same condition. Did you consider creating a helper function?
>
> I wonder if adding a helper function would encourage people to think they're the same again.

All three places doesn't quite have identical conditions today. We might want to clean this up, for example, I'd argue that at least one of the asserts could be removed. However, I'm not sure I want to do such a cleanup of a fairly unrelated thing as part of this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From pliden at openjdk.java.net  Mon Sep 13 12:13:51 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 12:13:51 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <-e2FC1G1xRjJP9pJtKgQV3AhyIfdrtG72Isk3K-Gnng=.956fb2cc-17be-4292-ba20-6a66881be603@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <-e2FC1G1xRjJP9pJtKgQV3AhyIfdrtG72Isk3K-Gnng=.956fb2cc-17be-4292-ba20-6a66881be603@github.com>
Message-ID: <uStOjM4Ibxb650PhyUmRb7U8kknAEwahPBT8X6smTNE=.3a2545bb-b90f-4f98-8b24-843a79bfdd03@github.com>

On Fri, 10 Sep 2021 14:34:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Per Liden has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix constructor call
>>  - Add ConcurrentGCThread::cast()
>
> src/hotspot/share/gc/z/zCollectedHeap.cpp line 84:
> 
>> 82:   virtual void do_thread(Thread* thread) {
>> 83:     if (thread->is_ConcurrentGC_thread()) {
>> 84:       static_cast<ConcurrentGCThread*>(thread)->stop();
> 
> Should you have a cast function like JavaThread does  ?
>   static JavaThread* cast(Thread* t) {
>     assert(t->is_Java_thread(), "incorrect cast to JavaThread");
>     return static_cast<JavaThread*>(t);
>   }
> 
> At one point @dholmes replaced all the thread->as_Java_thread() with JavaThread::cast() so this would be consistent with that and nice.

Sounds like a good idea. Added `ConcurrentGCThread::cast()`.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From pliden at openjdk.java.net  Mon Sep 13 12:13:50 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 12:13:50 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>
Message-ID: <48uPaCg9rbZx6L-mZeasYujge4GExezphi6b3adNBfA=.64b0f346-b620-4d1e-b389-f73598e8db23@github.com>

On Fri, 10 Sep 2021 13:43:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Per Liden has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix constructor call
>>  - Add ConcurrentGCThread::cast()
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 122:
> 
>> 120:     _old_pool(NULL),
>> 121:     _workers("GC Thread",
>> 122:              ParallelGCThreads) { }
> 
> Consider moving this up to the line above, like the G1 code.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From stefank at openjdk.java.net  Mon Sep 13 12:24:57 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 13 Sep 2021 12:24:57 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <CEwagIGY5oyYLt2Rmsa4Zz3aQDWom-YPCuN5aifTDWQ=.7656a3e5-0cfe-4bc4-97b9-038f324d76fa@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <ssU6ndYj4wxDIVSIZb2tu8FMda70iBauxc1GXmfMu_0=.ddeff2ba-0a61-4fab-852d-4cf0f6b03447@github.com>
 <zBhsUdUUdhNFEa1KHy-4Xa8QOLWDokNcQKAjSH9s8gI=.844e5627-dd03-4101-8ba3-e3f47c5fb050@github.com>
 <CEwagIGY5oyYLt2Rmsa4Zz3aQDWom-YPCuN5aifTDWQ=.7656a3e5-0cfe-4bc4-97b9-038f324d76fa@github.com>
Message-ID: <5HaunoyVGOx5xjDk1pW5q0SYXGn3cLo7M0QwflA8AiY=.870a709a-181a-4627-91b2-91a75fe3d5c0@github.com>

On Mon, 13 Sep 2021 12:09:15 GMT, Per Liden <pliden at openjdk.org> wrote:

>> I wonder if adding a helper function would encourage people to think they're the same again.
>
> All three places doesn't quite have identical conditions today. We might want to clean this up, for example, I'd argue that at least one of the asserts could be removed. However, I'm not sure I want to do such a cleanup of a fairly unrelated thing as part of this PR.

I agree.  I missed that one of the one of them is_at_safepoint and not is_gc_active.

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From stefank at openjdk.java.net  Mon Sep 13 12:24:57 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 13 Sep 2021 12:24:57 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
Message-ID: <5w9LT70Xgw0fu3bme0Tx4ko3zShJrqT2OQU613E7Ff8=.4b4211fc-7d8b-4b91-b6ed-e24a8e28947f@github.com>

On Mon, 13 Sep 2021 12:07:17 GMT, Per Liden <pliden at openjdk.org> wrote:

>> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
>> 
>> It would be reasonable to think that code like this would be correct:
>> 
>> 
>>   if (thread->is_ConcurrentGC_thread()) {
>>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>>     ...
>>   }
>> 
>> 
>> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
>> 
>> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.
>
> Per Liden has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix constructor call
>  - Add ConcurrentGCThread::cast()

Marked as reviewed by stefank (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From zgu at openjdk.java.net  Mon Sep 13 12:32:15 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:32:15 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v2]
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <-9varZ1RTYOW8rzeK4NGQPGN1AGi1kHpTLLjV9v62o4=.3d64f9b0-51f7-49d6-880c-5327b9320580@github.com>

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Aleksey and Severin's comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5473/files
  - new: https://git.openjdk.java.net/jdk/pull/5473/files/1432e964..31406df7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5473&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5473&range=00-01

  Stats: 12 lines in 5 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5473/head:pull/5473

PR: https://git.openjdk.java.net/jdk/pull/5473

From zgu at openjdk.java.net  Mon Sep 13 12:35:59 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:35:59 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v2]
In-Reply-To: <88HP7CdhnW6Bj6pQ2tQ2HnzfxJOm8fIbsZ-IKJLX2Gc=.89170242-6aea-4a36-afc1-d5808027964f@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <88HP7CdhnW6Bj6pQ2tQ2HnzfxJOm8fIbsZ-IKJLX2Gc=.89170242-6aea-4a36-afc1-d5808027964f@github.com>
Message-ID: <6MGFfCiG43QqTj65MyyCf_HLv2GgjXQYTdI_DPrxoCo=.efe967cd-6591-478d-91da-c7b789a1ea2e@github.com>

On Mon, 13 Sep 2021 10:09:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey and Severin's comments
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 263:
> 
>> 261:    assert(Thread::current()->is_VM_thread(), "Only by VM thread");
>> 262:    // Must use _claim_none to avoid interfering with concurrent CLDG iteration
>> 263:    CLDToOopClosure clds(oops, ClassLoaderData::_claim_other);
> 
> Nit: Update/remove comment? `Must use _claim_none ...` seems to conflict with code.

Fixed. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From coleenp at openjdk.java.net  Mon Sep 13 12:40:51 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 12:40:51 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
Message-ID: <pJbdB0SsvZD1aEloDIRgJQao3EUFLH7VjjhlB-Ga3LQ=.499ac265-617f-49a2-afe5-0d1e5ffc1a0a@github.com>

On Mon, 13 Sep 2021 12:07:17 GMT, Per Liden <pliden at openjdk.org> wrote:

>> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
>> 
>> It would be reasonable to think that code like this would be correct:
>> 
>> 
>>   if (thread->is_ConcurrentGC_thread()) {
>>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>>     ...
>>   }
>> 
>> 
>> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
>> 
>> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.
>
> Per Liden has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix constructor call
>  - Add ConcurrentGCThread::cast()

Looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5463

From zgu at openjdk.java.net  Mon Sep 13 12:42:47 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:42:47 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v2]
In-Reply-To: <4UD4Fgl1VmQ1pG2cL_rOmaO5j163s5LvFilUOIFgaCw=.7d4c1b28-11f1-4dbc-9edc-986085431517@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <4UD4Fgl1VmQ1pG2cL_rOmaO5j163s5LvFilUOIFgaCw=.7d4c1b28-11f1-4dbc-9edc-986085431517@github.com>
Message-ID: <wNbo_5_smfdypq390vZ8rLuNhoBgv4kq8GlAgYz6FjE=.9ae28c9b-9263-43e6-8ba2-2bfeb756863f@github.com>

On Mon, 13 Sep 2021 08:55:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey and Severin's comments
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp line 124:
> 
>> 122: 
>> 123: public:
>> 124:   ShenandoahClassLoaderDataRoots(ShenandoahPhaseTimings::Phase phase, uint n_workers, bool heapdump);
> 
> Can we call the new parameter `heap_iteration`? This would match the `ShenandoahHeapIterationRootScanner` name. I could also imagine that iteration is used for something else than a heap dump (maybe JFR/JVMTI heap walk for profiling/debugging?).

Fixed. Thanks!

> test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java line 156:
> 
>> 154:         }
>> 155:     }
>> 156: }
> 
> Newline is missing.

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From zgu at openjdk.java.net  Mon Sep 13 13:34:28 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 13:34:28 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

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

 - Merge
 - Aleksey and Severin's comments
 - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

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

Changes: https://git.openjdk.java.net/jdk/pull/5473/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5473&range=02
  Stats: 206 lines in 6 files changed: 161 ins; 10 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5473/head:pull/5473

PR: https://git.openjdk.java.net/jdk/pull/5473

From coleenp at openjdk.java.net  Mon Sep 13 15:19:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 15:19:52 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v2]
In-Reply-To: <0fzRARQKdoAbSLHq_SaKs698DuGgRWMkCUI4omDmurk=.acb1126f-5b41-46ad-a022-74eabffdb71f@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <2yiIxm7CaiJf3_wiiYcuQjbRNFauGO0MJoJGUphSmR0=.29fe408e-8707-402f-8e3c-5366aff3a8cc@github.com>
 <0fzRARQKdoAbSLHq_SaKs698DuGgRWMkCUI4omDmurk=.acb1126f-5b41-46ad-a022-74eabffdb71f@github.com>
Message-ID: <AHwa4h8CEw_T5uJUwfUAM1Rs9p5k4Bi_sKBEdwfK-Ys=.cf7be6b6-e1a1-45ff-baf2-f1acf9642223@github.com>

On Sun, 12 Sep 2021 22:33:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If I see a lock with a rank service-1, then should I infer that lock can be acquired while the service (or notification) lock is held? And that if lock A is service-1 and lock B is service-2, then B can be acquired while holding A?

Yes.  The Service_lock is held while all these other locks are taken.  The subtraction comes from the highest ranked lock with a name, in this case 'service'.

> src/hotspot/share/memory/universe.cpp line 125:
> 
>> 123: LatestMethodCache* Universe::_do_stack_walk_cache     = NULL;
>> 124: 
>> 125: bool Universe::_verify_in_progress                    = false;
> 
> This cleanup seems completely unrelated to your mutex change and is best left to a separate cleanup RFE.

I could do it in a trivial other RFE.

> src/hotspot/share/memory/universe.cpp line 1116:
> 
>> 1114:   }
>> 1115:   if (should_verify_subset(Verify_CodeCache)) {
>> 1116:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 
> Is this needed to allow the new rankings to work? And is this enabled by the _verify_in_progress change? If so I'd rather see all of that related stuff changed first in a separate RFE that can easily be independently backported.

Yes, this is needed.  This verification is done during a safepoint, so we don't need this lock.  The CodeCache_lock has a vary low ranking and takes out VtableStubs_lock which is a higher ranking.  With this change, we do not take out the CodeCache_lock, so it's needed for this change.  I see no reason whatsoever to backport it though.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Mon Sep 13 21:04:32 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 21:04:32 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v3]
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <YbS3MuL1kC1UI6EbtiGwuuSATE8Y-ospxm2Kshk-T2M=.6673314c-8a9d-497b-96d8-215cd6bba555@github.com>

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

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

 - Merge branch 'master' into checkrank
 - Fix Shenandoah mismerge
 - 8273300: Check Mutex ranking during a safepoint

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

Changes: https://git.openjdk.java.net/jdk/pull/5467/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=02
  Stats: 31 lines in 12 files changed: 1 ins; 7 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5467/head:pull/5467

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Mon Sep 13 21:04:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 21:04:33 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v3]
In-Reply-To: <AHwa4h8CEw_T5uJUwfUAM1Rs9p5k4Bi_sKBEdwfK-Ys=.cf7be6b6-e1a1-45ff-baf2-f1acf9642223@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <2yiIxm7CaiJf3_wiiYcuQjbRNFauGO0MJoJGUphSmR0=.29fe408e-8707-402f-8e3c-5366aff3a8cc@github.com>
 <0fzRARQKdoAbSLHq_SaKs698DuGgRWMkCUI4omDmurk=.acb1126f-5b41-46ad-a022-74eabffdb71f@github.com>
 <AHwa4h8CEw_T5uJUwfUAM1Rs9p5k4Bi_sKBEdwfK-Ys=.cf7be6b6-e1a1-45ff-baf2-f1acf9642223@github.com>
Message-ID: <jqXRgE9uncgRkj4tEhm01qM1CYdaOv1X3drkDPb76N0=.b031a047-e95f-41e7-aba8-72b919a0541b@github.com>

On Mon, 13 Sep 2021 15:12:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/memory/universe.cpp line 125:
>> 
>>> 123: LatestMethodCache* Universe::_do_stack_walk_cache     = NULL;
>>> 124: 
>>> 125: long Universe::verify_flags                           = Universe::Verify_All;
>> 
>> This cleanup seems completely unrelated to your mutex change and is best left to a separate cleanup RFE.
>
> I could do it in a trivial other RFE.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From kdnilsen at openjdk.java.net  Mon Sep 13 21:37:15 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 13 Sep 2021 21:37:15 GMT
Subject: RFR: Fix full gc with class unloading
Message-ID: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>

This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.

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

Commit messages:
 - Merge branch 'shenandoah' into fix-class-unloading-with-full-gc
 - Respond to reviewer feedback
 - Fix up state diagram
 - Update state diagram to incorporate full gc
 - Fix class unloading interactions with full gc

Changes: https://git.openjdk.java.net/shenandoah/pull/67/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=67&range=00
  Stats: 60 lines in 4 files changed: 31 ins; 5 del; 24 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/67/head:pull/67

PR: https://git.openjdk.java.net/shenandoah/pull/67

From gnu.andrew at redhat.com  Tue Sep 14 02:19:07 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 14 Sep 2021 03:19:07 +0100
Subject: [RFR] [8u] 8u312-b02 Upstream Sync
Message-ID: <YUAGmx9oj/ZarQxl@hex.discworld.ac.uk>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u312-b02:
  - JDK-8247469: getSystemCpuLoad() returns -1 on linux when some offline cpus are present and cpusets.effective_cpus is not available
  - JDK-8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container

Main issues of note:
None, clean merge (no HotSpot changes).

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for corba
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxp
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxws
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for langtools
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for nashorn
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jdk
 b/.hgtags                                                     |    1 
 b/make/mapfiles/libmanagement/mapfile-vers                    |    2 
 b/src/solaris/classes/sun/management/OperatingSystemImpl.java |   67 ++++++++--
 b/src/solaris/native/sun/management/LinuxOperatingSystem.c    |   39 +++++
 b/src/solaris/native/sun/management/OperatingSystemImpl.c     |   16 ++
 5 files changed, 110 insertions(+), 15 deletions(-)

diffstat for hotspot
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From github.com+39413832+weixlu at openjdk.java.net  Tue Sep 14 03:42:11 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Tue, 14 Sep 2021 03:42:11 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <bN29__wPY1ryV8d9uuuOXhcyBmntQkDIAUoX3S7sRiI=.b6b8a9bc-7075-4469-99eb-195e67a2feb3@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
 <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>
 <uCo4Uu-RlYKbnSUXQHzMT8Nb2tIkuALPtQCFhAfn6_c=.5e6e1ebc-43f7-4972-9cbb-907f3299a372@github.com>
 <bN29__wPY1ryV8d9uuuOXhcyBmntQkDIAUoX3S7sRiI=.b6b8a9bc-7075-4469-99eb-195e67a2feb3@github.com>
Message-ID: <mLz4iXhVjiTh4x74bGz1a1uPtMiqD-z3qCIx6Hmykhg=.02b200bb-0e4c-4594-807e-9dc53180f5a8@github.com>

On Fri, 10 Sep 2021 07:41:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> @shipilev Hi, I have tested this pull request as well as this pull request + `OrderAccess::release();` on specjbb 2015 on AArch64 (Kunpeng 920). Maybe there is a slight improvement on critical-jOPS? Here is the result.
>> 
>> Thanks for testing. So explicit barrier does seem to result in a slight bump in critical-jOPS.
>> 
>> I assume "base" results are this PR? If so, do you have performance results for the current master? In other words, it would be interesting to see three results: baseline (current master), this PR, and this PR + `OrderAccess::release()`.
>
>> @shipilev Yes, ?base? means this PR in my previous comment. Here is the result of the current master(i.e. revert all commits in this PR). It seems master performs better, so the cost of ?acquire? may be really high as you have said.
> 
> (sighs) Thanks for testing. Do you have spare cycles to verify that "acquire" is indeed the culprit for this? It would be simple to check: replace all `mark_acquire()` to just `mark()` in this PR. I am somewhat sure that would not break things very much for the test runs.

@shipilev quite confusing. I have replaced `mark_acquire()` in get_forwardee_raw() and get_forwardee_mutator() and run specjbb, only to see a slight decrease on critical-jOPS compared with master. But the implementation of LSE instructions isn't so efficient on the current server(kunpeng 920), which may bother CAS instructions with memory order. So I use an Ampere processor to run the tests again. However, Same as before, critical-jOPS decreases by about 3% even if we have replaced the acquire in forwardee access.
Anyway, compared with current PR, relax `mark_acquire()` to `mark()` gives us perf boost. But I'm confused why it is below master, since we adopt `release` or even `relaxed` in self heal and forwardee update.

on kunpeng 920
relax_acquire_1:RUN RESULT: hbIR (max attempted) = 41119, hbIR (settled) = 34282, max-jOPS = 30017, critical-jOPS = 22581
relax_acquire_2:RUN RESULT: hbIR (max attempted) = 41119, hbIR (settled) = 34282, max-jOPS = 30017, critical-jOPS = 22581
relax_acquire_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 21492

on Ampere 
master_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107127, max-jOPS = 101742, critical-jOPS = 37649
master_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107689, max-jOPS = 100516, critical-jOPS = 38331
master_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 103341, max-jOPS = 99291, critical-jOPS = 37898
relax_acquire_1:RUN RESULT: hbIR (max attempted) = 108894, hbIR (settled) = 104937, max-jOPS = 99094, critical-jOPS = 34048
relax_acquire_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106745, max-jOPS = 101742, critical-jOPS = 38273
relax_acquire_3:RUN RESULT: hbIR (max attempted) = 108894, hbIR (settled) = 104937, max-jOPS = 101271, critical-jOPS = 37701

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

PR: https://git.openjdk.java.net/jdk/pull/2496

From pliden at openjdk.java.net  Tue Sep 14 10:32:11 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 14 Sep 2021 10:32:11 GMT
Subject: Integrated: 8273597: Rectify Thread::is_ConcurrentGC_thread()
In-Reply-To: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
Message-ID: <fpdbFy_XDOIOU0yV5btlqh87mgnXPsaUdEKNNM9AtSc=.f3e9d8aa-3ef2-442b-89e0-85869faf1e1b@github.com>

On Fri, 10 Sep 2021 12:39:14 GMT, Per Liden <pliden at openjdk.org> wrote:

> `Thread::is_ConcurrentGC_thread()` behaves differently to all other `Thread::is_xxx_thread()` functions, in the sense that it doesn't directly map to a distinct `Thread` sub-class. Instead, `is_ConcurrentGC_thread()` can today return true for both `ConcurrentGCThread` and `GangWorker`. These two classes have no super/sub-class relation. This is confusing and and potentially dangerous.
> 
> It would be reasonable to think that code like this would be correct:
> 
> 
>   if (thread->is_ConcurrentGC_thread()) {
>     conc_thread = static_cast<ConcurrentGCThread*>(thread);
>     ...
>   }
> 
> 
> but it's not, since we might try to cast a `GangWorker` to a `ConcurrentGCThread`. And again, these two classes have no super/sub-class relation.
> 
> I propose that we clean this up, so that `is_ConcurrentGCThread()` only returns true for threads inheriting from `ConcurrentGCThread`. The main side-effect is that a handful of asserts need to be adjusted. In return, the code example above would become legal, and we can also remove some cruft from `WorkGang`/`GangWorker`.

This pull request has now been integrated.

Changeset: 38845805
Author:    Per Liden <pliden at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3884580591e932536a078f4f138920dcc8139c1a
Stats:     61 lines in 18 files changed: 12 ins; 27 del; 22 mod

8273597: Rectify Thread::is_ConcurrentGC_thread()

Reviewed-by: stefank, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From pliden at openjdk.java.net  Tue Sep 14 10:32:10 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 14 Sep 2021 10:32:10 GMT
Subject: RFR: 8273597: Rectify Thread::is_ConcurrentGC_thread() [v2]
In-Reply-To: <5w9LT70Xgw0fu3bme0Tx4ko3zShJrqT2OQU613E7Ff8=.4b4211fc-7d8b-4b91-b6ed-e24a8e28947f@github.com>
References: <QjGF85swX6j4l1rtvt6S5_WZgBuj7YYDv-gyNrKT2wc=.63d3b6b0-a12d-459c-90e5-804fc46e4963@github.com>
 <xmVWPbapPOTmm_6sPjJHofkKZhk92iJQ6mLn_jlVTSw=.1f2636b5-08c0-4d61-913f-928b81d55043@github.com>
 <5w9LT70Xgw0fu3bme0Tx4ko3zShJrqT2OQU613E7Ff8=.4b4211fc-7d8b-4b91-b6ed-e24a8e28947f@github.com>
Message-ID: <6UjyClC5-2-INjTE4um_TGLBFHI9iP3FNlYWkJ9j0R4=.ae087677-6e30-4bf6-99cd-42228b6f7db6@github.com>

On Mon, 13 Sep 2021 12:22:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Per Liden has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix constructor call
>>  - Add ConcurrentGCThread::cast()
>
> Marked as reviewed by stefank (Reviewer).

Thanks for reviewing @stefank and @coleenp!

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

PR: https://git.openjdk.java.net/jdk/pull/5463

From coleenp at openjdk.java.net  Tue Sep 14 15:21:19 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Sep 2021 15:21:19 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

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

 - Fix Shenandoah mismerge
 - Merge branch 'master' into checkrank
 - Fix Shenandoah mismerge
 - 8273300: Check Mutex ranking during a safepoint

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

Changes: https://git.openjdk.java.net/jdk/pull/5467/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=03
  Stats: 33 lines in 14 files changed: 1 ins; 7 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5467/head:pull/5467

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Tue Sep 14 15:21:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Sep 2021 15:21:20 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v3]
In-Reply-To: <YbS3MuL1kC1UI6EbtiGwuuSATE8Y-ospxm2Kshk-T2M=.6673314c-8a9d-497b-96d8-215cd6bba555@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <YbS3MuL1kC1UI6EbtiGwuuSATE8Y-ospxm2Kshk-T2M=.6673314c-8a9d-497b-96d8-215cd6bba555@github.com>
Message-ID: <HavV0ZoKTj1eqiNsKEKqQB9X3Mc89IzPBCWeASudDdM=.a25f1a34-9b1f-4ee4-a1aa-892cdfb1a687@github.com>

On Mon, 13 Sep 2021 21:04:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
>> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
>> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
>> Tests run tier1-8.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into checkrank
>  - Fix Shenandoah mismerge
>  - 8273300: Check Mutex ranking during a safepoint

I just remerged from master and a couple of copyright updates leaked in from my script (which I shouldn't have used).

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From wkemper at openjdk.java.net  Tue Sep 14 21:31:23 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 14 Sep 2021 21:31:23 GMT
Subject: RFR: Fix full gc with class unloading
In-Reply-To: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
Message-ID: <Lk387KCNjy-T8u316uLk7mjinQl2httsMDn_5-hLJUM=.402609e0-1d73-489f-8289-b9e005694f4b@github.com>

On Mon, 13 Sep 2021 21:01:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 591:

> 589:     assert(heap->cancelled_gc(), "Must have been cancelled");
> 590:     check_cancellation_or_degen(gc.degen_point());
> 591:     if (generation->generation_mode() == OLD) {

Is this ever true here? Old collections should go through the `service_concurrent_old_cycle` method.

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

PR: https://git.openjdk.java.net/shenandoah/pull/67

From kdnilsen at openjdk.java.net  Tue Sep 14 21:56:34 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Sep 2021 21:56:34 GMT
Subject: RFR: Fix full gc with class unloading
In-Reply-To: <Lk387KCNjy-T8u316uLk7mjinQl2httsMDn_5-hLJUM=.402609e0-1d73-489f-8289-b9e005694f4b@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
 <Lk387KCNjy-T8u316uLk7mjinQl2httsMDn_5-hLJUM=.402609e0-1d73-489f-8289-b9e005694f4b@github.com>
Message-ID: <gfulAgO2Y77yFUFqaAcQAU4lRjTfBTgWoPBdis0dtvg=.c5ae083a-41de-41fd-98b7-50fb0ec2cc26@github.com>

On Mon, 13 Sep 2021 21:59:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 591:
> 
>> 589:     assert(heap->cancelled_gc(), "Must have been cancelled");
>> 590:     check_cancellation_or_degen(gc.degen_point());
>> 591:     if (generation->generation_mode() == OLD) {
> 
> Is this ever true here? Old collections should go through the `service_concurrent_old_cycle` method.

I think you're right.  I had not understood all the control paths to this point.

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

PR: https://git.openjdk.java.net/shenandoah/pull/67

From kdnilsen at openjdk.java.net  Tue Sep 14 21:56:35 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Sep 2021 21:56:35 GMT
Subject: RFR: Fix full gc with class unloading
In-Reply-To: <gfulAgO2Y77yFUFqaAcQAU4lRjTfBTgWoPBdis0dtvg=.c5ae083a-41de-41fd-98b7-50fb0ec2cc26@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
 <Lk387KCNjy-T8u316uLk7mjinQl2httsMDn_5-hLJUM=.402609e0-1d73-489f-8289-b9e005694f4b@github.com>
 <gfulAgO2Y77yFUFqaAcQAU4lRjTfBTgWoPBdis0dtvg=.c5ae083a-41de-41fd-98b7-50fb0ec2cc26@github.com>
Message-ID: <_hhD8IwCJB2_-bnBRSi3Kk1KsMEHfw0aOU9QUc3xiIw=.fd2247af-ca4a-4dca-be09-74b1bb982818@github.com>

On Tue, 14 Sep 2021 21:43:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 591:
>> 
>>> 589:     assert(heap->cancelled_gc(), "Must have been cancelled");
>>> 590:     check_cancellation_or_degen(gc.degen_point());
>>> 591:     if (generation->generation_mode() == OLD) {
>> 
>> Is this ever true here? Old collections should go through the `service_concurrent_old_cycle` method.
>
> I think you're right.  I had not understood all the control paths to this point.

I'll replace this with an assertion.

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

PR: https://git.openjdk.java.net/shenandoah/pull/67

From kdnilsen at openjdk.java.net  Tue Sep 14 23:43:27 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Sep 2021 23:43:27 GMT
Subject: RFR: Fix full gc with class unloading [v2]
In-Reply-To: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
Message-ID: <bGtaTv5Yxb5E_9ZnlEjOivnNIWBOIEQlVUBQJ0g3JnQ=.b29cda0f-4218-4d5a-8639-e909e76fb924@github.com>

> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.

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

  Respond to feedback: remove unneeded code
  
  Replaced with an assertion.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/67/files
  - new: https://git.openjdk.java.net/shenandoah/pull/67/files/fc33f30b..82e1e6e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=67&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=67&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/67/head:pull/67

PR: https://git.openjdk.java.net/shenandoah/pull/67

From wkemper at openjdk.java.net  Tue Sep 14 23:50:27 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 14 Sep 2021 23:50:27 GMT
Subject: RFR: Fix handling of weak references during verification
Message-ID: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>

This is fallout from our last big merge from upstream. When verifying reachable objects before evacuation during final mark, concurrent reference processing hasn't happened yet. For this reason, verification is required to ignore weak references which hold an unmarked referent (that would be cleared during reference processing). In our last merged, we inadvertently disabled the code to ignore weak references during certain verification phases.

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

Commit messages:
 - Fix handling of weak references during verification

Changes: https://git.openjdk.java.net/shenandoah/pull/68/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=68&range=00
  Stats: 30 lines in 5 files changed: 0 ins; 22 del; 8 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/68.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/68/head:pull/68

PR: https://git.openjdk.java.net/shenandoah/pull/68

From kdnilsen at openjdk.java.net  Tue Sep 14 23:50:27 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Sep 2021 23:50:27 GMT
Subject: RFR: Fix handling of weak references during verification
In-Reply-To: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>
References: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>
Message-ID: <iwpaMgWfdgETP3EaVyllInu8HtECL4NFOx2FnpCQl1U=.a191ded8-e3fc-4c1b-80d0-48305710a8f4@github.com>

On Tue, 14 Sep 2021 23:39:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is fallout from our last big merge from upstream. When verifying reachable objects before evacuation during final mark, concurrent reference processing hasn't happened yet. For this reason, verification is required to ignore weak references which hold an unmarked referent (that would be cleared during reference processing). In our last merged, we inadvertently disabled the code to ignore weak references during certain verification phases.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/68

From dholmes at openjdk.java.net  Wed Sep 15 01:33:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 01:33:52 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <AHwa4h8CEw_T5uJUwfUAM1Rs9p5k4Bi_sKBEdwfK-Ys=.cf7be6b6-e1a1-45ff-baf2-f1acf9642223@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <2yiIxm7CaiJf3_wiiYcuQjbRNFauGO0MJoJGUphSmR0=.29fe408e-8707-402f-8e3c-5366aff3a8cc@github.com>
 <0fzRARQKdoAbSLHq_SaKs698DuGgRWMkCUI4omDmurk=.acb1126f-5b41-46ad-a022-74eabffdb71f@github.com>
 <AHwa4h8CEw_T5uJUwfUAM1Rs9p5k4Bi_sKBEdwfK-Ys=.cf7be6b6-e1a1-45ff-baf2-f1acf9642223@github.com>
Message-ID: <Bb9g2whmgUrKBsmPJZ5AmLtPXsUTl3j5M7mITdJOWKc=.d299b14b-1b01-4314-ab23-203a521a9651@github.com>

On Mon, 13 Sep 2021 15:15:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/memory/universe.cpp line 1109:
>> 
>>> 1107:   }
>>> 1108:   if (should_verify_subset(Verify_CodeCache)) {
>>> 1109:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>> 
>> Is this needed to allow the new rankings to work? And is this enabled by the _verify_in_progress change? If so I'd rather see all of that related stuff changed first in a separate RFE that can easily be independently backported.
>
> Yes, this is needed.  This verification is done during a safepoint, so we don't need this lock.  The CodeCache_lock has a vary low ranking and takes out VtableStubs_lock which is a higher ranking.  With this change, we do not take out the CodeCache_lock, so it's needed for this change.  I see no reason whatsoever to backport it though.

This isn't connected to the _verify_in_progress change, so that is fine.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From dholmes at openjdk.java.net  Wed Sep 15 01:33:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 01:33:51 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
Message-ID: <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>

On Tue, 14 Sep 2021 15:21:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
>> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
>> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
>> Tests run tier1-8.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Fix Shenandoah mismerge
>  - Merge branch 'master' into checkrank
>  - Fix Shenandoah mismerge
>  - 8273300: Check Mutex ranking during a safepoint

Hi Coleen,

It wasn't clear if you thought you had already fixed the incorrect copyright notices so I flagged the two I saw.

I still have some queries about this - see comment below - but nothing that would stop it from being pushed as-is.

Thanks,
David

src/hotspot/cpu/zero/vm_version_zero.cpp line 2:

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

Unwanted copyright date change.

src/hotspot/share/runtime/mutex.hpp line 53:

> 51:        special        = tty            +   3,
> 52:        oopstorage     = special        +   3,
> 53:        leaf           = oopstorage     +  10,

Why do we need such a big gap here? Is there any reason we can't just use the same gap between all named rankings? As it is there seems to be no rationale for the  "+ N" value used.

src/hotspot/share/utilities/growableArray.hpp line 2:

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

Unwanted copyright change.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5467

From shade at openjdk.java.net  Wed Sep 15 09:51:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 09:51:57 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
Message-ID: <dAlzsbkSF7Ib5xeTT3bU6B6cbrgmPTH0xctNr4vcqao=.c20b47f7-08c0-4f42-81de-76151b0a1c3e@github.com>

On Mon, 13 Sep 2021 13:34:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
>> 
>>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
>> 
>> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1 with Shenandoah GC
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - Aleksey and Severin's comments
>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From rkennke at openjdk.java.net  Wed Sep 15 11:54:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 15 Sep 2021 11:54:53 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
Message-ID: <X7xbwqfyGIfSN-9YaXklx4gybYsOH8Bt-jCUxb_QgEY=.f637f926-dc7e-4d7e-9a1b-2758009ee888@github.com>

On Mon, 13 Sep 2021 13:34:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
>> 
>>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
>> 
>> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1 with Shenandoah GC
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - Aleksey and Severin's comments
>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Marked as reviewed by rkennke (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From coleenp at openjdk.java.net  Wed Sep 15 11:56:21 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Sep 2021 11:56:21 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
 <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>
Message-ID: <a4RYQnrM9nPXSglZ03HGw3DgQe22GIU9ZXXv_092Uww=.cfebafdf-c348-452d-8323-0d3abd70e422@github.com>

On Wed, 15 Sep 2021 01:28:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Fix Shenandoah mismerge
>>  - Merge branch 'master' into checkrank
>>  - Fix Shenandoah mismerge
>>  - 8273300: Check Mutex ranking during a safepoint
>
> src/hotspot/share/runtime/mutex.hpp line 53:
> 
>> 51:        special        = tty            +   3,
>> 52:        oopstorage     = special        +   3,
>> 53:        leaf           = oopstorage     +  10,
> 
> Why do we need such a big gap here? Is there any reason we can't just use the same gap between all named rankings? As it is there seems to be no rationale for the  "+ N" value used.

The gap is pretty much arbitrary, but there's already some leaf-2 and having overlapping rankings is something we don't really want, so I changed it to 10 for now.

> src/hotspot/share/utilities/growableArray.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> Unwanted copyright change.

I think I finally reverted them.  My commit script fixed them back again.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Wed Sep 15 11:56:14 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Sep 2021 11:56:14 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v5]
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <TQ3ZPR71TGsDupofS6ysfRd2U0ZgD8yZ12xSoMSwJxg=.4f6cf82b-ee0c-47c3-b217-13a64a2dd480@github.com>

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:

 - Revert copyright changes again
 - Revert "Revert unintended copyright changes."
   
   This reverts commit 712af5df87a5cefc16a9844867c3be1ae663b00d.
 - Revert unintended copyright changes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5467/files
  - new: https://git.openjdk.java.net/jdk/pull/5467/files/9920c227..eec9b842

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From rkennke at openjdk.java.net  Wed Sep 15 11:58:43 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 15 Sep 2021 11:58:43 GMT
Subject: RFR: Fix full gc with class unloading [v2]
In-Reply-To: <bGtaTv5Yxb5E_9ZnlEjOivnNIWBOIEQlVUBQJ0g3JnQ=.b29cda0f-4218-4d5a-8639-e909e76fb924@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
 <bGtaTv5Yxb5E_9ZnlEjOivnNIWBOIEQlVUBQJ0g3JnQ=.b29cda0f-4218-4d5a-8639-e909e76fb924@github.com>
Message-ID: <AxuMgJyl6Fr1dHkF7JTHBj8X2GP7xZzYsS1YiVjFF5k=.11ee26ed-b805-4c3d-925a-3b0728338242@github.com>

On Tue, 14 Sep 2021 23:43:27 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to feedback: remove unneeded code
>   
>   Replaced with an assertion.

Looks good. Only one small question.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 315:

> 313:       if (heap->unload_classes()) {
> 314:         // HEY! Should we do this if the cycle was cancelled/degenerated?
> 315:         assert(generation == GLOBAL, "Only unload classes during GLOBAL cycle");

Is the comment still valid? Also, maybe change 'HEY!' to TODO so that IDE would flag it.

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

Marked as reviewed by rkennke (Lead).

PR: https://git.openjdk.java.net/shenandoah/pull/67

From rkennke at openjdk.java.net  Wed Sep 15 11:59:06 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 15 Sep 2021 11:59:06 GMT
Subject: RFR: Fix handling of weak references during verification
In-Reply-To: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>
References: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>
Message-ID: <rO1TBWH3mhfuZqch5K0t0vG7Soi3OMaUjn08fMHf_Ss=.ac07b472-8504-4bb6-b711-b3c64a9f7c25@github.com>

On Tue, 14 Sep 2021 23:39:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is fallout from our last big merge from upstream. When verifying reachable objects before evacuation during final mark, concurrent reference processing hasn't happened yet. For this reason, verification is required to ignore weak references which hold an unmarked referent (that would be cleared during reference processing). In our last merged, we inadvertently disabled the code to ignore weak references during certain verification phases.

Marked as reviewed by rkennke (Lead).

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

PR: https://git.openjdk.java.net/shenandoah/pull/68

From dholmes at openjdk.java.net  Wed Sep 15 13:03:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 13:03:47 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <a4RYQnrM9nPXSglZ03HGw3DgQe22GIU9ZXXv_092Uww=.cfebafdf-c348-452d-8323-0d3abd70e422@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
 <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>
 <a4RYQnrM9nPXSglZ03HGw3DgQe22GIU9ZXXv_092Uww=.cfebafdf-c348-452d-8323-0d3abd70e422@github.com>
Message-ID: <9JRLvqeKqRe4yC21ZgRCNGGrFjJqykgTSQ4Q-9Ea2ss=.15756d59-e67e-4852-9413-4ae69049d9ae@github.com>

On Wed, 15 Sep 2021 11:51:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutex.hpp line 53:
>> 
>>> 51:        special        = tty            +   3,
>>> 52:        oopstorage     = special        +   3,
>>> 53:        leaf           = oopstorage     +  10,
>> 
>> Why do we need such a big gap here? Is there any reason we can't just use the same gap between all named rankings? As it is there seems to be no rationale for the  "+ N" value used.
>
> The gap is pretty much arbitrary, but there's already some leaf-2 and having overlapping rankings is something we don't really want, so I changed it to 10 for now.

Okay but is there a reason not to use the same gap?

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From sgehwolf at openjdk.java.net  Wed Sep 15 13:09:52 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 15 Sep 2021 13:09:52 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
Message-ID: <8D9Zf4Q0V6IJfD-X5_Py2y-TDxE7L6w-RxLdf4AzQ1k=.1899ecc1-71c9-4bd9-af47-53f5a17637c1@github.com>

On Mon, 13 Sep 2021 13:34:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
>> 
>>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
>> 
>> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1 with Shenandoah GC
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge
>  - Aleksey and Severin's comments
>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

comment change looks good :)

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5473

From zgu at openjdk.java.net  Wed Sep 15 13:09:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 13:09:53 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <dAlzsbkSF7Ib5xeTT3bU6B6cbrgmPTH0xctNr4vcqao=.c20b47f7-08c0-4f42-81de-76151b0a1c3e@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
 <dAlzsbkSF7Ib5xeTT3bU6B6cbrgmPTH0xctNr4vcqao=.c20b47f7-08c0-4f42-81de-76151b0a1c3e@github.com>
Message-ID: <j4Kwm78hQAx6q0KuJScLXl10mHW8ORy-vlnfGZKrw90=.0d845902-cc7b-442c-82f8-f6b35a726eff@github.com>

On Wed, 15 Sep 2021 09:48:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge
>>  - Aleksey and Severin's comments
>>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump
>
> Marked as reviewed by shade (Reviewer).

Thanks, @shipilev  @jerboaa  @rkennke

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From zgu at openjdk.java.net  Wed Sep 15 13:13:02 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 13:13:02 GMT
Subject: Integrated: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <gMpplukpHz3IHER5yxH5rDlBpeTz31xhG_KajUAzacI=.f004546b-f289-490c-9a20-2e38a335a69a@github.com>

On Fri, 10 Sep 2021 18:17:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

This pull request has now been integrated.

Changeset: 8132bfd2
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8132bfd23f2f7fb52e502a3e6fe488fbdb537df0
Stats:     206 lines in 6 files changed: 161 ins; 10 del; 35 mod

8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Reviewed-by: shade, rkennke, sgehwolf

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

PR: https://git.openjdk.java.net/jdk/pull/5473

From coleenp at openjdk.java.net  Wed Sep 15 15:33:56 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Sep 2021 15:33:56 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <9JRLvqeKqRe4yC21ZgRCNGGrFjJqykgTSQ4Q-9Ea2ss=.15756d59-e67e-4852-9413-4ae69049d9ae@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
 <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>
 <a4RYQnrM9nPXSglZ03HGw3DgQe22GIU9ZXXv_092Uww=.cfebafdf-c348-452d-8323-0d3abd70e422@github.com>
 <9JRLvqeKqRe4yC21ZgRCNGGrFjJqykgTSQ4Q-9Ea2ss=.15756d59-e67e-4852-9413-4ae69049d9ae@github.com>
Message-ID: <KJL20_X2Tfr80b2BBmZLcSfX-2GrF44U6CxUIV_vcC4=.b3d83808-9d15-4ecf-80f8-10d88e01ba2a@github.com>

On Wed, 15 Sep 2021 13:00:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The gap is pretty much arbitrary, but there's already some leaf-2 and having overlapping rankings is something we don't really want, so I changed it to 10 for now.
>
> Okay but is there a reason not to use the same gap?

If the gap is 2, then leaf-2 will == oopstorage?  I could make it 3 but it doesn't actually matter.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From pchilanomate at openjdk.java.net  Wed Sep 15 16:05:48 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 15 Sep 2021 16:05:48 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v5]
In-Reply-To: <TQ3ZPR71TGsDupofS6ysfRd2U0ZgD8yZ12xSoMSwJxg=.4f6cf82b-ee0c-47c3-b217-13a64a2dd480@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <TQ3ZPR71TGsDupofS6ysfRd2U0ZgD8yZ12xSoMSwJxg=.4f6cf82b-ee0c-47c3-b217-13a64a2dd480@github.com>
Message-ID: <vThM_3yuChso1dfR4hIKHgbnfOGo_Zc_W6-5oFbx8ts=.a5b579b3-eaa0-45f8-bfb1-c96cf4a32e64@github.com>

On Wed, 15 Sep 2021 11:56:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
>> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
>> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
>> Tests run tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert copyright changes again
>  - Revert "Revert unintended copyright changes."
>    
>    This reverts commit 712af5df87a5cefc16a9844867c3be1ae663b00d.
>  - Revert unintended copyright changes.

Marked as reviewed by pchilanomate (Committer).

src/hotspot/share/runtime/mutex.cpp line 375:

> 373:   Mutex* locks_owned = thread->owned_locks();
> 374: 
> 375:   if (!SafepointSynchronize::is_at_safepoint()) {

I think removing this conditional was okay in your previous change.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From tschatzl at openjdk.java.net  Wed Sep 15 16:22:13 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 16:22:13 GMT
Subject: RFR: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a
 @requires vm.gc.shenandoah
Message-ID: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>

Hi all,

  can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?

Currently testing tier2 with this change, but I expect this to work.

Thanks,
  Thomas

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

Commit messages:
 - Add requires label

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

PR: https://git.openjdk.java.net/jdk/pull/5535

From zgu at openjdk.java.net  Wed Sep 15 16:27:56 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 16:27:56 GMT
Subject: RFR: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a
 @requires vm.gc.shenandoah
In-Reply-To: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
References: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
Message-ID: <gIhZHIGIMfrEgEI4uhP6M3wnaa4RjmVgaKhcrIMIWOU=.980f37c0-7c95-4ed6-a8c5-d2033144c5d3@github.com>

On Wed, 15 Sep 2021 16:14:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?
> 
> Currently testing tier2 with this change, but I expect this to work.
> 
> Thanks,
>   Thomas

Looks good and trivial

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5535

From coleenp at openjdk.java.net  Wed Sep 15 16:32:24 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Sep 2021 16:32:24 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v6]
In-Reply-To: <vThM_3yuChso1dfR4hIKHgbnfOGo_Zc_W6-5oFbx8ts=.a5b579b3-eaa0-45f8-bfb1-c96cf4a32e64@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <TQ3ZPR71TGsDupofS6ysfRd2U0ZgD8yZ12xSoMSwJxg=.4f6cf82b-ee0c-47c3-b217-13a64a2dd480@github.com>
 <vThM_3yuChso1dfR4hIKHgbnfOGo_Zc_W6-5oFbx8ts=.a5b579b3-eaa0-45f8-bfb1-c96cf4a32e64@github.com>
Message-ID: <LDWL0-FXsDyBjmmOUnz9exig87rwHro3LQ66ScINURU=.d3b57d84-16ea-4348-a709-1fd2af0ab52b@github.com>

On Wed, 15 Sep 2021 16:02:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove safepoint conditional from other assert. The locks should now be in decreasing order.
>
> src/hotspot/share/runtime/mutex.cpp line 375:
> 
>> 373:   Mutex* locks_owned = thread->owned_locks();
>> 374: 
>> 375:   if (!SafepointSynchronize::is_at_safepoint()) {
> 
> I think removing this conditional was okay in your previous change.

Thanks Patricio for noticing this omission. I've removed it and retesting.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Wed Sep 15 16:32:22 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Sep 2021 16:32:22 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v6]
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <S01lA9o-2YolZG7Ce8LK8oBCTUT89cqe8Dpm-6gXviU=.bd25a4d6-64de-4b83-9378-354f4aa4ed52@github.com>

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove safepoint conditional from other assert. The locks should now be in decreasing order.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5467/files
  - new: https://git.openjdk.java.net/jdk/pull/5467/files/eec9b842..ee2ba0fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5467&range=04-05

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5467/head:pull/5467

PR: https://git.openjdk.java.net/jdk/pull/5467

From wkemper at openjdk.java.net  Wed Sep 15 17:12:57 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 15 Sep 2021 17:12:57 GMT
Subject: Integrated: Fix handling of weak references during verification
In-Reply-To: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>
References: <oNbLtLYaWWaRtU8RJ-NeUZ_9Id8_j92YXAgLdM_NVsE=.dd2483bb-b567-4c20-a46a-8b919f0b7f02@github.com>
Message-ID: <48ei0DrM44TgfHvh8ZnvfrPccfG2TrOvOJxbQ9u4eqE=.0884dbcb-273a-424b-99da-289ee982b15d@github.com>

On Tue, 14 Sep 2021 23:39:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is fallout from our last big merge from upstream. When verifying reachable objects before evacuation during final mark, concurrent reference processing hasn't happened yet. For this reason, verification is required to ignore weak references which hold an unmarked referent (that would be cleared during reference processing). In our last merged, we inadvertently disabled the code to ignore weak references during certain verification phases.

This pull request has now been integrated.

Changeset: dd7af296
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/dd7af296d20dca914fc2f39171a852f8408d6a5a
Stats:     30 lines in 5 files changed: 0 ins; 22 del; 8 mod

Fix handling of weak references during verification

Reviewed-by: kdnilsen, rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/68

From tschatzl at openjdk.java.net  Wed Sep 15 17:24:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 17:24:53 GMT
Subject: Integrated: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not
 have a @requires vm.gc.shenandoah
In-Reply-To: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
References: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
Message-ID: <nIkqPW5mLTxIWOL4zlByMhkEyHzzgi4J6XQxEYF_6zU=.c0b73c43-8e8a-4cbf-88af-3cf5a1af66a5@github.com>

On Wed, 15 Sep 2021 16:14:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?
> 
> Currently testing tier2 with this change, but I expect this to work.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: cbffecc6
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cbffecc61e4a9ac1172926ef4f20d918d73adde9
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a @requires vm.gc.shenandoah

Reviewed-by: zgu

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

PR: https://git.openjdk.java.net/jdk/pull/5535

From tschatzl at openjdk.java.net  Wed Sep 15 17:24:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 17:24:52 GMT
Subject: RFR: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a
 @requires vm.gc.shenandoah
In-Reply-To: <gIhZHIGIMfrEgEI4uhP6M3wnaa4RjmVgaKhcrIMIWOU=.980f37c0-7c95-4ed6-a8c5-d2033144c5d3@github.com>
References: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
 <gIhZHIGIMfrEgEI4uhP6M3wnaa4RjmVgaKhcrIMIWOU=.980f37c0-7c95-4ed6-a8c5-d2033144c5d3@github.com>
Message-ID: <LMneEENt845XNwyDdzPfUzbfDP4FePVCp2WwhuWxZ7g=.dc3ef59a-7339-469d-866f-3402408afe2f@github.com>

On Wed, 15 Sep 2021 16:25:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?
>> 
>> Currently testing tier2 with this change, but I expect this to work.
>> 
>> Thanks,
>>   Thomas
>
> Looks good and trivial

Thanks @zhengyu123 for your reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/5535

From kdnilsen at openjdk.java.net  Wed Sep 15 17:32:03 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 15 Sep 2021 17:32:03 GMT
Subject: RFR: Fix full gc with class unloading [v3]
In-Reply-To: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
Message-ID: <QnSc5785PXtAN7D55m1f4zGevIMVsVxE8vcKmY6_9rU=.5dd43f4c-f0a1-4604-b8fc-ff8a77adc992@github.com>

> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.

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

  Remove irrelevant comment found during code review

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/67/files
  - new: https://git.openjdk.java.net/shenandoah/pull/67/files/82e1e6e0..513963b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=67&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=67&range=01-02

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

PR: https://git.openjdk.java.net/shenandoah/pull/67

From rkennke at openjdk.java.net  Wed Sep 15 17:40:46 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 15 Sep 2021 17:40:46 GMT
Subject: RFR: Fix full gc with class unloading [v3]
In-Reply-To: <QnSc5785PXtAN7D55m1f4zGevIMVsVxE8vcKmY6_9rU=.5dd43f4c-f0a1-4604-b8fc-ff8a77adc992@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
 <QnSc5785PXtAN7D55m1f4zGevIMVsVxE8vcKmY6_9rU=.5dd43f4c-f0a1-4604-b8fc-ff8a77adc992@github.com>
Message-ID: <BrE0CWX6J0kcw24r_QedwRwBHi5coxoOogyHIrnsHbI=.f22c1d83-38d6-413d-9ee0-b2ca12187460@github.com>

On Wed, 15 Sep 2021 17:32:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove irrelevant comment found during code review

Marked as reviewed by rkennke (Lead).

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

PR: https://git.openjdk.java.net/shenandoah/pull/67

From kdnilsen at openjdk.java.net  Wed Sep 15 17:46:40 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 15 Sep 2021 17:46:40 GMT
Subject: Integrated: Fix full gc with class unloading
In-Reply-To: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
References: <CyK_qN0O_9X0vcJoRX_mgPtH6A6TKmwRDWYrxVcUvdY=.a544b387-d349-47b3-9534-6d5cf1d49fb8@github.com>
Message-ID: <xu9-VyVaiohflynCKlSyqcMrSZiVNJEr9wYzvAHBsV4=.a4610d38-057d-438a-a9d8-901a47e6ec0c@github.com>

On Mon, 13 Sep 2021 21:01:00 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request fixes incompatibilities between Full GC and class unloading.  In particular, when degenerated GC upgrades to Full GC, it is important to change the generation to GLOBAL.  Otherwise, certain assertions related to class unloading fail.

This pull request has now been integrated.

Changeset: 6a802c24
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/6a802c24caefcf555b381674bd81d8e5c6d25b0f
Stats:     56 lines in 4 files changed: 27 ins; 6 del; 23 mod

Fix full gc with class unloading

Reviewed-by: rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/67

From dholmes at openjdk.java.net  Wed Sep 15 21:56:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 21:56:57 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <KJL20_X2Tfr80b2BBmZLcSfX-2GrF44U6CxUIV_vcC4=.b3d83808-9d15-4ecf-80f8-10d88e01ba2a@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
 <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>
 <a4RYQnrM9nPXSglZ03HGw3DgQe22GIU9ZXXv_092Uww=.cfebafdf-c348-452d-8323-0d3abd70e422@github.com>
 <9JRLvqeKqRe4yC21ZgRCNGGrFjJqykgTSQ4Q-9Ea2ss=.15756d59-e67e-4852-9413-4ae69049d9ae@github.com>
 <KJL20_X2Tfr80b2BBmZLcSfX-2GrF44U6CxUIV_vcC4=.b3d83808-9d15-4ecf-80f8-10d88e01ba2a@github.com>
Message-ID: <JNZA6wiTKHmBD1RWZpISSJl9PLfJcA9NAg0OhyQ3Gm8=.5f03bd80-d7a2-4944-8fd7-742385cbb1e1@github.com>

On Wed, 15 Sep 2021 15:30:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Okay but is there a reason not to use the same gap?
>
> If the gap is 2, then leaf-2 will == oopstorage?  I could make it 3 but it doesn't actually matter.

Obviously the gap needs to be big enough to avoid the overlap, but the presence of +1, +3, +6 and +10 just raise questions as to why different values are used. Why not make them all +10 if you need 10 slots in some areas?

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Thu Sep 16 11:53:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 16 Sep 2021 11:53:46 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v4]
In-Reply-To: <JNZA6wiTKHmBD1RWZpISSJl9PLfJcA9NAg0OhyQ3Gm8=.5f03bd80-d7a2-4944-8fd7-742385cbb1e1@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <r9jCpwkPvipsWmNGPSzTpwyk395Ot9JTM8-DnIyAGdc=.89a15628-1e50-423b-83cc-61a9298ad227@github.com>
 <AO0T2d9O4YFwD5F1TM1O2t8N7WBBPmkz1EZaW-ye-g8=.e6a36ad8-90cd-4c3d-a5a9-37e0d2031966@github.com>
 <a4RYQnrM9nPXSglZ03HGw3DgQe22GIU9ZXXv_092Uww=.cfebafdf-c348-452d-8323-0d3abd70e422@github.com>
 <9JRLvqeKqRe4yC21ZgRCNGGrFjJqykgTSQ4Q-9Ea2ss=.15756d59-e67e-4852-9413-4ae69049d9ae@github.com>
 <KJL20_X2Tfr80b2BBmZLcSfX-2GrF44U6CxUIV_vcC4=.b3d83808-9d15-4ecf-80f8-10d88e01ba2a@github.com>
 <JNZA6wiTKHmBD1RWZpISSJl9PLfJcA9NAg0OhyQ3Gm8=.5f03bd80-d7a2-4944-8fd7-742385cbb1e1@github.com>
Message-ID: <rrQBgpHUgbIOJEeqqvGvzASATCK9E86OCRZdO9b1U8I=.f292209c-55f9-4ea1-b8df-b575f5489af3@github.com>

On Wed, 15 Sep 2021 21:53:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> If the gap is 2, then leaf-2 will == oopstorage?  I could make it 3 but it doesn't actually matter.
>
> Obviously the gap needs to be big enough to avoid the overlap, but the presence of +1, +3, +6 and +10 just raise questions as to why different values are used. Why not make them all +10 if you need 10 slots in some areas?

I'm going to address this with a future change because we don't have range checking for overlap yet, and they should all be some consistent and not arbitrary range.  If it was less arbitrary, I'd pick another 6 because
runtime/mutexLocker.cpp:  def(Metaspace_lock               , PaddedMutex  , leaf-3,      true,  _safepoint_check_never);
The rank 'service' had 6 because there are at least 4 locks below that.  Again, I should add range checking and maybe making them all 10 makes a lot of sense.  Locks don't nest that deeply.  I'll add this as a comment in: JDK-8176393.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Thu Sep 16 12:06:02 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 16 Sep 2021 12:06:02 GMT
Subject: RFR: 8273300: Check Mutex ranking during a safepoint [v6]
In-Reply-To: <S01lA9o-2YolZG7Ce8LK8oBCTUT89cqe8Dpm-6gXviU=.bd25a4d6-64de-4b83-9378-354f4aa4ed52@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
 <S01lA9o-2YolZG7Ce8LK8oBCTUT89cqe8Dpm-6gXviU=.bd25a4d6-64de-4b83-9378-354f4aa4ed52@github.com>
Message-ID: <4ildDdKOZMCmlTSX7hBnWPsO9UJwPdkcgoFD_pM036I=.f3fb3d0b-dba6-479f-84c1-a292675e8164@github.com>

On Wed, 15 Sep 2021 16:32:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
>> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
>> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
>> Tests run tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove safepoint conditional from other assert. The locks should now be in decreasing order.

Thanks Patricio for the code review.  Thanks David for all the comments.

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From coleenp at openjdk.java.net  Thu Sep 16 12:06:03 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 16 Sep 2021 12:06:03 GMT
Subject: Integrated: 8273300: Check Mutex ranking during a safepoint
In-Reply-To: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
References: <wPdeeyN6n5r3kkJfGxqYmiMzz-C_EepKSHGDJHIZ8JQ=.95b91a74-84f9-4aad-b410-9006c97d3283@github.com>
Message-ID: <u2YPs4PX0XRPBtaQHHvw3D0d6k7M_NfGVgmB0BftjGo=.7e9f7a1e-edd0-4bfa-9a93-dc80e5939379@github.com>

On Fri, 10 Sep 2021 15:23:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change checks lock ranking during a safepoint.  For some reason, safepoint checking was excluded, probably from the days where Safepoint_lock and Threads_lock were used.
> Because of checking during a safepoint, some locks had to get lower ranks.  The CR has the details of which locks these were.  The Service_lock complicates things because it's held during oops_do, which may take out other G1 locks.
> This was built and tested with Shenandoah.  Thanks to @zhengyu123 for the changes in Shenandoah.
> Tests run tier1-8.

This pull request has now been integrated.

Changeset: 5e4d09c2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5e4d09c22921f2980f84f849eb600d2e524d0733
Stats:     39 lines in 12 files changed: 1 ins; 9 del; 29 mod

8273300: Check Mutex ranking during a safepoint

Reviewed-by: eosterlund, dholmes, pchilanomate

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

PR: https://git.openjdk.java.net/jdk/pull/5467

From shade at redhat.com  Thu Sep 16 15:51:13 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 17:51:13 +0200
Subject: [RFR] [8u] 8u312-b02 Upstream Sync
In-Reply-To: <YUAGmx9oj/ZarQxl@hex.discworld.ac.uk>
References: <YUAGmx9oj/ZarQxl@hex.discworld.ac.uk>
Message-ID: <22094b0b-b7e3-b910-be34-8faa2299515b@redhat.com>

On 9/14/21 4:19 AM, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jaxws/merge.changeset

Trivially fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jdk/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/hotspot/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/root/merge.changeset

Trivially fine.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Thu Sep 16 16:55:29 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 16 Sep 2021 17:55:29 +0100
Subject: [RFR] [8u] 8u312-b02 Upstream Sync
In-Reply-To: <22094b0b-b7e3-b910-be34-8faa2299515b@redhat.com>
References: <YUAGmx9oj/ZarQxl@hex.discworld.ac.uk>
 <22094b0b-b7e3-b910-be34-8faa2299515b@redhat.com>
Message-ID: <YUN3AQHY9ECYadII@hex.discworld.ac.uk>

On 17:51 Thu 16 Sep     , Aleksey Shipilev wrote:
> On 9/14/21 4:19 AM, Andrew Hughes wrote:
> > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/
> > 
> > Merge changesets:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jaxws/merge.changeset
> 
> Trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/jdk/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/hotspot/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b02/root/merge.changeset
> 
> Trivially fine.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks. Pushed.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From wkemper at openjdk.java.net  Thu Sep 16 20:11:50 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 16 Sep 2021 20:11:50 GMT
Subject: RFR: Reset task queue stats before rset scan
Message-ID: <H67Z4FiDL5T-nkJc9OOokZ6weXO-9-ykjme6gSUCzRI=.24612ed9-71c0-47aa-9850-2b5b70a7915b@github.com>

This change fixes an assert caused when task queue stats were reset after the rset scan has pushed oops into the queues (all of those "pushes" become uncounted).

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

Commit messages:
 - Move concurrent rset scan to top level in phase timings report
 - Reset task queue stats before rset scan

Changes: https://git.openjdk.java.net/shenandoah/pull/69/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=69&range=00
  Stats: 12 lines in 3 files changed: 8 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/69.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/69/head:pull/69

PR: https://git.openjdk.java.net/shenandoah/pull/69

From kdnilsen at openjdk.java.net  Thu Sep 16 20:30:31 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 16 Sep 2021 20:30:31 GMT
Subject: RFR: Reset task queue stats before rset scan
In-Reply-To: <H67Z4FiDL5T-nkJc9OOokZ6weXO-9-ykjme6gSUCzRI=.24612ed9-71c0-47aa-9850-2b5b70a7915b@github.com>
References: <H67Z4FiDL5T-nkJc9OOokZ6weXO-9-ykjme6gSUCzRI=.24612ed9-71c0-47aa-9850-2b5b70a7915b@github.com>
Message-ID: <IXY2H5Rju9m984vv8TzPi-Vup35OfySDAqxN5p3YR4U=.fe091dc7-fd1d-4aa1-8b39-a0d32f77bf23@github.com>

On Thu, 16 Sep 2021 20:06:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change fixes an assert caused when task queue stats were reset after the rset scan has pushed oops into the queues (all of those "pushes" become uncounted).

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/69

From wkemper at openjdk.java.net  Thu Sep 16 20:45:34 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 16 Sep 2021 20:45:34 GMT
Subject: RFR: Track promotion rate into old generation
Message-ID: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>

The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.

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

Commit messages:
 - Merge branch 'shenandoah' into promotion-rate-heuristic
 - Remove unused bytes allocated tracking from heap
 - Logging to verify allocation rates for each generation
 - Merge branch 'shenandoah' into promotion-rate-heuristic
 - Track allocation rate for each generation

Changes: https://git.openjdk.java.net/shenandoah/pull/70/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=70&range=00
  Stats: 68 lines in 7 files changed: 47 ins; 14 del; 7 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/70.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/70/head:pull/70

PR: https://git.openjdk.java.net/shenandoah/pull/70

From wkemper at openjdk.java.net  Thu Sep 16 20:48:46 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 16 Sep 2021 20:48:46 GMT
Subject: Integrated: Reset task queue stats before rset scan
In-Reply-To: <H67Z4FiDL5T-nkJc9OOokZ6weXO-9-ykjme6gSUCzRI=.24612ed9-71c0-47aa-9850-2b5b70a7915b@github.com>
References: <H67Z4FiDL5T-nkJc9OOokZ6weXO-9-ykjme6gSUCzRI=.24612ed9-71c0-47aa-9850-2b5b70a7915b@github.com>
Message-ID: <uGZ94KeNk7NX6KmIkXlCdMfoe199j65tKWSEYJd4TOE=.952a39c4-4bcf-4f19-84b0-dae517954277@github.com>

On Thu, 16 Sep 2021 20:06:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change fixes an assert caused when task queue stats were reset after the rset scan has pushed oops into the queues (all of those "pushes" become uncounted).

This pull request has now been integrated.

Changeset: 1c2ee14e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/1c2ee14e7edab901d96419bae491d8bb574e0ce6
Stats:     12 lines in 3 files changed: 8 ins; 4 del; 0 mod

Reset task queue stats before rset scan

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/69

From kdnilsen at openjdk.java.net  Thu Sep 16 21:47:30 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 16 Sep 2021 21:47:30 GMT
Subject: RFR: Track promotion rate into old generation
In-Reply-To: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
References: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
Message-ID: <NbYQ9rSmgV0cxLV2UqstwYCX9A2OkHEwB4CWlWg3dGs=.9d20e22a-71bd-405a-a425-1b08662927e1@github.com>

On Thu, 16 Sep 2021 20:38:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.

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

> 1036:     } else {
> 1037:       if (req.is_old()) {
> 1038:         old_generation()->increase_allocated(actual_bytes);

I'm not sure I follow all the logic.  When we allocate a PLAB for promotions into old-gen, we want to increment the promotion rate.  But when we allocate a ?LAB to hold the results of an old-gen allocation, that should not be counted as "promotion" memory.  Are we distinguishing these two cases?

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

PR: https://git.openjdk.java.net/shenandoah/pull/70

From wkemper at openjdk.java.net  Thu Sep 16 22:02:56 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 16 Sep 2021 22:02:56 GMT
Subject: RFR: Track promotion rate into old generation
In-Reply-To: <NbYQ9rSmgV0cxLV2UqstwYCX9A2OkHEwB4CWlWg3dGs=.9d20e22a-71bd-405a-a425-1b08662927e1@github.com>
References: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
 <NbYQ9rSmgV0cxLV2UqstwYCX9A2OkHEwB4CWlWg3dGs=.9d20e22a-71bd-405a-a425-1b08662927e1@github.com>
Message-ID: <Jey2G_PH-jeG6tDEQKUpxItSfgbklcc7LtJF7aLXcbQ=.9e81720a-cda7-43ac-90b8-2c180ca6b82e@github.com>

On Thu, 16 Sep 2021 21:43:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1038:
> 
>> 1036:     } else {
>> 1037:       if (req.is_old()) {
>> 1038:         old_generation()->increase_allocated(actual_bytes);
> 
> I'm not sure I follow all the logic.  When we allocate a PLAB for promotions into old-gen, we want to increment the promotion rate.  But when we allocate a ?LAB to hold the results of an old-gen evacuation, that should not be counted as "promotion" memory.  Are we distinguishing these two cases?

Ah, that's a good catch. I think this would count evacuations in old as part of the promotion rate. Will work on a fix.

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

PR: https://git.openjdk.java.net/shenandoah/pull/70

From gnu.andrew at redhat.com  Fri Sep 17 00:21:07 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 17 Sep 2021 01:21:07 +0100
Subject: [RFR] [8u] 8u312-b03 Upstream Sync
Message-ID: <YUPfczB3UbOHyOIH@hex.discworld.ac.uk>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u312-b03:
  - JDK-8237495: Java MIDI fails with a dereferenced memory error when asked to send a raw 0xF7
  - JDK-8254967: com.sun.net.HttpsServer spins on TLS session close
  - JDK-8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M
  - JDK-8266206: Build failure after JDK-8264752 with older GCCs
  - JDK-8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup
  - JDK-8272214: [8u] Build failure after backport of JDK-8248901

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for corba
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxp
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxws
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for langtools
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for nashorn
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jdk
 b/.hgtags                                                           |    1 
 b/src/share/classes/sun/net/httpserver/SSLStreams.java              |    7 
 b/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java |   70 ++---
 b/src/share/classes/sun/security/krb5/internal/ReferralsCache.java  |   46 ++-
 b/src/share/native/com/sun/media/sound/MidiOutDevice.c              |    4 
 b/test/javax/sound/midi/SysexMessage/SendRawSysexMessage.java       |  121 ++++++++++
 b/test/jdk/jfr/startupargs/TestBadOptionValues.java                 |   31 ++
 b/test/jdk/jfr/startupargs/TestMemoryOptions.java                   |    5 
 b/test/sun/security/krb5/auto/ReferralsTest.java                    |   22 +
 9 files changed, 253 insertions(+), 54 deletions(-)

diffstat for hotspot
 b/.hgtags                                              |    1 
 b/src/share/vm/jfr/recorder/service/jfrMemorySizer.cpp |   16 +++
 b/src/share/vm/jfr/recorder/service/jfrMemorySizer.hpp |    4 
 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp   |   71 ++++++++++++++---
 b/src/share/vm/utilities/globalDefinitions.hpp         |    5 +
 b/src/share/vm/utilities/globalDefinitions_visCPP.hpp  |    7 +
 6 files changed, 92 insertions(+), 12 deletions(-)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Fri Sep 17 05:34:54 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 17 Sep 2021 07:34:54 +0200
Subject: [RFR] [8u] 8u312-b03 Upstream Sync
In-Reply-To: <YUPfczB3UbOHyOIH@hex.discworld.ac.uk>
References: <YUPfczB3UbOHyOIH@hex.discworld.ac.uk>
Message-ID: <abc6bcc6-1233-9e95-4ae8-592c9e71778f@redhat.com>

On 9/17/21 2:21 AM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jaxws/merge.changeset

Trivially fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jdk/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/hotspot/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/root/merge.changeset

Trivially fine.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From wkemper at openjdk.java.net  Fri Sep 17 17:10:22 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 17 Sep 2021 17:10:22 GMT
Subject: RFR: Fix loop error when reconstructing remembered set for humongous
 objects
Message-ID: <LwfH9nqzgepdk9-koCLD7x2uoN5i0EZDKkPbcxsLePE=.90c5d0b4-4b59-46b1-a934-9a8a80b0a581@github.com>

Also a small fix to avoid public `get_update_watermark` method when logging changes to a region affiliation.

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

Commit messages:
 - Avoid public API for update watermark when logging
 - End of object will be top of region, not bottom

Changes: https://git.openjdk.java.net/shenandoah/pull/71/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=71&range=00
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/71.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/71/head:pull/71

PR: https://git.openjdk.java.net/shenandoah/pull/71

From wkemper at openjdk.java.net  Fri Sep 17 20:53:20 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 17 Sep 2021 20:53:20 GMT
Subject: Integrated: Fix loop error when reconstructing remembered set for
 humongous objects
In-Reply-To: <LwfH9nqzgepdk9-koCLD7x2uoN5i0EZDKkPbcxsLePE=.90c5d0b4-4b59-46b1-a934-9a8a80b0a581@github.com>
References: <LwfH9nqzgepdk9-koCLD7x2uoN5i0EZDKkPbcxsLePE=.90c5d0b4-4b59-46b1-a934-9a8a80b0a581@github.com>
Message-ID: <ZYDPclzm-KyqObsImrp-jZzHeoyW6W3dNVVbLv6EYh4=.7827b1af-05a8-43e6-b62c-0dd4bfe0760d@github.com>

On Fri, 17 Sep 2021 17:03:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Also a small fix to avoid public `get_update_watermark` method when logging changes to a region affiliation.

This pull request has now been integrated.

Changeset: fd275426
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/fd2754268dc0f00d6b46ae84c4de1fa9b957dd17
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

Fix loop error when reconstructing remembered set for humongous objects

Reviewed-by: rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/71

From wkemper at openjdk.java.net  Fri Sep 17 21:25:39 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 17 Sep 2021 21:25:39 GMT
Subject: RFR: Track promotion rate into old generation [v2]
In-Reply-To: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
References: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
Message-ID: <P6Imrv1NQfGFDxIaFqc8S6rZpne208DBuUJ-QeRBHWE=.ce894f1d-0aa2-433f-af89-78e159fbea49@github.com>

> The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.

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

 - Only register successful old evacuations
 - Only treat promotions as old gen allocations

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/70/files
  - new: https://git.openjdk.java.net/shenandoah/pull/70/files/9f4d5d20..588c5203

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=70&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=70&range=00-01

  Stats: 71 lines in 3 files changed: 18 ins; 45 del; 8 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/70.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/70/head:pull/70

PR: https://git.openjdk.java.net/shenandoah/pull/70

From gnu.andrew at redhat.com  Sun Sep 19 12:44:59 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 19 Sep 2021 13:44:59 +0100
Subject: [RFR] [8u] 8u312-b03 Upstream Sync
In-Reply-To: <abc6bcc6-1233-9e95-4ae8-592c9e71778f@redhat.com>
References: <YUPfczB3UbOHyOIH@hex.discworld.ac.uk>
 <abc6bcc6-1233-9e95-4ae8-592c9e71778f@redhat.com>
Message-ID: <YUcwy7TTrv/P1P1q@hex.discworld.ac.uk>

On 07:34 Fri 17 Sep     , Aleksey Shipilev wrote:
> On 9/17/21 2:21 AM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jaxws/merge.changeset
> 
> Trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/jdk/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/hotspot/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b03/root/merge.changeset
> 
> Trivially fine.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks, pushed.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From github.com+5106647+oscerd at openjdk.java.net  Mon Sep 20 13:51:28 2021
From: github.com+5106647+oscerd at openjdk.java.net (Andrea Cosentino)
Date: Mon, 20 Sep 2021 13:51:28 GMT
Subject: RFR: Update LogCompilation junit to 4.13.2
Message-ID: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>

I don't have an account on the issue tracker for creating an issue to track this one.

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

Commit messages:
 - Update LogCompilation junit to 4.13.2

Changes: https://git.openjdk.java.net/shenandoah/pull/72/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=72&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/72.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/72/head:pull/72

PR: https://git.openjdk.java.net/shenandoah/pull/72

From rkennke at openjdk.java.net  Mon Sep 20 15:12:23 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 20 Sep 2021 15:12:23 GMT
Subject: RFR: Update LogCompilation junit to 4.13.2
In-Reply-To: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
References: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
Message-ID: <q-peTaoi1C6SlIX-FdUiosfh405xeoRlGwe6-A5s65U=.77038c8d-1cb2-4ed3-aaaa-1436ac626cca@github.com>

On Mon, 20 Sep 2021 13:27:24 GMT, Andrea Cosentino <github.com+5106647+oscerd at openjdk.org> wrote:

> I don't have an account on the issue tracker for creating an issue to track this one.

Can you describe what is the intention behind the change and why we should include it in the Shenandoah repo and not, e.g., in upstream JDK?

Thanks,
Roman

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

PR: https://git.openjdk.java.net/shenandoah/pull/72

From rkennke at openjdk.java.net  Mon Sep 20 15:15:54 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 20 Sep 2021 15:15:54 GMT
Subject: RFR: Track promotion rate into old generation [v2]
In-Reply-To: <P6Imrv1NQfGFDxIaFqc8S6rZpne208DBuUJ-QeRBHWE=.ce894f1d-0aa2-433f-af89-78e159fbea49@github.com>
References: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
 <P6Imrv1NQfGFDxIaFqc8S6rZpne208DBuUJ-QeRBHWE=.ce894f1d-0aa2-433f-af89-78e159fbea49@github.com>
Message-ID: <4rzg1_kVS1nDP7lkYn5IRpmnAQtDC552_NM9pQUiAi0=.f5d708c2-d4e9-468a-964c-70c3d3fdb21a@github.com>

On Fri, 17 Sep 2021 21:25:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Only register successful old evacuations
>  - Only treat promotions as old gen allocations

Looks good to me, thanks!

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

Marked as reviewed by rkennke (Lead).

PR: https://git.openjdk.java.net/shenandoah/pull/70

From github.com+5106647+oscerd at openjdk.java.net  Mon Sep 20 15:18:24 2021
From: github.com+5106647+oscerd at openjdk.java.net (Andrea Cosentino)
Date: Mon, 20 Sep 2021 15:18:24 GMT
Subject: RFR: Update LogCompilation junit to 4.13.2
In-Reply-To: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
References: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
Message-ID: <AzQWGkr47aU8yAs0cV5-THNSS90R7vqISJHgW_-FJ14=.79ac1c4e-ae22-4ad3-9f80-4018bec4044e@github.com>

On Mon, 20 Sep 2021 13:27:24 GMT, Andrea Cosentino <github.com+5106647+oscerd at openjdk.org> wrote:

> I don't have an account on the issue tracker for creating an issue to track this one.

My intention was mainly to understand the workflow to contribute. In the beginning i was looking for something to start so I looked at old commits. It's not an important change and if it needs to be done in openjdk in general I'll look there eventually. Thanks for pointing it out

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

PR: https://git.openjdk.java.net/shenandoah/pull/72

From github.com+5106647+oscerd at openjdk.java.net  Mon Sep 20 15:18:24 2021
From: github.com+5106647+oscerd at openjdk.java.net (Andrea Cosentino)
Date: Mon, 20 Sep 2021 15:18:24 GMT
Subject: Withdrawn: Update LogCompilation junit to 4.13.2
In-Reply-To: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
References: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
Message-ID: <kx-CPFtDN13gpmJJtzAHCPJFMxP0_sqGJ060JQGHCYE=.8e5b437e-f1a5-4f0b-ab3e-d59d79f247e2@github.com>

On Mon, 20 Sep 2021 13:27:24 GMT, Andrea Cosentino <github.com+5106647+oscerd at openjdk.org> wrote:

> I don't have an account on the issue tracker for creating an issue to track this one.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/shenandoah/pull/72

From kdnilsen at openjdk.java.net  Mon Sep 20 16:15:17 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 20 Sep 2021 16:15:17 GMT
Subject: RFR: Track promotion rate into old generation [v2]
In-Reply-To: <P6Imrv1NQfGFDxIaFqc8S6rZpne208DBuUJ-QeRBHWE=.ce894f1d-0aa2-433f-af89-78e159fbea49@github.com>
References: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
 <P6Imrv1NQfGFDxIaFqc8S6rZpne208DBuUJ-QeRBHWE=.ce894f1d-0aa2-433f-af89-78e159fbea49@github.com>
Message-ID: <k-1LlD0alJgZ_00jXbQGPhpDfHi5kJNtfHhrRt8V38E=.2e469c8a-ba0a-40c5-adc2-eab3742461a3@github.com>

On Fri, 17 Sep 2021 21:25:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Only register successful old evacuations
>  - Only treat promotions as old gen allocations

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/70

From wkemper at openjdk.java.net  Mon Sep 20 16:25:24 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 20 Sep 2021 16:25:24 GMT
Subject: Integrated: Track promotion rate into old generation
In-Reply-To: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
References: <U5EwConxmy7zrSkRlLFXds-PYecH3p94ZQsJoMquUDo=.54c5875f-ea5f-4e76-b528-31bf79d36398@github.com>
Message-ID: <gNXeyqg_PUvS7NGATHNXot0R-AjzmsiDt16QP7uEe04=.780c8ebf-f052-45b9-b64b-c1773de12897@github.com>

On Thu, 16 Sep 2021 20:38:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The member `_bytes_allocated_since_last_gc` has been moved into the `ShenandoahGeneration` abstraction and is updated accordingly. Evacuations into the old generation (i.e., promotion) are counted as allocations against the old generation. Promotion of entire regions is not recorded in the promotion rate.

This pull request has now been integrated.

Changeset: 52973cc9
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/52973cc9b2ef8e5768fbd6fd24604978240a144a
Stats:     133 lines in 8 files changed: 62 ins; 56 del; 15 mod

Track promotion rate into old generation

Reviewed-by: rkennke, kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/70

From github.com+5106647+oscerd at openjdk.java.net  Mon Sep 20 17:10:21 2021
From: github.com+5106647+oscerd at openjdk.java.net (Andrea Cosentino)
Date: Mon, 20 Sep 2021 17:10:21 GMT
Subject: RFR: Update LogCompilation junit to 4.13.2
In-Reply-To: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
References: <M8NiCEIuljeoxr-oIkbNK61jA1-xs_UeKizYBt2DSD0=.7acfc867-b444-4abb-9859-57300a74f5a7@github.com>
Message-ID: <qUkP0QRvW1XwbB8wlEMQhjwRgVZxttnVzKoVZt1yV4s=.106c7798-c874-4be2-a4f2-c641e9dd34c9@github.com>

On Mon, 20 Sep 2021 13:27:24 GMT, Andrea Cosentino <github.com+5106647+oscerd at openjdk.org> wrote:

> I don't have an account on the issue tracker for creating an issue to track this one.

Sorry for the noise.

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

PR: https://git.openjdk.java.net/shenandoah/pull/72

From wkemper at openjdk.java.net  Wed Sep 22 17:19:01 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 22 Sep 2021 17:19:01 GMT
Subject: Integrated: Fix failing jtreg tests
Message-ID: <phbjxTHRd_ZOJg19MY_hCxTeVwoLhw__nobRsmgm2Bo=.82940a1e-42c7-49c6-9f30-14ee09492f73@github.com>

With these (minor) changes, generational Shenandoah passes the full suite of Shenandoah jtreg tests.

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

Commit messages:
 - Fix missing include
 - Increment GC ID before starting cycle (fixes whitebox breakpoint tests)
 - Use fully qualified name for ClassFileInstaller

Changes: https://git.openjdk.java.net/shenandoah/pull/73/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=73&range=00
  Stats: 24 lines in 4 files changed: 3 ins; 17 del; 4 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/73.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/73/head:pull/73

PR: https://git.openjdk.java.net/shenandoah/pull/73

From kdnilsen at openjdk.java.net  Wed Sep 22 17:19:01 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 22 Sep 2021 17:19:01 GMT
Subject: Integrated: Fix failing jtreg tests
In-Reply-To: <phbjxTHRd_ZOJg19MY_hCxTeVwoLhw__nobRsmgm2Bo=.82940a1e-42c7-49c6-9f30-14ee09492f73@github.com>
References: <phbjxTHRd_ZOJg19MY_hCxTeVwoLhw__nobRsmgm2Bo=.82940a1e-42c7-49c6-9f30-14ee09492f73@github.com>
Message-ID: <enbD7TiyAUfZkN7KrYdylmSwEPP9TswsUlu3h8sIM3Q=.c90f22ab-ced8-477a-8c57-cb88fc4b6d38@github.com>

On Wed, 22 Sep 2021 17:07:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> With these (minor) changes, generational Shenandoah passes the full suite of Shenandoah jtreg tests.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/73

From wkemper at openjdk.java.net  Wed Sep 22 17:19:02 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 22 Sep 2021 17:19:02 GMT
Subject: Integrated: Fix failing jtreg tests
In-Reply-To: <phbjxTHRd_ZOJg19MY_hCxTeVwoLhw__nobRsmgm2Bo=.82940a1e-42c7-49c6-9f30-14ee09492f73@github.com>
References: <phbjxTHRd_ZOJg19MY_hCxTeVwoLhw__nobRsmgm2Bo=.82940a1e-42c7-49c6-9f30-14ee09492f73@github.com>
Message-ID: <GoYpVrvZkBYho8u1KSlojfYpieP61_8b3cSSbm5zbow=.404b3078-1740-48f4-a111-7b03b8cfe3a4@github.com>

On Wed, 22 Sep 2021 17:07:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> With these (minor) changes, generational Shenandoah passes the full suite of Shenandoah jtreg tests.

This pull request has now been integrated.

Changeset: f9e068dc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/f9e068dce2fecf6a0705a4685ea2f336e65ea2a5
Stats:     24 lines in 4 files changed: 3 ins; 17 del; 4 mod

Fix failing jtreg tests

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/73

From gnu.andrew at redhat.com  Mon Sep 27 14:18:22 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 27 Sep 2021 15:18:22 +0100
Subject: [RFR] [8u] 8u312-b04 Upstream Sync
Message-ID: <YVHSrrVRn2mZ7Mel@hex.discworld.ac.uk>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u312-b04:
  - JDK-6847157: java.lang.NullPointerException: HDC for component at sun.java2d.loops.Blit.Blit
  - JDK-8161016: Strange behavior of URLConnection with proxy
  - JDK-8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism
  - JDK-8194246: JVM crashes when calling getStackTrace if stack contains a method that is a member of a very large class
  - JDK-8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files
  - JDK-8263382: java/util/logging/ParentLoggersTest.java failed with "checkLoggers: getLoggerNames() returned unexpected loggers"
  - JDK-8268103: JNI functions incorrectly return a double after JDK-8265836
  - JDK-8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark
  - JDK-8269859: BacktraceBuilder._cprefs needs to be accessed as unsigned short
  - JDK-8269882: stack-use-after-scope in NewObjectA

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags            |    1 
 b/THIRD_PARTY_README |   92 +++++++++++++++++++++++++++++++++++----------------
 2 files changed, 65 insertions(+), 28 deletions(-)

diffstat for corba
 b/.hgtags            |    1 
 b/THIRD_PARTY_README |   92 +++++++++++++++++++++++++++++++++++----------------
 2 files changed, 65 insertions(+), 28 deletions(-)

diffstat for jaxp
 b/.hgtags            |    1 
 b/THIRD_PARTY_README |   92 +++++++++++++++++++++++++++++++++++----------------
 2 files changed, 65 insertions(+), 28 deletions(-)

diffstat for jaxws
 b/.hgtags            |    1 
 b/THIRD_PARTY_README |   92 +++++++++++++++++++++++++++++++++++----------------
 2 files changed, 65 insertions(+), 28 deletions(-)

diffstat for langtools
 b/.hgtags            |    1 
 b/THIRD_PARTY_README |   92 +++++++++++++++++++++++++++++++++++----------------
 2 files changed, 65 insertions(+), 28 deletions(-)

diffstat for nashorn
 b/.hgtags            |    1 
 b/THIRD_PARTY_README |   92 +++++++++++++++++++++++++++++++++++----------------
 2 files changed, 65 insertions(+), 28 deletions(-)

diffstat for jdk
 b/.hgtags                                                            |    1 
 b/THIRD_PARTY_README                                                 |   92 
 b/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java |    7 
 b/src/share/classes/sun/security/pkcs11/wrapper/Functions.java       |  213 +
 b/src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java |  340 ++
 b/src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java |  202 -
 b/src/share/classes/sun/security/ssl/SSLSocketImpl.java              |   12 
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11.h              |   73 
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11f.h             |  260 ++
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h             | 1164 ++++++----
 b/src/solaris/native/sun/management/OperatingSystemImpl.c            |    2 
 b/src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp     |    7 
 b/test/java/awt/Paint/RepaintOnAWTShutdown.java                      |   88 
 b/test/java/net/HttpURLConnection/HttpURLConWithProxy.java           |  106 
 b/test/java/util/logging/ParentLoggersTest.java                      |    2 
 b/test/sun/security/ssl/SSLSocketImpl/SSLSocketReset.java            |  108 
 16 files changed, 2067 insertions(+), 610 deletions(-)

diffstat for hotspot
 b/.hgtags                                     |    1 
 b/THIRD_PARTY_README                          |   92 +++++++++++-----
 b/src/share/vm/classfile/javaClasses.cpp      |   12 +-
 b/src/share/vm/prims/jni.cpp                  |    2 
 b/src/share/vm/runtime/safepoint.cpp          |    1 
 b/test/runtime/StackTrace/LargeClassTest.java |  147 ++++++++++++++++++++++++++
 6 files changed, 220 insertions(+), 35 deletions(-)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Mon Sep 27 14:28:40 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 27 Sep 2021 16:28:40 +0200
Subject: [RFR] [8u] 8u312-b04 Upstream Sync
In-Reply-To: <YVHSrrVRn2mZ7Mel@hex.discworld.ac.uk>
References: <YVHSrrVRn2mZ7Mel@hex.discworld.ac.uk>
Message-ID: <83bdb46c-f07a-ff4c-c5ad-5ef70da10cde@redhat.com>

On 9/27/21 4:18 PM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/jaxws/merge.changeset

THIRD_PARTY_README changes only. Look good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/jdk/merge.changeset

PKCS updates. Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/hotspot/merge.changeset

Yay, my constant pool overflow fixes. Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b04/root/merge.changeset

THIRD_PARTY_README changes only. Look good.

> Ok to push?

Yes.


-- 
Thanks,
-Aleksey


From wkemper at openjdk.java.net  Tue Sep 28 22:57:05 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 28 Sep 2021 22:57:05 GMT
Subject: RFR: Also register filler object for retired gclabs
Message-ID: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>

Shenandoah verify will complain that the objects created when gclabs are retired are not properly registered. We already have code to register objects when the promotion labs are retired, this change extends it to also cover other gclabs.

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

Commit messages:
 - Also register filler object for retired gclabs

Changes: https://git.openjdk.java.net/shenandoah/pull/74/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=74&range=00
  Stats: 15 lines in 1 file changed: 4 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/74.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/74/head:pull/74

PR: https://git.openjdk.java.net/shenandoah/pull/74

From kdnilsen at openjdk.java.net  Tue Sep 28 23:10:19 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 28 Sep 2021 23:10:19 GMT
Subject: RFR: Also register filler object for retired gclabs
In-Reply-To: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>
References: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>
Message-ID: <B4wFEbVA0pf0yRFWgOj-aBZ3m1ERvKQ2d6TwwSiJNlc=.5f73158e-7931-45d0-9abe-5a954e3f7c98@github.com>

On Tue, 28 Sep 2021 22:50:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah verify will complain that the objects created when gclabs are retired are not properly registered. We already have code to register objects when the promotion labs are retired, this change extends it to also cover other gclabs.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/74

From rkennke at openjdk.java.net  Wed Sep 29 09:43:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 29 Sep 2021 09:43:28 GMT
Subject: RFR: Also register filler object for retired gclabs
In-Reply-To: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>
References: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>
Message-ID: <XeN678-zTfhZ58puCdpvZ13Ot1ZJGoFcC7PdNUtHLXg=.dc57ab4c-95d1-44ae-8352-0c43608a2f8d@github.com>

On Tue, 28 Sep 2021 22:50:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah verify will complain that the objects created when gclabs are retired are not properly registered. We already have code to register objects when the promotion labs are retired, this change extends it to also cover other gclabs.

Marked as reviewed by rkennke (Lead).

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

PR: https://git.openjdk.java.net/shenandoah/pull/74

From kdnilsen at openjdk.java.net  Wed Sep 29 17:04:37 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 29 Sep 2021 17:04:37 GMT
Subject: RFR: Full region promotion
Message-ID: <OTCzmWWO7O83CUW_-9MKj16fM7aYfv-djOpVdcYWMHQ=.32070277-f0b4-407f-9ff1-c23f1dd2309b@github.com>

Prior to this patch, full-region-promotion occurred during the final-evacuation safepoint.  When heap regions are very large (e.g. 16 MB) and a large number of heap regions need to be promoted, this was measured to require over 500 ms in certain scenarios.  Another disadvantage of the prior implementation is that entire heap regions are promoted as-is without any compaction.  A problem with this is that all fragments of garbage within the young-region are promoted into old-gen, where the target heap-region utilization is generally much higher than heap-utilization target within young-gen memory.  Once promoted, it is much more costly to compact this memory because an old-gen collection is much more expensive than a young-gen collection.

This patch moves region promotion out of the safepoint.  Regions that have reached the tenure age are biased for inclusion within the collection set and are processed during concurrent evacuation using the established conventions.  Humongous heap regions are also promoted during concurrent evacuation rather than during the safepoint.

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

Commit messages:
 - Fix whitespace
 - Add comment to explain avoidance of floating point math
 - Respond to reviewer feedback
 - Remove instrumentation
 - Tinkering with instrumentation
 - Fix error in collection-set evacuation under generational mode
 - Merge branch 'shenandoah' into full-region-promotion
 - New instrumentation to chase a new bug
 - Dial back instrumentation
 - Remove deprecated code for whole-region promotion
 - ... and 6 more: https://git.openjdk.java.net/shenandoah/compare/f9e068dc...5921401e

Changes: https://git.openjdk.java.net/shenandoah/pull/75/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=75&range=00
  Stats: 308 lines in 13 files changed: 111 ins; 150 del; 47 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/75.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/75/head:pull/75

PR: https://git.openjdk.java.net/shenandoah/pull/75

From wkemper at openjdk.java.net  Wed Sep 29 18:24:15 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 29 Sep 2021 18:24:15 GMT
Subject: Integrated: Also register filler object for retired gclabs
In-Reply-To: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>
References: <QfAnPq0yismjIBg1Z0glersi1S0cbNovuQ2M2WxrUO4=.a4833d3c-2228-41a8-9141-34baafa757f1@github.com>
Message-ID: <4EsKa8D3jBxcZQpqKF3Xye6VtopJCmCgX-OdTMSlj_U=.eaaf4779-767a-4216-8647-7269a5bfbb6d@github.com>

On Tue, 28 Sep 2021 22:50:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah verify will complain that the objects created when gclabs are retired are not properly registered. We already have code to register objects when the promotion labs are retired, this change extends it to also cover other gclabs.

This pull request has now been integrated.

Changeset: ea8469a1
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/ea8469a118d21e41ecbaca17478bd2e7617dbeed
Stats:     15 lines in 1 file changed: 4 ins; 0 del; 11 mod

Also register filler object for retired gclabs

Reviewed-by: kdnilsen, rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/74

From wkemper at openjdk.java.net  Wed Sep 29 19:24:25 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 29 Sep 2021 19:24:25 GMT
Subject: RFR: Decouple generational heuristics
Message-ID: <WSE5IM0JRpfrkKIwmQjLBbG3SLLwtbKXQdOQ6XXhouY=.fc40ea27-c44e-41d4-9efa-41387f15308e@github.com>

### Summary
This commit is part of an effort to improve the performance of the old generation heuristic.

* added `ShenandoahOldGCHeuristics` - choose the heuristic for old generation (adaptive is default, aggressive is not allowed, only used to trigger old marking, has no influence on cset selection for old generation).
* added `ShenandoahOldGarbageThreshold` - The minimum percentage of garbage in old region to be included in old cset.
* added `ShenandoahOldEvacReserve` - Percentage of old generation to withhold from old evacuation.
* added `ShenandoahGuaranteedOldGCInterval` - Minimum time between old generation collection (default is 10 min).
* refactored old generation heuristic class hierarchy to reduce code duplication
* added more detail to log messages and formatted byte sizes for easier human readability

### Testing
Passes tier3 shenandoah jtreg tests and Dacapo and Heapothesys on x86 and aarch64.

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

Commit messages:
 - Log immediate and collectable garbage for old generation
 - Merge branch 'shenandoah' into decouple-gen-heuristics
 - Fix uninitialized member
 - Merge branch 'shenandoah' into decouple-gen-heuristics
 - Apply configuration to old gen's trigger heuristic
 - Add parameter to control guaranteed gc interval for old generation
 - Add parameters to control Old generation cset selection
 - Record name of generation in log message
 - Merge branch 'promotion-rate-heuristic' into decouple-gen-heuristics
 - Merge branch 'shenandoah' into promotion-rate-heuristic
 - ... and 11 more: https://git.openjdk.java.net/shenandoah/compare/ea8469a1...45153b9e

Changes: https://git.openjdk.java.net/shenandoah/pull/76/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=76&range=00
  Stats: 1239 lines in 29 files changed: 206 ins; 995 del; 38 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/76.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/76/head:pull/76

PR: https://git.openjdk.java.net/shenandoah/pull/76

From wkemper at openjdk.java.net  Wed Sep 29 23:02:26 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 29 Sep 2021 23:02:26 GMT
Subject: RFR: Introduce second mark bitmap to support remembered set scan
In-Reply-To: <OzhYD7n6GRWkHZzUFjKJb6fyPYmotZrXX506j2_eWV0=.943d79cb-52b5-4f66-a12d-f01b13f8b61c@github.com>
References: <OzhYD7n6GRWkHZzUFjKJb6fyPYmotZrXX506j2_eWV0=.943d79cb-52b5-4f66-a12d-f01b13f8b61c@github.com>
Message-ID: <aFQaVHhS8RvZiacxFUFQgp47NNohUyT7z6lfNygVvJo=.376da4ba-dce8-40e1-b195-13587fa82e42@github.com>

On Mon, 21 Jun 2021 21:48:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ## Motivation
> After final mark, Shenandoah chooses the collection set (regions that will be reclaimed). If there is a sufficient amount of reclaimable memory in regions that are 100% garbage, it recycles them immediately and skips the evacuation and update reference phases (there are no pointers into these 100% garbage regions). Note that in this case there are still dead objects in regions outside of the collection set. During subsequent remembered set scans, Shenandoah must safely iterate objects in regions of memory indicated by marked cards. Specifically, it must not attempt to iterate over oops in the dead objects outside the collection set. Prior to the changes in this review, Generational Shenandoah disarmed these dead objects by coalescing them and then overwriting them with filler objects during the update references phase. There are some drawbacks to this approach:
> 
> * Originally, Generational Shenandoah used the oopDesc::size API to compute the size of filler objects. This API uses the klass for the oop to provide the size. Since we were using the size method on dead oops, if there were no instances of the klass still alive it could be unloaded during weak root processing and the size method would fail. To prevent this issue, we disabled ClassUnloading. 
> * We now use the mark bitmap to compute the size of dead objects, but there is still a risk here: when young collections coalesce and fill dead objects during concurrent old generation marking, the mark bitmap is incomplete.
> * It forced us to go through evacuation and update reference phases for every cycle. Our tests (Dacapo) show that approximately 33% of collections (with the default settings) find enough pure garbage regions to complete without evacuations.
> * It forces the collector to perform work proportional to the amount of garbage outside the collection set (in the old generation). For performance reasons, the collector should avoid any work which is proportional to the amount of garbage.
> 
> ## Overview of Changes
> Rather than filling in dead objects to provide safety to the remembered set scan, the scan now uses the marking bit map to skip over dead objects. This leverages the work already completed during the marking phase and no longer requires any additional maintenance work during the update reference phase. There are, however, a few wrinkles to consider:
> 
> * The evacuation phase needs to update the mark bitmap. This essentially mimics the work currently done to register objects with the remembered set.
> * During concurrent old marking, the remembered set scan cannot rely on the mark bitmap for the old generation. For this reason, a second bitmap has been added. At the beginning of a concurrent old mark, the bitmaps are switched. During concurrent old marking, the remembered set scan will use the previous (i.e., stable) bitmap for determining object liveness.
> * Though not directly related to these changes, a fix for reference processing has been implemented in terms of these changes (i.e., the fix uses the secondary bitmap). Please note, the "fix" for reference processing is incorrect. It does not preserve the atomicity required when null'ing out references. Work on reference processing is proceeding on a separate branch, unrelated to these changes.
> 
> ## Remaining Work
> 
> * Object registration should no longer be necessary. We can use the mark bitmap to tell us if a card has any objects.
> * Shenandoah has an optimization to avoid clearing bitmap regions that are known to contain no marked bits. This optimization is currently disabled. It needs to be debugged (I think it is confused by extra marks made during evacuation).
> * Region promotions that happen during a concurrent old mark must copy the bitmap of the promoted region - this is currently done in a most inefficient way.

Closing this for now.

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

PR: https://git.openjdk.java.net/shenandoah/pull/50

From wkemper at openjdk.java.net  Wed Sep 29 23:02:26 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 29 Sep 2021 23:02:26 GMT
Subject: Withdrawn: Introduce second mark bitmap to support remembered set scan
In-Reply-To: <OzhYD7n6GRWkHZzUFjKJb6fyPYmotZrXX506j2_eWV0=.943d79cb-52b5-4f66-a12d-f01b13f8b61c@github.com>
References: <OzhYD7n6GRWkHZzUFjKJb6fyPYmotZrXX506j2_eWV0=.943d79cb-52b5-4f66-a12d-f01b13f8b61c@github.com>
Message-ID: <NSel_so3Yn9Vfb7kIZ4Tmcog92hHLL388NjaM13wLOk=.47f6a89e-e584-4e15-b74a-03e3d2c72ca2@github.com>

On Mon, 21 Jun 2021 21:48:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ## Motivation
> After final mark, Shenandoah chooses the collection set (regions that will be reclaimed). If there is a sufficient amount of reclaimable memory in regions that are 100% garbage, it recycles them immediately and skips the evacuation and update reference phases (there are no pointers into these 100% garbage regions). Note that in this case there are still dead objects in regions outside of the collection set. During subsequent remembered set scans, Shenandoah must safely iterate objects in regions of memory indicated by marked cards. Specifically, it must not attempt to iterate over oops in the dead objects outside the collection set. Prior to the changes in this review, Generational Shenandoah disarmed these dead objects by coalescing them and then overwriting them with filler objects during the update references phase. There are some drawbacks to this approach:
> 
> * Originally, Generational Shenandoah used the oopDesc::size API to compute the size of filler objects. This API uses the klass for the oop to provide the size. Since we were using the size method on dead oops, if there were no instances of the klass still alive it could be unloaded during weak root processing and the size method would fail. To prevent this issue, we disabled ClassUnloading. 
> * We now use the mark bitmap to compute the size of dead objects, but there is still a risk here: when young collections coalesce and fill dead objects during concurrent old generation marking, the mark bitmap is incomplete.
> * It forced us to go through evacuation and update reference phases for every cycle. Our tests (Dacapo) show that approximately 33% of collections (with the default settings) find enough pure garbage regions to complete without evacuations.
> * It forces the collector to perform work proportional to the amount of garbage outside the collection set (in the old generation). For performance reasons, the collector should avoid any work which is proportional to the amount of garbage.
> 
> ## Overview of Changes
> Rather than filling in dead objects to provide safety to the remembered set scan, the scan now uses the marking bit map to skip over dead objects. This leverages the work already completed during the marking phase and no longer requires any additional maintenance work during the update reference phase. There are, however, a few wrinkles to consider:
> 
> * The evacuation phase needs to update the mark bitmap. This essentially mimics the work currently done to register objects with the remembered set.
> * During concurrent old marking, the remembered set scan cannot rely on the mark bitmap for the old generation. For this reason, a second bitmap has been added. At the beginning of a concurrent old mark, the bitmaps are switched. During concurrent old marking, the remembered set scan will use the previous (i.e., stable) bitmap for determining object liveness.
> * Though not directly related to these changes, a fix for reference processing has been implemented in terms of these changes (i.e., the fix uses the secondary bitmap). Please note, the "fix" for reference processing is incorrect. It does not preserve the atomicity required when null'ing out references. Work on reference processing is proceeding on a separate branch, unrelated to these changes.
> 
> ## Remaining Work
> 
> * Object registration should no longer be necessary. We can use the mark bitmap to tell us if a card has any objects.
> * Shenandoah has an optimization to avoid clearing bitmap regions that are known to contain no marked bits. This optimization is currently disabled. It needs to be debugged (I think it is confused by extra marks made during evacuation).
> * Region promotions that happen during a concurrent old mark must copy the bitmap of the promoted region - this is currently done in a most inefficient way.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/shenandoah/pull/50

From wkemper at openjdk.java.net  Wed Sep 29 23:08:32 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 29 Sep 2021 23:08:32 GMT
Subject: RFR: Only register retired plab waste in old regions
Message-ID: <m301azXLLbnNjWB4y0GsrlzZCnSgEnK7XIP09ZRSjq4=.8cf5d60a-d118-464b-b44f-15411111938e@github.com>

This is a follow up to [PR 74](https://github.com/openjdk/shenandoah/pull/74) in which we register filler objects from retired gclabs. This should _only_ be done if the plab was in an old region. Registering young objects in the remembered set confuses the verifier.

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

Commit messages:
 - Only register retired plab waste in old regions

Changes: https://git.openjdk.java.net/shenandoah/pull/77/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=77&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/77.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/77/head:pull/77

PR: https://git.openjdk.java.net/shenandoah/pull/77

From kdnilsen at openjdk.java.net  Thu Sep 30 00:15:33 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 30 Sep 2021 00:15:33 GMT
Subject: RFR: Only register retired plab waste in old regions
In-Reply-To: <m301azXLLbnNjWB4y0GsrlzZCnSgEnK7XIP09ZRSjq4=.8cf5d60a-d118-464b-b44f-15411111938e@github.com>
References: <m301azXLLbnNjWB4y0GsrlzZCnSgEnK7XIP09ZRSjq4=.8cf5d60a-d118-464b-b44f-15411111938e@github.com>
Message-ID: <rveJqWPu5sGJrFPhvBTrBG6Or1i0O1gov3cmB2jRYSE=.fb60e806-b90b-46c2-bf74-95b5f775fd4c@github.com>

On Wed, 29 Sep 2021 23:00:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a follow up to [PR 74](https://github.com/openjdk/shenandoah/pull/74) in which we register filler objects from retired gclabs. This should _only_ be done if the plab was in an old region. Registering young objects in the remembered set confuses the verifier.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/77

From github.com+16811675+linade at openjdk.java.net  Thu Sep 30 09:31:46 2021
From: github.com+16811675+linade at openjdk.java.net (Yude Lin)
Date: Thu, 30 Sep 2021 09:31:46 GMT
Subject: RFR: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy
Message-ID: <qgI0F1nYm8hbJT8kyjaE8gSNhr35OrQrWDvXbGxc61g=.5e4a6191-00da-4e5d-a8a8-2d3012a34a19@github.com>

Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp

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

Commit messages:
 - 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy

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

PR: https://git.openjdk.java.net/jdk/pull/5770

From zgu at openjdk.java.net  Thu Sep 30 11:20:30 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 30 Sep 2021 11:20:30 GMT
Subject: RFR: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask
 copy
In-Reply-To: <qgI0F1nYm8hbJT8kyjaE8gSNhr35OrQrWDvXbGxc61g=.5e4a6191-00da-4e5d-a8a8-2d3012a34a19@github.com>
References: <qgI0F1nYm8hbJT8kyjaE8gSNhr35OrQrWDvXbGxc61g=.5e4a6191-00da-4e5d-a8a8-2d3012a34a19@github.com>
Message-ID: <fHGf5oCAQO0MBMCW5hU0ZHVLj2NrgMLwt9zWOfArU5I=.0f8e0ecf-b0f8-49f4-b4b0-c92b19614a80@github.com>

On Thu, 30 Sep 2021 09:23:48 GMT, Yude Lin <github.com+16811675+linade at openjdk.org> wrote:

> Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp

Looks good. Thanks for cleaning up.

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5770

From wkemper at openjdk.java.net  Thu Sep 30 15:50:34 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 30 Sep 2021 15:50:34 GMT
Subject: Integrated: Only register retired plab waste in old regions
In-Reply-To: <m301azXLLbnNjWB4y0GsrlzZCnSgEnK7XIP09ZRSjq4=.8cf5d60a-d118-464b-b44f-15411111938e@github.com>
References: <m301azXLLbnNjWB4y0GsrlzZCnSgEnK7XIP09ZRSjq4=.8cf5d60a-d118-464b-b44f-15411111938e@github.com>
Message-ID: <ILp5j3qYzKdXdmhhIUIfr3rFgkfa9eqqAKXjaMh-33M=.9772c0b2-a151-4634-8c3d-bfb9a15bc31d@github.com>

On Wed, 29 Sep 2021 23:00:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a follow up to [PR 74](https://github.com/openjdk/shenandoah/pull/74) in which we register filler objects from retired gclabs. This should _only_ be done if the plab was in an old region. Registering young objects in the remembered set confuses the verifier.

This pull request has now been integrated.

Changeset: 7fe11a23
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/7fe11a23d3bdde1d7fb511c5251a0413f61667a9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

Only register retired plab waste in old regions

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/77