From gnu.andrew at redhat.com Fri Oct 1 01:11:41 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 1 Oct 2021 02:11:41 +0100 Subject: [RFR] [8u] 8u312-b04 Upstream Sync In-Reply-To: <83bdb46c-f07a-ff4c-c5ad-5ef70da10cde@redhat.com> References: <83bdb46c-f07a-ff4c-c5ad-5ef70da10cde@redhat.com> Message-ID: On 16:28 Mon 27 Sep , Aleksey Shipilev wrote: > 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 > 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 tschatzl at openjdk.java.net Fri Oct 1 16:32:32 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 1 Oct 2021 16:32:32 GMT Subject: RFR: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:23:48 GMT, Yude Lin wrote: > Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5770 From gnu.andrew at redhat.com Mon Oct 4 03:32:19 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 4 Oct 2021 04:32:19 +0100 Subject: [RFR] [8u] 8u312-b05 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/root/merge.changeset Changes in aarch64-shenandoah-jdk8u312-b05: - JDK-7188942: Remove support of pbuffers in OGL Java2d pipeline - JDK-8022323: [JavaSecurityScanner] review package com.sun.management.* Native methods should be private - JDK-8131062: aarch64: add support for GHASH acceleration - JDK-8134869: AARCH64: GHASH intrinsic is not optimal - JDK-8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage in containers - JDK-8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon - JDK-8272714: [8u] Build failure after backport of JDK-8248901 with MSVC 2013 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/make/mapfiles/libawt/mapfile-mawt-vers | 1 b/make/mapfiles/libawt_xawt/mapfile-vers | 1 b/make/mapfiles/libmanagement/mapfile-vers | 12 b/src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java | 5 b/src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java | 20 b/src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java | 5 b/src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java | 24 b/src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m | 18 b/src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h | 3 b/src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m | 147 ----- b/src/share/classes/sun/awt/image/VolatileSurfaceManager.java | 4 b/src/share/classes/sun/java2d/opengl/OGLContext.java | 8 b/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java | 18 b/src/share/classes/sun/java2d/opengl/OGLUtilities.java | 3 b/src/share/classes/sun/java2d/pipe/hw/AccelSurface.java | 5 b/src/share/native/sun/java2d/opengl/OGLContext.h | 4 b/src/share/native/sun/java2d/opengl/OGLSurfaceData.h | 3 b/src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java | 20 b/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java | 10 b/src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java | 24 b/src/solaris/classes/sun/management/OperatingSystemImpl.java | 252 ++++++---- b/src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c | 8 b/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c | 84 --- b/src/solaris/native/sun/management/LinuxOperatingSystem.c | 2 b/src/solaris/native/sun/management/MacosxOperatingSystem.c | 2 b/src/solaris/native/sun/management/OperatingSystemImpl.c | 10 b/src/solaris/native/sun/management/SolarisOperatingSystem.c | 2 b/src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java | 21 b/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java | 5 b/src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java | 29 - b/src/windows/classes/sun/management/OperatingSystemImpl.java | 50 + b/src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c | 11 b/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c | 176 ------ b/src/windows/native/sun/management/OperatingSystemImpl.c | 16 b/test/java/awt/image/VolatileImage/BitmaskVolatileImage.java | 93 +++ 36 files changed, 414 insertions(+), 683 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/cpu/aarch64/vm/assembler_aarch64.hpp | 85 ++++++++- b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp | 157 +++++++++++++++++- b/src/cpu/aarch64/vm/vm_version_aarch64.cpp | 10 + b/src/share/vm/utilities/globalDefinitions_visCPP.hpp | 8 5 files changed, 241 insertions(+), 20 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 Oct 4 05:49:38 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Oct 2021 07:49:38 +0200 Subject: [RFR] [8u] 8u312-b05 Upstream Sync In-Reply-To: References: Message-ID: <60893926-cb3f-3277-c233-ef2db9525274@redhat.com> On 10/4/21 5:32 AM, Andrew Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jdk/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/hotspot/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From coleenp at openjdk.java.net Mon Oct 4 06:51:50 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Oct 2021 06:51:50 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex Message-ID: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. The transformation in this change is as follows: nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) leaf => nonleaf - Many of these locks were top level locks leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock leaf-n => nonleaf-n The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. This has been tested with tier1-8, and retesting tier1-3 locally in progress. ------------- Commit messages: - Fix lock name. - 8273917: Remove 'leaf' ranking for Mutex Changes: https://git.openjdk.java.net/jdk/pull/5801/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273917 Stats: 139 lines in 11 files changed: 54 ins; 23 del; 62 mod Patch: https://git.openjdk.java.net/jdk/pull/5801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5801/head:pull/5801 PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Mon Oct 4 06:51:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Oct 2021 06:51:52 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex In-Reply-To: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: <7xeQ9UDvFVktUSHsIWJf0j47Mp4b9E48qM-np75wjqw=.46ddd7cd-f9b0-4ed8-9ce8-cfe611918a63@github.com> On Sun, 3 Oct 2021 21:08:51 GMT, Coleen Phillimore wrote: > This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. > > The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. > > The transformation in this change is as follows: > nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) > leaf => nonleaf - Many of these locks were top level locks > leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock > leaf-n => nonleaf-n > > The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. > > This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. > > This has been tested with tier1-8, and retesting tier1-3 locally in progress. src/hotspot/share/oops/methodData.cpp line 1210: > 1208: : _method(method()), > 1209: // Holds Compile_lock > 1210: _extra_data_lock(Mutex::nonleaf-2, "MDOExtraData_lock", Mutex::_safepoint_check_always), MDO lock (nonleaf-2) is taken when the Compile_lock is held (nonleaf-1) which is taken while the MethodCompileQueue_lock (nonleaf) is held. ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Mon Oct 4 14:10:29 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 4 Oct 2021 14:10:29 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v2] In-Reply-To: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: > This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. > > The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. > > The transformation in this change is as follows: > nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) > leaf => nonleaf - Many of these locks were top level locks > leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock > leaf-n => nonleaf-n > > The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. > > This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. > > This has been tested with tier1-8, and retesting tier1-3 locally in progress. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix Minimal build. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5801/files - new: https://git.openjdk.java.net/jdk/pull/5801/files/34c43ec0..4596df6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5801/head:pull/5801 PR: https://git.openjdk.java.net/jdk/pull/5801 From wkemper at openjdk.java.net Mon Oct 4 16:22:34 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 16:22:34 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 16:54:46 GMT, Kelvin Nilsen wrote: > 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. src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 890: > 888: > 889: // Since this region may have served previously as OLD, it may hold obsolete object range info. > 890: heap->card_scan()->reset_object_range(bottom(), bottom() + spanned_regions * ShenandoahHeapRegion::region_size_words()); Do we write this memory again on line 911 or 915? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 804: > 802: size_t num_clusters = (size_t) ((num_heapwords - 1 + cluster_size) / cluster_size); > 803: > 804: if (!region->is_humongous_continuation()) { Is this safe? why do we no longer need to scan humongous continuations? ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From kdnilsen at openjdk.java.net Mon Oct 4 16:29:40 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 4 Oct 2021 16:29:40 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 16:16:08 GMT, William Kemper wrote: >> 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. > > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 890: > >> 888: >> 889: // Since this region may have served previously as OLD, it may hold obsolete object range info. >> 890: heap->card_scan()->reset_object_range(bottom(), bottom() + spanned_regions * ShenandoahHeapRegion::region_size_words()); > > Do we write this memory again on line 911 or 915? The code at lines 911 and 915 clears or sets the card dirty bits. The code here at line 890 changes the remembered set's knowledge of where objects begin. These are two different activities. > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 804: > >> 802: size_t num_clusters = (size_t) ((num_heapwords - 1 + cluster_size) / cluster_size); >> 803: >> 804: if (!region->is_humongous_continuation()) { > > Is this safe? why do we no longer need to scan humongous continuations? humongous continuations are scanned when the humongous start that "governs" the continuation is scanned. I'll add a comment here. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From wkemper at openjdk.java.net Mon Oct 4 16:41:42 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 16:41:42 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 16:26:38 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 804: >> >>> 802: size_t num_clusters = (size_t) ((num_heapwords - 1 + cluster_size) / cluster_size); >>> 803: >>> 804: if (!region->is_humongous_continuation()) { >> >> Is this safe? why do we no longer need to scan humongous continuations? > > humongous continuations are scanned when the humongous start that "governs" the continuation is scanned. I'll add a comment here. Wouldn't we need to change how `end_of_range` is computed for humongous starts? ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From kdnilsen at openjdk.java.net Mon Oct 4 16:53:36 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 4 Oct 2021 16:53:36 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 16:38:27 GMT, William Kemper wrote: >> humongous continuations are scanned when the humongous start that "governs" the continuation is scanned. I'll add a comment here. > > Wouldn't we need to change how `end_of_range` is computed for humongous starts? That's a good catch. I'm a bit inconsistent with this. I think this is "harmless" because end_of_range does not limit the scanning within a single humongous object. It only limits the search for the "next object" following an initially scanned object. I agree I should fix this up to make the code less confusing. (Do you agree that the error is "harmless as is"? Would appreciate your careful eyes on this.) ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From wkemper at openjdk.java.net Mon Oct 4 17:09:30 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 17:09:30 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 16:50:53 GMT, Kelvin Nilsen wrote: >> Wouldn't we need to change how `end_of_range` is computed for humongous starts? > > That's a good catch. I'm a bit inconsistent with this. I think this is "harmless" because end_of_range does not limit the scanning within a single humongous object. It only limits the search for the "next object" following an initially scanned object. I agree I should fix this up to make the code less confusing. (Do you agree that the error is "harmless as is"? Would appreciate your careful eyes on this.) `end_of_range` is used earlier to compute the `count` parameter (which is named `num_clusters` in the calling function). As I read it, this _does_ limit the number of cards scanned in the `process_clusters` call. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From kdnilsen at openjdk.java.net Mon Oct 4 17:16:32 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 4 Oct 2021 17:16:32 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 17:05:57 GMT, William Kemper wrote: >> That's a good catch. I'm a bit inconsistent with this. I think this is "harmless" because end_of_range does not limit the scanning within a single humongous object. It only limits the search for the "next object" following an initially scanned object. I agree I should fix this up to make the code less confusing. (Do you agree that the error is "harmless as is"? Would appreciate your careful eyes on this.) > > `end_of_range` is used earlier to compute the `count` parameter (which is named `num_clusters` in the calling function). As I read it, this _does_ limit the number of cards scanned in the `process_clusters` call. The way I read it, if you call process_clusters with an address that represents the start of a humongous region, it will go through its object-processing loop at least once (p < endp first time through) and will completely scan the object found at p, which will be a humongous object that spans multiple following regions (which may exceed count clusters scanned in total and may reach reach well beyond endp in total scan). Do you agree with this? ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From wkemper at openjdk.java.net Mon Oct 4 18:31:34 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 18:31:34 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: <-dCDJZcsYrII_BHaCDHTozMbtEcyqXBgDo0Rtib2yLs=.467828c6-1ea0-4432-a7e3-4eaf3bcdd613@github.com> On Wed, 29 Sep 2021 16:54:46 GMT, Kelvin Nilsen wrote: > 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. Marked as reviewed by wkemper (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From wkemper at openjdk.java.net Mon Oct 4 18:31:34 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 18:31:34 GMT Subject: RFR: Full region promotion In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 17:13:20 GMT, Kelvin Nilsen wrote: >> `end_of_range` is used earlier to compute the `count` parameter (which is named `num_clusters` in the calling function). As I read it, this _does_ limit the number of cards scanned in the `process_clusters` call. > > The way I read it, if you call process_clusters with an address that represents the start of a humongous region, it will go through its object-processing loop at least once (p < endp first time through) and will completely scan the object found at p, which will be a humongous object that spans multiple following regions (which may exceed count clusters scanned in total and may reach reach well beyond endp in total scan). Do you agree with this? Ah, okay - the `obj->oop_iterate` (or more likely, `array->oop_iterate_range`) will cover the entire humongous object if there is a dirty card in the start region. If the humongous object has no dirty cards in the start region, the last card for the object will be past the end card for this cluster and we'll `oop_iterate` it anyway. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From xcheng.dev at gmail.com Mon Oct 4 18:44:42 2021 From: xcheng.dev at gmail.com (Xi Cheng) Date: Mon, 4 Oct 2021 11:44:42 -0700 Subject: JVM Crashes after switching from G1GC to Shenandoah In-Reply-To: References: <4c4fb2f9-df12-3c90-0b3c-4598cb4dba05@redhat.com> Message-ID: Thanks for the response. We have switched from Shenandoah to G1GC for now due to the frequent crashes. We will experiment with the latest build in production a bit later. On Wed, Aug 25, 2021 at 12:51 PM Aleksey Shipilev wrote: > On 8/19/21 1:51 PM, Aleksey Shipilev wrote: > > Better yet: > > https://builds.shipilev.net/openjdk-jdk11-dev/ > > These builds should now include all known AArch64 bugfixes: > 8272909: Shenandoah: streamline post-LRB CAS barrier (aarch64) > 8272896: AArch64: gc/shenandoah/TestVerifyJCStress.java fails > intermittently with C1 > 8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent > > Please try them and shout if they still do not work. > > -- > Thanks, > -Aleksey > > From wkemper at openjdk.java.net Mon Oct 4 19:53:36 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 19:53:36 GMT Subject: RFR: Coalesce and fill unmarked objects during global degenerated cycle Message-ID: This is necessary to prevent the remembered set scan from iterating over garbage. We already do this for _concurrent_ global cycles, but it was missing from _degenerated _ global cycles. ------------- Commit messages: - Also coalesce and fill unmarked objects during global degenerated cycle Changes: https://git.openjdk.java.net/shenandoah/pull/78/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=78&range=00 Stats: 45 lines in 5 files changed: 28 ins; 16 del; 1 mod Patch: https://git.openjdk.java.net/shenandoah/pull/78.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/78/head:pull/78 PR: https://git.openjdk.java.net/shenandoah/pull/78 From kdnilsen at openjdk.java.net Mon Oct 4 20:34:19 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 4 Oct 2021 20:34:19 GMT Subject: RFR: Full region promotion [v2] In-Reply-To: References: Message-ID: > 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. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Add comments to clarify boundary case handling ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/75/files - new: https://git.openjdk.java.net/shenandoah/pull/75/files/5921401e..8fdb0703 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=75&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=75&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 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 kdnilsen at openjdk.java.net Mon Oct 4 20:34:21 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 4 Oct 2021 20:34:21 GMT Subject: Integrated: Full region promotion In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 16:54:46 GMT, Kelvin Nilsen wrote: > 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. This pull request has now been integrated. Changeset: 85592d91 Author: Kelvin Nilsen URL: https://git.openjdk.java.net/shenandoah/commit/85592d91833dea6361f063c31c41e17affeb16a2 Stats: 313 lines in 13 files changed: 116 ins; 150 del; 47 mod Full region promotion Reviewed-by: wkemper ------------- PR: https://git.openjdk.java.net/shenandoah/pull/75 From kdnilsen at openjdk.java.net Mon Oct 4 23:09:28 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 4 Oct 2021 23:09:28 GMT Subject: RFR: Coalesce and fill unmarked objects during global degenerated cycle In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 19:47:57 GMT, William Kemper wrote: > This is necessary to prevent the remembered set scan from iterating over garbage. We already do this for _concurrent_ global cycles, but it was missing from _degenerated _ global cycles. Looks good. Thanks for catching this bug and cleaning up the other code. ------------- Marked as reviewed by kdnilsen (Committer). PR: https://git.openjdk.java.net/shenandoah/pull/78 From wkemper at openjdk.java.net Mon Oct 4 23:23:32 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 4 Oct 2021 23:23:32 GMT Subject: Integrated: Coalesce and fill unmarked objects during global degenerated cycle In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 19:47:57 GMT, William Kemper wrote: > This is necessary to prevent the remembered set scan from iterating over garbage. We already do this for _concurrent_ global cycles, but it was missing from _degenerated _ global cycles. This pull request has now been integrated. Changeset: 2493e37e Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/2493e37ee8120b3f5db9fa9ef6640be207396503 Stats: 45 lines in 5 files changed: 28 ins; 16 del; 1 mod Coalesce and fill unmarked objects during global degenerated cycle Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/78 From kdnilsen at openjdk.java.net Tue Oct 5 00:01:36 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 5 Oct 2021 00:01:36 GMT Subject: RFR: Decouple generational heuristics In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 19:19:17 GMT, William Kemper wrote: > ### 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. Thanks for this cleanup. Big improvement. Am eager to test this out. ------------- Marked as reviewed by kdnilsen (Committer). PR: https://git.openjdk.java.net/shenandoah/pull/76 From coleenp at openjdk.java.net Tue Oct 5 13:31:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Oct 2021 13:31:10 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v2] In-Reply-To: References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: On Mon, 4 Oct 2021 14:10:29 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Minimal build. According to my logging, the shenandoah locks don't have any dependencies when running runThese with shenandoah, but could someone confirm this is ok to make them nonleaf? @zhengyu123 ? $ grep -r ShenandoahAllocFailureGC_lock 38_ShenandoahAllocFailureGC_lock:def(ShenandoahAllocFailureGC_lock , PaddedMonitor, nonleaf, _safepoint_check_always, true); $ grep -r ShenandoahRequestedGC_lock 38_ShenandoahRequestedGC_lock:def(ShenandoahRequestedGC_lock , PaddedMonitor, nonleaf, _safepoint_check_always, true); _wait_monitor (should rename to a consistent lock name) depends on PeriodicTask_lock: $ grep -r PeriodicTask_lock 38_PeriodicTask_lock:def(PeriodicTask_lock , PaddedMonitor, nonleaf, _safepoint_check_always, true); 37__wait_monitor:def(_wait_monitor , PaddedMonitor, PeriodicTask_lock, _safepoint_check_always, true); ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Tue Oct 5 14:35:31 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Oct 2021 14:35:31 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v3] In-Reply-To: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> > This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. > > The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. > > The transformation in this change is as follows: > nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) > leaf => nonleaf - Many of these locks were top level locks > leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock > leaf-n => nonleaf-n > > The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. > > This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. > > This has been tested with tier1-8, and retesting tier1-3 locally in progress. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Adjust some nonleaf-2 ranks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5801/files - new: https://git.openjdk.java.net/jdk/pull/5801/files/4596df6f..bc4022c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=01-02 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5801/head:pull/5801 PR: https://git.openjdk.java.net/jdk/pull/5801 From wkemper at openjdk.java.net Tue Oct 5 16:26:32 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 5 Oct 2021 16:26:32 GMT Subject: Integrated: Decouple generational heuristics In-Reply-To: References: Message-ID: <5IWEDh2ASDPCA9is5ngfznrwrLo9Wr9QJEESIa23Hho=.1b2900d2-5bfc-4d44-9891-4e6194115015@github.com> On Wed, 29 Sep 2021 19:19:17 GMT, William Kemper wrote: > ### 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. This pull request has now been integrated. Changeset: 4d8ce22f Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/4d8ce22f209f125a456cc757842f10a459822e60 Stats: 1239 lines in 29 files changed: 206 ins; 995 del; 38 mod Decouple generational heuristics Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/76 From eosterlund at openjdk.java.net Tue Oct 5 17:01:13 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 5 Oct 2021 17:01:13 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v3] In-Reply-To: <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> Message-ID: On Tue, 5 Oct 2021 14:35:31 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Adjust some nonleaf-2 ranks. I think this is a step in the right direction, and I heard great things will come in the next patch. Thanks for reducing the changes to nonleaf - 2. Go Coleen, go! Also looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Tue Oct 5 19:49:14 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 5 Oct 2021 19:49:14 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v3] In-Reply-To: <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> Message-ID: On Tue, 5 Oct 2021 14:35:31 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Adjust some nonleaf-2 ranks. Thank you Erik! ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From kdnilsen at openjdk.java.net Tue Oct 5 23:41:43 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 5 Oct 2021 23:41:43 GMT Subject: RFR: Age cycle periodically Message-ID: Add option to allow object ages to increment periodically instead of on every young cycle. ------------- Commit messages: - Turn off aging cycle on a safepoint and remove assert from vmop_entry_final_updaterefs - Do not use GC State flag for is_aging_cycle - Implement period for increasing age Changes: https://git.openjdk.java.net/shenandoah/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=80&range=00 Stats: 38 lines in 8 files changed: 33 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/shenandoah/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/80/head:pull/80 PR: https://git.openjdk.java.net/shenandoah/pull/80 From kdnilsen at openjdk.java.net Tue Oct 5 23:44:55 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 5 Oct 2021 23:44:55 GMT Subject: RFR: Age cycle periodically [v2] In-Reply-To: References: Message-ID: > Add option to allow object ages to increment periodically instead of on every young cycle. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Cosmetic cleanup ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/80/files - new: https://git.openjdk.java.net/shenandoah/pull/80/files/a679866b..5fda5a3b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=80&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=80&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/shenandoah/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/80/head:pull/80 PR: https://git.openjdk.java.net/shenandoah/pull/80 From dholmes at openjdk.java.net Wed Oct 6 00:33:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 6 Oct 2021 00:33:07 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v3] In-Reply-To: <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> Message-ID: On Tue, 5 Oct 2021 14:35:31 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Adjust some nonleaf-2 ranks. Hi Coleen, A minor comment below but otherwise this all seems okay. Thanks, David src/hotspot/share/runtime/mutex.cpp line 300: > 298: > 299: assert(_rank >= 0, "Bad lock rank: %s", name); > 300: assert(_rank <= nonleaf, "Bad lock rank: %s", name); Can we just combine these into a single range check? And really the assert message should include the bad rank value. And probably this basic range check should be first. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Wed Oct 6 01:22:25 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 01:22:25 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v3] In-Reply-To: <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> Message-ID: On Tue, 5 Oct 2021 14:35:31 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Adjust some nonleaf-2 ranks. Thank you for reviewing, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Wed Oct 6 01:22:24 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 01:22:24 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v4] In-Reply-To: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: > This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. > > The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. > > The transformation in this change is as follows: > nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) > leaf => nonleaf - Many of these locks were top level locks > leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock > leaf-n => nonleaf-n > > The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. > > This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. > > This has been tested with tier1-8, and retesting tier1-3 locally in progress. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Combine bad rank range checks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5801/files - new: https://git.openjdk.java.net/jdk/pull/5801/files/bc4022c6..bd6ff180 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5801&range=02-03 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5801.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5801/head:pull/5801 PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Wed Oct 6 01:22:26 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 01:22:26 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v3] In-Reply-To: References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> <7Q5YHVtzbMG9Hj1y19E81HPARccq0RxaNwWqX05-fkE=.612b2d93-42f3-4df3-bd66-7b97bf66dad6@github.com> Message-ID: On Wed, 6 Oct 2021 00:26:24 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust some nonleaf-2 ranks. > > src/hotspot/share/runtime/mutex.cpp line 300: > >> 298: >> 299: assert(_rank >= 0, "Bad lock rank: %s", name); >> 300: assert(_rank <= nonleaf, "Bad lock rank: %s", name); > > Can we just combine these into a single range check? And really the assert message should include the bad rank value. And probably this basic range check should be first. I combined the check and moved it up for now. In my next change that makes Rank into an enum class, the range check is different because you can't add to nonleaf which is going to be renamed 'safepoint' rank. ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From dholmes at openjdk.java.net Wed Oct 6 01:40:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 6 Oct 2021 01:40:06 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v4] In-Reply-To: References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: On Wed, 6 Oct 2021 01:22:24 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Combine bad rank range checks. Thanks for that tweak. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Wed Oct 6 12:18:11 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 12:18:11 GMT Subject: Integrated: 8273917: Remove 'leaf' ranking for Mutex In-Reply-To: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: On Sun, 3 Oct 2021 21:08:51 GMT, Coleen Phillimore wrote: > This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. > > The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. > > The transformation in this change is as follows: > nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) > leaf => nonleaf - Many of these locks were top level locks > leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock > leaf-n => nonleaf-n > > The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. > > This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. > > This has been tested with tier1-8, and retesting tier1-3 locally in progress. This pull request has now been integrated. Changeset: b8af6a9b Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/b8af6a9bfb28aaf0fea0cfdaba13236dc8cbaa3a Stats: 141 lines in 11 files changed: 54 ins; 24 del; 63 mod 8273917: Remove 'leaf' ranking for Mutex Reviewed-by: eosterlund, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From coleenp at openjdk.java.net Wed Oct 6 12:18:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 12:18:10 GMT Subject: RFR: 8273917: Remove 'leaf' ranking for Mutex [v4] In-Reply-To: References: <0u1_bu5EunfDFYz-AMKxs-wOVO0-HwpYpe8YoSXBwtM=.e25a1229-de90-4d15-9e89-2f20d6ccf40b@github.com> Message-ID: On Wed, 6 Oct 2021 01:22:24 GMT, Coleen Phillimore wrote: >> This change removes 'leaf' ranking. The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always. >> >> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank. >> >> The transformation in this change is as follows: >> nonleaf+n => nonleaf - Generally these 'nonleaf' mutex were top level locks) >> leaf => nonleaf - Many of these locks were top level locks >> leaf => nonleaf-2 - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock >> leaf-n => nonleaf-n >> >> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2. >> >> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it. So these relative mutex are moved to the end of the init function in mutexLocker.cpp. >> >> This has been tested with tier1-8, and retesting tier1-3 locally in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Combine bad rank range checks. Thanks for the reviews Erik and David. ------------- PR: https://git.openjdk.java.net/jdk/pull/5801 From wkemper at openjdk.java.net Wed Oct 6 17:24:49 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Wed, 6 Oct 2021 17:24:49 GMT Subject: RFR: Improve handling of promotion and old generation evacuation failures Message-ID: <7ERqF5iG2Yw_JmUokwNd_9__2bL3wQbhhwoyXclF1qM=.a01fb076-5c1a-42e6-b51a-ce2ff58a8ce5@github.com> There are two changes here: * A promotion failure will cause the old generation heuristic to request an old collection. * An evacuation failure in the old generation will trigger a full collection. Minor change: * If an allocation failure has been detected, the control thread will not sleep at the bottom of its loop. ------------- Commit messages: - Reword assert message - Force FullGC when old generation evacuation fails - Schedule an old generation collection upon promotion failure - Only treat promotions as old gen allocations - Track allocation rate for each generation Changes: https://git.openjdk.java.net/shenandoah/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=81&range=00 Stats: 80 lines in 6 files changed: 58 ins; 15 del; 7 mod Patch: https://git.openjdk.java.net/shenandoah/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/81/head:pull/81 PR: https://git.openjdk.java.net/shenandoah/pull/81 From wkemper at openjdk.java.net Wed Oct 6 17:30:32 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Wed, 6 Oct 2021 17:30:32 GMT Subject: RFR: Age cycle periodically [v2] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 23:44:55 GMT, Kelvin Nilsen wrote: >> Add option to allow object ages to increment periodically instead of on every young cycle. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Cosmetic cleanup Looks good to me. ------------- Marked as reviewed by wkemper (Committer). PR: https://git.openjdk.java.net/shenandoah/pull/80 From kdnilsen at openjdk.java.net Wed Oct 6 18:08:29 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Wed, 6 Oct 2021 18:08:29 GMT Subject: RFR: Improve handling of promotion and old generation evacuation failures In-Reply-To: <7ERqF5iG2Yw_JmUokwNd_9__2bL3wQbhhwoyXclF1qM=.a01fb076-5c1a-42e6-b51a-ce2ff58a8ce5@github.com> References: <7ERqF5iG2Yw_JmUokwNd_9__2bL3wQbhhwoyXclF1qM=.a01fb076-5c1a-42e6-b51a-ce2ff58a8ce5@github.com> Message-ID: On Wed, 6 Oct 2021 17:17:54 GMT, William Kemper wrote: > There are two changes here: > * A promotion failure will cause the old generation heuristic to request an old collection. > * An evacuation failure in the old generation will trigger a full collection. > > Minor change: > * If an allocation failure has been detected, the control thread will not sleep at the bottom of its loop. Thank you for these improvements. ------------- Marked as reviewed by kdnilsen (Committer). PR: https://git.openjdk.java.net/shenandoah/pull/81 From wkemper at openjdk.java.net Wed Oct 6 18:26:38 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Wed, 6 Oct 2021 18:26:38 GMT Subject: Integrated: Improve handling of promotion and old generation evacuation failures In-Reply-To: <7ERqF5iG2Yw_JmUokwNd_9__2bL3wQbhhwoyXclF1qM=.a01fb076-5c1a-42e6-b51a-ce2ff58a8ce5@github.com> References: <7ERqF5iG2Yw_JmUokwNd_9__2bL3wQbhhwoyXclF1qM=.a01fb076-5c1a-42e6-b51a-ce2ff58a8ce5@github.com> Message-ID: On Wed, 6 Oct 2021 17:17:54 GMT, William Kemper wrote: > There are two changes here: > * A promotion failure will cause the old generation heuristic to request an old collection. > * An evacuation failure in the old generation will trigger a full collection. > > Minor change: > * If an allocation failure has been detected, the control thread will not sleep at the bottom of its loop. This pull request has now been integrated. Changeset: 6a1eebb9 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/6a1eebb97378db11fc269c4ffce550bea2567777 Stats: 80 lines in 6 files changed: 58 ins; 15 del; 7 mod Improve handling of promotion and old generation evacuation failures Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/81 From kdnilsen at openjdk.java.net Wed Oct 6 19:05:30 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Wed, 6 Oct 2021 19:05:30 GMT Subject: Integrated: Age cycle periodically In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 23:35:16 GMT, Kelvin Nilsen wrote: > Add option to allow object ages to increment periodically instead of on every young cycle. This pull request has now been integrated. Changeset: a910ee86 Author: Kelvin Nilsen URL: https://git.openjdk.java.net/shenandoah/commit/a910ee86ca788a502d02a87a8723d818fe0d93c3 Stats: 37 lines in 8 files changed: 33 ins; 0 del; 4 mod Age cycle periodically Reviewed-by: wkemper ------------- PR: https://git.openjdk.java.net/shenandoah/pull/80 From coleenp at openjdk.java.net Wed Oct 6 23:37:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 6 Oct 2021 23:37:18 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name Message-ID: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> 8273956: Add checking for rank values This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions isn't unmanageable. There are actually not many nested Mutex. This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. Tested with tier1-8 at one point in time and just retested with tier1-6. ------------- Commit messages: - 8274004: Change 'nonleaf' rank name Changes: https://git.openjdk.java.net/jdk/pull/5845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274004 Stats: 445 lines in 41 files changed: 98 ins; 117 del; 230 mod Patch: https://git.openjdk.java.net/jdk/pull/5845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5845/head:pull/5845 PR: https://git.openjdk.java.net/jdk/pull/5845 From dcubed at openjdk.java.net Wed Oct 6 23:45:04 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 6 Oct 2021 23:45:04 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions isn't unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. The PR description mentions: `8273956: Add checking for rank values` but the PR synopsis is: `8274004: Change 'nonleaf' rank name` ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From dcubed at openjdk.java.net Wed Oct 6 23:55:10 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 6 Oct 2021 23:55:10 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions isn't unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Just do ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From gnu.andrew at redhat.com Thu Oct 7 01:08:50 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 7 Oct 2021 02:08:50 +0100 Subject: [RFR] [8u] 8u312-b05 Upstream Sync In-Reply-To: <60893926-cb3f-3277-c233-ef2db9525274@redhat.com> References: <60893926-cb3f-3277-c233-ef2db9525274@redhat.com> Message-ID: On 07:49 Mon 04 Oct , Aleksey Shipilev wrote: > On 10/4/21 5:32 AM, Andrew Hughes wrote: > > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/ > > > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/jdk/merge.changeset > > Looks fine. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/hotspot/merge.changeset > > Looks fine. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b05/root/merge.changeset > > Look trivially good. > > > 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 dholmes at openjdk.java.net Thu Oct 7 02:15:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 7 Oct 2021 02:15:06 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Hi Coleen, Overall this looks good! But shouldn't the test: test/hotspot/gtest/runtime/test_safepoint_locks.cpp be replaced by one that checks we lock with/without a safepoint check for a safepoint/nonsafepoint lock respectively? (Or does that test already exist elsewhere?). Also should there not be a gtest to verify your Rank overlap checking? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From shade at redhat.com Thu Oct 7 07:32:03 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:03 +0000 Subject: hg: shenandoah/jdk8/nashorn: 37 new changesets Message-ID: <202110070732.1977W3fi015156@aojmv0008.oracle.com> Changeset: cbf10a6ff850 Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/cbf10a6ff850 Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset 5a46bdc6b447 ! .hgtags Changeset: a247af3c2e26 Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/a247af3c2e26 Added tag jdk8u302-b04 for changeset 059c39ec74bf ! .hgtags Changeset: 5f1f67be0291 Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/5f1f67be0291 Merge jdk8u302-b04 ! .hgtags Changeset: aa65093e6367 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/aa65093e6367 Merge ! .hgtags Changeset: 9a6cc751fd8e Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/9a6cc751fd8e Added tag aarch64-shenandoah-jdk8u302-b04 for changeset aa65093e6367 ! .hgtags Changeset: 067a65992a07 Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/067a65992a07 Added tag jdk8u302-b05 for changeset a247af3c2e26 ! .hgtags Changeset: 31278301a0d8 Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/31278301a0d8 Merge jdk8u302-b05 ! .hgtags Changeset: 2b15c0d8d4ae Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/2b15c0d8d4ae Added tag aarch64-shenandoah-jdk8u302-b05 for changeset 31278301a0d8 ! .hgtags Changeset: 1a5a89139fa0 Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/1a5a89139fa0 Added tag jdk8u302-b06 for changeset 067a65992a07 ! .hgtags Changeset: 359667ad6404 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/359667ad6404 Merge jdk8u302-b06 ! .hgtags Changeset: 9a3b2c116c2d Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/9a3b2c116c2d Added tag aarch64-shenandoah-jdk8u302-b06 for changeset 359667ad6404 ! .hgtags Changeset: a69c36cf0f4f Author: andrew Date: 2021-06-28 06:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/a69c36cf0f4f Added tag jdk8u302-b07 for changeset 1a5a89139fa0 ! .hgtags Changeset: 9dbeb5865c47 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/9dbeb5865c47 Merge jdk8u302-b07 ! .hgtags Changeset: 9007be4f9b68 Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/9007be4f9b68 Added tag aarch64-shenandoah-jdk8u302-b07 for changeset 9dbeb5865c47 ! .hgtags Changeset: 82ff7ab9553a Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/82ff7ab9553a Added tag jdk8u302-b08 for changeset a69c36cf0f4f ! .hgtags Changeset: ba9a2979f3a3 Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ba9a2979f3a3 Merge jdk8u302-b08 ! .hgtags Changeset: 6b3212566751 Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/6b3212566751 Added tag aarch64-shenandoah-jdk8u302-b08 for changeset ba9a2979f3a3 ! .hgtags Changeset: ca40d19ce186 Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ca40d19ce186 Added tag jdk8u302-ga for changeset a69c36cf0f4f ! .hgtags Changeset: 3631734314bd Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/3631734314bd Added tag jdk8u312-b00 for changeset a247af3c2e26 ! .hgtags Changeset: d74c3ed85f57 Author: andrew Date: 2021-07-06 22:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/d74c3ed85f57 Merge ! .hgtags Changeset: 4e3edd6a4734 Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/4e3edd6a4734 Merge ! .hgtags Changeset: 1d64859b8b61 Author: andrew Date: 2021-08-02 13:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/1d64859b8b61 Added tag jdk8u312-b01 for changeset 4e3edd6a4734 ! .hgtags Changeset: 0448ab3f729d Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/0448ab3f729d Merge jdk8u312-b01 ! .hgtags Changeset: efb3495d211b Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/efb3495d211b Added tag aarch64-shenandoah-jdk8u312-b01 for changeset 0448ab3f729d ! .hgtags Changeset: 72cdbda3c12e Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/72cdbda3c12e Added tag jdk8u312-b02 for changeset 1d64859b8b61 ! .hgtags Changeset: afbb7c3ec94a Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/afbb7c3ec94a Merge jdk8u312-b02 ! .hgtags Changeset: 32c3e1bf0fba Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/32c3e1bf0fba Added tag aarch64-shenandoah-jdk8u312-b02 for changeset afbb7c3ec94a ! .hgtags Changeset: c0c4e4c99e7a Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/c0c4e4c99e7a Added tag jdk8u312-b03 for changeset 72cdbda3c12e ! .hgtags Changeset: 5ffdd22dbff0 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/5ffdd22dbff0 Merge jdk8u312-b03 ! .hgtags Changeset: 70a62c8cff4b Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/70a62c8cff4b Added tag aarch64-shenandoah-jdk8u312-b03 for changeset 5ffdd22dbff0 ! .hgtags Changeset: 94e307665a04 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/94e307665a04 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: edea31f4b06b Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/edea31f4b06b Added tag jdk8u312-b04 for changeset 94e307665a04 ! .hgtags Changeset: 013d2af7d094 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/013d2af7d094 Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 7b264e831a70 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/7b264e831a70 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset 013d2af7d094 ! .hgtags Changeset: c0cd14e232ae Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/c0cd14e232ae Added tag jdk8u312-b05 for changeset edea31f4b06b ! .hgtags Changeset: 525a766e6faf Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/525a766e6faf Merge jdk8u312-b05 ! .hgtags Changeset: ef6521ddf176 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ef6521ddf176 Added tag aarch64-shenandoah-jdk8u312-b05 for changeset 525a766e6faf ! .hgtags From shade at redhat.com Thu Oct 7 07:32:00 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:00 +0000 Subject: hg: shenandoah/jdk8/jaxws: 37 new changesets Message-ID: <202110070732.1977W1NN015133@aojmv0008.oracle.com> Changeset: 573c18341307 Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/573c18341307 Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset cdf7f1dfbc4d ! .hgtags Changeset: 0113b64bec62 Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/0113b64bec62 Added tag jdk8u302-b04 for changeset a3ee7e77cb8e ! .hgtags Changeset: 8f959a46bac3 Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/8f959a46bac3 Merge jdk8u302-b04 ! .hgtags Changeset: ce6b43749afa Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/ce6b43749afa Merge ! .hgtags Changeset: e8ea524c3e0c Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/e8ea524c3e0c Added tag aarch64-shenandoah-jdk8u302-b04 for changeset ce6b43749afa ! .hgtags Changeset: 55f9e93f9393 Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/55f9e93f9393 Added tag jdk8u302-b05 for changeset 0113b64bec62 ! .hgtags Changeset: b4a945504976 Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/b4a945504976 Merge jdk8u302-b05 ! .hgtags Changeset: 0de9e4950c38 Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/0de9e4950c38 Added tag aarch64-shenandoah-jdk8u302-b05 for changeset b4a945504976 ! .hgtags Changeset: 29ad7b133014 Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/29ad7b133014 Added tag jdk8u302-b06 for changeset 55f9e93f9393 ! .hgtags Changeset: f1990466d776 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/f1990466d776 Merge jdk8u302-b06 ! .hgtags Changeset: b9fa0061c49d Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/b9fa0061c49d Added tag aarch64-shenandoah-jdk8u302-b06 for changeset f1990466d776 ! .hgtags Changeset: eae73754c31e Author: andrew Date: 2021-06-28 06:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/eae73754c31e Added tag jdk8u302-b07 for changeset 29ad7b133014 ! .hgtags Changeset: b48f3540b938 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/b48f3540b938 Merge jdk8u302-b07 ! .hgtags Changeset: 6015ecf323d3 Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/6015ecf323d3 Added tag aarch64-shenandoah-jdk8u302-b07 for changeset b48f3540b938 ! .hgtags Changeset: 93ce5e16830b Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/93ce5e16830b Added tag jdk8u302-b08 for changeset eae73754c31e ! .hgtags Changeset: 70514dc086cd Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/70514dc086cd Merge jdk8u302-b08 ! .hgtags Changeset: 7afc8e20a21f Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/7afc8e20a21f Added tag aarch64-shenandoah-jdk8u302-b08 for changeset 70514dc086cd ! .hgtags Changeset: 72c48a19454c Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/72c48a19454c Added tag jdk8u302-ga for changeset eae73754c31e ! .hgtags Changeset: 9952a9cb2d86 Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/9952a9cb2d86 Added tag jdk8u312-b00 for changeset 0113b64bec62 ! .hgtags Changeset: a36411bbc1b5 Author: andrew Date: 2021-07-06 22:54 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/a36411bbc1b5 Merge ! .hgtags Changeset: 396d9b5a44b5 Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/396d9b5a44b5 Merge ! .hgtags Changeset: 9e557fa24afb Author: andrew Date: 2021-08-02 13:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/9e557fa24afb Added tag jdk8u312-b01 for changeset 396d9b5a44b5 ! .hgtags Changeset: 5bdbfaaf4ba4 Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/5bdbfaaf4ba4 Merge jdk8u312-b01 ! .hgtags Changeset: 5d86095a0932 Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/5d86095a0932 Added tag aarch64-shenandoah-jdk8u312-b01 for changeset 5bdbfaaf4ba4 ! .hgtags Changeset: 21ceec5ba311 Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/21ceec5ba311 Added tag jdk8u312-b02 for changeset 9e557fa24afb ! .hgtags Changeset: fc0ad745d880 Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/fc0ad745d880 Merge jdk8u312-b02 ! .hgtags Changeset: 5c6005f48715 Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/5c6005f48715 Added tag aarch64-shenandoah-jdk8u312-b02 for changeset fc0ad745d880 ! .hgtags Changeset: 3674bee66aa5 Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/3674bee66aa5 Added tag jdk8u312-b03 for changeset 21ceec5ba311 ! .hgtags Changeset: 0c84fc7368af Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/0c84fc7368af Merge jdk8u312-b03 ! .hgtags Changeset: 7a96893ef05d Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/7a96893ef05d Added tag aarch64-shenandoah-jdk8u312-b03 for changeset 0c84fc7368af ! .hgtags Changeset: 68fd93243cf3 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/68fd93243cf3 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: 869edc64d5d0 Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/869edc64d5d0 Added tag jdk8u312-b04 for changeset 68fd93243cf3 ! .hgtags Changeset: ada368cf652d Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/ada368cf652d Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 7fed89c7c5c5 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/7fed89c7c5c5 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset ada368cf652d ! .hgtags Changeset: 70fa0fdf6a6c Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/70fa0fdf6a6c Added tag jdk8u312-b05 for changeset 869edc64d5d0 ! .hgtags Changeset: 2a4392185799 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/2a4392185799 Merge jdk8u312-b05 ! .hgtags Changeset: 6f4c9005f4f4 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/6f4c9005f4f4 Added tag aarch64-shenandoah-jdk8u312-b05 for changeset 2a4392185799 ! .hgtags From shade at redhat.com Thu Oct 7 07:32:02 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:02 +0000 Subject: hg: shenandoah/jdk8/langtools: 37 new changesets Message-ID: <202110070732.1977W3cQ015150@aojmv0008.oracle.com> Changeset: 65bec8965db9 Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/65bec8965db9 Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset 815d07930e17 ! .hgtags Changeset: ef5cb85b148e Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ef5cb85b148e Added tag jdk8u302-b04 for changeset a6ea4245dc14 ! .hgtags Changeset: a34441ef6451 Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a34441ef6451 Merge jdk8u302-b04 ! .hgtags Changeset: 26bcec213c96 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/26bcec213c96 Merge ! .hgtags Changeset: bb857e8d7704 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/bb857e8d7704 Added tag aarch64-shenandoah-jdk8u302-b04 for changeset 26bcec213c96 ! .hgtags Changeset: b13b58afad1e Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b13b58afad1e Added tag jdk8u302-b05 for changeset ef5cb85b148e ! .hgtags Changeset: 250a24c15439 Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/250a24c15439 Merge jdk8u302-b05 ! .hgtags Changeset: dcb2a89c2567 Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/dcb2a89c2567 Added tag aarch64-shenandoah-jdk8u302-b05 for changeset 250a24c15439 ! .hgtags Changeset: dccbf90608eb Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/dccbf90608eb Added tag jdk8u302-b06 for changeset b13b58afad1e ! .hgtags Changeset: a0f380ed17b7 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a0f380ed17b7 Merge jdk8u302-b06 ! .hgtags Changeset: 9e9b20b564c5 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9e9b20b564c5 Added tag aarch64-shenandoah-jdk8u302-b06 for changeset a0f380ed17b7 ! .hgtags Changeset: 361a561709af Author: andrew Date: 2021-06-28 06:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/361a561709af Added tag jdk8u302-b07 for changeset dccbf90608eb ! .hgtags Changeset: 0dce4abf93e6 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/0dce4abf93e6 Merge jdk8u302-b07 ! .hgtags Changeset: 6de80bfb5889 Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/6de80bfb5889 Added tag aarch64-shenandoah-jdk8u302-b07 for changeset 0dce4abf93e6 ! .hgtags Changeset: ba2970a4d7d4 Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ba2970a4d7d4 Added tag jdk8u302-b08 for changeset 361a561709af ! .hgtags Changeset: e0a50d855acb Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/e0a50d855acb Merge jdk8u302-b08 ! .hgtags Changeset: 7e0406a333f2 Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/7e0406a333f2 Added tag aarch64-shenandoah-jdk8u302-b08 for changeset e0a50d855acb ! .hgtags Changeset: eb6c3d1852d4 Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/eb6c3d1852d4 Added tag jdk8u302-ga for changeset 361a561709af ! .hgtags Changeset: 8ededdf091de Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/8ededdf091de Added tag jdk8u312-b00 for changeset ef5cb85b148e ! .hgtags Changeset: 230d152ca0e7 Author: andrew Date: 2021-07-06 22:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/230d152ca0e7 Merge ! .hgtags Changeset: c2908eb7d16d Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/c2908eb7d16d Merge ! .hgtags Changeset: ac02c03356e0 Author: andrew Date: 2021-08-02 13:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ac02c03356e0 Added tag jdk8u312-b01 for changeset c2908eb7d16d ! .hgtags Changeset: c0155d421f8d Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/c0155d421f8d Merge jdk8u312-b01 ! .hgtags Changeset: d79a3c35815f Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/d79a3c35815f Added tag aarch64-shenandoah-jdk8u312-b01 for changeset c0155d421f8d ! .hgtags Changeset: de6e8a37b71b Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/de6e8a37b71b Added tag jdk8u312-b02 for changeset ac02c03356e0 ! .hgtags Changeset: b97803f8a37f Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b97803f8a37f Merge jdk8u312-b02 ! .hgtags Changeset: 2fc0dff47dff Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/2fc0dff47dff Added tag aarch64-shenandoah-jdk8u312-b02 for changeset b97803f8a37f ! .hgtags Changeset: bb00b298b8ae Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/bb00b298b8ae Added tag jdk8u312-b03 for changeset de6e8a37b71b ! .hgtags Changeset: 9e7e2f0df692 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9e7e2f0df692 Merge jdk8u312-b03 ! .hgtags Changeset: abb9d554ac6c Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/abb9d554ac6c Added tag aarch64-shenandoah-jdk8u312-b03 for changeset 9e7e2f0df692 ! .hgtags Changeset: 7580f5f7f890 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/7580f5f7f890 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: 8ec4f4e9ef0f Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/8ec4f4e9ef0f Added tag jdk8u312-b04 for changeset 7580f5f7f890 ! .hgtags Changeset: e0e19466d85e Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/e0e19466d85e Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 2c52a8e6a2b6 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/2c52a8e6a2b6 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset e0e19466d85e ! .hgtags Changeset: 9472308f16d4 Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9472308f16d4 Added tag jdk8u312-b05 for changeset 8ec4f4e9ef0f ! .hgtags Changeset: fe14494cf8eb Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/fe14494cf8eb Merge jdk8u312-b05 ! .hgtags Changeset: a5506f237c4b Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a5506f237c4b Added tag aarch64-shenandoah-jdk8u312-b05 for changeset fe14494cf8eb ! .hgtags From shade at redhat.com Thu Oct 7 07:32:02 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:02 +0000 Subject: hg: shenandoah/jdk8/jaxp: 38 new changesets Message-ID: <202110070732.1977W2J6015146@aojmv0008.oracle.com> Changeset: 5d37d9885181 Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/5d37d9885181 Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset 7a2ae4650175 ! .hgtags Changeset: f529944cbf6e Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f529944cbf6e Added tag jdk8u302-b04 for changeset dd6914b1b116 ! .hgtags Changeset: 100f558e8b5f Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/100f558e8b5f Merge jdk8u302-b04 ! .hgtags Changeset: 86e2ec87d9c0 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/86e2ec87d9c0 Merge ! .hgtags Changeset: dcd3044ae57d Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/dcd3044ae57d Added tag aarch64-shenandoah-jdk8u302-b04 for changeset 86e2ec87d9c0 ! .hgtags Changeset: 7443fa2f19b0 Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/7443fa2f19b0 Added tag jdk8u302-b05 for changeset f529944cbf6e ! .hgtags Changeset: d43fb2e2e10e Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/d43fb2e2e10e Merge jdk8u302-b05 ! .hgtags Changeset: dce914ccf0bb Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/dce914ccf0bb Added tag aarch64-shenandoah-jdk8u302-b05 for changeset d43fb2e2e10e ! .hgtags Changeset: 5f019dc37164 Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/5f019dc37164 Added tag jdk8u302-b06 for changeset 7443fa2f19b0 ! .hgtags Changeset: f34611079419 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f34611079419 Merge jdk8u302-b06 ! .hgtags Changeset: b56ae8bdab07 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/b56ae8bdab07 Added tag aarch64-shenandoah-jdk8u302-b06 for changeset f34611079419 ! .hgtags Changeset: 1988106f4b5d Author: andrew Date: 2021-06-28 06:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/1988106f4b5d Added tag jdk8u302-b07 for changeset 5f019dc37164 ! .hgtags Changeset: 0de86d6e3bc9 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/0de86d6e3bc9 Merge jdk8u302-b07 ! .hgtags Changeset: 81d17ad7cb28 Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/81d17ad7cb28 Added tag aarch64-shenandoah-jdk8u302-b07 for changeset 0de86d6e3bc9 ! .hgtags Changeset: 41f3654e3404 Author: avoitylov Date: 2021-04-05 23:51 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/41f3654e3404 8262380: Enhance XML processing passes Reviewed-by: mbalao, andrew ! src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/jdk/xml/internal/JdkXmlUtils.java Changeset: 847e39769327 Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/847e39769327 Added tag jdk8u302-b08 for changeset 41f3654e3404 ! .hgtags Changeset: fc8969bc434f Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/fc8969bc434f Merge jdk8u302-b08 ! .hgtags Changeset: 835e62d275b5 Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/835e62d275b5 Added tag aarch64-shenandoah-jdk8u302-b08 for changeset fc8969bc434f ! .hgtags Changeset: a4ee601a399f Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/a4ee601a399f Added tag jdk8u302-ga for changeset 41f3654e3404 ! .hgtags Changeset: bb8396a37697 Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/bb8396a37697 Added tag jdk8u312-b00 for changeset f529944cbf6e ! .hgtags Changeset: 39c63cebb498 Author: andrew Date: 2021-07-06 22:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/39c63cebb498 Merge ! .hgtags Changeset: 211ac8fe58f6 Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/211ac8fe58f6 Merge ! .hgtags Changeset: 4e6491f455d0 Author: andrew Date: 2021-08-02 13:57 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/4e6491f455d0 Added tag jdk8u312-b01 for changeset 211ac8fe58f6 ! .hgtags Changeset: cc36a306a065 Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/cc36a306a065 Merge jdk8u312-b01 ! .hgtags Changeset: 9681cf090b64 Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/9681cf090b64 Added tag aarch64-shenandoah-jdk8u312-b01 for changeset cc36a306a065 ! .hgtags Changeset: 6a8a5589afaa Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/6a8a5589afaa Added tag jdk8u312-b02 for changeset 4e6491f455d0 ! .hgtags Changeset: 1874b1afab2c Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/1874b1afab2c Merge jdk8u312-b02 ! .hgtags Changeset: b36e71b91655 Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/b36e71b91655 Added tag aarch64-shenandoah-jdk8u312-b02 for changeset 1874b1afab2c ! .hgtags Changeset: 1d9b1da535cc Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/1d9b1da535cc Added tag jdk8u312-b03 for changeset 6a8a5589afaa ! .hgtags Changeset: ba2857643a5b Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/ba2857643a5b Merge jdk8u312-b03 ! .hgtags Changeset: bb9ce17f61f9 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/bb9ce17f61f9 Added tag aarch64-shenandoah-jdk8u312-b03 for changeset ba2857643a5b ! .hgtags Changeset: ebcae27bdac1 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/ebcae27bdac1 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: f62968808184 Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f62968808184 Added tag jdk8u312-b04 for changeset ebcae27bdac1 ! .hgtags Changeset: 8193d34aa882 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/8193d34aa882 Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README Changeset: c4cd03628941 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/c4cd03628941 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset 8193d34aa882 ! .hgtags Changeset: 2ffc0e316b15 Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/2ffc0e316b15 Added tag jdk8u312-b05 for changeset f62968808184 ! .hgtags Changeset: 6c573428c0ec Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/6c573428c0ec Merge jdk8u312-b05 ! .hgtags Changeset: 167bbbcabde9 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/167bbbcabde9 Added tag aarch64-shenandoah-jdk8u312-b05 for changeset 6c573428c0ec ! .hgtags From shade at redhat.com Thu Oct 7 07:32:04 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:04 +0000 Subject: hg: shenandoah/jdk8: 47 new changesets Message-ID: <202110070732.1977W4sm015160@aojmv0008.oracle.com> Changeset: 0aaa236e5362 Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/0aaa236e5362 Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset a32e2d38548e ! .hgtags Changeset: 381d5f4a839e Author: aleonard Date: 2021-05-12 11:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/381d5f4a839e 8265666: Enable AIX build platform to make external debug symbols Reviewed-by: phh ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! make/common/NativeCompilation.gmk Changeset: 14f5c4deb6d9 Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/14f5c4deb6d9 Added tag jdk8u302-b04 for changeset 381d5f4a839e ! .hgtags Changeset: 3e54deb0a4c1 Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/3e54deb0a4c1 Merge jdk8u302-b04 ! .hgtags ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: f04252985d9c Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/f04252985d9c Merge ! .hgtags Changeset: c754494561b8 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/c754494561b8 Added tag aarch64-shenandoah-jdk8u302-b04 for changeset f04252985d9c ! .hgtags Changeset: 5892050572b3 Author: vkempik Date: 2020-08-10 22:42 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/5892050572b3 8250876: Fix issues with cross-compile on macos Reviewed-by: erikj, ihse Contributed-by: benty at amazon.com ! common/autoconf/toolchain.m4 Changeset: d2e85075e016 Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/d2e85075e016 Added tag jdk8u302-b05 for changeset 5892050572b3 ! .hgtags Changeset: 466c81760dfb Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/466c81760dfb Merge jdk8u302-b05 ! .hgtags ! common/autoconf/generated-configure.sh Changeset: b102516679eb Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/b102516679eb Added tag aarch64-shenandoah-jdk8u302-b05 for changeset 466c81760dfb ! .hgtags Changeset: 50e950384272 Author: phh Date: 2021-06-09 21:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/50e950384272 8267545: [8u] Enable Xcode 12 builds on macOS Summary: Makefile patches to enable Xcode 12 builds Reviewed-by: simonis, andrew Contributed-by: benty at amazon.com, hohensee at amazon.com ! common/autoconf/basics.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/toolchain.m4 Changeset: 1cf600b857ba Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/1cf600b857ba Added tag jdk8u302-b06 for changeset 50e950384272 ! .hgtags Changeset: ffd326f001c5 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/ffd326f001c5 Merge jdk8u302-b06 ! .hgtags ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 0d63065bbbef Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/0d63065bbbef Added tag aarch64-shenandoah-jdk8u302-b06 for changeset ffd326f001c5 ! .hgtags Changeset: 26920b304bf9 Author: andrew Date: 2021-06-28 19:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/26920b304bf9 8269468: JDK-8269388 breaks the build on older GCCs Summary: Only set -Wno-error=format-overflow when -Wformat-overflow is supported Reviewed-by: aph, sgehwolf ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in Changeset: f7f1e6a9ee97 Author: andrew Date: 2021-06-28 19:48 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/f7f1e6a9ee97 Added tag jdk8u302-b07 for changeset 26920b304bf9 ! .hgtags Changeset: 82e113fd9f64 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/82e113fd9f64 Merge jdk8u302-b07 ! .hgtags ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 88fbfcbfb6db Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/88fbfcbfb6db Added tag aarch64-shenandoah-jdk8u302-b07 for changeset 82e113fd9f64 ! .hgtags Changeset: 172520d9a494 Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/172520d9a494 Added tag jdk8u302-b08 for changeset f7f1e6a9ee97 ! .hgtags Changeset: 69f1629d1b29 Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/69f1629d1b29 Merge jdk8u302-b08 ! .hgtags Changeset: bd873c6c4cee Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/bd873c6c4cee Added tag aarch64-shenandoah-jdk8u302-b08 for changeset 69f1629d1b29 ! .hgtags Changeset: 66de4d7f29b8 Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/66de4d7f29b8 Added tag jdk8u302-ga for changeset f7f1e6a9ee97 ! .hgtags Changeset: 4a96f4904ebc Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/4a96f4904ebc Added tag jdk8u312-b00 for changeset 5892050572b3 ! .hgtags Changeset: 9baf7f61d7fd Author: sgehwolf Date: 2021-07-02 14:28 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/9baf7f61d7fd 8269810: [8u] Update generated_configure.sh after JDK-8250876 backport Reviewed-by: shade ! common/autoconf/generated-configure.sh Changeset: 34cd25653b9d Author: ihse Date: 2014-11-21 16:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/34cd25653b9d 8065215: Print warning summary at end of configure Reviewed-by: erikj, tbell ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 Changeset: 7cf12efdd88d Author: ihse Date: 2015-05-11 13:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/7cf12efdd88d 8079891: Store configure log in $BUILD/configure.log Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 Changeset: 432eda47feff Author: ihse Date: 2015-05-12 13:24 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/432eda47feff 8080082: configure fails if you create an empty directory and then run configure from it Reviewed-by: dholmes, erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 555d2d07fad0 Author: shade Date: 2021-07-06 16:37 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/555d2d07fad0 8265978: make test should look for more locations when searching for exit code Reviewed-by: sgehwolf ! common/autoconf/generated-configure.sh ! make/Main.gmk Changeset: 0592e166c5ec Author: andrew Date: 2021-07-06 22:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/0592e166c5ec Merge ! .hgtags ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 4cfb48482d81 Author: shade Date: 2021-07-07 17:09 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/4cfb48482d81 8269953: config.log is not in build directory after 8u backport of JDK-8079891 Reviewed-by: sgehwolf ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: dc82fdcc8c4d Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/dc82fdcc8c4d Merge ! .hgtags Changeset: 843da1208969 Author: andrew Date: 2021-08-02 13:57 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/843da1208969 Added tag jdk8u312-b01 for changeset dc82fdcc8c4d ! .hgtags Changeset: 35cdd021003f Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/35cdd021003f Merge jdk8u312-b01 ! .hgtags ! common/autoconf/generated-configure.sh Changeset: bd10bb72a83f Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/bd10bb72a83f Added tag aarch64-shenandoah-jdk8u312-b01 for changeset 35cdd021003f ! .hgtags Changeset: 34cc72c686eb Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/34cc72c686eb Added tag jdk8u312-b02 for changeset 843da1208969 ! .hgtags Changeset: 6f3f67998fec Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/6f3f67998fec Merge jdk8u312-b02 ! .hgtags Changeset: 1805dbe2a4e4 Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/1805dbe2a4e4 Added tag aarch64-shenandoah-jdk8u312-b02 for changeset 6f3f67998fec ! .hgtags Changeset: 1f7a6303f6e4 Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/1f7a6303f6e4 Added tag jdk8u312-b03 for changeset 34cc72c686eb ! .hgtags Changeset: e1b0ea7df67b Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/e1b0ea7df67b Merge jdk8u312-b03 ! .hgtags Changeset: c7afd2d78ec8 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/c7afd2d78ec8 Added tag aarch64-shenandoah-jdk8u312-b03 for changeset e1b0ea7df67b ! .hgtags Changeset: c75657a93892 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/c75657a93892 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: f91451a251db Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/f91451a251db Added tag jdk8u312-b04 for changeset c75657a93892 ! .hgtags Changeset: a44e5962cd6d Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/a44e5962cd6d Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README Changeset: e3d19365e8b3 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/e3d19365e8b3 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset a44e5962cd6d ! .hgtags Changeset: 7159d482bda2 Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/7159d482bda2 Added tag jdk8u312-b05 for changeset f91451a251db ! .hgtags Changeset: 5c3a05a6b848 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/5c3a05a6b848 Merge jdk8u312-b05 ! .hgtags Changeset: 1f8dd58efb0f Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/1f8dd58efb0f Added tag aarch64-shenandoah-jdk8u312-b05 for changeset 5c3a05a6b848 ! .hgtags From shade at redhat.com Thu Oct 7 07:32:03 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:03 +0000 Subject: hg: shenandoah/jdk8/corba: 37 new changesets Message-ID: <202110070732.1977W3VX015153@aojmv0008.oracle.com> Changeset: 739608353eab Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/739608353eab Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset 73adc97111db ! .hgtags Changeset: d4bb92501f9b Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/d4bb92501f9b Added tag jdk8u302-b04 for changeset 08c22f2bc790 ! .hgtags Changeset: cbb85fa8f4f6 Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/cbb85fa8f4f6 Merge jdk8u302-b04 ! .hgtags Changeset: ed79d7768940 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/ed79d7768940 Merge ! .hgtags Changeset: 914682090954 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/914682090954 Added tag aarch64-shenandoah-jdk8u302-b04 for changeset ed79d7768940 ! .hgtags Changeset: 6e8029bd8c62 Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/6e8029bd8c62 Added tag jdk8u302-b05 for changeset d4bb92501f9b ! .hgtags Changeset: 381083a1d38b Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/381083a1d38b Merge jdk8u302-b05 ! .hgtags Changeset: 046241617d53 Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/046241617d53 Added tag aarch64-shenandoah-jdk8u302-b05 for changeset 381083a1d38b ! .hgtags Changeset: c9effa70be0a Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/c9effa70be0a Added tag jdk8u302-b06 for changeset 6e8029bd8c62 ! .hgtags Changeset: c4da099e8ac5 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/c4da099e8ac5 Merge jdk8u302-b06 ! .hgtags Changeset: e9bf920d7568 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e9bf920d7568 Added tag aarch64-shenandoah-jdk8u302-b06 for changeset c4da099e8ac5 ! .hgtags Changeset: 78fc946c1154 Author: andrew Date: 2021-06-28 06:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/78fc946c1154 Added tag jdk8u302-b07 for changeset c9effa70be0a ! .hgtags Changeset: b1d9383275ca Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/b1d9383275ca Merge jdk8u302-b07 ! .hgtags Changeset: 6d09dec09d2f Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/6d09dec09d2f Added tag aarch64-shenandoah-jdk8u302-b07 for changeset b1d9383275ca ! .hgtags Changeset: 741cfac074c4 Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/741cfac074c4 Added tag jdk8u302-b08 for changeset 78fc946c1154 ! .hgtags Changeset: 4618a8d58d47 Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/4618a8d58d47 Merge jdk8u302-b08 ! .hgtags Changeset: 36c19caa2112 Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/36c19caa2112 Added tag aarch64-shenandoah-jdk8u302-b08 for changeset 4618a8d58d47 ! .hgtags Changeset: 3f93edcf015b Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/3f93edcf015b Added tag jdk8u302-ga for changeset 78fc946c1154 ! .hgtags Changeset: f05cd86bf17d Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/f05cd86bf17d Added tag jdk8u312-b00 for changeset d4bb92501f9b ! .hgtags Changeset: 4438d08be174 Author: andrew Date: 2021-07-06 22:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/4438d08be174 Merge ! .hgtags Changeset: 0c131269504a Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/0c131269504a Merge ! .hgtags Changeset: a9f336580ece Author: andrew Date: 2021-08-02 13:57 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a9f336580ece Added tag jdk8u312-b01 for changeset 0c131269504a ! .hgtags Changeset: a8b28563fdf3 Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a8b28563fdf3 Merge jdk8u312-b01 ! .hgtags Changeset: 9085a50a24f2 Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/9085a50a24f2 Added tag aarch64-shenandoah-jdk8u312-b01 for changeset a8b28563fdf3 ! .hgtags Changeset: 94a3388d19fd Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/94a3388d19fd Added tag jdk8u312-b02 for changeset a9f336580ece ! .hgtags Changeset: 2aeb5d340f18 Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2aeb5d340f18 Merge jdk8u312-b02 ! .hgtags Changeset: a95738aeb968 Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a95738aeb968 Added tag aarch64-shenandoah-jdk8u312-b02 for changeset 2aeb5d340f18 ! .hgtags Changeset: 13423de0e42a Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/13423de0e42a Added tag jdk8u312-b03 for changeset 94a3388d19fd ! .hgtags Changeset: d009d1dd34a2 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/d009d1dd34a2 Merge jdk8u312-b03 ! .hgtags Changeset: 2b639711d003 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2b639711d003 Added tag aarch64-shenandoah-jdk8u312-b03 for changeset d009d1dd34a2 ! .hgtags Changeset: 9c71a7d12e88 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/9c71a7d12e88 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: 899084e742de Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/899084e742de Added tag jdk8u312-b04 for changeset 9c71a7d12e88 ! .hgtags Changeset: 617b64865143 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/617b64865143 Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 8df5df039c13 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/8df5df039c13 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset 617b64865143 ! .hgtags Changeset: d514245c66bd Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/d514245c66bd Added tag jdk8u312-b05 for changeset 899084e742de ! .hgtags Changeset: a2a771d76898 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a2a771d76898 Merge jdk8u312-b05 ! .hgtags Changeset: 43c755ea428a Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/43c755ea428a Added tag aarch64-shenandoah-jdk8u312-b05 for changeset a2a771d76898 ! .hgtags From shade at redhat.com Thu Oct 7 07:32:05 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:05 +0000 Subject: hg: shenandoah/jdk8/hotspot: 74 new changesets Message-ID: <202110070732.1977W6ix015164@aojmv0008.oracle.com> Changeset: b47820a50c0f Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b47820a50c0f Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset 7f48d1e4d261 ! .hgtags Changeset: 4e83cd6c5eec Author: phh Date: 2021-05-17 15:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4e83cd6c5eec 8257039: [8u] GenericTaskQueue destructor is incorrect Summary: Remove duplicate FREE_C_HEAP_ARRAY from ~GenericTaskQueue Reviewed-by: phh Contributed-by: wattsun at tencent.com ! src/share/vm/utilities/taskqueue.hpp Changeset: d5e43150cbdc Author: phh Date: 2020-09-30 12:16 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d5e43150cbdc 8253375: OSX build fails with Xcode 12.0 (12A7209) Summary: Replace double array with short array in AdapterHandlerLibrary::create_native_wrapper Reviewed-by: prr, kbarrett, lucy ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c673c965975e Author: sspitsyn Date: 2014-05-17 01:59 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c673c965975e 8043264: hsdis library not picked up correctly on expected paths Summary: Fix file separator issue on Windows Reviewed-by: sla, sspitsyn Contributed-by: krismo at azulsystems.com ! src/share/vm/compiler/disassembler.cpp Changeset: 8c40ddd927ce Author: andrew Date: 2021-05-19 16:08 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8c40ddd927ce Merge Changeset: 362d99aef38e Author: aleonard Date: 2021-05-12 11:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/362d99aef38e 8265666: Enable AIX build platform to make external debug symbols Reviewed-by: phh ! make/aix/makefiles/defs.make ! make/aix/makefiles/jsig.make ! make/aix/makefiles/saproc.make ! make/aix/makefiles/vm.make Changeset: 76c173746025 Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/76c173746025 Added tag jdk8u302-b04 for changeset 362d99aef38e ! .hgtags Changeset: 166b46cb217f Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/166b46cb217f Merge jdk8u302-b04 ! .hgtags ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: cef2221ea4d8 Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cef2221ea4d8 Merge ! .hgtags Changeset: f8a4f99c78cb Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f8a4f99c78cb Added tag aarch64-shenandoah-jdk8u302-b04 for changeset cef2221ea4d8 ! .hgtags Changeset: 88e29f735f12 Author: jbachorik Date: 2021-05-07 17:37 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/88e29f735f12 8266723: JFR periodic events are causing extra allocations Reviewed-by: adinn ! src/share/vm/jfr/jni/jfrJniMethod.cpp ! src/share/vm/jfr/jni/jfrJniMethod.hpp ! src/share/vm/jfr/jni/jfrJniMethodRegistration.cpp ! src/share/vm/jfr/utilities/jfrJavaLog.cpp ! src/share/vm/jfr/utilities/jfrJavaLog.hpp Changeset: 25016dd2c4cd Author: ctornqvi Date: 2014-06-24 07:10 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/25016dd2c4cd 8047939: [TESTBUG] Rewrite test/runtime/8001071/Test8001071.sh Summary: Rewrote the test in Java, limited the heap size to avoid time out issues on machines with a lot of memory Reviewed-by: minqi, rdurbin, dcubed - test/runtime/8001071/Test8001071.java - test/runtime/8001071/Test8001071.sh + test/runtime/Unsafe/RangeCheck.java Changeset: 2d8e910c71e3 Author: vkempik Date: 2021-05-20 15:46 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2d8e910c71e3 8267235: [macos_aarch64] InterpreterRuntime::throw_pending_exception messing up LR results in crash Reviewed-by: akozlov, aph ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Changeset: 85c1e19cae36 Author: andrew Date: 2021-05-26 18:02 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/85c1e19cae36 Merge - test/runtime/8001071/Test8001071.java - test/runtime/8001071/Test8001071.sh Changeset: 4962a2ce077a Author: phh Date: 2021-05-27 13:27 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4962a2ce077a 8239053: [8u] clean up undefined-var-template warnings Summary: From 8182299, clean up undefined-var-template warnings Reviewed-by: phh, simonis Contributed-by: benty at amazon.com ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 32dfc0a37b47 Author: phh Date: 2021-05-27 13:27 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/32dfc0a37b47 8239400: [8u] clean up undefined-var-template warnings Summary: From 8182299, clean up delete-non-virtual-dtor warnings in HotSpot Reviewed-by: phh, simonis Contributed-by: benty at amazon.com ! src/os/aix/vm/decoder_aix.hpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 36b8f4cb56c2 Author: vkempik Date: 2020-08-10 22:42 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/36b8f4cb56c2 8250876: Fix issues with cross-compile on macos Reviewed-by: erikj, ihse Contributed-by: benty at amazon.com ! make/bsd/makefiles/saproc.make Changeset: 54326de2a1d7 Author: simonis Date: 2021-05-07 19:42 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/54326de2a1d7 8267689: [aarch64] Crash due to bad shift in indirect addressing mode Reviewed-by: adinn, aph, phh ! src/cpu/aarch64/vm/aarch64.ad Changeset: f5e5d3ac66a0 Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f5e5d3ac66a0 Added tag jdk8u302-b05 for changeset 54326de2a1d7 ! .hgtags Changeset: fca142bcb039 Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fca142bcb039 Merge jdk8u302-b05 ! .hgtags ! make/bsd/makefiles/saproc.make ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/utilities/hashtable.cpp - test/runtime/8001071/Test8001071.java - test/runtime/8001071/Test8001071.sh Changeset: 192dc0eafc75 Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/192dc0eafc75 Added tag aarch64-shenandoah-jdk8u302-b05 for changeset fca142bcb039 ! .hgtags Changeset: 782f3b88b5ba Author: phh Date: 2021-06-09 21:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/782f3b88b5ba 8267545: [8u] Enable Xcode 12 builds on macOS Summary: Makefile and source code patches to enable Xcode 12 builds Reviewed-by: simonis, andrew Contributed-by: benty at amazon.com, hohensee at amazon.com ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 542ef054d462 Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/542ef054d462 Added tag jdk8u302-b06 for changeset 782f3b88b5ba ! .hgtags Changeset: c025871295ef Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c025871295ef Merge jdk8u302-b06 ! .hgtags ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 420bcbc042c8 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/420bcbc042c8 Added tag aarch64-shenandoah-jdk8u302-b06 for changeset c025871295ef ! .hgtags Changeset: c43e69afd9aa Author: jvanek Date: 2021-06-28 06:05 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c43e69afd9aa 8269388: Default build of OpenJDK 8 fails on newer GCCs with warnings as errors on format-overflow Summary: Disable promoting the format-overflow warning to an error in os_linux.cpp until the code is fixed Reviewed-by: andrew ! make/linux/makefiles/gcc.make Changeset: 78dfe32cac58 Author: andrew Date: 2021-06-28 19:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/78dfe32cac58 8269468: JDK-8269388 breaks the build on older GCCs Summary: Only set -Wno-error=format-overflow when -Wformat-overflow is supported Reviewed-by: aph, sgehwolf ! make/linux/makefiles/gcc.make Changeset: 1bcfb8cc3c6d Author: andrew Date: 2021-06-28 19:48 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1bcfb8cc3c6d Added tag jdk8u302-b07 for changeset 78dfe32cac58 ! .hgtags Changeset: a48af4014158 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a48af4014158 Merge jdk8u302-b07 ! .hgtags ! make/linux/makefiles/gcc.make Changeset: 45e385842e9c Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/45e385842e9c Added tag aarch64-shenandoah-jdk8u302-b07 for changeset a48af4014158 ! .hgtags Changeset: 28f0a3ffc3e9 Author: iveresov Date: 2021-04-19 21:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/28f0a3ffc3e9 8264066: Enhance compiler validation Reviewed-by: ahgross, kvn, rhalade, thartmann, andrew ! src/share/vm/c1/c1_RangeCheckElimination.cpp Changeset: f827618f286c Author: mbalao Date: 2021-04-09 09:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f827618f286c 8264079: Improve abstractions Reviewed-by: andrew ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp Changeset: a209b6f5b09a Author: aph Date: 2021-07-15 06:29 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a209b6f5b09a 8270533: AArch64: size_fits_all_mem_uses should return false if its output is a CAS Reviewed-by: adinn ! src/cpu/aarch64/vm/aarch64.ad Changeset: 9f69a248b980 Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9f69a248b980 Added tag jdk8u302-b08 for changeset a209b6f5b09a ! .hgtags Changeset: e7fba27b8fde Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e7fba27b8fde Merge jdk8u302-b08 ! .hgtags ! src/cpu/aarch64/vm/aarch64.ad ! src/share/vm/code/dependencies.cpp Changeset: c5f68aaf0120 Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c5f68aaf0120 Added tag aarch64-shenandoah-jdk8u302-b08 for changeset e7fba27b8fde ! .hgtags Changeset: 91924b4ea982 Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/91924b4ea982 Added tag jdk8u302-ga for changeset a209b6f5b09a ! .hgtags Changeset: f988e1e0cc63 Author: roland Date: 2014-05-26 10:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f988e1e0cc63 8042557: compiler/uncommontrap/TestSpecTrapClassUnloading.java fails with: GC triggered before VM initialization completed Summary: larger heap size, bug fix when trying to exhaust memory Reviewed-by: vlivanov, twisti, kvn ! test/compiler/uncommontrap/TestSpecTrapClassUnloading.java Changeset: f415cba8e61a Author: coleenp Date: 2019-10-28 16:41 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f415cba8e61a 8086003: Test fails on OSX with java.lang.RuntimeException 'Narrow klass base: 0x0000000000000000, Narrow klass shift: 3' missing Summary: Make the test reserve 1G rather than 3G, so it is more reliable. Reviewed-by: hseigel, stuefe ! test/runtime/CompressedOops/CompressedClassPointers.java Changeset: 53f5e22f747c Author: andrew Date: 2021-06-28 16:45 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/53f5e22f747c Merge Changeset: 95f3b2c9884d Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/95f3b2c9884d Added tag jdk8u312-b00 for changeset 54326de2a1d7 ! .hgtags Changeset: 44fa2587c2c3 Author: andrew Date: 2021-07-06 23:00 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/44fa2587c2c3 Merge ! .hgtags Changeset: ac778bf9cea0 Author: simonis Date: 2021-07-07 12:25 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ac778bf9cea0 8220786: Create new switch to redirect error reporting output to stdout or stderr Reviewed-by: dholmes, goetz ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp + test/runtime/ErrorHandling/ErrorFileRedirectTest.java Changeset: cd0b0defd596 Author: phedlin Date: 2020-07-06 21:29 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cd0b0defd596 8248901: Signed immediate support in .../share/assembler.hpp is broken. Reviewed-by: neliasso, kvn, thartmann ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/utilities/debug.hpp Changeset: 0f0e2e13d711 Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0f0e2e13d711 Merge ! .hgtags Changeset: 2f7a380c9a0a Author: andrew Date: 2021-08-02 07:22 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2f7a380c9a0a 8271466: StackGap test fails on aarch64 due to "-m64" Summary: Don't add -m64 when running on aarch64 Reviewed-by: andrew Contributed-by: xiangyuan ! test/runtime/StackGap/testme.sh Changeset: 4735f3031e23 Author: andrew Date: 2021-08-02 13:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4735f3031e23 Added tag jdk8u312-b01 for changeset 2f7a380c9a0a ! .hgtags Changeset: bd8b3f13eaac Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bd8b3f13eaac Merge jdk8u312-b01 ! .hgtags ! src/share/vm/asm/assembler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 0a0e4583e99d Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0a0e4583e99d Added tag aarch64-shenandoah-jdk8u312-b01 for changeset bd8b3f13eaac ! .hgtags Changeset: 7c6a486aa598 Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7c6a486aa598 Added tag jdk8u312-b02 for changeset 4735f3031e23 ! .hgtags Changeset: 2d50ba15bdc8 Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2d50ba15bdc8 Merge jdk8u312-b02 ! .hgtags Changeset: dd300c382624 Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/dd300c382624 Added tag aarch64-shenandoah-jdk8u312-b02 for changeset 2d50ba15bdc8 ! .hgtags Changeset: 3a32b3b405b1 Author: hshi Date: 2021-08-11 15:13 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3a32b3b405b1 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M 8266206: Build failure after JDK-8264752 with older GCCs Reviewed-by: phh ! src/share/vm/jfr/recorder/service/jfrMemorySizer.cpp ! src/share/vm/jfr/recorder/service/jfrMemorySizer.hpp ! src/share/vm/jfr/recorder/service/jfrOptionSet.cpp Changeset: a6da205dfd9f Author: andrew Date: 2021-08-16 06:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a6da205dfd9f 8272214: [8u] Build failure after backport of JDK-8248901 Summary: glibc and newer Windows systems need __STDC_CONSTANT_MACROS, older Windows systems need INT64_C & UINT64_C defined Reviewed-by: sgehwolf Contributed-by: Severin Gehwolf ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: a3f01f9da231 Author: andrew Date: 2021-08-16 06:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a3f01f9da231 Added tag jdk8u312-b03 for changeset a6da205dfd9f ! .hgtags Changeset: 9b521fc2cb93 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9b521fc2cb93 Merge jdk8u312-b03 ! .hgtags ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 22f0032a35ec Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/22f0032a35ec Added tag aarch64-shenandoah-jdk8u312-b03 for changeset 9b521fc2cb93 ! .hgtags Changeset: 35617854e529 Author: dholmes Date: 2021-07-06 02:20 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/35617854e529 8269882: stack-use-after-scope in NewObjectA Reviewed-by: kbarrett ! src/share/vm/prims/jni.cpp Changeset: be817949c260 Author: zgu Date: 2021-06-30 11:37 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/be817949c260 8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark Reviewed-by: coleenp, jvernee ! src/share/vm/runtime/safepoint.cpp Changeset: bb5bec382764 Author: andrew Date: 2021-08-18 05:51 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bb5bec382764 Merge Changeset: 803cbdf0f152 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/803cbdf0f152 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README Changeset: f25ffaede0d8 Author: coleenp Date: 2018-01-29 11:55 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f25ffaede0d8 8194246: JVM crashes when calling getStackTrace if stack contains a method that is a member of a very large class Summary: Use unsigned short to save method_id in stack trace. Reviewed-by: mchung, hseigel ! src/share/vm/classfile/javaClasses.cpp + test/runtime/StackTrace/LargeClassTest.java Changeset: 21394894714b Author: shade Date: 2021-08-18 11:17 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/21394894714b 8269859: BacktraceBuilder._cprefs needs to be accessed as unsigned short Reviewed-by: sgehwolf ! src/share/vm/classfile/javaClasses.cpp Changeset: 2bcd260edd04 Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2bcd260edd04 Added tag jdk8u312-b04 for changeset 21394894714b ! .hgtags Changeset: e9539ed1b99e Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e9539ed1b99e Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/safepoint.cpp Changeset: 6aa32e16a652 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6aa32e16a652 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset e9539ed1b99e ! .hgtags Changeset: a878df156b91 Author: shade Date: 2021-08-20 11:28 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a878df156b91 8272714: [8u] Build failure after backport of JDK-8248901 with MSVC 2013 Summary: Relax the check to accept more MSVC versions Reviewed-by: sgehwolf ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 2696ba6cc474 Author: andrew Date: 2021-08-25 17:51 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2696ba6cc474 Merge Changeset: a366742f8036 Author: enevill Date: 2015-07-21 13:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a366742f8036 8131062: aarch64: add support for GHASH acceleration Summary: Add support for GHASH using pmull Reviewed-by: kvn, goetz, aph Contributed-by: alexander.alexeev at caviumnetworks.com ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp Changeset: e7fc0c4f478e Author: aph Date: 2015-09-02 13:23 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e7fc0c4f478e 8134869: AARCH64: GHASH intrinsic is not optimal Summary: Rewrite intrinsic to make better use of SIMD instructions Reviewed-by: kvn ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: e2ac513ec7b3 Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e2ac513ec7b3 Added tag jdk8u312-b05 for changeset e7fc0c4f478e ! .hgtags Changeset: 0155888ff4c9 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0155888ff4c9 Merge jdk8u312-b05 ! .hgtags ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 3a5d2b02bbb5 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3a5d2b02bbb5 Added tag aarch64-shenandoah-jdk8u312-b05 for changeset 0155888ff4c9 ! .hgtags Changeset: 94ebbbbecb23 Author: shade Date: 2021-10-07 09:14 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/94ebbbbecb23 Merge ! src/share/vm/prims/jni.cpp From shade at redhat.com Thu Oct 7 07:32:18 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 07:32:18 +0000 Subject: hg: shenandoah/jdk8/jdk: 123 new changesets Message-ID: <202110070732.1977WMQu015204@aojmv0008.oracle.com> Changeset: 86e87df5672e Author: shade Date: 2021-06-23 12:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/86e87df5672e Added tag aarch64-shenandoah-jdk8u302-b03-shenandoah-merge-2021-06-23 for changeset 945bac034e46 ! .hgtags Changeset: 1fa2e83e4e7f Author: tyan Date: 2014-02-15 10:23 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1fa2e83e4e7f 8032050: Clean up for java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java Reviewed-by: smarks ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/testlibrary/JavaVM.java Changeset: 497370175665 Author: abakhtin Date: 2021-05-17 17:07 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/497370175665 8242565: Policy initialization issues when the denyAfter constraint is enabled Reviewed-by: andrew, sgehwolf ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! test/java/security/Policy/SignedJar/SignedJarTest.java + test/java/security/Policy/SignedJar/java.security Changeset: f9073d041c9d Author: yan Date: 2015-07-09 12:34 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f9073d041c9d 8130430: [TEST_BUG] remove unnecessary internal calls from javax/swing/JRadioButton/8075609/bug8075609.java Reviewed-by: alexsch ! test/javax/swing/JRadioButton/8075609/bug8075609.java Changeset: 7b979289680f Author: dmarkov Date: 2021-03-08 16:38 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7b979289680f 8262446: DragAndDrop hangs on Windows Reviewed-by: aivanov, serb, kizune ! src/windows/native/sun/windows/awt_DnDDT.cpp Changeset: 79198fff6d1d Author: xuelei Date: 2019-08-19 12:56 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/79198fff6d1d 8228757: Fail fast if the handshake type is unknown Reviewed-by: jnimeh, sgehwolf ! src/share/classes/sun/security/ssl/SSLEngineInputRecord.java ! src/share/classes/sun/security/ssl/SSLHandshake.java ! src/share/classes/sun/security/ssl/SSLSocketInputRecord.java Changeset: ba0e36b4275f Author: andrew Date: 2021-05-19 16:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ba0e36b4275f Merge Changeset: 821ac4be0e8f Author: xuelei Date: 2020-05-27 09:46 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/821ac4be0e8f 8206925: Support the certificate_authorities extension Reviewed-by: mullan + src/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java ! src/share/classes/sun/security/ssl/CertificateRequest.java ! src/share/classes/sun/security/ssl/SSLExtension.java ! src/share/classes/sun/security/ssl/X509Authentication.java ! test/javax/net/ssl/templates/SSLContextTemplate.java + test/sun/security/ssl/X509KeyManager/CertificateAuthorities.java + test/sun/security/ssl/X509TrustManagerImpl/CacertsLimit.java + test/sun/security/ssl/X509TrustManagerImpl/TooManyCAs.java Changeset: 6a07e2cb5bdb Author: snazarki Date: 2021-05-20 16:26 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6a07e2cb5bdb 8206243: java -XshowSettings fails if memory.limit_in_bytes overflows LONG.max Reviewed-by: sgehwolf ! src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java Changeset: 521644855745 Author: andrew Date: 2021-05-25 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/521644855745 Added tag jdk8u302-b04 for changeset 6a07e2cb5bdb ! .hgtags Changeset: c083a4d5f649 Author: andrew Date: 2021-06-20 22:32 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c083a4d5f649 Merge jdk8u302-b04 ! .hgtags ! src/share/classes/sun/security/tools/KeyStoreUtil.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java Changeset: a6d54e1f057b Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a6d54e1f057b Merge ! .hgtags Changeset: 202ae03a591e Author: andrew Date: 2021-06-30 02:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/202ae03a591e Added tag aarch64-shenandoah-jdk8u302-b04 for changeset a6d54e1f057b ! .hgtags Changeset: cb560b38d15a Author: jbachorik Date: 2021-05-07 17:23 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cb560b38d15a 8266723: JFR periodic events are causing extra allocations Reviewed-by: adinn ! src/share/classes/jdk/jfr/internal/JVM.java ! src/share/classes/jdk/jfr/internal/Logger.java ! src/share/classes/jdk/jfr/internal/RequestEngine.java Changeset: 93a23f95f629 Author: smarks Date: 2014-12-01 17:59 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/93a23f95f629 8035000: clean up ActivationLibrary.DestroyThread Reviewed-by: lancea ! test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java ! test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java ! test/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java ! test/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java ! test/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java ! test/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java ! test/java/rmi/activation/Activatable/extLoadedImpl/ExtLoadedImplTest.java ! test/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java ! test/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/NestedActivate.java ! test/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java ! test/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java ! test/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java ! test/java/rmi/activation/Activatable/restartService/RestartService.java ! test/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java ! test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java ! test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java ! test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/RMID.java Changeset: c52704d27852 Author: serb Date: 2019-03-16 17:50 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c52704d27852 7106851: Test should not use System.exit Reviewed-by: aivanov, psadhukhan, kaddepalli + test/javax/accessibility/6192422/bug6192422.java Changeset: 7fb344096b3b Author: pchopra Date: 2015-08-13 16:26 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7fb344096b3b 8081764: [TEST_BUG] Test javax/swing/plaf/aqua/CustomComboBoxFocusTest.java fails on Windows, Solaris Sparcv9 and Linux but passes on MacOSX Reviewed-by: alexsch, azvegint ! test/javax/swing/plaf/aqua/CustomComboBoxFocusTest.java Changeset: 51233f24cf43 Author: prr Date: 2020-09-19 17:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/51233f24cf43 8249142: java/awt/FontClass/CreateFont/DeleteFont.sh is unstable Reviewed-by: serb ! test/java/awt/FontClass/CreateFont/DeleteFont.java ! test/java/awt/FontClass/CreateFont/DeleteFont.sh Changeset: 9122a352fb12 Author: kshefov Date: 2015-08-05 16:35 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9122a352fb12 8028618: [TEST BUG] javax/swing/JScrollBar/bug4202954/bug4202954.java fails Reviewed-by: alexsch, azvegint Contributed-by: nadeesh.tv at oracle.com ! test/javax/swing/JScrollBar/bug4202954/bug4202954.java Changeset: dc8461142fb8 Author: weijun Date: 2015-03-16 18:08 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/dc8461142fb8 8074836: Resolve disabled warnings for libosxkrb5 8074835: Resolve disabled warnings for libj2gss Reviewed-by: erikj ! make/lib/SecurityLibraries.gmk ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/krb5/nativeccache.c Changeset: 801743983ed6 Author: mikael Date: 2014-02-18 17:55 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/801743983ed6 8035287: gcc warnings compiling various libraries files Reviewed-by: prr ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/sun/java2d/opengl/OGLContext.c ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XToolkit.c Changeset: e6d50cd7310b Author: sla Date: 2014-03-21 09:38 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e6d50cd7310b 8037825: Fix warnings and enable "warnings as errors" in serviceability native libraries Reviewed-by: alanb ! make/lib/ServiceabilityLibraries.gmk ! src/share/back/SDE.c ! src/share/back/eventHandler.c ! src/share/back/log_messages.c ! src/share/instrument/InvocationAdapter.c ! src/share/instrument/PathCharsValidator.c ! src/solaris/back/util_md.h ! src/solaris/native/sun/management/MacosxOperatingSystem.c ! src/windows/back/linker_md.c ! src/windows/back/proc_md.h Changeset: 4984fad6c950 Author: pchelko Date: 2014-05-22 15:46 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4984fad6c950 8043646: libosxapp.dylib fails to build on Mac OS 10.9 with clang Reviewed-by: anthony, serb ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: bae272e8923c Author: ctornqvi Date: 2017-01-05 16:46 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/bae272e8923c 8172188: JDI tests fail due to "permission denied" when creating temp file Reviewed-by: hseigel, mseledtsov ! test/com/sun/jdi/ShellScaffold.sh Changeset: 72e77abe6d85 Author: serb Date: 2018-01-22 08:00 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/72e77abe6d85 6990210: [TEST_BUG] EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java fails on gnome Reviewed-by: serb Contributed-by: Michal Vala ! test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java Changeset: 7a7302919f69 Author: sgehwolf Date: 2021-05-19 12:10 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7a7302919f69 8266929: Unable to use algorithms from 3p providers Summary: Delay initializtion of AID cache table until after jar verification Reviewed-by: phh ! src/share/classes/sun/security/x509/AlgorithmId.java Changeset: 68d30424a687 Author: snazarki Date: 2021-05-26 12:00 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/68d30424a687 8267426: MonitorVmStartTerminate test timed out on Embedded VM Reviewed-by: dholmes, sspitsyn ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java Changeset: a6258600dfe0 Author: pchopra Date: 2015-05-22 17:30 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a6258600dfe0 8078855: [TEST_BUG] javax/swing/JComboBox/8032878/bug8032878.java fails in WindowsClassicLookAndFeel Reviewed-by: alexsch, aivanov ! test/javax/swing/JComboBox/8032878/bug8032878.java Changeset: 18b7da5618f5 Author: psadhukhan Date: 2020-12-14 11:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/18b7da5618f5 8196092: javax/swing/JComboBox/8032878/bug8032878.java fails Reviewed-by: serb, pbansal ! test/javax/swing/JComboBox/8032878/bug8032878.java Changeset: 63e69aef6997 Author: andrew Date: 2021-05-26 18:02 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/63e69aef6997 Merge Changeset: c6da1ce5c680 Author: mbalao Date: 2021-05-18 22:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c6da1ce5c680 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod Reviewed-by: valeriep, andrew ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c ! src/share/native/sun/security/pkcs11/j2secmod.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h Changeset: 219c9107171b Author: abakhtin Date: 2021-05-27 19:17 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/219c9107171b 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 Reviewed-by: phh, andrew ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/EmptyPassword.java Changeset: d727e88aa12a Author: wetmore Date: 2020-12-02 04:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d727e88aa12a 8254631: Better support ALPN byte wire values in SunJSSE Reviewed-by: xuelei, dfuchs, sgehwolf ! src/share/classes/sun/security/ssl/AlpnExtension.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + test/sun/security/ssl/ALPN/AlpnGreaseTest.java Changeset: 8f0c77f98b2a Author: andrew Date: 2021-06-01 05:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8f0c77f98b2a Added tag jdk8u302-b05 for changeset d727e88aa12a ! .hgtags Changeset: 2da15443e659 Author: andrew Date: 2021-07-02 05:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2da15443e659 Merge jdk8u302-b05 ! .hgtags ! make/lib/SecurityLibraries.gmk ! make/lib/ServiceabilityLibraries.gmk ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! test/com/sun/jdi/ShellScaffold.sh ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java Changeset: ca1f2a42a25c Author: andrew Date: 2021-07-02 05:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ca1f2a42a25c Added tag aarch64-shenandoah-jdk8u302-b05 for changeset 2da15443e659 ! .hgtags Changeset: 9f55d69c13a7 Author: phh Date: 2021-06-09 21:46 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9f55d69c13a7 8267545: [8u] Enable Xcode 12 builds on macOS Summary: Makefile and source code patches to enable Xcode 12 builds Reviewed-by: simonis, andrew Contributed-by: benty at amazon.com, hohensee at amazon.com ! make/lib/CoreLibraries.gmk ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/share/native/sun/misc/URLClassPath.c Changeset: 80412c544023 Author: dongbohe Date: 2021-06-09 17:53 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/80412c544023 8268444: keytool -v -list print is incorrect after backport JDK-8141457 Reviewed-by: coffeys, mullan, sgehwolf ! src/share/classes/sun/security/tools/keytool/Resources.java Changeset: 7762468ad650 Author: andrew Date: 2021-06-14 18:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7762468ad650 Added tag jdk8u302-b06 for changeset 80412c544023 ! .hgtags Changeset: 64380a69f541 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/64380a69f541 Merge jdk8u302-b06 ! .hgtags ! make/lib/CoreLibraries.gmk ! src/share/classes/sun/security/tools/keytool/Resources.java Changeset: c297e1c12615 Author: andrew Date: 2021-07-05 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c297e1c12615 Added tag aarch64-shenandoah-jdk8u302-b06 for changeset 64380a69f541 ! .hgtags Changeset: d58d184d3cb9 Author: andrew Date: 2021-06-28 06:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d58d184d3cb9 Added tag jdk8u302-b07 for changeset 7762468ad650 ! .hgtags Changeset: 1f2200318be4 Author: andrew Date: 2021-07-07 16:15 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1f2200318be4 Merge jdk8u302-b07 ! .hgtags Changeset: de8acda9b284 Author: andrew Date: 2021-07-07 16:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/de8acda9b284 Added tag aarch64-shenandoah-jdk8u302-b07 for changeset 1f2200318be4 ! .hgtags Changeset: 88f399f9f55f Author: mbalao Date: 2021-04-26 12:04 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/88f399f9f55f 8256157: Improve bytecode assembly Reviewed-by: andrew ! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java Changeset: b00ff8ba3b41 Author: mbalao Date: 2021-04-16 16:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b00ff8ba3b41 8256491: Better HTTP transport Reviewed-by: andrew ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: 2464c9fe4c11 Author: alvdavi Date: 2021-05-21 19:56 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2464c9fe4c11 8258432: Improve file transfers Reviewed-by: mbalao, andrew ! src/share/classes/sun/net/ftp/impl/FtpClient.java Changeset: 6c4088f2f22e Author: alvdavi Date: 2021-06-07 15:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6c4088f2f22e 8260453: Improve Font Bounding Reviewed-by: mbalao, andrew ! src/share/classes/sun/font/TrueTypeFont.java Changeset: cd1f22f0c2a3 Author: avoitylov Date: 2021-03-09 20:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cd1f22f0c2a3 8260960: Signs of jarsigner signing Reviewed-by: mbalao, andrew ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/jarsigner/Resources.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh Changeset: 465a2d03f9b0 Author: mbalao Date: 2021-03-29 17:02 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/465a2d03f9b0 8260967: Better jar file validation Reviewed-by: bae, andrew ! make/mapfiles/libzip/mapfile-vers ! make/mapfiles/libzip/reorder-sparc ! make/mapfiles/libzip/reorder-sparcv9 ! make/mapfiles/libzip/reorder-x86 ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarInputStream.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/misc/JavaUtilZipFileAccess.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h Changeset: f856b833b9cc Author: serb Date: 2021-03-27 00:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f856b833b9cc 8262403: Enhanced data transfers Reviewed-by: rhalade, prr, vdyakov, ahgross, andrew, mbalao ! src/share/classes/java/awt/datatransfer/MimeType.java Changeset: 20d58ea2a5af Author: naoto Date: 2021-03-04 20:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/20d58ea2a5af 8262410: Enhanced rules for zones Reviewed-by: rriggs, rhalade, mbalao, andrew ! src/share/classes/java/time/zone/ZoneRules.java Changeset: 2629129bcbd6 Author: alvdavi Date: 2021-06-07 15:08 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2629129bcbd6 8262477: Enhance String Conclusions Reviewed-by: mbalao, andrew ! src/share/classes/sun/font/TrueTypeFont.java Changeset: d8b4a533887c Author: robm Date: 2021-05-24 11:44 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d8b4a533887c 8262967: Improve Zip file support Reviewed-by: ahgross, rhalade, aefimov, andrew ! src/share/classes/java/util/zip/ZipFile.java Changeset: 06b4012edc72 Author: weijun Date: 2021-03-31 17:24 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/06b4012edc72 8264460: Improve NTLM support Reviewed-by: xuelei, mbalao, andrew ! src/share/classes/com/sun/security/ntlm/NTLM.java Changeset: aaa85c12fdd0 Author: andrew Date: 2021-07-16 05:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aaa85c12fdd0 Added tag jdk8u302-b08 for changeset 06b4012edc72 ! .hgtags Changeset: aa8000d6c33c Author: andrew Date: 2021-07-16 05:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/aa8000d6c33c Merge jdk8u302-b08 ! .hgtags ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/native/java/util/zip/zip_util.c Changeset: 3b3a8353e5eb Author: andrew Date: 2021-07-16 05:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3b3a8353e5eb Added tag aarch64-shenandoah-jdk8u302-b08 for changeset aa8000d6c33c ! .hgtags Changeset: b7aeec2b20fa Author: andrew Date: 2021-07-20 18:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b7aeec2b20fa Added tag jdk8u302-ga for changeset 06b4012edc72 ! .hgtags Changeset: 171c8c18af5e Author: martin Date: 2016-05-12 10:57 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/171c8c18af5e 8156584: Initialization race in sun.security.x509.AlgorithmId.get Summary: Use safe variant of double-checked locking to initialize oidTable Reviewed-by: xuelei ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/OidTableInit.java Changeset: 1ca2806744e0 Author: phh Date: 2021-06-01 11:56 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1ca2806744e0 8265238: [8u] [macos] build failure in OpenJDK8u after JDK-8211301 in older xcode Summary: Cast nsWindow.contentView to NSView* before use Reviewed-by: simonis Contributed-by: alvdavi at amazon.com ! src/macosx/native/sun/awt/AWTWindow.m Changeset: fa98d2743adf Author: smarks Date: 2014-12-04 18:54 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/fa98d2743adf 8035001: TEST_BUG: the retry logic in RMID.start() should check that the subprocess hasn't terminated Reviewed-by: lancea ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java Changeset: a45d9a654ac5 Author: abakhtin Date: 2018-07-12 08:44 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a45d9a654ac5 8206189: sun/security/pkcs12/EmptyPassword.java fails with Sequence tag error Reviewed-by: phh, andrew ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Changeset: a6e7a526f636 Author: mbaesken Date: 2019-09-23 17:02 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a6e7a526f636 8231222: fix pkcs11 P11_DEBUG guarded native traces Reviewed-by: clanger ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c Changeset: 546239816d7d Author: abakhtin Date: 2021-06-09 21:43 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/546239816d7d 8202837: PBES2 AlgorithmId encoding error in PKCS12 KeyStore Reviewed-by: phh, andrew ! src/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/sun/security/pkcs12/PBES2Encoding.java Changeset: cf9f21699cd3 Author: abakhtin Date: 2021-06-09 22:10 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cf9f21699cd3 8214513: A PKCS12 keystore from Java 8 using custom PBE parameters cannot be read in Java 11 Reviewed-by: phh, andrew ! src/share/classes/com/sun/crypto/provider/PBES2Parameters.java + test/sun/security/pkcs12/WrongPBES2.java Changeset: 136c3a250de4 Author: alexsch Date: 2015-04-15 14:38 +0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/136c3a250de4 8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object Reviewed-by: serb, azvegint ! src/share/classes/javax/swing/JComboBox.java + test/javax/swing/JComboBox/8072767/bug8072767.java Changeset: 272f5ef51115 Author: akasko Date: 2021-06-09 10:39 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/272f5ef51115 8263311: Watch registry changes for remote printers update instead of polling Reviewed-by: psadhukhan, serb ! src/windows/classes/sun/print/PrintServiceLookupProvider.java ! src/windows/native/sun/windows/WPrinterJob.cpp ! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java Changeset: 2ddc14308c13 Author: serb Date: 2020-04-16 10:12 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2ddc14308c13 8196181: sun/java2d/GdiRendering/InsetClipping.java fails Reviewed-by: jdv ! test/sun/java2d/GdiRendering/InsetClipping.java Changeset: 5d28f9478875 Author: pkbalakr Date: 2017-08-02 11:26 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/5d28f9478875 8027154: [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb, arapte Contributed-by: krishna.addepalli at oracle.com ! test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: 93d2b685f50c Author: xiaofeya Date: 2017-09-04 17:46 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/93d2b685f50c 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address Reviewed-by: rriggs, chegar, msheppar ! test/java/net/MulticastSocket/TestInterfaces.java Changeset: 0ee846c86b54 Author: abakhtin Date: 2021-06-22 22:11 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0ee846c86b54 8229243: SunPKCS11-Solaris provider tests failing on Solaris 11.4 Summary: For CK_GCM_PARAMS, try the spec definition first before falling back to the header file definition Reviewed-by: andrew ! src/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c + src/share/native/sun/security/pkcs11/wrapper/pkcs11gcm2.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.h ! src/windows/native/sun/security/pkcs11/wrapper/p11_md.h ! test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java Changeset: 3251e36d8d58 Author: tnakamura Date: 2020-03-09 15:07 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3251e36d8d58 8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print Reviewed-by: serb, pbansal, psadhukhan ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp Changeset: dae426e8ef64 Author: aivanov Date: 2021-03-09 11:36 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/dae426e8ef64 8262829: Native crash in Win32PrintServiceLookup.getAllPrinterNames() Reviewed-by: prr, psadhukhan, serb ! src/windows/native/sun/windows/WPrinterJob.cpp Changeset: 769917bdba1c Author: msheppar Date: 2014-08-11 15:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/769917bdba1c 8054118: java/net/ipv6tests/UdpTest.java failed intermittently Summary: ignore the Teredo interface on windows test machines Reviewed-by: chegar ! test/java/net/ipv6tests/Tests.java Changeset: 3a9c28384b35 Author: redestad Date: 2016-11-29 16:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3a9c28384b35 8170467: (reflect) Optimize SignatureParser's use of StringBuilders Reviewed-by: shade, redestad Contributed-by: Max-Kanat Alexander ! src/share/classes/sun/reflect/generics/parser/SignatureParser.java Changeset: 2e292618f87a Author: plevart Date: 2016-11-30 19:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2e292618f87a 8035424: (reflect) Performance problem in sun.reflect.generics.parser.SignatureParser Reviewed-by: redestad ! src/share/classes/sun/reflect/generics/parser/SignatureParser.java Changeset: 4b71278b9760 Author: serb Date: 2020-04-08 02:36 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4b71278b9760 8238567: SoftMainMixer.processAudioBuffers(): Wrong handling of stoppedMixers Reviewed-by: prr ! src/share/classes/com/sun/media/sound/SoftMainMixer.java Changeset: d2fcf157ec27 Author: lkorinth Date: 2021-03-04 13:20 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d2fcf157ec27 8262000: jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParallelScavenge.java failed with "OutOfMemoryError: Java heap space" Reviewed-by: tschatzl, egahlin ! test/jdk/jfr/event/gc/detailed/ExecuteOOMApp.java Changeset: eac7639b533d Author: jpai Date: 2021-01-18 11:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/eac7639b533d 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Reviewed-by: alanb, chegar ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java Changeset: 40816fbc2f3f Author: andrew Date: 2021-06-28 16:45 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/40816fbc2f3f Merge Changeset: ec6207f84216 Author: andrew Date: 2021-06-28 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ec6207f84216 Added tag jdk8u312-b00 for changeset d727e88aa12a ! .hgtags Changeset: 3b17a40d9a8d Author: abakhtin Date: 2021-05-10 09:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3b17a40d9a8d 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Reviewed-by: jnimeh, xuelei, mdoerr ! src/share/classes/sun/security/ssl/PreSharedKeyExtension.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/ServerHello.java ! src/share/classes/sun/security/util/Cache.java Changeset: 831e982a328e Author: ant Date: 2014-11-14 12:32 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/831e982a328e 8004148: NPE in sun.awt.SunToolkit.getWindowDeactivationTime Reviewed-by: serb ! src/share/classes/sun/awt/SunToolkit.java Changeset: ae86052f5a48 Author: serb Date: 2016-10-18 18:00 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ae86052f5a48 8166673: The new implementation of Robot.waitForIdle() may hang Reviewed-by: azvegint, ssadetsky ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/Robot/WaitForIdleSyncroizedOnString/WaitForIdleSyncroizedOnString.java Changeset: 4884da884f13 Author: andrew Date: 2021-07-06 22:59 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4884da884f13 Merge ! .hgtags Changeset: b0c07274cb96 Author: clanger Date: 2021-07-05 08:31 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b0c07274cb96 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Reviewed-by: shade ! test/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 73b25a844e71 Author: andrew Date: 2021-07-07 02:42 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/73b25a844e71 Merge Changeset: 6ad1494ea3f4 Author: xuelei Date: 2019-01-14 10:00 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6ad1494ea3f4 8214418: half-closed SSLEngine status may cause application dead loop Reviewed-by: jnimeh, dfuchs, chegar ! src/share/classes/sun/security/ssl/Ciphertext.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/TransportContext.java Changeset: 52d602b87c1d Author: andrew Date: 2021-07-29 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/52d602b87c1d Merge ! .hgtags Changeset: fdb55e17615e Author: andrew Date: 2021-08-02 13:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/fdb55e17615e Added tag jdk8u312-b01 for changeset 52d602b87c1d ! .hgtags Changeset: a220333daa84 Author: andrew Date: 2021-08-16 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a220333daa84 Merge jdk8u312-b01 ! .hgtags ! src/macosx/native/sun/awt/AWTWindow.m ! src/share/classes/java/net/URL.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! test/java/net/MulticastSocket/TestInterfaces.java Changeset: dc6149718987 Author: andrew Date: 2021-08-16 18:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/dc6149718987 Added tag aarch64-shenandoah-jdk8u312-b01 for changeset a220333daa84 ! .hgtags Changeset: 5839fcca86a2 Author: sgehwolf Date: 2021-06-08 08:13 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/5839fcca86a2 8247469: getSystemCpuLoad() returns -1 on linux when some offline cpus are present and cpusets.effective_cpus is not available Reviewed-by: adinn, andrew ! make/mapfiles/libmanagement/mapfile-vers ! src/solaris/classes/sun/management/OperatingSystemImpl.java ! src/solaris/native/sun/management/LinuxOperatingSystem.c ! src/solaris/native/sun/management/OperatingSystemImpl.c Changeset: cc5ddc374b24 Author: sgehwolf Date: 2021-06-11 18:17 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cc5ddc374b24 8265836: OperatingSystemImpl.getCpuLoad() returns incorrect CPU load inside a container Reviewed-by: adinn, andrew ! make/mapfiles/libmanagement/mapfile-vers ! src/solaris/classes/sun/management/OperatingSystemImpl.java ! src/solaris/native/sun/management/LinuxOperatingSystem.c ! src/solaris/native/sun/management/OperatingSystemImpl.c Changeset: dfd02c3ca67c Author: andrew Date: 2021-08-09 03:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/dfd02c3ca67c Added tag jdk8u312-b02 for changeset cc5ddc374b24 ! .hgtags Changeset: 6a7aac7d660a Author: andrew Date: 2021-09-10 03:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6a7aac7d660a Merge jdk8u312-b02 ! .hgtags ! make/mapfiles/libmanagement/mapfile-vers Changeset: 7bb49d5b6613 Author: andrew Date: 2021-09-10 03:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7bb49d5b6613 Added tag aarch64-shenandoah-jdk8u312-b02 for changeset 6a7aac7d660a ! .hgtags Changeset: e80eda310088 Author: hshi Date: 2021-08-11 15:09 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e80eda310088 8264752: SIGFPE crash with option FlightRecorderOptions:threadbuffersize=30M 8266206: Build failure after JDK-8264752 with older GCCs Reviewed-by: phh ! test/jdk/jfr/startupargs/TestBadOptionValues.java ! test/jdk/jfr/startupargs/TestMemoryOptions.java Changeset: bb533a765f06 Author: mbalao Date: 2021-08-11 19:01 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/bb533a765f06 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup Reviewed-by: weijun ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/ReferralsCache.java ! test/sun/security/krb5/auto/ReferralsTest.java Changeset: 39b9c1c5f2eb Author: mdoerr Date: 2021-08-13 10:17 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/39b9c1c5f2eb 8254967: com.sun.net.HttpsServer spins on TLS session close Reviewed-by: dfuchs ! src/share/classes/sun/net/httpserver/SSLStreams.java Changeset: 61729ad5f50e Author: serb Date: 2020-11-11 01:31 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/61729ad5f50e 8237495: Java MIDI fails with a dereferenced memory error when asked to send a raw 0xF7 Reviewed-by: kizune ! src/share/native/com/sun/media/sound/MidiOutDevice.c + test/javax/sound/midi/SysexMessage/SendRawSysexMessage.java Changeset: 25905541d6f0 Author: andrew Date: 2021-08-16 06:12 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/25905541d6f0 Added tag jdk8u312-b03 for changeset 61729ad5f50e ! .hgtags Changeset: 62ab9659d631 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/62ab9659d631 Merge jdk8u312-b03 ! .hgtags ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java Changeset: a2a2797f1256 Author: andrew Date: 2021-09-13 10:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a2a2797f1256 Added tag aarch64-shenandoah-jdk8u312-b03 for changeset 62ab9659d631 ! .hgtags Changeset: b196b541720a Author: abakhtin Date: 2019-09-20 21:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b196b541720a 8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism Summary: 8268965: TCP Connection Reset when connecting simple socket to SSL server Reviewed-by: mdoerr ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/SSLSocketImpl/SSLSocketReset.java Changeset: e091a3b3405d Author: rpatil Date: 2016-09-01 10:35 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e091a3b3405d 8161016: Strange behavior of URLConnection with proxy Reviewed-by: shade, chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/HttpURLConnection/HttpURLConWithProxy.java Changeset: 35439fbe0cf7 Author: serb Date: 2020-11-09 06:35 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/35439fbe0cf7 6847157: java.lang.NullPointerException: HDC for component at sun.java2d.loops.Blit.Blit Reviewed-by: prr ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp + test/java/awt/Paint/RepaintOnAWTShutdown.java Changeset: 3f71306ef5b0 Author: andrew Date: 2021-08-18 05:50 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3f71306ef5b0 Merge Changeset: 281109452469 Author: jdowland Date: 2020-12-01 00:49 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/281109452469 8244154: Update SunPKCS11 provider with PKCS11 v3.0 header files Reviewed-by: andrew, mbalao ! THIRD_PARTY_README ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/native/sun/security/pkcs11/wrapper/pkcs11.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11f.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h Changeset: de1e02c701d7 Author: dfuchs Date: 2021-05-13 08:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/de1e02c701d7 8263382: java/util/logging/ParentLoggersTest.java failed with "checkLoggers: getLoggerNames() returned unexpected loggers" Reviewed-by: bpb, mchung ! test/java/util/logging/ParentLoggersTest.java Changeset: 40bb77912d3f Author: sgehwolf Date: 2021-06-15 08:45 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/40bb77912d3f 8268103: JNI functions incorrectly return a double after JDK-8265836 Reviewed-by: shade, andrew, phh ! src/solaris/native/sun/management/OperatingSystemImpl.c Changeset: 888e0e447ffd Author: andrew Date: 2021-08-23 14:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/888e0e447ffd Added tag jdk8u312-b04 for changeset 40bb77912d3f ! .hgtags Changeset: f9a188fef6bd Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f9a188fef6bd Merge jdk8u312-b04 ! .hgtags ! THIRD_PARTY_README ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: b56ec2175799 Author: andrew Date: 2021-09-22 13:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b56ec2175799 Added tag aarch64-shenandoah-jdk8u312-b04 for changeset f9a188fef6bd ! .hgtags Changeset: 9f9fdd94b94a Author: andrew Date: 2021-08-25 17:42 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/9f9fdd94b94a 8022323: [JavaSecurityScanner] review package com.sun.management.* Native methods should be private Summary: Create Java methods that call native ones Reviewed-by: sgehwolf ! make/mapfiles/libmanagement/mapfile-vers ! src/solaris/classes/sun/management/OperatingSystemImpl.java ! src/solaris/native/sun/management/LinuxOperatingSystem.c ! src/solaris/native/sun/management/MacosxOperatingSystem.c ! src/solaris/native/sun/management/OperatingSystemImpl.c ! src/solaris/native/sun/management/SolarisOperatingSystem.c ! src/windows/classes/sun/management/OperatingSystemImpl.java ! src/windows/native/sun/management/OperatingSystemImpl.c Changeset: e38bbfc4a6e0 Author: vkempik Date: 2020-09-10 13:14 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e38bbfc4a6e0 7188942: Remove support of pbuffers in OGL Java2d pipeline Reviewed-by: serb, andrew ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.h ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/opengl/OGLUtilities.java ! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java ! src/share/native/sun/java2d/opengl/OGLContext.h ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java ! src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/solaris/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java ! src/solaris/native/sun/java2d/opengl/GLXGraphicsConfig.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java ! src/windows/native/sun/java2d/opengl/WGLGraphicsConfig.c ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c + test/java/awt/image/VolatileImage/BitmaskVolatileImage.java Changeset: f6fe14d5daa9 Author: andrew Date: 2021-08-25 17:44 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f6fe14d5daa9 Merge Changeset: a66d9f5906c9 Author: sgehwolf Date: 2021-08-05 14:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a66d9f5906c9 8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage in containers Reviewed-by: andrew ! src/solaris/classes/sun/management/OperatingSystemImpl.java Changeset: 991bbb9501e2 Author: sgehwolf Date: 2021-08-26 17:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/991bbb9501e2 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon Reviewed-by: shade ! src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java Changeset: f9ea6cf9425f Author: andrew Date: 2021-08-31 17:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f9ea6cf9425f Added tag jdk8u312-b05 for changeset 991bbb9501e2 ! .hgtags Changeset: 8d77a3390834 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8d77a3390834 Merge jdk8u312-b05 ! .hgtags ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! make/mapfiles/libmanagement/mapfile-vers Changeset: cfb19b3c2111 Author: andrew Date: 2021-09-27 15:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cfb19b3c2111 Added tag aarch64-shenandoah-jdk8u312-b05 for changeset 8d77a3390834 ! .hgtags From shade at redhat.com Thu Oct 7 08:36:06 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Oct 2021 10:36:06 +0200 Subject: [URGENT] [8u] Re-cast MetadataOnStack patch to be Shenandoah-specific Message-ID: <6a663b0e-e87c-cc13-b59d-4d17aef65a6d@redhat.com> There is a hard requirement for 8u-aarch64 integration that any non-mainline patch in shared code was either trivial, or be obviously Shenandoah-specific. Unfortunately, at least one of the changes affects the shared path. With this patch, I demote it to Shenandoah-specific paths only. This blocks 8u integration. Note: a similar problem exists in jni.cpp, see: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/hotspot/src/share/vm/prims/jni.cpp.sdiff.html -- I'll take a stab at it, but Zhengyu, please take a look as well. That one is urgent as well. 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-metadata-on-stack/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Thu Oct 7 09:43:20 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Oct 2021 11:43:20 +0200 Subject: [URGENT] [8u] Re-cast JNI critical strings patch to be Shenandoah-specific Message-ID: <9845f112-4efe-9a8a-b9fe-ad26ec9656f5@redhat.com> There is a hard requirement for 8u-aarch64 integration that any non-mainline patch in shared code was either trivial, or be obviously Shenandoah-specific. Unfortunately, at least one of the changes affects the shared path. With this patch, I demote it to Shenandoah-specific paths only. This blocks 8u integration. 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-jni-critical-strings/webrev.01/ The resulting difference against 8u upstream would be: https://cr.openjdk.java.net/~shade/shenandoah/8u-jni-critical-strings/8u-upstream.diff Testing: hotspot_gc_shenandoah; minimal1 build (to test INCLUDE_ALL_GCS path) -- Thanks, -Aleksey From rkennke at redhat.com Thu Oct 7 10:27:35 2021 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Oct 2021 12:27:35 +0200 Subject: [URGENT] [8u] Re-cast JNI critical strings patch to be Shenandoah-specific In-Reply-To: <9845f112-4efe-9a8a-b9fe-ad26ec9656f5@redhat.com> References: <9845f112-4efe-9a8a-b9fe-ad26ec9656f5@redhat.com> Message-ID: <263fc674-54cd-92d2-e202-c56641011de1@redhat.com> Looks good to me. Roman > There is a hard requirement for 8u-aarch64 integration that any > non-mainline patch in shared code > was either trivial, or be obviously Shenandoah-specific. Unfortunately, > at least one of the changes > affects the shared path. With this patch, I demote it to > Shenandoah-specific paths only. > > This blocks 8u integration. > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-jni-critical-strings/webrev.01/ > > > The resulting difference against 8u upstream would be: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-jni-critical-strings/8u-upstream.diff > > > Testing: hotspot_gc_shenandoah; minimal1 build (to test INCLUDE_ALL_GCS > path) > From github.com+16811675+linade at openjdk.java.net Thu Oct 7 11:32:10 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Thu, 7 Oct 2021 11:32:10 GMT Subject: Integrated: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:23:48 GMT, Yude Lin wrote: > Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp This pull request has now been integrated. Changeset: 83198361 Author: Yude Lin Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/8319836152cbd0aa5bf6c93d3ba04733cacf83b4 Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy Reviewed-by: zgu, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5770 From zgu at redhat.com Thu Oct 7 12:16:01 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Oct 2021 08:16:01 -0400 Subject: [URGENT] [8u] Re-cast MetadataOnStack patch to be Shenandoah-specific In-Reply-To: <6a663b0e-e87c-cc13-b59d-4d17aef65a6d@redhat.com> References: <6a663b0e-e87c-cc13-b59d-4d17aef65a6d@redhat.com> Message-ID: <18b504f1-5d0b-d32d-af2a-bde3f40a33c8@redhat.com> Hi Aleksey, The nontrivial divergence was introduced by [1], intended to fix a hard to reproduce crash. Apparently, it does not work, I am more leaning toward backing it out if it is still an option. Thanks, -Zhengyu [1] http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b261d2db2ea2 On 10/7/21 04:36, Aleksey Shipilev wrote: > There is a hard requirement for 8u-aarch64 integration that any > non-mainline patch in shared code was either trivial, or be obviously > Shenandoah-specific. Unfortunately, at least one of the changes affects > the shared path. With this patch, I demote it to Shenandoah-specific > paths only. > > This blocks 8u integration. > > Note: a similar problem exists in jni.cpp, see: > https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/hotspot/src/share/vm/prims/jni.cpp.sdiff.html > -- I'll take a stab at it, but Zhengyu, please take a look as well. That > one is urgent as well. > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-metadata-on-stack/webrev.01/ > > > Testing: hotspot_gc_shenandoah > From zgu at redhat.com Thu Oct 7 12:16:09 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Oct 2021 08:16:09 -0400 Subject: [URGENT] [8u] Re-cast MetadataOnStack patch to be Shenandoah-specific In-Reply-To: <6a663b0e-e87c-cc13-b59d-4d17aef65a6d@redhat.com> References: <6a663b0e-e87c-cc13-b59d-4d17aef65a6d@redhat.com> Message-ID: Hi Aleksey, The nontrivial divergence was introduced by [1], intended to fix a hard to reproduce crash. Apparently, it does not work, I am more leaning toward backing it out if it is still an option. Thanks, -Zhengyu [1] http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b261d2db2ea2 On 10/7/21 04:36, Aleksey Shipilev wrote: > There is a hard requirement for 8u-aarch64 integration that any > non-mainline patch in shared code was either trivial, or be obviously > Shenandoah-specific. Unfortunately, at least one of the changes affects > the shared path. With this patch, I demote it to Shenandoah-specific > paths only. > > This blocks 8u integration. > > Note: a similar problem exists in jni.cpp, see: > https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/hotspot/src/share/vm/prims/jni.cpp.sdiff.html > -- I'll take a stab at it, but Zhengyu, please take a look as well. That > one is urgent as well. > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-metadata-on-stack/webrev.01/ > > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Thu Oct 7 12:17:31 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Oct 2021 14:17:31 +0200 Subject: [URGENT] [8u] Re-cast MetadataOnStack patch to be Shenandoah-specific In-Reply-To: References: <6a663b0e-e87c-cc13-b59d-4d17aef65a6d@redhat.com> Message-ID: <4a42ebb4-c88d-fe5b-fd76-d5059f64abe3@redhat.com> On 10/7/21 2:16 PM, Zhengyu Gu wrote: > The nontrivial divergence was introduced by [1], intended to fix a hard > to reproduce crash. Apparently, it does not work, I am more leaning > toward backing it out if it is still an option. OK, that's even better. I'll RFR the backout from 8u then. -- Thanks, -Aleksey From zgu at redhat.com Thu Oct 7 12:18:55 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Oct 2021 08:18:55 -0400 Subject: [URGENT] [8u] Re-cast JNI critical strings patch to be Shenandoah-specific In-Reply-To: <9845f112-4efe-9a8a-b9fe-ad26ec9656f5@redhat.com> References: <9845f112-4efe-9a8a-b9fe-ad26ec9656f5@redhat.com> Message-ID: <28a2c53d-c0ef-b102-e66c-5613cbfb706f@redhat.com> Looks good. Thanks, -Zhengyu On 10/7/21 05:43, Aleksey Shipilev wrote: > There is a hard requirement for 8u-aarch64 integration that any > non-mainline patch in shared code > was either trivial, or be obviously Shenandoah-specific. Unfortunately, > at least one of the changes > affects the shared path. With this patch, I demote it to > Shenandoah-specific paths only. > > This blocks 8u integration. > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-jni-critical-strings/webrev.01/ > > > The resulting difference against 8u upstream would be: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-jni-critical-strings/8u-upstream.diff > > > Testing: hotspot_gc_shenandoah; minimal1 build (to test INCLUDE_ALL_GCS > path) > From shade at redhat.com Thu Oct 7 12:22:50 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Oct 2021 14:22:50 +0200 Subject: [URGENT] [8u] Backout "MetadataOnStackMark::record() is not MT-safe" Message-ID: <77dedf62-8d28-1446-3d17-a573eadb9a0a@redhat.com> There is a hard requirement for 8u-aarch64 integration that any non-mainline patch in shared code was either trivial, or be obviously Shenandoah-specific. This patch was the attempt to fix the bug, and it still does not work. Therefore we are better to backout it completely. This blocks 8u integration. 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-backout-metadata/webrev.01/ This is a clean backout of: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b261d2db2ea2 Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Thu Oct 7 12:25:10 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Oct 2021 08:25:10 -0400 Subject: [URGENT] [8u] Backout "MetadataOnStackMark::record() is not MT-safe" In-Reply-To: <77dedf62-8d28-1446-3d17-a573eadb9a0a@redhat.com> References: <77dedf62-8d28-1446-3d17-a573eadb9a0a@redhat.com> Message-ID: <02fd77c2-1e91-7e63-41b1-aa166b9c136a@redhat.com> Looks good. Thanks, -Zhengyu On 10/7/21 08:22, Aleksey Shipilev wrote: > There is a hard requirement for 8u-aarch64 integration that any > non-mainline patch in shared code > was either trivial, or be obviously Shenandoah-specific. This patch was > the attempt to fix the bug, and it still does not work. Therefore we are > better to backout it completely. > > This blocks 8u integration. > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-backout-metadata/webrev.01/ > > > This is a clean backout of: > ? https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b261d2db2ea2 > > Testing: hotspot_gc_shenandoah > From coleenp at openjdk.java.net Thu Oct 7 12:29:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 12:29:10 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. test/hotspot/gtest/runtime/test_mutex.cpp line 290: > 288: ThreadInVMfromNative invm(THREAD); > 289: > 290: Monitor* monitor_rank_broken = new Monitor(Mutex::oopstorage-4, "monitor_rank_broken"); @dholmes-ora This test checks for overlapping safepoint ranges. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Thu Oct 7 12:38:09 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 12:38:09 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <4dtM1iipmdLApuuovC-NqC6ejIpsqdn3r69uRdr6POY=.49a782a0-3c52-45dc-9710-55c09dc2bb58@github.com> On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. test/hotspot/gtest/runtime/test_mutex.cpp line 327: > 325: // If the lock above succeeds, try to safepoint to test the NSV implied with this nosafepoint lock. > 326: ThreadBlockInVM tbivm(thread); > 327: thread->print_thread_state_on(tty); I moved the three tests from test_safepoint.cpp here. The third test in that file was checking the specification of _safepoint_check_always/never matched the rank, which is now obsolete. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From shade at redhat.com Thu Oct 7 12:45:26 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Oct 2021 14:45:26 +0200 Subject: [URGENT] [8u] Re-cast JNI critical strings patch to be Shenandoah-specific In-Reply-To: <28a2c53d-c0ef-b102-e66c-5613cbfb706f@redhat.com> References: <9845f112-4efe-9a8a-b9fe-ad26ec9656f5@redhat.com> <28a2c53d-c0ef-b102-e66c-5613cbfb706f@redhat.com> Message-ID: <3690a08f-08df-c972-0d22-412878e18135@redhat.com> On 10/7/21 2:18 PM, Zhengyu Gu wrote: > Looks good. Thank you, pushed. -- -Aleksey From shade at redhat.com Thu Oct 7 12:45:37 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Oct 2021 14:45:37 +0200 Subject: [URGENT] [8u] Backout "MetadataOnStackMark::record() is not MT-safe" In-Reply-To: <02fd77c2-1e91-7e63-41b1-aa166b9c136a@redhat.com> References: <77dedf62-8d28-1446-3d17-a573eadb9a0a@redhat.com> <02fd77c2-1e91-7e63-41b1-aa166b9c136a@redhat.com> Message-ID: <0a4fde79-aaeb-89d2-b666-44560a043084@redhat.com> On 10/7/21 2:25 PM, Zhengyu Gu wrote: > Looks good. Thanks you, pushed. -- -Aleksey From shade at redhat.com Thu Oct 7 12:45:15 2021 From: shade at redhat.com (shade at redhat.com) Date: Thu, 07 Oct 2021 12:45:15 +0000 Subject: hg: shenandoah/jdk8/hotspot: 2 new changesets Message-ID: <202110071245.197CjFIL016180@aojmv0008.oracle.com> Changeset: 2851e9c8e567 Author: shade Date: 2021-10-07 14:44 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2851e9c8e567 Backout "MetadataOnStackMark::record() is not MT-safe" Reviewed-by: zgu ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 17d6c475d565 Author: shade Date: 2021-10-07 14:44 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/17d6c475d565 Re-cast JNI critical strings patch to be Shenandoah-specific Reviewed-by: zgu, rkennke ! src/share/vm/prims/jni.cpp From coleenp at openjdk.java.net Thu Oct 7 15:28:31 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 15:28:31 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix overlap error message printing and add a test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5845/files - new: https://git.openjdk.java.net/jdk/pull/5845/files/3c6a5b6c..59bfd945 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=00-01 Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5845/head:pull/5845 PR: https://git.openjdk.java.net/jdk/pull/5845 From wkemper at openjdk.java.net Thu Oct 7 15:46:03 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 15:46:03 GMT Subject: RFR: Add an option to stream region sampling data to a file Message-ID: This change adds two command line options to enable and configure a feature that has Shenandoah stream region sampling data to disk. These changes are complemented by changes in the [Shenandoah Visualizer](https://github.com/openjdk/shenandoah-visualizer) project to load and replay the logged region sampling data. ------------- Commit messages: - Whitespace fixes - Add a test that configured region sampling log file is created - Fixed Shenandoah log file path handling and file overwriting - Fixed copyrights and added default value to ShenandoahRegionSamplingFile option - Changed ShenandoahLogFileOutput to independent class and added copyrights - Added Shenandoah logging flags and Shenandoah log file formatting - Added logSnapshotsFile option in shenandoah_globals.hpp Changes: https://git.openjdk.java.net/shenandoah/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=82&range=00 Stats: 414 lines in 8 files changed: 394 ins; 15 del; 5 mod Patch: https://git.openjdk.java.net/shenandoah/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/82/head:pull/82 PR: https://git.openjdk.java.net/shenandoah/pull/82 From pchilanomate at openjdk.java.net Thu Oct 7 16:02:08 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 7 Oct 2021 16:02:08 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote: >> Also fixes: 8273956: Add checking for rank values >> >> This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. >> >> Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. >> >> This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. >> >> Tested with tier1-8 at one point in time and just retested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix overlap error message printing and add a test. LGTM! Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Thu Oct 7 16:10:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 7 Oct 2021 16:10:08 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:59:42 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix overlap error message printing and add a test. > > LGTM! > > Thanks, > Patricio Thanks for the review @pchilano and offline discussion about check_for_overlap. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From rkennke at openjdk.java.net Thu Oct 7 16:17:38 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Oct 2021 16:17:38 GMT Subject: RFR: Add an option to stream region sampling data to a file In-Reply-To: References: Message-ID: <3fEif0a7KMavqaIXPPeEIVbPirrWIkcko4DJQPrm6LQ=.6ef2c008-70b9-4d24-8a1c-09a087928913@github.com> On Thu, 7 Oct 2021 15:34:08 GMT, William Kemper wrote: > This change adds two command line options to enable and configure a feature that has Shenandoah stream region sampling data to disk. These changes are complemented by changes in the [Shenandoah Visualizer](https://github.com/openjdk/shenandoah-visualizer) project to load and replay the logged region sampling data. Looks ok, I only have some minor nits. src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 92: > 90: jlong last = _last_sample_millis; > 91: if (current - last > ShenandoahRegionSamplingRate && > 92: Atomic::cmpxchg(&_last_sample_millis, last, current) == last) { Neither the previous nor the new version seems to align correctly. src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp line 104: > 102: > 103: #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGIONCOUNTERS_HPP > 104: Bunch of unrelated new newlines. src/hotspot/share/gc/shenandoah/shenandoahLogFileOutput.cpp line 3: > 1: /* > 2: * Copyright (c) 2021, Amazon.com, Inc. All rights reserved. > 3: * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. Is this a copy of or derived from an existing source file? If not, only putting the 2021 header should be enough. src/hotspot/share/gc/shenandoah/shenandoahLogFileOutput.hpp line 2: > 1: /* > 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. Is this a new file? Then the 2021-Amazon header should be enough. If it's derived from an existing file, then the header is ok as it is. ------------- Marked as reviewed by rkennke (Lead). PR: https://git.openjdk.java.net/shenandoah/pull/82 From wkemper at openjdk.java.net Thu Oct 7 17:11:17 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 17:11:17 GMT Subject: RFR: Add an option to stream region sampling data to a file [v2] In-Reply-To: References: Message-ID: > This change adds two command line options to enable and configure a feature that has Shenandoah stream region sampling data to disk. These changes are complemented by changes in the [Shenandoah Visualizer](https://github.com/openjdk/shenandoah-visualizer) project to load and replay the logged region sampling data. William Kemper has updated the pull request incrementally with two additional commits since the last revision: - Whitespace fixes - Update copyright headers ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/82/files - new: https://git.openjdk.java.net/shenandoah/pull/82/files/6cedcbc4..e93d18d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=82&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=82&range=00-01 Stats: 11 lines in 4 files changed: 2 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/shenandoah/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/82/head:pull/82 PR: https://git.openjdk.java.net/shenandoah/pull/82 From wkemper at openjdk.java.net Thu Oct 7 17:11:19 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 17:11:19 GMT Subject: RFR: Add an option to stream region sampling data to a file [v2] In-Reply-To: <3fEif0a7KMavqaIXPPeEIVbPirrWIkcko4DJQPrm6LQ=.6ef2c008-70b9-4d24-8a1c-09a087928913@github.com> References: <3fEif0a7KMavqaIXPPeEIVbPirrWIkcko4DJQPrm6LQ=.6ef2c008-70b9-4d24-8a1c-09a087928913@github.com> Message-ID: On Thu, 7 Oct 2021 16:10:41 GMT, Roman Kennke wrote: >> William Kemper has updated the pull request incrementally with two additional commits since the last revision: >> >> - Whitespace fixes >> - Update copyright headers > > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 92: > >> 90: jlong last = _last_sample_millis; >> 91: if (current - last > ShenandoahRegionSamplingRate && >> 92: Atomic::cmpxchg(&_last_sample_millis, last, current) == last) { > > Neither the previous nor the new version seems to align correctly. Fixed > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp line 104: > >> 102: >> 103: #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGIONCOUNTERS_HPP >> 104: > > Bunch of unrelated new newlines. Deleted extra lines > src/hotspot/share/gc/shenandoah/shenandoahLogFileOutput.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. > > Is this a new file? Then the 2021-Amazon header should be enough. If it's derived from an existing file, then the header is ok as it is. Both these files were derived from `logFileOutput`, which has an Oracle copyright. I've updated the copyright headers. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/82 From wkemper at openjdk.java.net Thu Oct 7 17:39:45 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 17:39:45 GMT Subject: RFR: Inline usage of pointer_delta Message-ID: Card table sometimes erroneously triggers assert added in JDK-8260046. ------------- Commit messages: - Inline usage of pointer_delta Changes: https://git.openjdk.java.net/shenandoah/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=83&range=00 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/shenandoah/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/83/head:pull/83 PR: https://git.openjdk.java.net/shenandoah/pull/83 From rkennke at openjdk.java.net Thu Oct 7 17:49:39 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Oct 2021 17:49:39 GMT Subject: RFR: Inline usage of pointer_delta In-Reply-To: References: Message-ID: <-jDJh_7uzAbc-7HyBhBbI-F1wnOH6VUyI9BMa9YFPk8=.c07c6f7c-f293-4fbf-b0a0-a1affb27b86b@github.com> On Thu, 7 Oct 2021 17:35:13 GMT, William Kemper wrote: > Card table sometimes erroneously triggers assert added in JDK-8260046. I don't quite understand. Can p become legally < then _byte_map_base? ------------- PR: https://git.openjdk.java.net/shenandoah/pull/83 From wkemper at openjdk.java.net Thu Oct 7 18:28:35 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 18:28:35 GMT Subject: RFR: Inline usage of pointer_delta In-Reply-To: References: Message-ID: <8SBQlYjM5z91-QV9X3tylS6LOUPaUSGevjPuC_hhADc=.69414b8a-30c4-4c02-adaa-4feb2e1008b9@github.com> On Thu, 7 Oct 2021 17:35:13 GMT, William Kemper wrote: > Card table sometimes erroneously triggers assert added in JDK-8260046. The issue happens when card table computes `_byte_map_base` as `_byte_map - (uintptr_t(whole_heap.start()) >> card_shift)`. There's nothing to prevent the kernel from putting `_byte_map` before `whole_heap.start()`, in which case `_byte_map_base` underflows and triggers the assert in `pointer_delta` later on when computing the heap address for a card. Kelvin and I worked through the math and convinced ourselves it was safe in this case: `low_bound` here is `whole_heap.start()`. 1. By precomputing `_byte_map_base`, we avoid the need to subtract an offset every time we look up a card-table index. 2. The "unoptimized" card-table lookup would look like `byte_map[(addr - low_bound) >> _card_shift]` 3. Which by distributive property is the same as `byte_map[addr >> _card_shift - low_bound >> _card_shift]` 4. Which is `*(_byte_map + addr >> _card_shift - low_bound >> _card_shift)` 5. Which is `*((_byte_map - low_bound >> _card_shift) + addr >> _card_shift)` 6. Which is `*(_byte_map_base + addr >> _card_shift)` where `_byte_map_base = _byte_map - low_bound >> _card_shift` 7. Which is `byte_map_base[addr >> _card_shift]` I'd expect this to also affect Parallel and Serial gc, but it does not happen often (and it does not cause problems for release builds). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/83 From rkennke at openjdk.java.net Thu Oct 7 18:44:35 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 7 Oct 2021 18:44:35 GMT Subject: RFR: Inline usage of pointer_delta In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 17:35:13 GMT, William Kemper wrote: > Card table sometimes erroneously triggers assert added in JDK-8260046. Ok then! Thank you! ------------- Marked as reviewed by rkennke (Lead). PR: https://git.openjdk.java.net/shenandoah/pull/83 From wkemper at openjdk.java.net Thu Oct 7 21:18:30 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 21:18:30 GMT Subject: Integrated: Add an option to stream region sampling data to a file In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 15:34:08 GMT, William Kemper wrote: > This change adds two command line options to enable and configure a feature that has Shenandoah stream region sampling data to disk. These changes are complemented by changes in the [Shenandoah Visualizer](https://github.com/openjdk/shenandoah-visualizer) project to load and replay the logged region sampling data. This pull request has now been integrated. Changeset: d59d18ef Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/d59d18efd0f5ecb2790c59793afb878383ca61e2 Stats: 420 lines in 8 files changed: 395 ins; 20 del; 5 mod Add an option to stream region sampling data to a file Co-authored-by: Christian Young Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/shenandoah/pull/82 From wkemper at openjdk.java.net Thu Oct 7 21:19:26 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 7 Oct 2021 21:19:26 GMT Subject: Integrated: Inline usage of pointer_delta In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 17:35:13 GMT, William Kemper wrote: > Card table sometimes erroneously triggers assert added in JDK-8260046. This pull request has now been integrated. Changeset: 7765c144 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/7765c14461f3343c067a2de805a55d83d4b63835 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Inline usage of pointer_delta Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/shenandoah/pull/83 From dholmes at openjdk.java.net Fri Oct 8 00:56:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 8 Oct 2021 00:56:18 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote: >> Also fixes: 8273956: Add checking for rank values >> >> This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. >> >> Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. >> >> This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. >> >> Tested with tier1-8 at one point in time and just retested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix overlap error message printing and add a test. Hi Coleen, A couple of comments on tests, but otherwise okay. Thanks, David test/hotspot/gtest/runtime/test_mutex.cpp line 292: > 290: Monitor* monitor_rank_broken = new Monitor(Mutex::oopstorage-4, "monitor_rank_broken"); > 291: monitor_rank_broken->lock_without_safepoint_check(); > 292: monitor_rank_broken->unlock(); This is dead code right - the assertion failure will stop us getting here. test/hotspot/gtest/runtime/test_mutex.cpp line 302: > 300: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-40, "monitor_rank_broken"); > 301: monitor_rank_broken->lock_without_safepoint_check(); > 302: monitor_rank_broken->unlock(); Ditto - dead code test/hotspot/gtest/runtime/test_mutex.cpp line 310: > 308: ThreadInVMfromNative invm(THREAD); > 309: > 310: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-1, "monitor_rank_broken"); This rank is not actually broken is it - otherwise we won't get to the next line. test/hotspot/gtest/runtime/test_mutex.cpp line 313: > 311: Monitor* monitor_rank_also_broken = new Monitor(monitor_rank_broken->rank()-39, "monitor_rank_also_broken"); > 312: monitor_rank_also_broken->lock_without_safepoint_check(); > 313: monitor_rank_also_broken->unlock(); Dead code ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5845 From shade at redhat.com Fri Oct 8 06:55:08 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Oct 2021 08:55:08 +0200 Subject: RFR/RFC: Shenandoah 8u integration 2021-10-07 Message-ID: <511ac2ce-a3a5-2f15-f9ac-65403defeb0a@redhat.com> Hi, I would like to integrate the regular update of Shenandoah 8u to our integration repository, aarch64-port/jdk8u-shenandoah. It comes with a single bugfix. Webrev: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20211007/webrev.01/ The change in jni.cpp actually reverts some of the Shenandoah-specific code to be exactly Shenandoah-specific. The difference against upstream becomes: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20211007/jni.cpp-upstream.diff I am tagging all repos with aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07. Testing: hotspot_gc_shenandoah; I see no build/test failures in builds.shipilev.net CI -- Thanks, -Aleksey From coleenp at openjdk.java.net Fri Oct 8 12:26:46 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:46 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: On Thu, 7 Oct 2021 15:28:31 GMT, Coleen Phillimore wrote: >> Also fixes: 8273956: Add checking for rank values >> >> This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. >> >> Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. >> >> This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. >> >> Tested with tier1-8 at one point in time and just retested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix overlap error message printing and add a test. I removed the dead test code and retested. Thanks for the code review David, and all the discussions leading to this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Fri Oct 8 12:26:42 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:42 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v3] In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <_j_8HU0x6wY_wdykmr-yK3m3Vh9xe_8EBHAndUvqaTI=.6868eeb9-8087-45bd-8aea-06ed9cda720f@github.com> > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove dead code in test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5845/files - new: https://git.openjdk.java.net/jdk/pull/5845/files/59bfd945..e8df15de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5845&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5845/head:pull/5845 PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Fri Oct 8 12:26:55 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:55 GMT Subject: RFR: 8274004: Change 'nonleaf' rank name [v2] In-Reply-To: References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <6D3k_Hszkk1_wh4hVsg_SN-KjzC-qtLzz7y7KY8oy_c=.7c9d92e6-0564-45b5-84fa-d3750f218626@github.com> On Fri, 8 Oct 2021 00:48:05 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix overlap error message printing and add a test. > > test/hotspot/gtest/runtime/test_mutex.cpp line 292: > >> 290: Monitor* monitor_rank_broken = new Monitor(Mutex::oopstorage-4, "monitor_rank_broken"); >> 291: monitor_rank_broken->lock_without_safepoint_check(); >> 292: monitor_rank_broken->unlock(); > > This is dead code right - the assertion failure will stop us getting here. Yes, it is dead code. I'll remove it and retest to make sure nothing surprising happens. > test/hotspot/gtest/runtime/test_mutex.cpp line 302: > >> 300: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-40, "monitor_rank_broken"); >> 301: monitor_rank_broken->lock_without_safepoint_check(); >> 302: monitor_rank_broken->unlock(); > > Ditto - dead code removed. > test/hotspot/gtest/runtime/test_mutex.cpp line 310: > >> 308: ThreadInVMfromNative invm(THREAD); >> 309: >> 310: Monitor* monitor_rank_broken = new Monitor(Mutex::safepoint-1, "monitor_rank_broken"); > > This rank is not actually broken is it - otherwise we won't get to the next line. right. It's not broken. I'll rename it to 'monitor_rank_ok'. > test/hotspot/gtest/runtime/test_mutex.cpp line 313: > >> 311: Monitor* monitor_rank_also_broken = new Monitor(monitor_rank_broken->rank()-39, "monitor_rank_also_broken"); >> 312: monitor_rank_also_broken->lock_without_safepoint_check(); >> 313: monitor_rank_also_broken->unlock(); > > Dead code removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From coleenp at openjdk.java.net Fri Oct 8 12:26:57 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 8 Oct 2021 12:26:57 GMT Subject: Integrated: 8274004: Change 'nonleaf' rank name In-Reply-To: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> References: <6s02U-nIpDg-XFfG32B8-dHSZqzY79fHVLrOM_OLBkY=.94efe120-31fb-41c6-a9a9-05cb233414b6@github.com> Message-ID: <0lCdhQcwqr2iY7jits8rmozKtqgOpJ1f4NAWCRoWQIc=.8d3c7b24-6629-4743-bd4c-537198df641d@github.com> On Wed, 6 Oct 2021 23:27:17 GMT, Coleen Phillimore wrote: > Also fixes: 8273956: Add checking for rank values > > This change does 3 things. I could separate them but this has all been tested together and most of the change is mechanical. The first is a simple rename of nonleaf => safepoint. The second change is to add the enum class Rank which only allows subtraction from a base rank, and some additional type checking so that rank arithmetic doesn't overlap with a different rank. Ie if you say nosafepoint-n, that doesn't overlap with oopstorage. The third change is to remove the _safepoint_check_always/never flag. That is now intrinsic in the ranking, as all nosafepoint ranks are lower than all safepoint ranks. > > Future changes could add rank names in the middle of nosafepoint and safepoint, like handshake. As of now, the rank subtractions are not unmanageable. There are actually not many nested Mutex. > > This is the last of the planned subtasks for Mutex ranking cleanup. If you have other ideas or suggestions, please let me know. > > Tested with tier1-8 at one point in time and just retested with tier1-6. This pull request has now been integrated. Changeset: 6364719c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/6364719cd1c57220769ea580d958da8dc2fdf7f9 Stats: 452 lines in 41 files changed: 105 ins; 117 del; 230 mod 8274004: Change 'nonleaf' rank name 8273956: Add checking for rank values Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/5845 From zgu at openjdk.java.net Fri Oct 8 13:49:18 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 8 Oct 2021 13:49:18 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check Message-ID: JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/5865/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5865&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274925 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5865/head:pull/5865 PR: https://git.openjdk.java.net/jdk/pull/5865 From gnu.andrew at redhat.com Fri Oct 8 15:59:45 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 8 Oct 2021 16:59:45 +0100 Subject: RFR/RFC: Shenandoah 8u integration 2021-10-07 In-Reply-To: <511ac2ce-a3a5-2f15-f9ac-65403defeb0a@redhat.com> References: <511ac2ce-a3a5-2f15-f9ac-65403defeb0a@redhat.com> Message-ID: On 08:55 Fri 08 Oct , Aleksey Shipilev wrote: > Hi, > > I would like to integrate the regular update of Shenandoah 8u to our integration repository, > aarch64-port/jdk8u-shenandoah. It comes with a single bugfix. > > Webrev: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20211007/webrev.01/ > > The change in jni.cpp actually reverts some of the Shenandoah-specific code to be exactly > Shenandoah-specific. The difference against upstream becomes: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20211007/jni.cpp-upstream.diff > > I am tagging all repos with aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07. > > Testing: hotspot_gc_shenandoah; I see no build/test failures in builds.shipilev.net CI > > > -- > Thanks, > -Aleksey > Looks good to me. I was expecting a lot more changes, so happy to see it's a relatively small update. 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 zgu at openjdk.java.net Fri Oct 8 16:55:26 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 8 Oct 2021 16:55:26 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests Message-ID: I were able to reproduce with aggressive heuristics. While a _wb_breakpoint GC request , at the moment a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. The solution is only run breakpoints during _wb_breakpoint GC. Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. Test: - [x] tier1 with Shenandoah ------------- Commit messages: - Order requested gc cause and gc requested flag - Merge branch 'master' into JDK-8273614-conbkptr-timeout - v1 - Merge branch 'master' into JDK-8273614-conbkptr-timeout - Merge branch 'master' into JDK-8273614-conbkptr-timeout - use wait - Merge branch 'master' into JDK-8273614-conbkptr-timeout - Merge branch 'master' into TestJNIWeak-timeout - v0 Changes: https://git.openjdk.java.net/jdk/pull/5868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273614 Stats: 29 lines in 2 files changed: 16 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5868/head:pull/5868 PR: https://git.openjdk.java.net/jdk/pull/5868 From shade at redhat.com Mon Oct 11 06:02:54 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Oct 2021 08:02:54 +0200 Subject: RFR/RFC: Shenandoah 8u integration 2021-10-07 In-Reply-To: References: <511ac2ce-a3a5-2f15-f9ac-65403defeb0a@redhat.com> Message-ID: <00d3b9dc-50e0-560e-fa3c-6974dbd56f42@redhat.com> On 10/8/21 5:59 PM, Andrew Hughes wrote: > Looks good to me. I was expecting a lot more changes, so happy to see it's a relatively > small update. Thank you, pushed. -- -Aleksey From maoliang.ml at alibaba-inc.com Mon Oct 11 08:13:54 2021 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Mon, 11 Oct 2021 16:13:54 +0800 Subject: =?UTF-8?B?UXVlc3Rpb24gYWJvdXQgZ2VuLXNoZW4=?= Message-ID: <872b4421-10f0-4b07-bccf-07f42c117e78.maoliang.ml@alibaba-inc.com> Dear Shenandoah Developers, I see that gen-shen project is in a pretty good shape now and I wonder if I can make an early try. But looks like the young GC heuristics only has a time(interval) based GC triggering. Is my understanding correct? Could we use -Xmn recently? Thanks, Liang ------------------------------------------------------------------ From:Aleksey Shipilev Send Time:2021 Oct. 11 (Mon.) 14:03 To:Andrew Hughes Cc:aarch64-port-dev at openjdk.java.net ; shenandoah-dev at openjdk.java.net Subject:Re: RFR/RFC: Shenandoah 8u integration 2021-10-07 On 10/8/21 5:59 PM, Andrew Hughes wrote: > Looks good to me. I was expecting a lot more changes, so happy to see it's a relatively > small update. Thank you, pushed. -- -Aleksey From shade at openjdk.java.net Mon Oct 11 10:47:23 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 10:47:23 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 16:47:07 GMT, Zhengyu Gu wrote: > I were able to reproduce with aggressive heuristics. > > A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. > > The solution is only run breakpoints during _wb_breakpoint GC. > > Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. > > Test: > > - [x] tier1 with Shenandoah Looks good with minor nits. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 54: > 52: class ShenandoahBreakpointGCScope : public StackObj { > 53: private: > 54: GCCause::Cause _cause; Better be `const`? src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 72: > 70: class ShenandoahBreakpointMarkScope : public StackObj { > 71: private: > 72: GCCause::Cause _cause; Also `const`? src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 509: > 507: while (current_gc_id < required_gc_id) { > 508: _requested_gc_cause = cause; > 509: _gc_requested.set(); Ah. This whole thing is under _gc_waiters_lock. But there is a raw read of `_requested_gc_cause` and `_gc_requested` in `ShenandoahControlThread::run_service`. Pity. Could you please fork it out as separate (more backportable) bug? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5868 From shade at openjdk.java.net Mon Oct 11 10:49:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 10:49:10 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu wrote: > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah Hold on a sec, I have questions... I see `MultiArray_lock` is `safepoint`. Shouldn't this be `safepoint - 1` then? I think this would basically say "you can acquire any `safepoint` lock", right? Also, does the same thing apply to `_gc_waiters_lock`? Changing both locks to `safepoint - 1` passes `hotspot_gc_shenandoah` for me here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From zgu at openjdk.java.net Mon Oct 11 12:23:11 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 12:23:11 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 10:46:09 GMT, Aleksey Shipilev wrote: > Hold on a sec, I have questions... > > I see `MultiArray_lock` is `safepoint`. Shouldn't this be `safepoint - 1` then? You see any difference with safepoint-1 and safepoint-2? I do agree probably should be safepoint-1 because https://github.com/openjdk/jdk/pull/5869 did that. I think this would basically say "you can acquire any `safepoint` lock", right? Also, does the same thing apply to `_gc_waiters_lock`? > I thought about that. It appears that _gc_waiters_lock is only acquired vs. SH::collect(), where I don't see it is possible holding MultiArray_lock. > Changing both locks to `safepoint - 1` passes `hotspot_gc_shenandoah` for me here. I will make change on _alloc_failure_waiters_lock rank, but not sure we really need to change _gc_waiters_lock, what your opinion? ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From pliden at openjdk.java.net Mon Oct 11 12:33:42 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 11 Oct 2021 12:33:42 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure Message-ID: I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: * Rename AbstractGangTask to WorkerTask * Rename WorkGang to WorkerThreads * Fold GangWorker into WorkerThread * Fold WorkManager into WorkerThreads * Move SubTaskDone and friends to a new workerUtils.hpp/cpp I've split things up into several commits to make it easier to review. Testing: Passes Tier 1-3 on all Oracle platforms. ------------- Commit messages: - Clean up naming in ReferenceProcessor - Clean up naming in Shenandoah - Clean up naming in HeapDumper/HeapInspector - Clean up naming in G1 - Clean up naming in pretouch - Clean up naming in WeakProcessor - Clean up naming in ZGC - Remove unused log tag - Rename workgroup.hpp/cpp to workerThread.hpp/cpp - Clean up worker code - ... and 10 more: https://git.openjdk.java.net/jdk/compare/c032186b...39b23f42 Changes: https://git.openjdk.java.net/jdk/pull/5886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5886&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275035 Stats: 2415 lines in 105 files changed: 881 ins; 1083 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/5886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5886/head:pull/5886 PR: https://git.openjdk.java.net/jdk/pull/5886 From zgu at openjdk.java.net Mon Oct 11 12:42:33 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 12:42:33 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests [v2] In-Reply-To: References: Message-ID: > I were able to reproduce with aggressive heuristics. > > A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. > > The solution is only run breakpoints during _wb_breakpoint GC. > > Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. > > Test: > > - [x] tier1 with Shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5868/files - new: https://git.openjdk.java.net/jdk/pull/5868/files/175811c7..e34cd1bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5868&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5868&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5868/head:pull/5868 PR: https://git.openjdk.java.net/jdk/pull/5868 From stefank at openjdk.java.net Mon Oct 11 12:46:09 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 11 Oct 2021 12:46:09 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Looks good ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5886 From shade at openjdk.java.net Mon Oct 11 13:11:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:11:10 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:42:33 GMT, Zhengyu Gu wrote: >> I were able to reproduce with aggressive heuristics. >> >> A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. >> >> The solution is only run breakpoints during _wb_breakpoint GC. >> >> Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. >> >> Test: >> >> - [x] tier1 with Shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Aleksey's comment Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5868 From shade at openjdk.java.net Mon Oct 11 13:28:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:28:09 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu wrote: > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah > I do agree probably should be safepoint-1 because #5869 did that. Yes, I think Shenandoah never takes `JNICritical_lock`, so it is fine to have `safepoint - 1` here. > I thought about that. It appears that _gc_waiters_lock is only acquired vs. SH::collect(), where I don't see it is possible holding MultiArray_lock. I think it is technically possible to call `SH::collect()` from the Java code that holds the `MultiArray_lock`, as part of OOM allocation? I think it would be future-proof to accept all `safepoint`-rank locks in `ShenandoahControlThread`, i.e. make all of them `safepoint - 1`. You probably want to run `tier1`, `tier2` with `TEST_VM_OPTS=-XX:+UseShenandoahGC` to confirm. ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From zgu at openjdk.java.net Mon Oct 11 13:38:32 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 13:38:32 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check [v2] In-Reply-To: References: Message-ID: <0GZrEu1lHjo6kpJqn13T1YMpNkNErNjFY4eJ8qkkAcc=.a8afbde1-8a24-4812-99c2-afb924b4201d@github.com> > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5865/files - new: https://git.openjdk.java.net/jdk/pull/5865/files/bad7be7c..c224b441 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5865&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5865&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5865/head:pull/5865 PR: https://git.openjdk.java.net/jdk/pull/5865 From shade at openjdk.java.net Mon Oct 11 13:43:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:43:09 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check [v2] In-Reply-To: <0GZrEu1lHjo6kpJqn13T1YMpNkNErNjFY4eJ8qkkAcc=.a8afbde1-8a24-4812-99c2-afb924b4201d@github.com> References: <0GZrEu1lHjo6kpJqn13T1YMpNkNErNjFY4eJ8qkkAcc=.a8afbde1-8a24-4812-99c2-afb924b4201d@github.com> Message-ID: On Mon, 11 Oct 2021 13:38:32 GMT, Zhengyu Gu wrote: >> JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. >> >> This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. >> >> >> Test: >> >> - [x] hotspot_gc_shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Aleksey's comment Looks good, provided the tests pass. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5865 From zgu at openjdk.java.net Mon Oct 11 15:14:17 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 15:14:17 GMT Subject: Integrated: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 16:47:07 GMT, Zhengyu Gu wrote: > I were able to reproduce with aggressive heuristics. > > A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. > > The solution is only run breakpoints during _wb_breakpoint GC. > > Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. > > Test: > > - [x] tier1 with Shenandoah This pull request has now been integrated. Changeset: 3f073377 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/3f07337722a0c8c6b452a44745598268d67c0864 Stats: 27 lines in 1 file changed: 15 ins; 3 del; 9 mod 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5868 From zgu at openjdk.java.net Mon Oct 11 17:02:23 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 17:02:23 GMT Subject: Integrated: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: <6_QTyEr66ayhWg3BJhNCVcVP5iCl-roChJiNGlRUs_A=.3c364b78-f29d-476e-a467-c0a394c60222@github.com> On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu wrote: > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 75f5145e Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/75f5145e21a1320c1a08080af861497ce7c3f266 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From zgu at openjdk.java.net Mon Oct 11 18:13:34 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 18:13:34 GMT Subject: RFR: 8275051: Shenandoah: Enforce ordering of requested gc cause and gc request flag Message-ID: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> Although setting gc request is under _gc_waiters_lock, but read side (run_service()) does not take the lock. We need to enforce following ordering, so that read side sees latest requested gc cause when the flag is set. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Merge branch 'master' into JDK-8275051-gc_req_order - v0 Changes: https://git.openjdk.java.net/jdk/pull/5898/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5898&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275051 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5898.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5898/head:pull/5898 PR: https://git.openjdk.java.net/jdk/pull/5898 From wkemper at openjdk.java.net Mon Oct 11 19:02:06 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 11 Oct 2021 19:02:06 GMT Subject: RFR: Remove vestigial command line options and removed unused code Message-ID: <57JOB5MyAHPC8qoAGKjqJ_fotgsCRlA8nKt8HaoTRHY=.af32fad9-b274-421e-b4a2-6ac120397800@github.com> * Removed ShenandoahUseSimpleCardScanning and ShenandoahPromoteTenuredRegions command line options * Removed preprocessor directives FAST_REMEMBERED_SET_SCANNING and CROSSING_OFFSETS_NO_LONGER_NEEDED ------------- Commit messages: - Remove vestigial command line options and ifdef'd code sections Changes: https://git.openjdk.java.net/shenandoah/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=85&range=00 Stats: 169 lines in 4 files changed: 0 ins; 165 del; 4 mod Patch: https://git.openjdk.java.net/shenandoah/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/85/head:pull/85 PR: https://git.openjdk.java.net/shenandoah/pull/85 From wkemper at openjdk.java.net Mon Oct 11 19:02:12 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 11 Oct 2021 19:02:12 GMT Subject: RFR: Update heap usage tallies for generations after full GC compaction Message-ID: Two changes here: * Verification checks heap usage for _each_ generation every time (rather than only check the _active_ generation). * Compute heap usage after post compaction phase of full gc (rather than pre-compaction phase). ------------- Commit messages: - Simplify live usage accounting for generations during full gc - Verify usage tallies for all generations during verification Changes: https://git.openjdk.java.net/shenandoah/pull/84/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=84&range=00 Stats: 149 lines in 2 files changed: 57 ins; 83 del; 9 mod Patch: https://git.openjdk.java.net/shenandoah/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/84/head:pull/84 PR: https://git.openjdk.java.net/shenandoah/pull/84 From wkemper at openjdk.java.net Mon Oct 11 22:02:23 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 11 Oct 2021 22:02:23 GMT Subject: RFR: Register filler objects when non-lab allocations are backed out Message-ID: This is fallout from a recent change to have non-lab allocations stop registering objects. The code path for failed evacuations was not updated to register the filler objects created when the non-lab evacuation fails. ------------- Commit messages: - Register filler objects when non-lab allocations are backed out Changes: https://git.openjdk.java.net/shenandoah/pull/86/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=86&range=00 Stats: 15 lines in 1 file changed: 6 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/shenandoah/pull/86.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/86/head:pull/86 PR: https://git.openjdk.java.net/shenandoah/pull/86 From kdnilsen at openjdk.java.net Mon Oct 11 22:29:14 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Mon, 11 Oct 2021 22:29:14 GMT Subject: RFR: Register filler objects when non-lab allocations are backed out In-Reply-To: References: Message-ID: <_jgAD9lF0Hz63m576Op2daZQMVGhjbbG5AmK2OuZdaM=.9a6a7ef7-4116-40d6-b873-349f5f41987e@github.com> On Mon, 11 Oct 2021 21:56:52 GMT, William Kemper wrote: > This is fallout from a recent change to have non-lab allocations stop registering objects. The code path for failed evacuations was not updated to register the filler objects created when the non-lab evacuation fails. Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/86 From wkemper at openjdk.java.net Mon Oct 11 22:34:15 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 11 Oct 2021 22:34:15 GMT Subject: Integrated: Register filler objects when non-lab allocations are backed out In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 21:56:52 GMT, William Kemper wrote: > This is fallout from a recent change to have non-lab allocations stop registering objects. The code path for failed evacuations was not updated to register the filler objects created when the non-lab evacuation fails. This pull request has now been integrated. Changeset: fb788c84 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/fb788c84ca55d3ddce0af21109cff6f08931e1dd Stats: 15 lines in 1 file changed: 6 ins; 3 del; 6 mod Register filler objects when non-lab allocations are backed out Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/86 From dholmes at openjdk.java.net Tue Oct 12 02:12:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 12 Oct 2021 02:12:48 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Changes to non GC files look fine. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From shade at openjdk.java.net Tue Oct 12 05:59:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 05:59:00 GMT Subject: RFR: 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag In-Reply-To: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> References: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> Message-ID: On Mon, 11 Oct 2021 18:07:01 GMT, Zhengyu Gu wrote: > Although setting gc request is under _gc_waiters_lock, but read side (run_service()) does not take the lock. We need to enforce following ordering, so that read side sees latest requested gc cause when the flag is set. > > Test: > - [x] hotspot_gc_shenandoah Looks good! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5898 From zgu at openjdk.java.net Tue Oct 12 12:01:52 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 12 Oct 2021 12:01:52 GMT Subject: Integrated: 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag In-Reply-To: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> References: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> Message-ID: On Mon, 11 Oct 2021 18:07:01 GMT, Zhengyu Gu wrote: > Although setting gc request is under _gc_waiters_lock, but read side (run_service()) does not take the lock. We need to enforce following ordering, so that read side sees latest requested gc cause when the flag is set. > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 1ab64143 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/1ab64143c06e33e23172dd77c39e434443347364 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5898 From rkennke at openjdk.java.net Tue Oct 12 12:16:14 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 12 Oct 2021 12:16:14 GMT Subject: RFR: Update heap usage tallies for generations after full GC compaction In-Reply-To: References: Message-ID: <0B2E1tEF5UWN-C4EyBlihtgbzuFNA5sDWwXY15dQzx4=.662a9da5-1bdc-4407-9338-86a8b1fba333@github.com> On Mon, 11 Oct 2021 18:37:00 GMT, William Kemper wrote: > Two changes here: > * Verification checks heap usage for _each_ generation every time (rather than only check the _active_ generation). > * Compute heap usage after post compaction phase of full gc (rather than pre-compaction phase). Looks good to me! Thanks! ------------- Marked as reviewed by rkennke (Lead). PR: https://git.openjdk.java.net/shenandoah/pull/84 From rkennke at openjdk.java.net Tue Oct 12 12:18:20 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 12 Oct 2021 12:18:20 GMT Subject: RFR: Remove vestigial command line options and removed unused code In-Reply-To: <57JOB5MyAHPC8qoAGKjqJ_fotgsCRlA8nKt8HaoTRHY=.af32fad9-b274-421e-b4a2-6ac120397800@github.com> References: <57JOB5MyAHPC8qoAGKjqJ_fotgsCRlA8nKt8HaoTRHY=.af32fad9-b274-421e-b4a2-6ac120397800@github.com> Message-ID: On Mon, 11 Oct 2021 18:40:00 GMT, William Kemper wrote: > * Removed ShenandoahUseSimpleCardScanning and ShenandoahPromoteTenuredRegions command line options > * Removed preprocessor directives FAST_REMEMBERED_SET_SCANNING and CROSSING_OFFSETS_NO_LONGER_NEEDED Looks good to me, with one very minor nit (and really your choice). src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 541: > 539: ShenandoahCardCluster(RememberedSet *rs) { > 540: _rs = rs; > 541: // HEY! We don't really need object_starts entries for every card entry. We only need these for Consider changing 'HEY!' to 'TODO' or something. IDEs tend to highlight the latter (mine does). ------------- Marked as reviewed by rkennke (Lead). PR: https://git.openjdk.java.net/shenandoah/pull/85 From jborgers at jpinpoint.com Tue Oct 12 14:00:37 2021 From: jborgers at jpinpoint.com (Jeroen Borgers) Date: Tue, 12 Oct 2021 16:00:37 +0200 Subject: Long pacing time seems to result in long response times Message-ID: Hi, In a load test on a JSF application we encountered long response times up to 4 minutes instead of a few seconds, during a 20 min part of the test, while putting constant load on it. Pacing times seem large to me and I want to find out if this is causing the bad response times. The CPU usage on the host follows that of the jboss process which lowers from 45% to 12% in that period. So it seems that the app is slowed down for about 20 minutes; 5 minutes the slowest and then slowly recovering. There is a degenerate gc for 1.4 s., triggered by a TLAB allocation failure, followed by 10 s. pacing (212 ms avg non-zero). Then pacing of 28 ms. followed by 28 s.(!) pacing (900 ms avg non-zero). *1 Is this normal pacing behavior? Configuration: x86-64b, 6 cores, VMWare, RHEL 7.9, OpenJDK 11.0.12, jboss 7.3.3. jvm settings: -XX:+UseShenandoahGC -XX:+AlwaysPreTouch -XX:+UseNUMA -XX:-UseBiasedLocking -XX:+UseTransparentHugePages -Xlog:gc*:file=...log/gc-%t-%p.log:tags,uptime,time,level:filecount=5,filesize=3m -Xlog:safepoint*:file=...log/safepoints-%t-%p.log:tags,uptime,time,level:filecount=5,filesize=3m In our profiling tool it seems e.g. 88% of a long user tx (4 min) is spent in locking. *2. Is that how pacing shows? We will try out -XX:ShenandoahPacingMaxDelay=10 in a new test with also a bigger heap (12->16GB). *3 Would that solve the issue? *4 Would it help to provide gc logging here for better understanding what happens? Kind regards, Jeroen Borgers drs. Jeroen Borgers Principal Consultant jPinpoint Performance Services, jpinpoint com, The Netherlands. e-mail: jborgers at jpinpoint com From wkemper at openjdk.java.net Tue Oct 12 16:02:24 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 12 Oct 2021 16:02:24 GMT Subject: RFR: Remove vestigial command line options and removed unused code In-Reply-To: References: <57JOB5MyAHPC8qoAGKjqJ_fotgsCRlA8nKt8HaoTRHY=.af32fad9-b274-421e-b4a2-6ac120397800@github.com> Message-ID: On Tue, 12 Oct 2021 12:14:44 GMT, Roman Kennke wrote: >> * Removed ShenandoahUseSimpleCardScanning and ShenandoahPromoteTenuredRegions command line options >> * Removed preprocessor directives FAST_REMEMBERED_SET_SCANNING and CROSSING_OFFSETS_NO_LONGER_NEEDED > > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 541: > >> 539: ShenandoahCardCluster(RememberedSet *rs) { >> 540: _rs = rs; >> 541: // HEY! We don't really need object_starts entries for every card entry. We only need these for > > Consider changing 'HEY!' to 'TODO' or something. IDEs tend to highlight the latter (mine does). I'll replace these en masse with another pull request. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/85 From wkemper at openjdk.java.net Tue Oct 12 16:06:16 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 12 Oct 2021 16:06:16 GMT Subject: Integrated: Update heap usage tallies for generations after full GC compaction In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 18:37:00 GMT, William Kemper wrote: > Two changes here: > * Verification checks heap usage for _each_ generation every time (rather than only check the _active_ generation). > * Compute heap usage after post compaction phase of full gc (rather than pre-compaction phase). This pull request has now been integrated. Changeset: deb452d7 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/deb452d749339f21ecef18988bbb68b51def2fb2 Stats: 149 lines in 2 files changed: 57 ins; 83 del; 9 mod Update heap usage tallies for generations after full GC compaction Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/shenandoah/pull/84 From wkemper at openjdk.java.net Tue Oct 12 16:07:31 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 12 Oct 2021 16:07:31 GMT Subject: Integrated: Remove vestigial command line options and removed unused code In-Reply-To: <57JOB5MyAHPC8qoAGKjqJ_fotgsCRlA8nKt8HaoTRHY=.af32fad9-b274-421e-b4a2-6ac120397800@github.com> References: <57JOB5MyAHPC8qoAGKjqJ_fotgsCRlA8nKt8HaoTRHY=.af32fad9-b274-421e-b4a2-6ac120397800@github.com> Message-ID: On Mon, 11 Oct 2021 18:40:00 GMT, William Kemper wrote: > * Removed ShenandoahUseSimpleCardScanning and ShenandoahPromoteTenuredRegions command line options > * Removed preprocessor directives FAST_REMEMBERED_SET_SCANNING and CROSSING_OFFSETS_NO_LONGER_NEEDED This pull request has now been integrated. Changeset: 5ccbfbc3 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/5ccbfbc3f77bc6b81d5a5cf9edd65c78a52e603b Stats: 169 lines in 4 files changed: 0 ins; 165 del; 4 mod Remove vestigial command line options and removed unused code Reviewed-by: rkennke ------------- PR: https://git.openjdk.java.net/shenandoah/pull/85 From wkemper at openjdk.java.net Tue Oct 12 16:53:29 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 12 Oct 2021 16:53:29 GMT Subject: RFR: Replace 'HEY!' comments with TODO and remove unnecessary usages Message-ID: <8um2teLTecHdEYT5BbKzTrYQPpCNl6g94M9Lo-AeLoM=.47a0f380-6533-4048-b685-d4c3286ad472@github.com> Replace idiosyncratic `HEY!` comments with `TODO` and remove it from places where it is no longer necessary. No code changes here, just changes in comments. ------------- Commit messages: - Replace 'HEY!' comments with TODO and remove unnecessary usages Changes: https://git.openjdk.java.net/shenandoah/pull/87/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=87&range=00 Stats: 14 lines in 6 files changed: 0 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/shenandoah/pull/87.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/87/head:pull/87 PR: https://git.openjdk.java.net/shenandoah/pull/87 From kdnilsen at openjdk.java.net Tue Oct 12 21:34:38 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 12 Oct 2021 21:34:38 GMT Subject: RFR: Preempt old preparation Message-ID: Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. ------------- Commit messages: - Cleanup white space - Undo gratuitous cosmetic changes - Remove instrumentation - Fix syntax errors from merge - Merge branch 'shenandoah' of ssh://git.amazon.com/pkg/OpenJDKTipSrc into preempt-old-preparation - Undef instrumentation - Fix up resumption of mixed-evac preparation - Make coalesce-and-fill effort preemptible Changes: https://git.openjdk.java.net/shenandoah/pull/88/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=88&range=00 Stats: 203 lines in 13 files changed: 128 ins; 11 del; 64 mod Patch: https://git.openjdk.java.net/shenandoah/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/88/head:pull/88 PR: https://git.openjdk.java.net/shenandoah/pull/88 From wkemper at openjdk.java.net Tue Oct 12 21:51:13 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 12 Oct 2021 21:51:13 GMT Subject: RFR: Preempt old preparation In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 21:15:01 GMT, Kelvin Nilsen wrote: > Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. Changes requested by wkemper (Committer). src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 75: > 73: }; > 74: > 75: class ShenandoahGlobalCoalesceAndFill : public ShenandoahHeapRegionClosure { Not sure how this ended up `shenandoahConcurrentGC.cpp`, last I checked it was defined in `shenandoahHeap.cpp`. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 177: > 175: // Any OLD region allocated during concurrent coalesce-and-fill does not need to be coalesced and filled. > 176: // This code is only necessary if req.affiliation() is old, but harmless if not. > 177: r->finish_coalesce_and_fill(); Not sure I understand why that's the case. This region could still contain garbage objects that could break the remembered set scan. How does allocating out of the region make these objects parseable? src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 467: > 465: obj_addr = next_marked_obj; > 466: } > 467: if (!ops_before_preempt_check--) { I think the `C++` way is to compare against 0, not coerce to bool. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/88 From kdnilsen at openjdk.java.net Tue Oct 12 23:10:15 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 12 Oct 2021 23:10:15 GMT Subject: RFR: Preempt old preparation In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 21:37:18 GMT, William Kemper wrote: >> Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 75: > >> 73: }; >> 74: >> 75: class ShenandoahGlobalCoalesceAndFill : public ShenandoahHeapRegionClosure { > > Not sure how this ended up `shenandoahConcurrentGC.cpp`, last I checked it was defined in `shenandoahHeap.cpp`. Not sure either. It is in both places in my branch. I see no reason for it to be here so am removing it. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/88 From kdnilsen at openjdk.java.net Tue Oct 12 23:21:37 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 12 Oct 2021 23:21:37 GMT Subject: RFR: Preempt old preparation [v2] In-Reply-To: References: Message-ID: > Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Respond to reviewer feedback ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/88/files - new: https://git.openjdk.java.net/shenandoah/pull/88/files/bdc5f8b9..280a6215 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=88&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=88&range=00-01 Stats: 22 lines in 3 files changed: 4 ins; 15 del; 3 mod Patch: https://git.openjdk.java.net/shenandoah/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/88/head:pull/88 PR: https://git.openjdk.java.net/shenandoah/pull/88 From kdnilsen at openjdk.java.net Tue Oct 12 23:21:40 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 12 Oct 2021 23:21:40 GMT Subject: RFR: Preempt old preparation [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 21:40:06 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to reviewer feedback > > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 177: > >> 175: // Any OLD region allocated during concurrent coalesce-and-fill does not need to be coalesced and filled. >> 176: // This code is only necessary if req.affiliation() is old, but harmless if not. >> 177: r->finish_coalesce_and_fill(); > > Not sure I understand why that's the case. This region could still contain garbage objects that could break the remembered set scan. How does allocating out of the region make these objects parseable? I've augmented this comment in an attempt to make the rationale more clear. > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 467: > >> 465: obj_addr = next_marked_obj; >> 466: } >> 467: if (!ops_before_preempt_check--) { > > I think the `C++` way is to compare against 0, not coerce to bool. Thanks. I've changed the condition. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/88 From kdnilsen at openjdk.java.net Tue Oct 12 23:28:46 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 12 Oct 2021 23:28:46 GMT Subject: RFR: Preempt old preparation [v3] In-Reply-To: References: Message-ID: > Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix bad comment ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/88/files - new: https://git.openjdk.java.net/shenandoah/pull/88/files/280a6215..de7fc92f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=88&range=02 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=88&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/shenandoah/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/88/head:pull/88 PR: https://git.openjdk.java.net/shenandoah/pull/88 From ayang at openjdk.java.net Wed Oct 13 14:57:52 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 13 Oct 2021 14:57:52 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: <0_2hNibwTQ_O4ogxshpot8dy46d3J9NkHQ2CCP4TMIo=.3f95825d-1aa9-44e6-b068-50c7515102a9@github.com> On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From zgu at openjdk.java.net Wed Oct 13 15:40:21 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Oct 2021 15:40:21 GMT Subject: RFR: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges Message-ID: I believe for the cases that there is no plain read of atomic variables, we can relax memory ordering constraints for claiming tasks/ranges by workers. Test: - [x] hotspot_gc_shenandoah (fastdebug + release) on x86_64 and aarch64 Linux ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/5929/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5929&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275226 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5929.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5929/head:pull/5929 PR: https://git.openjdk.java.net/jdk/pull/5929 From gnu.andrew at redhat.com Wed Oct 13 16:10:17 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Oct 2021 17:10:17 +0100 Subject: How To Solve a Problem Like Shenandoah 8u Message-ID: Hi all, For those who are unaware, there is now a proposal to migrate OpenJDK 8u first to a mono repository, and then to git+Skara: https://bugs.openjdk.java.net/browse/SKARA-1214 We thus need to decide what to do with the 8u+Shenandoah forks. We could just apply the Shenandoah changes as one large patch to the new monorepo, which would then be migrated to git. Or we could try and involve Oracle to migrate the existing repo. I think the first option is the most straight-forward, but it would mean the history would only then exist in the retired Mercurial forest. Thoughts? -- 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 Wed Oct 13 18:27:26 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Wed, 13 Oct 2021 18:27:26 GMT Subject: RFR: Preempt old preparation [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 23:28:46 GMT, Kelvin Nilsen wrote: >> Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Fix bad comment Marked as reviewed by wkemper (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/88 From kdnilsen at openjdk.java.net Wed Oct 13 19:06:26 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Wed, 13 Oct 2021 19:06:26 GMT Subject: Integrated: Preempt old preparation In-Reply-To: References: Message-ID: <7DNIXbOegWltJkx7Fh74FHF4Ce6F2mMTu5ORs2Nfcfc=.c94e09d1-2361-46a3-9a5f-38c187f1c18d@github.com> On Tue, 12 Oct 2021 21:15:01 GMT, Kelvin Nilsen wrote: > Previously, all old-gen regions not selected as collection set candidates were "made parseable" during the final-mark safepoint. Making each of these regions parseable involves coalescing consecutive unmarked objects into contiguous larger objects that contain no pointers. The process of identifying each span of consecutive unmarked objects within a large number of large heap regions was found to require hundreds of ms in some cases. This patch changes the behavior so that preparation of heap regions for subsequent evacuation is performed during a concurrent phase of operation. This concurrent phase must complete before any of the old heap regions placed in the candidate collection set can be evacuated. This pull request has now been integrated. Changeset: aa775e99 Author: Kelvin Nilsen URL: https://git.openjdk.java.net/shenandoah/commit/aa775e9971207c4325ef447767940dcdfc11e135 Stats: 192 lines in 12 files changed: 117 ins; 11 del; 64 mod Preempt old preparation Reviewed-by: wkemper ------------- PR: https://git.openjdk.java.net/shenandoah/pull/88 From rkennke at redhat.com Wed Oct 13 19:54:21 2021 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Oct 2021 21:54:21 +0200 Subject: How To Solve a Problem Like Shenandoah 8u In-Reply-To: References: Message-ID: <3a951ce6-274f-7e8b-9783-0c419051371f@redhat.com> Hi Andrew, > For those who are unaware, there is now a proposal to migrate > OpenJDK 8u first to a mono repository, and then to git+Skara: > > https://bugs.openjdk.java.net/browse/SKARA-1214 > > We thus need to decide what to do with the 8u+Shenandoah forks. > > We could just apply the Shenandoah changes as one large patch > to the new monorepo, which would then be migrated to git. > > Or we could try and involve Oracle to migrate the existing > repo. > > I think the first option is the most straight-forward, but > it would mean the history would only then exist in the > retired Mercurial forest. > > Thoughts? I have no problem with the history remaining in a retired Mercurial forest only. The advantage of retaining all history would be the ability to bisect, but this seems very rarely/never needed in 8u backports repo. Others who do more frequent backports than me (Aleksey maybe?) might have more insights.? Roman From duke at openjdk.java.net Wed Oct 13 23:21:50 2021 From: duke at openjdk.java.net (duke) Date: Wed, 13 Oct 2021 23:21:50 GMT Subject: Withdrawn: 8270554: Shenandoah: Optimize heap scan loop In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 14:37:26 GMT, Roman Kennke wrote: > This is a fall-out from Lilliput. I noticed that in the heap scan loop, we load the size of objects in the size-based object scanner, even though all of the object closures already load the size, or at least in some cases, the Klass* which is necessary to determine the size. We can optimize that by making the scan loop co-operate with the closures. In other words, this changes the loop to avoid double-loading the Klass* in most cases in the size-based part of the scan loop. > > Note: the motivation in Lilliput is not performance, but correctness, because there loading the Klass* means loading the header, and this needs to be done carefully because of concurrent evacuation and concurrent locking code both messing with the header, and thus depends a lot on the actual closures to do it correctly. > > Implementation notes: > - SH::evacuate_object() has been changed so that it can return both the forwardee and the size. I opted to return the size as return-value because otherwise I'd have to null check an incoming pointer in the cases when we're not interested in the size. The way it is done, it can simply be ignored (and optimized-out) by the compiler. > - I added a do_object_size() variant to all affected iterators. I tried to do it with templates, but could not figure out how to please the compiler. > - While I was at it, I marked all do_object() methods as 'inline'. > - I ran some benchmarks. I think I see consistent but small improvements in evac and update-refs times, but it's not large enough to say that it is a definite improvement. > > Testing: > - [x] hotspot_gc_shenandoah > - [x] tier1 (+UseShenandoahGC) > - [x] specjvm testing This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4797 From shade at redhat.com Thu Oct 14 08:29:03 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Oct 2021 10:29:03 +0200 Subject: How To Solve a Problem Like Shenandoah 8u In-Reply-To: <3a951ce6-274f-7e8b-9783-0c419051371f@redhat.com> References: <3a951ce6-274f-7e8b-9783-0c419051371f@redhat.com> Message-ID: <7ef2da88-b46f-5462-785f-0a89d08f252d@redhat.com> On 10/13/21 9:54 PM, Roman Kennke wrote: > Others who do more frequent backports than me (Aleksey maybe?) might > have more insights.? Our backport tracking machinery parses the changesets in that HG repo. That's the only option for tracking, because 8u Shenandoah backports are not tracked in JBS. I suspect it would be fine to keep the read-only snapshot of old Mercurial repo, so that backports-monitor can still read it. FWIW, we did the similar history-losing-squash commit when moving sh/jdk9 -> sh/jdk10 for the monorepo migration, and that was not very painful. -- Thanks, -Aleksey From shade at openjdk.java.net Thu Oct 14 08:34:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Oct 2021 08:34:52 GMT Subject: RFR: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges In-Reply-To: References: Message-ID: <2KXtqgqHRH8hpgNUw3Z-iQa8_Wt9k_IdOh8eoWoyFa0=.4ab69119-d9fb-4d0e-8fa8-2ad8a146259c@github.com> On Wed, 13 Oct 2021 15:33:23 GMT, Zhengyu Gu wrote: > I believe for the cases that there is no plain read on atomic variables, we can relax memory ordering constraints for claiming tasks/ranges by workers. > > Test: > - [x] hotspot_gc_shenandoah (fastdebug + release) on x86_64 and aarch64 Linux Yes, all these look like plain atomic-counter CASes. Nothing seems to depend on their memory semantics. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5929 From pliden at openjdk.java.net Thu Oct 14 09:03:18 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 14 Oct 2021 09:03:18 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure [v2] In-Reply-To: References: Message-ID: <-Syf1OT7GZmoQxHt8U4f-A5sEDEy4Yppqwqfj4B1FXo=.bbb9637d-bc9f-4e35-a1a5-0c94a90d825f@github.com> > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. Per Liden has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge master - Clean up naming in ReferenceProcessor - Clean up naming in Shenandoah - Clean up naming in HeapDumper/HeapInspector - Clean up naming in G1 - Clean up naming in pretouch - Clean up naming in WeakProcessor - Clean up naming in ZGC - Remove unused log tag - Rename workgroup.hpp/cpp to workerThread.hpp/cpp - ... and 11 more: https://git.openjdk.java.net/jdk/compare/8b1b6f9f...9a89f785 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5886&range=01 Stats: 2415 lines in 105 files changed: 881 ins; 1083 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/5886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5886/head:pull/5886 PR: https://git.openjdk.java.net/jdk/pull/5886 From zgu at openjdk.java.net Thu Oct 14 12:56:51 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 14 Oct 2021 12:56:51 GMT Subject: Integrated: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 15:33:23 GMT, Zhengyu Gu wrote: > I believe for the cases that there is no plain read on atomic variables, we can relax memory ordering constraints for claiming tasks/ranges by workers. > > Test: > - [x] hotspot_gc_shenandoah (fastdebug + release) on x86_64 and aarch64 Linux This pull request has now been integrated. Changeset: 3b0b6adc Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/3b0b6adc3d547fcf4b971536d2404c342d18046f Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5929 From pliden at openjdk.java.net Thu Oct 14 14:08:56 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 14 Oct 2021 14:08:56 GMT Subject: RFR: 8275035: Clean up worker thread infrastructure [v2] In-Reply-To: <-Syf1OT7GZmoQxHt8U4f-A5sEDEy4Yppqwqfj4B1FXo=.bbb9637d-bc9f-4e35-a1a5-0c94a90d825f@github.com> References: <-Syf1OT7GZmoQxHt8U4f-A5sEDEy4Yppqwqfj4B1FXo=.bbb9637d-bc9f-4e35-a1a5-0c94a90d825f@github.com> Message-ID: On Thu, 14 Oct 2021 09:03:18 GMT, Per Liden wrote: >> I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: >> >> * Rename AbstractGangTask to WorkerTask >> * Rename WorkGang to WorkerThreads >> * Fold GangWorker into WorkerThread >> * Fold WorkManager into WorkerThreads >> * Move SubTaskDone and friends to a new workerUtils.hpp/cpp >> >> I've split things up into several commits to make it easier to review. >> >> Testing: Passes Tier 1-3 on all Oracle platforms. > > Per Liden has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge master > - Clean up naming in ReferenceProcessor > - Clean up naming in Shenandoah > - Clean up naming in HeapDumper/HeapInspector > - Clean up naming in G1 > - Clean up naming in pretouch > - Clean up naming in WeakProcessor > - Clean up naming in ZGC > - Remove unused log tag > - Rename workgroup.hpp/cpp to workerThread.hpp/cpp > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/8b1b6f9f...9a89f785 Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From pliden at openjdk.java.net Thu Oct 14 14:08:57 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 14 Oct 2021 14:08:57 GMT Subject: Integrated: 8275035: Clean up worker thread infrastructure In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote: > I propose that we clean up our GangWorker/WorkGang and related classes, to remove abstractions we no longer need (after CMS was removed, MutexDispatcher was removed, Parallel is now using WorkGang, etc) and adjusting names as follows: > > * Rename AbstractGangTask to WorkerTask > * Rename WorkGang to WorkerThreads > * Fold GangWorker into WorkerThread > * Fold WorkManager into WorkerThreads > * Move SubTaskDone and friends to a new workerUtils.hpp/cpp > > I've split things up into several commits to make it easier to review. > > Testing: Passes Tier 1-3 on all Oracle platforms. This pull request has now been integrated. Changeset: 54b88707 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/54b887076612c0eaa410a849178f8ba0c4ed3eeb Stats: 2415 lines in 105 files changed: 881 ins; 1083 del; 451 mod 8275035: Clean up worker thread infrastructure Reviewed-by: stefank, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5886 From wkemper at openjdk.java.net Thu Oct 14 20:31:30 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 14 Oct 2021 20:31:30 GMT Subject: RFR: Do not coalesce dead objects in global cycle if GC was cancelled Message-ID: Attempting to coalesce and fill with an incomplete mark context triggers an assert in debug builds (and may cause problems for a release build). ------------- Commit messages: - Do not coalesce dead objects in global cycle if GC was cancelled Changes: https://git.openjdk.java.net/shenandoah/pull/89/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=89&range=00 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/shenandoah/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/89/head:pull/89 PR: https://git.openjdk.java.net/shenandoah/pull/89 From kdnilsen at openjdk.java.net Thu Oct 14 22:16:25 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Oct 2021 22:16:25 GMT Subject: RFR: Do not coalesce dead objects in global cycle if GC was cancelled In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 20:25:38 GMT, William Kemper wrote: > Attempting to coalesce and fill with an incomplete mark context triggers an assert in debug builds (and may cause problems for a release build). Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/89 From wkemper at openjdk.java.net Thu Oct 14 22:32:27 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 14 Oct 2021 22:32:27 GMT Subject: Integrated: Do not coalesce dead objects in global cycle if GC was cancelled In-Reply-To: References: Message-ID: <_bposTQkX1__4KcZpBBDq1LkikItP14naf7ok1WLG3Y=.d7c751e7-d9f2-47b3-80d9-f8e448a4d796@github.com> On Thu, 14 Oct 2021 20:25:38 GMT, William Kemper wrote: > Attempting to coalesce and fill with an incomplete mark context triggers an assert in debug builds (and may cause problems for a release build). This pull request has now been integrated. Changeset: 6d8ebd70 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/6d8ebd70eaa24127b33787a9ba48b95e56246061 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Do not coalesce dead objects in global cycle if GC was cancelled Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/89 From wkemper at openjdk.java.net Thu Oct 14 22:32:37 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 14 Oct 2021 22:32:37 GMT Subject: RFR: Reset coalesce and fill boundary during global collect Message-ID: Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. ------------- Commit messages: - Reset coalesce and fill boundary during global collect Changes: https://git.openjdk.java.net/shenandoah/pull/90/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=90&range=00 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/shenandoah/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/90/head:pull/90 PR: https://git.openjdk.java.net/shenandoah/pull/90 From kdnilsen at openjdk.java.net Thu Oct 14 22:47:10 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Oct 2021 22:47:10 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. I'm actually not sure this is the right way to fix this. The implementation of ShenandoahHeapRegion::oop_fill_and_coalesce() does not re-register surviving objects. It only registers the result of coalescing previously independent objects. If we feel a need for this fix, maybe the bug is in the implementation of heap->card_scan()->coalesce_objects(). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From kdnilsen at openjdk.java.net Thu Oct 14 22:50:13 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Oct 2021 22:50:13 GMT Subject: RFR: Replace 'HEY!' comments with TODO and remove unnecessary usages In-Reply-To: <8um2teLTecHdEYT5BbKzTrYQPpCNl6g94M9Lo-AeLoM=.47a0f380-6533-4048-b685-d4c3286ad472@github.com> References: <8um2teLTecHdEYT5BbKzTrYQPpCNl6g94M9Lo-AeLoM=.47a0f380-6533-4048-b685-d4c3286ad472@github.com> Message-ID: On Tue, 12 Oct 2021 16:48:55 GMT, William Kemper wrote: > Replace idiosyncratic `HEY!` comments with `TODO` and remove it from places where it is no longer necessary. No code changes here, just changes in comments. Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/87 From wkemper at openjdk.java.net Thu Oct 14 22:59:23 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 14 Oct 2021 22:59:23 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. We don't need it to re-register live objects, we need it to fill in the dead objects. The sequence of events looks like this: 1. FREE region services an allocation request and calls `finish_coalesce_and_fill` (this sets fill boundary to `_end`). 2. Global collection happens, dead objects in old regions outside of cset are coalesced. Coalescing begins from the coalesce boundary and walks objects until `_end`. But for regions in the state from step 1, coalescing does _nothing_ (`heap->card_scan()->coalesce_objects()` isn't even called). 3. Young generation remembered set scan attempts to iterate dead objects that should have been filled in step 2 and goes off the rails. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From wkemper at openjdk.java.net Thu Oct 14 23:02:09 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 14 Oct 2021 23:02:09 GMT Subject: Integrated: Replace 'HEY!' comments with TODO and remove unnecessary usages In-Reply-To: <8um2teLTecHdEYT5BbKzTrYQPpCNl6g94M9Lo-AeLoM=.47a0f380-6533-4048-b685-d4c3286ad472@github.com> References: <8um2teLTecHdEYT5BbKzTrYQPpCNl6g94M9Lo-AeLoM=.47a0f380-6533-4048-b685-d4c3286ad472@github.com> Message-ID: On Tue, 12 Oct 2021 16:48:55 GMT, William Kemper wrote: > Replace idiosyncratic `HEY!` comments with `TODO` and remove it from places where it is no longer necessary. No code changes here, just changes in comments. This pull request has now been integrated. Changeset: 8caba428 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/8caba42835369dc25105850f7022497c7ec0bf41 Stats: 14 lines in 6 files changed: 0 ins; 4 del; 10 mod Replace 'HEY!' comments with TODO and remove unnecessary usages Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/87 From kdnilsen at openjdk.java.net Thu Oct 14 23:09:21 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Oct 2021 23:09:21 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. My concern is that if we insert code to reset_coalesce_and_fill_boundary() for the entire region before we invoke region->oop_fill_and_coalesce(), then we would need region->oop_fill_and_coalesce() to reregister all the live objects (because we just zapped all of their registrations). Maybe the "problem" is that we are failing to reset_coalesce_and_fill_boundary() when we begin a stop-the-world or GLOBAL collection. This would cause the regions outside the cset to not be coalesced and filled. Oh, that's exactly what you were doing. So sorry. I misunderstood which API you were invoking. Probably means I chose bad names for these services. :( ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From kdnilsen at openjdk.java.net Thu Oct 14 23:18:11 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Oct 2021 23:18:11 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. I'm still not sure this is the right place to invoke reset_coalesce_and_fill_boundary(). To support preemption of concurrent coalesce-and-fill, we reset_coalesce_and_fill_boundary() once for each region that needs to be coalesced and filled. Then we begin the preemptible coalesce and fill effort. If we preempt in the middle of processing a given region, we will come back to this region where coalesce-and-fill efforts left off, as preserved by the call to suspend_coalesce_and_fill(). Since concurrent GC also invokes this same heap_region_do() service, I believe the change you propose would make us go back to the start of each region and reprocess it multiple times each time we resume coalesce and fill following a preemption. I think what we want here is to iterate through all relevant regions and reset_coalesce_and_fill_boundary() before a STW GC calls ShenandoahHeap::coalesce_and_fill_old_regions(). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From kdnilsen at openjdk.java.net Thu Oct 14 23:21:17 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 14 Oct 2021 23:21:17 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. Better service names might be: s/reset_coalesce_and_fill_boundary/begin_preemptible_coalesce_and_fill/ s/finish_coalesce_and_fill/end_preemptible_coalesce_and_fill/ remove coalesce_and_fill_is_done() <--- this was apparently an incomplete thought of mine ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From wkemper at openjdk.java.net Thu Oct 14 23:38:11 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 14 Oct 2021 23:38:11 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. I think it's okay here because this code is only called to coalesce and fill regions during a global collect. Preemption during a global collect shouldn't be a concern (young collects can only preempt old marking, they can't preempt a global collect). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From kdnilsen at openjdk.java.net Fri Oct 15 15:55:15 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 15 Oct 2021 15:55:15 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: <1crExPegFffO3S-TIC_QHu9chuiek2uMNAVUbGwr3qE=.9ecadd3f-b882-4ede-bcb6-8c733169c3bf@github.com> On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. Marked as reviewed by kdnilsen (Committer). Sorry to be so slow to see how this works. I see that the old-gen coalesce-and-fill effort instantiates a ShenandoahConcurrentCoalesceAndFillTask to perform coalesce-and-fill with preemption, and does not call into ShenandoahHeap::coalesce_and_fill_old_regions(), so I agree your change is ok. It might be worthwhile to add a comment to ShenandoahHeap::coalesce_and_fill_old_regions() stating that this version of coalesce-and-fill is intended only for situations that do not need to respond to preemption requests by urgent young-gen collections. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From wkemper at openjdk.java.net Fri Oct 15 16:06:13 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 15 Oct 2021 16:06:13 GMT Subject: RFR: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. Sure - will add an explanatory comment there. ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From wkemper at openjdk.java.net Fri Oct 15 16:09:38 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 15 Oct 2021 16:09:38 GMT Subject: RFR: Reset coalesce and fill boundary during global collect [v2] In-Reply-To: References: Message-ID: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Add comment explaining why coalesce and fill boundary needs to be reset here ------------- Changes: - all: https://git.openjdk.java.net/shenandoah/pull/90/files - new: https://git.openjdk.java.net/shenandoah/pull/90/files/50d110ba..7d590284 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=90&range=01 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=90&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/shenandoah/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/90/head:pull/90 PR: https://git.openjdk.java.net/shenandoah/pull/90 From wkemper at openjdk.java.net Fri Oct 15 16:13:23 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 15 Oct 2021 16:13:23 GMT Subject: Integrated: Reset coalesce and fill boundary during global collect In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 22:27:49 GMT, William Kemper wrote: > Normally, this happens during cset selection for the old generation. It also needs to happen for coalesce and fill at the end of global collections or objects may not be filled. This pull request has now been integrated. Changeset: 8c87aa9c Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/8c87aa9c0122490cbb3760b524d5024fa8a0df3b Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Reset coalesce and fill boundary during global collect Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/90 From wkemper at openjdk.java.net Mon Oct 18 21:52:25 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Mon, 18 Oct 2021 21:52:25 GMT Subject: RFR: Degenerate to young cycles for out of cycle allocation failures Message-ID: ### Summary * Allocation failures outside of cycle degenerate to young collections (previously we ran a global cycle) * Added new degen point "roots" because remembered set swap during init mark is _not_ idempotent * There is also a change here to register old gen objects when they are allocated under a lock (this reverts a previous change) ------------- Commit messages: - Add new degen point for concurrent root mark - Register objects during allocation when heap is locked - Degenerate to young collection for allocation failure outside of cycle Changes: https://git.openjdk.java.net/shenandoah/pull/91/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=91&range=00 Stats: 75 lines in 10 files changed: 43 ins; 23 del; 9 mod Patch: https://git.openjdk.java.net/shenandoah/pull/91.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/91/head:pull/91 PR: https://git.openjdk.java.net/shenandoah/pull/91 From rkennke at openjdk.java.net Tue Oct 19 16:26:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 19 Oct 2021 16:26:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access Message-ID: Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); or similar constructs. Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. Testing: - [x] tier - [ ] tier2 - [x] hotspot_gc ------------- Commit messages: - Update some copyright headers - Add missing includes - Merge branch 'master' into optimize-fwdptr - Add missing includes - Rename mwd -> fwd - Add missing file - Move remaining forwarding methods to OopForwarding - Renames, cleanups - Initial implementation of MarkWordDecoder Changes: https://git.openjdk.java.net/jdk/pull/5955/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275527 Stats: 351 lines in 27 files changed: 170 ins; 79 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Tue Oct 19 16:26:05 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 16:26:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [ ] tier2 > - [x] hotspot_gc I like it. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5955 From stefank at openjdk.java.net Tue Oct 19 21:02:05 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 19 Oct 2021 21:02:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc I like how the mark/is_marked/decode_pointer code gets cleaned up. And having an OopForwading class probably makes sense for parts of the code. I'm less excited about the way the explicitly stack allocated OopForwarding objects make the code less readable. Take these two examples: assert(old->is_objArray(), "invariant"); - assert(old->is_forwarded(), "invariant"); + assert(OopForwarding(old).is_forwarded(), "invariant"); oop new_obj = obj->is_forwarded() ? obj->forwardee() : _young_gen->copy_to_survivor_space(obj); OopForwarding fwd(obj); oop new_obj = fwd.is_forwarded() ? fwd.forwardee() : _young_gen->copy_to_survivor_space(obj); I think both snippets were nicer to read in the earlier code. And there's a lot of those kind of changes in this patch. Maybe there's a hybrid approach where we could still have oopDesc::is_forwarded, oopDesc::forwardee, etc. but also have OopForwarding objects for those places that really need them? And then minimize the amount of places we use `OopForwarding fwd(obj)` and `OopForwarding(obj)->forwardee()` in the code? ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5955 From kdnilsen at openjdk.java.net Tue Oct 19 21:26:38 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 19 Oct 2021 21:26:38 GMT Subject: RFR: Degenerate to young cycles for out of cycle allocation failures In-Reply-To: References: Message-ID: <8YPJsMr35cpsK2sABqFjLFaPwEd4bMo-SMZsXCDNTcc=.a8e15258-1815-4233-afc8-0d73ece70215@github.com> On Mon, 18 Oct 2021 21:47:44 GMT, William Kemper wrote: > ### Summary > * Allocation failures outside of cycle degenerate to young collections (previously we ran a global cycle) > * Added new degen point "roots" because remembered set swap during init mark is _not_ idempotent > * There is also a change here to register old gen objects when they are allocated under a lock (this reverts a previous change) Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/91 From wkemper at openjdk.java.net Tue Oct 19 21:36:26 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 19 Oct 2021 21:36:26 GMT Subject: Integrated: Degenerate to young cycles for out of cycle allocation failures In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 21:47:44 GMT, William Kemper wrote: > ### Summary > * Allocation failures outside of cycle degenerate to young collections (previously we ran a global cycle) > * Added new degen point "roots" because remembered set swap during init mark is _not_ idempotent > * There is also a change here to register old gen objects when they are allocated under a lock (this reverts a previous change) This pull request has now been integrated. Changeset: ca939b69 Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/ca939b69f95db2cb8ead9c9459b2d7712909a4b6 Stats: 75 lines in 10 files changed: 43 ins; 23 del; 9 mod Degenerate to young cycles for out of cycle allocation failures Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/91 From wkemper at openjdk.java.net Tue Oct 19 23:02:58 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 19 Oct 2021 23:02:58 GMT Subject: RFR: Initialize promotion failed member to false Message-ID: Trivial fix ------------- Commit messages: - Initialize promotion failed member to false Changes: https://git.openjdk.java.net/shenandoah/pull/92/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=92&range=00 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/shenandoah/pull/92.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/92/head:pull/92 PR: https://git.openjdk.java.net/shenandoah/pull/92 From kdnilsen at openjdk.java.net Tue Oct 19 23:17:26 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Tue, 19 Oct 2021 23:17:26 GMT Subject: RFR: Initialize promotion failed member to false In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 22:56:55 GMT, William Kemper wrote: > Trivial fix Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/92 From wkemper at openjdk.java.net Tue Oct 19 23:51:31 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Tue, 19 Oct 2021 23:51:31 GMT Subject: Integrated: Initialize promotion failed member to false In-Reply-To: References: Message-ID: <6hgBsyj3wWP6-5XabsDtOHsey0RFhq5ZZOqKFHbfhKU=.3bb49b04-40b8-4f9b-b313-5284106038bb@github.com> On Tue, 19 Oct 2021 22:56:55 GMT, William Kemper wrote: > Trivial fix This pull request has now been integrated. Changeset: e2c8047c Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/e2c8047cfc83fd4932d64f2ea393fd8bf27ea0d7 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Initialize promotion failed member to false Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/92 From tschatzl at openjdk.java.net Wed Oct 20 10:30:06 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 10:30:06 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc @rkennke : could you close the superfluous CRs for this issue? You filed this one 9 times in total... (probably due to network issues yesterday). Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Wed Oct 20 10:41:08 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Oct 2021 10:41:08 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 10:36:17 GMT, Thomas Schatzl wrote: > Never mind, already did that. I did not check if any of the duplicates contain more information than the one used for this PR though. Oh dear! Thank you! Yes, when I tried to file the issue, bugs.o.j.n was down and/or very slow. Apparently every attempt actually went through, without actually sending back a confirmation. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Wed Oct 20 10:41:08 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 10:41:08 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Never mind, already did that. I did not check if any of the duplicates contain more information than the one used for this PR though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From ayang at openjdk.java.net Wed Oct 20 11:33:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 20 Oct 2021 11:33:06 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). Overriding the markword to return null for non-forwarded objs is indeed a bit hacky. However, from a caller's perspective, this is the most intuitive one. Taking `G1FullGCCompactTask::G1CompactRegionClosure::apply` as an example: HeapWord* destination = cast_from_oop(obj->forwardee()); if (destination == NULL) { // Object not moving return size; } ... Copy::aligned_conjoint_words(obj_addr, destination, size); `destination` is either null (obj is not moved) or the new location after moving; rather smooth and straightforward control flow. I wonder if we can use this pattern without overriding the markdown. Here's a straw man proposal. oop oopDesc::forwardee() const { auto mark_word = mark(); bool is_forwarded = mark_word.is_marked(); if (!is_forwarded) { return nullptr; } return cast_to_oop(mark_word.decode_pointer()); } The intention is to load the markword only once. Additionally, callers can continue using the `is_forwarded() / forwardee()` pair, or switch to the `forwardee() == nullptr` pattern on a case-by-case basis if desired. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Wed Oct 20 11:37:06 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Oct 2021 11:37:06 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 20:58:49 GMT, Stefan Karlsson wrote: > I like how the mark/is_marked/decode_pointer code gets cleaned up. And having an OopForwading class probably makes sense for parts of the code. > > I'm less excited about the way the explicitly stack allocated OopForwarding objects make the code less readable. Take these two examples: > > ``` > assert(old->is_objArray(), "invariant"); > - assert(old->is_forwarded(), "invariant"); > + assert(OopForwarding(old).is_forwarded(), "invariant"); > ``` > > ``` > oop new_obj = obj->is_forwarded() ? obj->forwardee() > : _young_gen->copy_to_survivor_space(obj); > OopForwarding fwd(obj); > oop new_obj = fwd.is_forwarded() ? fwd.forwardee() > : _young_gen->copy_to_survivor_space(obj); > ``` > > I think both snippets were nicer to read in the earlier code. And there's a lot of those kind of changes in this patch. > > Maybe there's a hybrid approach where we could still have oopDesc::is_forwarded, oopDesc::forwardee, etc. but also have OopForwarding objects for those places that really need them? And then minimize the amount of places we use `OopForwarding fwd(obj)` and `OopForwarding(obj)->forwardee()` in the code? In the first snippet, there is only one usage of the mark-word, i.e. no problem to simplify that. However, in the 2nd snippet, the point is that we can avoid loading the mark-word twice, and if we want to do that, we need an enclosing scope. The alternative would be to do something like: markWord mark = obj->mark(); oop fwd = mark->is_forwarded() ? mark->forwardee() : something_else(); ... which is pretty much the same as what I proposed, except that the markWord and the logic is encapsulated in OopForwarding. Notice that in some cases we actually already do that - those are the 'messy' cases where we deliberately load the mark-word once, and drag it through the code that needs it (sometimes not only for performance but also for correctness in the face of concurrency) - and the use is_marked() and decode_pointer() on it. Given that I have not been able to show performance benefits, I could revert cases like you mentioned to their original form, and consolidate the implementation into markWord, unless we prefer the most efficient solution everywhere. ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From stefank at openjdk.java.net Wed Oct 20 12:59:08 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 20 Oct 2021 12:59:08 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc I don't think we should make the code more complicated by using the micro optimized version unless we can measure the benefits. IMHO, it is harder to read and it makes it more difficult to know if the read-once of was done for correctness purposes or not. I understand that that other reviewers might disagree with my view, and if that's the case, then I'll back off. Some concrete feedback on the current patch: I don't like that we store the oop in the OopForwarding. That oop gets snuck into functions via the fwd variable. That makes it less obvious that the functions depend on the old oop. Code like the following becomes more obscure, when you don't immediately see that it operates on the original (old) object: const oop forward_ptr = fwd.forward_to_atomic(obj, memory_order_relaxed); if (forward_ptr == NULL) { I wonder if it wouldn't make sense to make forward_to_atomic static, just like the forward_to is static? That way we wouldn't have to store _obj in OopForwarding, and I think the code would be more decoupled and easier to read. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From stefank at openjdk.java.net Wed Oct 20 14:01:12 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 20 Oct 2021 14:01:12 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5 and here it is on-top of your branch: https://github.com/openjdk/jdk/compare/master...stefank:pr_5955 ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Wed Oct 20 14:17:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Oct 2021 14:17:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc > Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: [stefank at 58732bc](https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5) > > and here it is on-top of your branch: [master...stefank:pr_5955](https://github.com/openjdk/jdk/compare/master...stefank:pr_5955) > Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: [stefank at 58732bc](https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5) > > and here it is on-top of your branch: [master...stefank:pr_5955](https://github.com/openjdk/jdk/compare/master...stefank:pr_5955) Thanks! Yes this is indeed better. I will merge into this PR as soon as I get to it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From zgu at redhat.com Wed Oct 20 16:54:16 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Oct 2021 12:54:16 -0400 Subject: [sh/8u] RFR 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag Message-ID: I would like to backport this Shenandoah specific patch to Shenandoah 8u. The patch corrects the order of a couple of GC flags, ensure GC sees latest GC cause when a GC is requested. The original patch does not apply cleanly. The conflict is due to context difference in ShenandoahControlThread::handle_requested_gc() method, where newer version has code to handle concurrent GC breakpoint. Original bug: https://bugs.openjdk.java.net/browse/JDK-8275051 Original patch: https://github.com/openjdk/jdk/commit/1ab64143c06e33e23172dd77c39e434443347364 Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/JDK-8275051-8u/webrev/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Wed Oct 20 16:58:33 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Oct 2021 18:58:33 +0200 Subject: [sh/8u] RFR 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag In-Reply-To: References: Message-ID: On 10/20/21 6:54 PM, Zhengyu Gu wrote: > I would like to backport this Shenandoah specific patch to Shenandoah 8u. Hold on, I need to pull aarch64-port/jdk8u-shenandoah to sh/jdk8 first. -- Thanks, -Aleksey From zgu at redhat.com Wed Oct 20 17:02:25 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Oct 2021 13:02:25 -0400 Subject: [sh/8u] RFR 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag In-Reply-To: References: Message-ID: <848f347a-108e-c41f-b302-7984c6003276@redhat.com> On 10/20/21 12:58, Aleksey Shipilev wrote: > On 10/20/21 6:54 PM, Zhengyu Gu wrote: >> I would like to backport this Shenandoah specific patch to Shenandoah 8u. > > Hold on, I need to pull aarch64-port/jdk8u-shenandoah to sh/jdk8 first. Sure. -Zhengyu > From stefank at openjdk.java.net Thu Oct 21 07:47:05 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 21 Oct 2021 07:47:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc A few more comments: src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 112: > 110: // since it will be restored by preserved marks. > 111: object->init_mark(); > 112: } else { Could you explain why this was removed? src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp line 142: > 140: OopForwarding fwd(o); > 141: if (!fwd.is_forwarded()) { > 142: return copy_unmarked_to_survivor_space(o, fwd); I wonder if this copy_unmarked should be renamed to copy_unforwarded? src/hotspot/share/gc/serial/defNewGeneration.cpp line 56: > 54: #include "oops/instanceRefKlass.hpp" > 55: #include "oops/oop.inline.hpp" > 56: #include "oops/oopForwarding.hpp" The patch is inconsistent w.r.t. the include order between oop.inline.hpp and oopForwarding.hpp. src/hotspot/share/oops/oopForwarding.hpp line 83: > 81: #endif > 82: #endif > 83: } This should preferable be in a .cpp file, though it seems excessive to introduce one just for this case. Since it is only used by the forward_to functions, maybe add it to the suggested oopForwarding.inline.hpp file? src/hotspot/share/oops/oopForwarding.hpp line 125: > 123: return cast_to_oop(old_mark.decode_pointer()); > 124: } > 125: } The forward_to functions uses functions in oop.inline.hpp. They need to be split out into a oopForwarding.inline.hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From wkemper at openjdk.java.net Thu Oct 21 17:26:39 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 21 Oct 2021 17:26:39 GMT Subject: RFR: Enforce maximum capacity of young generation when allocating Message-ID: <6w38VnEBcfNqyzzVVZTeIJO3uMWhwWLvokDSBJb7JIE=.cba49e58-356d-4d35-8c24-01f3984ddfd3@github.com> Also log young generation maximum capacity during initialization. ------------- Commit messages: - Enforce maximum capacity of young generation when allocating Changes: https://git.openjdk.java.net/shenandoah/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=93&range=00 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/shenandoah/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/93/head:pull/93 PR: https://git.openjdk.java.net/shenandoah/pull/93 From wkemper at openjdk.java.net Thu Oct 21 17:26:53 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 21 Oct 2021 17:26:53 GMT Subject: RFR: Make region sampling aware of full collections Message-ID: Full collections do not change the `_gc_state` of `ShenandoahHeap` in a way the region sampling code expected. The region sampling code is now aware of full collections. ------------- Commit messages: - Make region sampling aware of full collections Changes: https://git.openjdk.java.net/shenandoah/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=94&range=00 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/shenandoah/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/94/head:pull/94 PR: https://git.openjdk.java.net/shenandoah/pull/94 From kdnilsen at openjdk.java.net Thu Oct 21 17:57:38 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 21 Oct 2021 17:57:38 GMT Subject: RFR: Make region sampling aware of full collections In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 17:21:37 GMT, William Kemper wrote: > Full collections do not change the `_gc_state` of `ShenandoahHeap` in a way the region sampling code expected. The region sampling code is now aware of full collections. Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/94 From kdnilsen at openjdk.java.net Thu Oct 21 17:58:37 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Thu, 21 Oct 2021 17:58:37 GMT Subject: RFR: Enforce maximum capacity of young generation when allocating In-Reply-To: <6w38VnEBcfNqyzzVVZTeIJO3uMWhwWLvokDSBJb7JIE=.cba49e58-356d-4d35-8c24-01f3984ddfd3@github.com> References: <6w38VnEBcfNqyzzVVZTeIJO3uMWhwWLvokDSBJb7JIE=.cba49e58-356d-4d35-8c24-01f3984ddfd3@github.com> Message-ID: On Thu, 21 Oct 2021 17:19:59 GMT, William Kemper wrote: > Also log young generation maximum capacity during initialization. Marked as reviewed by kdnilsen (Committer). ------------- PR: https://git.openjdk.java.net/shenandoah/pull/93 From wkemper at openjdk.java.net Thu Oct 21 20:31:42 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 21 Oct 2021 20:31:42 GMT Subject: Integrated: Make region sampling aware of full collections In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 17:21:37 GMT, William Kemper wrote: > Full collections do not change the `_gc_state` of `ShenandoahHeap` in a way the region sampling code expected. The region sampling code is now aware of full collections. This pull request has now been integrated. Changeset: 7bc0d2bf Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/7bc0d2bfd7cbff829e40c5bcbdfa71980ce1f3ba Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Make region sampling aware of full collections Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/94 From wkemper at openjdk.java.net Thu Oct 21 20:32:30 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Thu, 21 Oct 2021 20:32:30 GMT Subject: Integrated: Enforce maximum capacity of young generation when allocating In-Reply-To: <6w38VnEBcfNqyzzVVZTeIJO3uMWhwWLvokDSBJb7JIE=.cba49e58-356d-4d35-8c24-01f3984ddfd3@github.com> References: <6w38VnEBcfNqyzzVVZTeIJO3uMWhwWLvokDSBJb7JIE=.cba49e58-356d-4d35-8c24-01f3984ddfd3@github.com> Message-ID: On Thu, 21 Oct 2021 17:19:59 GMT, William Kemper wrote: > Also log young generation maximum capacity during initialization. This pull request has now been integrated. Changeset: e442388f Author: William Kemper URL: https://git.openjdk.java.net/shenandoah/commit/e442388f07101581cad97fe2052530f3d47ad794 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Enforce maximum capacity of young generation when allocating Reviewed-by: kdnilsen ------------- PR: https://git.openjdk.java.net/shenandoah/pull/93 From jborgers at jpinpoint.com Fri Oct 22 16:27:50 2021 From: jborgers at jpinpoint.com (Jeroen Borgers) Date: Fri, 22 Oct 2021 18:27:50 +0200 Subject: Long pacing time seems to result in long response times In-Reply-To: References: Message-ID: Hi, Just to let you know. We found that setting: -XX:ShenandoahPacingMaxDelay=10 solved our problem. Tuning SpikeFactor also helped a lot. Regards, Jeroen Op di 12 okt. 2021 om 16:00 schreef Jeroen Borgers : > Hi, > > In a load test on a JSF application we encountered long response times up > to 4 minutes instead of a few seconds, during a 20 min part of the test, > while putting constant load on it. Pacing times seem large to me and I > want to find out if this is causing the bad response times. The CPU usage > on the host follows that of the jboss process which lowers from 45% to 12% > in that period. So it seems that the app is slowed down for about 20 > minutes; 5 minutes the slowest and then slowly recovering. > > There is a degenerate gc for 1.4 s., triggered by a TLAB allocation > failure, followed by 10 s. pacing (212 ms avg non-zero). Then pacing of 28 > ms. followed by 28 s.(!) pacing (900 ms avg non-zero). > *1 Is this normal pacing behavior? > > Configuration: x86-64b, 6 cores, VMWare, RHEL 7.9, OpenJDK 11.0.12, jboss > 7.3.3. > jvm settings: -XX:+UseShenandoahGC -XX:+AlwaysPreTouch -XX:+UseNUMA > -XX:-UseBiasedLocking -XX:+UseTransparentHugePages > -Xlog:gc*:file=...log/gc-%t-%p.log:tags,uptime,time,level:filecount=5,filesize=3m > -Xlog:safepoint*:file=...log/safepoints-%t-%p.log:tags,uptime,time,level:filecount=5,filesize=3m > > In our profiling tool it seems e.g. 88% of a long user tx (4 min) is spent > in locking. > *2. Is that how pacing shows? > > We will try out -XX:ShenandoahPacingMaxDelay=10 in a new test with also a > bigger heap (12->16GB). > *3 Would that solve the issue? > > *4 Would it help to provide gc logging here for better understanding what > happens? > > Kind regards, > > Jeroen Borgers > > drs. Jeroen Borgers > Principal Consultant > jPinpoint Performance Services, jpinpoint com, The Netherlands. > e-mail: jborgers at jpinpoint com > From rkennke at redhat.com Sat Oct 23 16:18:04 2021 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 23 Oct 2021 18:18:04 +0200 Subject: Long pacing time seems to result in long response times In-Reply-To: References: Message-ID: <92ccf9ac-4e66-fce3-7d74-59f30a7a5468@redhat.com> Hi Jeroen, Sorry that I did not reply earlier. > Just to let you know. We found that setting: > -XX:ShenandoahPacingMaxDelay=10 > solved our problem. Isn't that the default? Have you set that flag to a higher value before? > Tuning SpikeFactor also helped a lot. Right. Which value worked better for you? Thanks, Roman >> Hi, >> >> In a load test on a JSF application we encountered long response times up >> to 4 minutes instead of a few seconds, during a 20 min part of the test, >> while putting constant load on it. Pacing times seem large to me and I >> want to find out if this is causing the bad response times. The CPU usage >> on the host follows that of the jboss process which lowers from 45% to 12% >> in that period. So it seems that the app is slowed down for about 20 >> minutes; 5 minutes the slowest and then slowly recovering. >> >> There is a degenerate gc for 1.4 s., triggered by a TLAB allocation >> failure, followed by 10 s. pacing (212 ms avg non-zero). Then pacing of 28 >> ms. followed by 28 s.(!) pacing (900 ms avg non-zero). >> *1 Is this normal pacing behavior? >> >> Configuration: x86-64b, 6 cores, VMWare, RHEL 7.9, OpenJDK 11.0.12, jboss >> 7.3.3. >> jvm settings: -XX:+UseShenandoahGC -XX:+AlwaysPreTouch -XX:+UseNUMA >> -XX:-UseBiasedLocking -XX:+UseTransparentHugePages >> -Xlog:gc*:file=...log/gc-%t-%p.log:tags,uptime,time,level:filecount=5,filesize=3m >> -Xlog:safepoint*:file=...log/safepoints-%t-%p.log:tags,uptime,time,level:filecount=5,filesize=3m >> >> In our profiling tool it seems e.g. 88% of a long user tx (4 min) is spent >> in locking. >> *2. Is that how pacing shows? >> >> We will try out -XX:ShenandoahPacingMaxDelay=10 in a new test with also a >> bigger heap (12->16GB). >> *3 Would that solve the issue? >> >> *4 Would it help to provide gc logging here for better understanding what >> happens? >> >> Kind regards, >> >> Jeroen Borgers >> >> drs. Jeroen Borgers >> Principal Consultant >> jPinpoint Performance Services, jpinpoint com, The Netherlands. >> e-mail: jborgers at jpinpoint com >> > From gnu.andrew at redhat.com Mon Oct 25 14:37:27 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Oct 2021 15:37:27 +0100 Subject: How To Solve a Problem Like Shenandoah 8u In-Reply-To: <7ef2da88-b46f-5462-785f-0a89d08f252d@redhat.com> References: <3a951ce6-274f-7e8b-9783-0c419051371f@redhat.com> <7ef2da88-b46f-5462-785f-0a89d08f252d@redhat.com> Message-ID: On 10:29 Thu 14 Oct , Aleksey Shipilev wrote: > On 10/13/21 9:54 PM, Roman Kennke wrote: > > Others who do more frequent backports than me (Aleksey maybe?) might > > have more insights.? > > Our backport tracking machinery parses the changesets in that HG repo. That's the only option for > tracking, because 8u Shenandoah backports are not tracked in JBS. I suspect it would be fine to keep > the read-only snapshot of old Mercurial repo, so that backports-monitor can still read it. > > FWIW, we did the similar history-losing-squash commit when moving sh/jdk9 -> sh/jdk10 for the > monorepo migration, and that was not very painful. > > -- > Thanks, > -Aleksey > I guess such a commit could also contain the list of backported changes, as we did with the AArch64 import into 8u? It should be easy enough to obtain from the Mercurial history and/or our release notes. 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 kdnilsen at openjdk.java.net Wed Oct 27 19:47:00 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Wed, 27 Oct 2021 19:47:00 GMT Subject: RFR: Align plabs on card boundaries Message-ID: If plabs are not aligned on remembered set card boundaries, then we need synchronization locks to register the promotion objects allocated by each thread. We do not currently have these synchronization locks and do not want to add them. Instead, we are enforcing that all of the objects that reside within a particular remembered set card are allocated by the same thread. ------------- Commit messages: - Fix whitespace - Respond to reviewer feedback - Debug plab alignment and remove instrumentation - Align PLAB allocations on remembered set card boundaries Changes: https://git.openjdk.java.net/shenandoah/pull/95/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=95&range=00 Stats: 95 lines in 4 files changed: 87 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/shenandoah/pull/95.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/95/head:pull/95 PR: https://git.openjdk.java.net/shenandoah/pull/95 From wkemper at openjdk.java.net Wed Oct 27 20:18:48 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Wed, 27 Oct 2021 20:18:48 GMT Subject: RFR: Align plabs on card boundaries In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 19:22:27 GMT, Kelvin Nilsen wrote: > If plabs are not aligned on remembered set card boundaries, then we need synchronization locks to register the promotion objects allocated by each thread. We do not currently have these synchronization locks and do not want to add them. Instead, we are enforcing that all of the objects that reside within a particular remembered set card are allocated by the same thread. Looks good to me. ------------- Marked as reviewed by wkemper (Committer). PR: https://git.openjdk.java.net/shenandoah/pull/95 From kdnilsen at openjdk.java.net Wed Oct 27 20:22:48 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Wed, 27 Oct 2021 20:22:48 GMT Subject: Integrated: Align plabs on card boundaries In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 19:22:27 GMT, Kelvin Nilsen wrote: > If plabs are not aligned on remembered set card boundaries, then we need synchronization locks to register the promotion objects allocated by each thread. We do not currently have these synchronization locks and do not want to add them. Instead, we are enforcing that all of the objects that reside within a particular remembered set card are allocated by the same thread. This pull request has now been integrated. Changeset: ad4ad1fb Author: Kelvin Nilsen URL: https://git.openjdk.java.net/shenandoah/commit/ad4ad1fb571b0c34c3bd4de492b0e0f9214612c8 Stats: 95 lines in 4 files changed: 87 ins; 1 del; 7 mod Align plabs on card boundaries Reviewed-by: wkemper ------------- PR: https://git.openjdk.java.net/shenandoah/pull/95 From rkennke at openjdk.java.net Thu Oct 28 11:44:45 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 11:44:45 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v2] In-Reply-To: References: Message-ID: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Revert unnecessary changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5955/files - new: https://git.openjdk.java.net/jdk/pull/5955/files/ec0a4bad..75fdec35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=00-01 Stats: 327 lines in 28 files changed: 60 ins; 171 del; 96 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 11:47:52 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 11:47:52 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v3] In-Reply-To: References: Message-ID: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix Parallel GC mistake ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5955/files - new: https://git.openjdk.java.net/jdk/pull/5955/files/75fdec35..a9f0c845 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 12:35:37 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 12:35:37 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v4] In-Reply-To: References: Message-ID: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move forward impl into markWord and add assert ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5955/files - new: https://git.openjdk.java.net/jdk/pull/5955/files/a9f0c845..9c2ed2ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=02-03 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 12:41:13 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 12:41:13 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v4] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 12:35:37 GMT, Roman Kennke wrote: >> Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: >> fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); >> >> or similar constructs. >> >> Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). >> >> I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. >> >> Testing: >> - [x] tier >> - [x] tier2 >> - [x] hotspot_gc > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move forward impl into markWord and add assert I've removed OopForwarding altogether, and only kept the actual refactorings and cleanups. Can you please re-review? ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 12:41:14 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 12:41:14 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v4] In-Reply-To: References: Message-ID: <9xpY2oFvx_vNWmeextHoveVIarXOJ4IUPtXQeLV6VqY=.02c0abc9-a5de-4309-909c-16aaf129b4bf@github.com> On Thu, 21 Oct 2021 07:30:44 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Move forward impl into markWord and add assert > > src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 112: > >> 110: // since it will be restored by preserved marks. >> 111: object->init_mark(); >> 112: } else { > > Could you explain why this was removed? The G1 Full GC code decoded the fwdptr without checking if object is actually forwarded (i.e. by checking the lowest two mark word bits), and then compare the result with NULL. In order for this to work, it modifies the mark word of not forwarded objects to prototype mark. This is all quite messy and can be avoided by checking is_forwarded() before actually decoding the fwdptr. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From gnu.andrew at redhat.com Thu Oct 28 13:49:43 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 Oct 2021 14:49:43 +0100 Subject: Fwd: [RFR] [8u] 8u312-b07 Upstream Sync In-Reply-To: References: Message-ID: Apparently, sending this to shenandaoh-dev doesn't get the feedback I expected... ---------- Forwarded message --------- From: Andrew Hughes Date: Tue, 26 Oct 2021 at 02:09 Subject: [RFR] [8u] 8u312-b07 Upstream Sync To: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/root/merge.changeset Changes in aarch64-shenandoah-jdk8u312-b07: - JDK-8130183: InnerClasses: VM permits wrong Throw ClassFormatError if InnerClasses attribute's inner_class_info_index is 0 - JDK-8157404: Unable to read certain PKCS12 keystores from SequenceInputStream - JDK-8163326: Update the default enabled cipher suites preference - JDK-8222751: closed/test/jdk/sun/security/util/DerIndefLenConverter/IndefBerPkcs12.java fail - JDK-8263314: Enhance XML Dsig modes - JDK-8265167: Richer Text Editors - JDK-8265574: Improve handling of sheets - JDK-8265580: Enhanced style for RTF kit - JDK-8265776: Improve Stream handling for SSL - JDK-8266097: Better hashing support - JDK-8266103: Better specified spec values - JDK-8266109: More Resilient Classloading - JDK-8266115: More Manifest Jar Loading - JDK-8266137: Improve Keystore integrity - JDK-8266689: More Constrained Delegation - JDK-8267086: ArrayIndexOutOfBoundsException in java.security.KeyFactory.generatePublic - JDK-8267712: Better LDAP reference processing - JDK-8267729: Improve TLS client handshaking - JDK-8267735: Better BMP support - JDK-8268193: Improve requests of certificates - JDK-8268199: Correct certificate requests - JDK-8268506: More Manifest Digests - JDK-8268965: TCP Connection Reset when connecting simple socket to SSL server - JDK-8269618: Better session identification - JDK-8269624: Enhance method selection support - JDK-8269763: The JEditorPane is blank after JDK-8265167 - JDK-8270398: Enhance canonicalization - JDK-8270404: Better canonicalization - JDK-8272643: Backout JDK-8176837 from 8u312 Main issues of note: None, clean merge. We skipped b06 as it just reverted 8268965 (JDK-8272643) and reapplied it under the correct bug ID, so there was no source change in the end. diffstat for root b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for corba b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxp b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxws b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for langtools b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for nashorn b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jdk b/.hgtags | 2 b/src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java | 7 b/src/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties | 1 b/src/share/classes/com/sun/jndi/ldap/Obj.java | 8 b/src/share/classes/com/sun/jndi/ldap/VersionHelper12.java | 2 b/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java | 8 b/src/share/classes/java/net/URLClassLoader.java | 5 b/src/share/classes/java/util/HashMap.java | 52 + b/src/share/classes/java/util/HashSet.java | 11 b/src/share/classes/java/util/jar/JarFile.java | 8 b/src/share/classes/javax/crypto/spec/IvParameterSpec.java | 11 b/src/share/classes/javax/crypto/spec/RC5ParameterSpec.java | 9 b/src/share/classes/javax/crypto/spec/SecretKeySpec.java | 9 b/src/share/classes/javax/swing/text/rtf/RTFParser.java | 63 +- b/src/share/classes/javax/swing/text/rtf/RTFReader.java | 72 +- b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java | 25 b/src/share/classes/sun/misc/Resource.java | 8 b/src/share/classes/sun/misc/URLClassPath.java | 14 b/src/share/classes/sun/net/httpserver/SSLStreams.java | 11 b/src/share/classes/sun/security/jgss/krb5/SubjectComber.java | 158 ++--- b/src/share/classes/sun/security/provider/KeyStoreDelegator.java | 2 b/src/share/classes/sun/security/ssl/CertificateRequest.java | 72 ++ b/src/share/classes/sun/security/ssl/CipherSuite.java | 300 +++++----- b/src/share/classes/sun/security/ssl/ClientHandshakeContext.java | 7 b/src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java | 21 b/src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java | 7 b/src/share/classes/sun/security/ssl/HelloCookieManager.java | 2 b/src/share/classes/sun/security/ssl/KeyShareExtension.java | 69 +- b/src/share/classes/sun/security/ssl/PreSharedKeyExtension.java | 3 b/src/share/classes/sun/security/ssl/RandomCookie.java | 10 b/src/share/classes/sun/security/ssl/RenegoInfoExtension.java | 8 b/src/share/classes/sun/security/ssl/SSLLogger.java | 2 b/src/share/classes/sun/security/ssl/ServerKeyExchange.java | 13 b/src/share/classes/sun/security/ssl/SessionId.java | 3 b/src/share/classes/sun/security/ssl/Utilities.java | 19 b/src/share/classes/sun/security/ssl/X509Authentication.java | 6 b/src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java | 9 b/src/share/classes/sun/security/tools/keytool/Main.java | 25 b/src/share/classes/sun/security/util/ByteArrays.java | 67 ++ b/src/share/classes/sun/security/util/DerIndefLenConverter.java | 280 +++++---- b/src/share/classes/sun/security/util/DerInputStream.java | 24 b/src/share/classes/sun/security/util/DerValue.java | 29 b/src/share/classes/sun/security/util/SignatureFileVerifier.java | 4 b/test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java | 236 +++++-- b/test/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java | 262 +++++--- b/test/javax/xml/crypto/dsig/GenerationTests.java | 7 46 files changed, 1271 insertions(+), 700 deletions(-) diffstat for hotspot b/.hgtags | 2 ++ b/src/share/vm/classfile/classFileParser.cpp | 10 ++++++++-- b/src/share/vm/classfile/verifier.cpp | 20 +++++++++++++++++--- b/src/share/vm/code/dependencies.cpp | 23 +++++++++++++++++++++++ b/src/share/vm/prims/jvm.cpp | 12 ++++++++++++ 5 files changed, 62 insertions(+), 5 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 -------------- next part -------------- -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRRMled0VQO0j4ExaDP2g+bNZZCIgUCYXdVVgAKCRDP2g+bNZZC Io1lAPsFW6aUZxS5mLwINUtt6AhoWSsdI+5JZHIuJnCfQ9yXfQD9Eu3AVE1LLVfC CCdjSTaZFCgjZEI+Y3LGzPyMexAiWAk= =3xBD -----END PGP SIGNATURE----- From shade at redhat.com Fri Oct 29 06:11:02 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 Oct 2021 08:11:02 +0200 Subject: Fwd: [RFR] [8u] 8u312-b07 Upstream Sync In-Reply-To: References: Message-ID: <65e322e5-cc26-68f2-d733-94c4bce24b18@redhat.com> On 10/28/21 3:49 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/root/merge.changeset Looks trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From kdnilsen at openjdk.java.net Fri Oct 29 21:41:00 2021 From: kdnilsen at openjdk.java.net (Kelvin Nilsen) Date: Fri, 29 Oct 2021 21:41:00 GMT Subject: RFR: Fix preempt old preparation Message-ID: To address crashes found following integration of "preempt old preparation", several fixes have been implemented: 1. Defer mixed evacuations until after coalesce-and-fill is done 2. Fix verification of remembered set to use the marking context whenever old-gen is in the process of preparing for mixed evacuations. 3. Cosmetic improvement to change "misleading" function names. ------------- Commit messages: - Improve function names - Merge branch 'shenandoah' of ssh://git.amazon.com/pkg/OpenJDKTipSrc into fix-preempt-old-preparation - Fix verification of remset to use mark context when appropriate - Defer mixed evacuations until after coalesce-and-fill is done - Merge branch 'shenandoah' of ssh://git.amazon.com/pkg/OpenJDKTipSrc into fix-preempt-old-preparation - Finish coalesce-and-fill before starting mixed evac Changes: https://git.openjdk.java.net/shenandoah/pull/96/files Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=96&range=00 Stats: 35 lines in 9 files changed: 14 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/shenandoah/pull/96.diff Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/96/head:pull/96 PR: https://git.openjdk.java.net/shenandoah/pull/96 From wkemper at openjdk.java.net Fri Oct 29 21:48:45 2021 From: wkemper at openjdk.java.net (William Kemper) Date: Fri, 29 Oct 2021 21:48:45 GMT Subject: RFR: Fix preempt old preparation In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 21:35:14 GMT, Kelvin Nilsen wrote: > To address crashes found following integration of "preempt old preparation", several fixes have been implemented: > > 1. Defer mixed evacuations until after coalesce-and-fill is done > 2. Fix verification of remembered set to use the marking context whenever old-gen is in the process of preparing for mixed evacuations. > 3. Cosmetic improvement to change "misleading" function names. Looks good to me. ------------- Marked as reviewed by wkemper (Committer). PR: https://git.openjdk.java.net/shenandoah/pull/96 From zgu at openjdk.java.net Sat Oct 30 13:03:28 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Sat, 30 Oct 2021 13:03:28 GMT Subject: RFR: 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Message-ID: There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point. Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion. The solution is to consult concurrent_mark_in_progress flag when selects degen-point. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/6179/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6179&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276201 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6179/head:pull/6179 PR: https://git.openjdk.java.net/jdk/pull/6179