From zgu at openjdk.java.net  Wed Jan  5 18:53:28 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 5 Jan 2022 18:53:28 GMT
Subject: RFR: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
Message-ID: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>

A trivial patch to remove unused always_true variable.

Test:
- [x] Built on Linux x86_64

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

Commit messages:
 - Merge branch 'master' into JDK-8279168-unused-always_true
 - 8279168: Shenandoah: Remove unused always_true in ShenandoahRootAdjuster::roots_do()

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

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

From shade at openjdk.java.net  Wed Jan  5 18:53:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 18:53:28 GMT
Subject: RFR: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
In-Reply-To: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
References: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
Message-ID: <xQdF8XhpdtGOyFNv5OEFiSj51DiaYHTH09f3CbNy8_A=.fb7b0f35-ea06-4d46-b3ce-7661dd7b2898@github.com>

On Wed, 22 Dec 2021 15:12:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> A trivial patch to remove unused always_true variable.
> 
> Test:
> - [x] Built on Linux x86_64

This PR is still "draft", intended?

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

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

From gnu.andrew at redhat.com  Wed Jan  5 18:57:42 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 5 Jan 2022 18:57:42 +0000
Subject: [RFR] [8u] 8u322-b01 Upstream Sync
In-Reply-To: <90e6289d-798f-2658-ae2d-d06e474935bf@redhat.com>
References: <YbqNhyatmcIcHV8a@hex.discworld.ac.uk>
 <90e6289d-798f-2658-ae2d-d06e474935bf@redhat.com>
Message-ID: <YdXqJu5oBHMxrHRL@hex.discworld.ac.uk>

On 14:30 Tue 21 Dec     , Aleksey Shipilev wrote:
> On 12/16/21 1:51 AM, Andrew Hughes wrote:
> > Merge changesets:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jaxws/merge.changeset
> 
> Looks trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/jdk/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/hotspot/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b01/root/merge.changeset
> 
> Looks trivially fine.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

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

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

From shade at openjdk.java.net  Wed Jan  5 19:01:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 19:01:16 GMT
Subject: RFR: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
In-Reply-To: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
References: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
Message-ID: <cojt5G9PeeUSxOKQdPFmioOJHmLycE4V3clBniMNOBI=.c6264082-9b27-4c55-9735-90ec2d46b5a0@github.com>

On Wed, 22 Dec 2021 15:12:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> A trivial patch to remove unused always_true variable.
> 
> Test:
> - [x] Built on Linux x86_64

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Wed Jan  5 19:16:14 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 5 Jan 2022 19:16:14 GMT
Subject: Integrated: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
In-Reply-To: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
References: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
Message-ID: <edvt3rToVK8WEW_XqJfTj0EV5-1E-I6d8oR6tf41nY4=.0f8b1ec4-6211-427f-9489-79a28fb2588b@github.com>

On Wed, 22 Dec 2021 15:12:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> A trivial patch to remove unused always_true variable.
> 
> Test:
> - [x] Built on Linux x86_64

This pull request has now been integrated.

Changeset: 7b429a64
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b429a64ce7def84833de9e95217f303d9a7629d
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8279168: Shenandoah: Remove unused always_true in ShenandoahRootAdjuster::roots_do()

Reviewed-by: shade

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

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

From gnu.andrew at redhat.com  Thu Jan  6 01:37:58 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 6 Jan 2022 01:37:58 +0000
Subject: [RFR] [8u] 8u322-b02 Upstream Sync
Message-ID: <YdZH9oC+RtD1drGc@hex.discworld.ac.uk>

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

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

Changes in aarch64-shenandoah-jdk8u322-b02:
  - JDK-8011541: [TEST_BUG] closed/javax/swing/plaf/metal/MetalUtils/bug6190373.java fails NPE since 7u25b03
  - JDK-8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
  - JDK-8041928: MouseEvent.getModifiersEx gives wrong result
  - JDK-8042199: The build of J2DBench via makefile is broken after the JDK-8005402
  - JDK-8044365: (dc) MulticastSendReceiveTests.java failing with ENOMEM when joining group (OS X 10.9)
  - JDK-8060027: Tests java/beans/XMLEncoder/Test4903007.java and java/beans/XMLEncoder/java_awt_GridBagLayout.java
  - JDK-8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS
  - JDK-8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated
  - JDK-8147051: StaxEntityResolverWrapper should create StaxXMLInputSource with a resolver indicator
  - JDK-8148915: Intermittent failures of bug6400879.java
  - JDK-8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride
  - JDK-8196572: Tests ColConvCCMTest.java and MTColConvTest.java fail
  - JDK-8220150: macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
  - JDK-8231254: (fs) Add test for macOS Catalina changes to protect system software
  - JDK-8232178: MacVolumesTest failed after upgrade to MacOS Catalina
  - JDK-8235153: [TESTBUG] [macos 10.15] java/awt/Graphics/DrawImageBG/SystemBgColorTest.java fails
  - JDK-8273826: Correct Manifest file name and NPE checks
  - JDK-8274595: DisableRMIOverHTTPTest failed: connection refused
  - JDK-8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST

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

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

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

diffstat for jaxp
 b/.hgtags                                                                 |    1 
 b/src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java |    2 
 b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java       |    6 +-
 b/src/com/sun/xml/internal/stream/StaxEntityResolverWrapper.java          |    6 +-
 b/src/com/sun/xml/internal/stream/StaxXMLInputSource.java                 |   21 +++-------
 5 files changed, 17 insertions(+), 19 deletions(-)

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

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

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

diffstat for jdk
 b/.hgtags                                                                         |    1 
 b/src/share/classes/java/beans/XMLEncoder.java                                    |   12 
 b/src/share/classes/java/util/jar/JarFile.java                                    |    2 
 b/src/share/classes/java/util/jar/JarInputStream.java                             |    2 
 b/src/share/classes/java/util/jar/JarVerifier.java                                |    2 
 b/src/share/classes/sun/font/FontStrikeDesc.java                                  |   20 
 b/src/share/classes/sun/font/FontUtilities.java                                   |   20 
 b/src/share/classes/sun/java2d/SunGraphics2D.java                                 |    5 
 b/src/share/classes/sun/java2d/SurfaceData.java                                   |    7 
 b/src/share/classes/sun/misc/InnocuousThread.java                                 |   10 
 b/src/share/classes/sun/net/www/http/HttpClient.java                              |    2 
 b/src/share/classes/sun/net/www/protocol/https/HttpsClient.java                   |    2 
 b/src/share/classes/sun/security/util/ManifestEntryVerifier.java                  |   21 
 b/src/share/demo/java2d/J2DBench/Makefile                                         |    7 
 b/src/share/demo/java2d/J2DBench/README                                           |   13 
 b/src/share/demo/java2d/J2DBench/build.xml                                        |    2 
 b/src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java             |   28 -
 b/src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java  |  152 ++---
 b/src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java  |    7 
 b/src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/EmbeddedProfileTests.java |   30 -
 b/src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java         |   12 
 b/src/solaris/native/java/util/TimeZone_md.c                                      |   19 
 b/src/solaris/native/sun/nio/ch/Net.c                                             |   16 
 b/src/windows/native/sun/windows/awt_Component.cpp                                |    3 
 b/test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java                       |   28 -
 b/test/java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java     |   15 
 b/test/java/awt/SplashScreen/GenerateTestImage.java                               |   15 
 b/test/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java   |  268 ++++++++++
 b/test/java/beans/XMLEncoder/ReferenceToNonStaticField.java                       |  164 ++++++
 b/test/java/nio/file/etc/MacVolumesTest.java                                      |  204 +++++++
 b/test/java/util/TimeZone/Bug8066652.java                                         |   57 ++
 b/test/java/util/TimeZone/Bug8066652.sh                                           |   68 ++
 b/test/javax/sound/sampled/DirectAudio/bug6400879.java                            |   18 
 b/test/javax/swing/JEditorPane/5076514/bug5076514.java                            |   58 ++
 b/test/javax/swing/plaf/metal/MetalUtils/bug6190373.java                          |  110 ++++
 b/test/sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java                          |    6 
 b/test/sun/java2d/loops/RenderToCustomBufferTest.java                             |    2 
 b/test/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java             |  138 +++++
 b/test/sun/net/www/http/RequestMethodCheck/sun/net/www/http/HttpClientAccess.java |   35 +
 b/test/sun/rmi/transport/tcp/DisableRMIOverHttp/DisableRMIOverHTTPTest.java       |    4 
 b/test/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java               |  121 ++++
 41 files changed, 1516 insertions(+), 190 deletions(-)

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

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

Ok to push?

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

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

From zgu at openjdk.java.net  Thu Jan  6 13:34:31 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 6 Jan 2022 13:34:31 GMT
Subject: RFR: 8279540: Shenandoah: Should only clear CLD::_claim_strong mark
 for strong CLD iterations
Message-ID: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>

JDK-8273559 started to use CLD::_claim_other for heap iteration in supporting multi-threaded heap walk. For regular CLD, it still uses CLD::_claim_strong, but for those walks, it clears all claim bits, instead of just _claim_strong bit.

I don't think it is a fatal bug, it just means heap iteration may walk a CLD by multiple workers, which impacts performance.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - 8279540: Shenandoah: Should only clear CLD::_claim_strong mark for strong CLD iterations

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

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

From shade at redhat.com  Thu Jan  6 17:46:00 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 6 Jan 2022 18:46:00 +0100
Subject: [RFR] [8u] 8u322-b02 Upstream Sync
In-Reply-To: <YdZH9oC+RtD1drGc@hex.discworld.ac.uk>
References: <YdZH9oC+RtD1drGc@hex.discworld.ac.uk>
Message-ID: <1f3db9e6-9742-fac8-a96e-394407a6d186@redhat.com>

On 1/6/22 2:37 AM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/corba/merge.changeset

Looks trivially fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/jaxp/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/jaxws/merge.changeset

Looks trivially fine.

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

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/hotspot/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/root/merge.changeset

Look trivially fine.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Fri Jan  7 01:19:26 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 7 Jan 2022 01:19:26 +0000
Subject: [RFR] [8u] 8u322-b02 Upstream Sync
In-Reply-To: <1f3db9e6-9742-fac8-a96e-394407a6d186@redhat.com>
References: <YdZH9oC+RtD1drGc@hex.discworld.ac.uk>
 <1f3db9e6-9742-fac8-a96e-394407a6d186@redhat.com>
Message-ID: <YdeVHrvYIIvVg3Ia@hex.discworld.ac.uk>

On 18:46 Thu 06 Jan     , Aleksey Shipilev wrote:
> On 1/6/22 2:37 AM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/corba/merge.changeset
> 
> Looks trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/jaxp/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/jaxws/merge.changeset
> 
> Looks trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/jdk/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/hotspot/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b02/root/merge.changeset
> 
> Look trivially fine.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

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

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

From shade at openjdk.java.net  Fri Jan  7 10:49:15 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 7 Jan 2022 10:49:15 GMT
Subject: RFR: 8279540: Shenandoah: Should only clear CLD::_claim_strong
 mark for strong CLD iterations
In-Reply-To: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
References: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
Message-ID: <rkhEZiK1n3shwzCMud71ialKQbxHjBqzOzvF_k5MHbo=.5ba310f5-ea84-4ba5-bad9-1d5686a2c559@github.com>

On Thu, 6 Jan 2022 13:27:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8273559 started to use CLD::_claim_other for heap iteration in supporting multi-threaded heap walk. For regular CLD, it still uses CLD::_claim_strong, but for those walks, it clears all claim bits, instead of just _claim_strong bit.
> 
> I don't think it is a fatal bug, it just means heap iteration may walk a CLD by multiple workers, which impacts performance.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks reasonable.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Fri Jan  7 13:37:14 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 7 Jan 2022 13:37:14 GMT
Subject: Integrated: 8279540: Shenandoah: Should only clear CLD::_claim_strong
 mark for strong CLD iterations
In-Reply-To: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
References: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
Message-ID: <6A8D44rBe8lB5hQHUauIwm7c1G3NZdUIqrI0X84FxeM=.8d281597-2171-46b3-85da-5cf53a3fa484@github.com>

On Thu, 6 Jan 2022 13:27:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8273559 started to use CLD::_claim_other for heap iteration in supporting multi-threaded heap walk. For regular CLD, it still uses CLD::_claim_strong, but for those walks, it clears all claim bits, instead of just _claim_strong bit.
> 
> I don't think it is a fatal bug, it just means heap iteration may walk a CLD by multiple workers, which impacts performance.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 4243f4c9
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4243f4c998344e77dccd4d5605e56e869bc8af89
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8279540: Shenandoah: Should only clear CLD::_claim_strong mark for strong CLD iterations

Reviewed-by: shade

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

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

From wkemper at openjdk.java.net  Tue Jan 11 22:23:20 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 11 Jan 2022 22:23:20 GMT
Subject: RFR: Reset top bitmap when region is immediately made into trash
Message-ID: <9mf0shw-fo91wBd20RdFpkpuJwpEADnmmln-kfegCnk=.34669ce4-de23-4f5c-beb6-84a12b06843a@github.com>

Resetting the top bitmap pointer for 100% garbage regions avoids having to clear the bitmap (which is already clear for regions with no live objects).

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

Commit messages:
 - Reset top bitmap when region is immediately made into trash

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

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

From kdnilsen at openjdk.java.net  Wed Jan 12 01:17:04 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 12 Jan 2022 01:17:04 GMT
Subject: RFR: Reset top bitmap when region is immediately made into trash
In-Reply-To: <9mf0shw-fo91wBd20RdFpkpuJwpEADnmmln-kfegCnk=.34669ce4-de23-4f5c-beb6-84a12b06843a@github.com>
References: <9mf0shw-fo91wBd20RdFpkpuJwpEADnmmln-kfegCnk=.34669ce4-de23-4f5c-beb6-84a12b06843a@github.com>
Message-ID: <DjZlNv0KrgL9JcCgpR0KrAzxvQS_X5mX3PWMBGWiI38=.e6acef35-a3da-46de-8860-917cf49d474c@github.com>

On Tue, 11 Jan 2022 22:18:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Resetting the top bitmap pointer for 100% garbage regions avoids having to clear the bitmap (which is already clear for regions with no live objects).

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Wed Jan 12 17:24:09 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 12 Jan 2022 17:24:09 GMT
Subject: Integrated: Reset top bitmap when region is immediately made into
 trash
In-Reply-To: <9mf0shw-fo91wBd20RdFpkpuJwpEADnmmln-kfegCnk=.34669ce4-de23-4f5c-beb6-84a12b06843a@github.com>
References: <9mf0shw-fo91wBd20RdFpkpuJwpEADnmmln-kfegCnk=.34669ce4-de23-4f5c-beb6-84a12b06843a@github.com>
Message-ID: <UsYSlAdex50fumQTYS2cYpUFuhuWi68264ggd0J4ryw=.215bd5dd-256c-493f-b938-83cd9e0ab8e0@github.com>

On Tue, 11 Jan 2022 22:18:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Resetting the top bitmap pointer for 100% garbage regions avoids having to clear the bitmap (which is already clear for regions with no live objects).

This pull request has now been integrated.

Changeset: 3e532346
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/3e532346c1f52d7fc89f8143246920ce0765215d
Stats:     5 lines in 2 files changed: 0 ins; 3 del; 2 mod

Reset top bitmap when region is immediately made into trash

Reviewed-by: kdnilsen

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

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

From kilyukhin at gmail.com  Tue Jan 18 04:32:47 2022
From: kilyukhin at gmail.com (Kirill Ilyukhin)
Date: Tue, 18 Jan 2022 13:32:47 +0900
Subject: Uncollected garbage
In-Reply-To: <CAB944-oHYVYp+zRxkFTzpxTAfsHjbyU8XGQ2RWuCqXPe7PQYGw@mail.gmail.com>
References: <CAB944-ogTvtzO6eeTrO43T8zN9G0AHGkwvn5Y67sOqh10NPqwg@mail.gmail.com>
 <e2071906-856e-0b96-a87c-7f984c10e3b0@redhat.com>
 <CAB944-ou9-XDnb2PF9nbwp3=LXeoDtLFQXPE3HTWrfSCLpZY2w@mail.gmail.com>
 <f53d30df-d428-1192-4e93-66f7e2d724b8@redhat.com>
 <CAB944-rR=LXckyq08yB-s0K4Hyzo+-y3dHpJ9Sbu1i1iYnFNMA@mail.gmail.com>
 <CAB944-oHYVYp+zRxkFTzpxTAfsHjbyU8XGQ2RWuCqXPe7PQYGw@mail.gmail.com>
Message-ID: <CAB944-qqzrQ7yC1vwER=6AW2aMnCrbJR1cqFtNmpjKeVXnHbjg@mail.gmail.com>

Roman, Aleksey,

Could you please reply?

Thank you,
Kirill

On Mon, 27 Dec 2021 at 10:57, Kirill Ilyukhin <kilyukhin at gmail.com> wrote:

> Roman, Aleksey,
>
> I have to accept the "filler object" explanation.
> I could not reproduce the issue on a test server. These int arrays keep
> accumulating but the memory is reclaimed when heap usage reaches 70-80%.
>
> Now the question is why did it take that long to reclaim the memory?
> Before a restart the JVM was running about 2 hours 20 minutes with heap
> usage more than 80%, including ~30 minutes with usage ~90%. Please see the
> GCeasy report in my previous mail.
>
> Thank you,
> Kirill
>
> On Mon, 20 Dec 2021 at 23:29, Kirill Ilyukhin <kilyukhin at gmail.com> wrote:
>
>> Roman, Aleksey,
>>
>> Here is what I got at the moment.
>>
>> Looks like these arrays are really eventually reclaimed, but after more
>> than an hour of high GC activity and nearly 100% CPU usage. Seems a bit
>> late.
>> Please see GCeasy report at
>> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMTIvMjAvLS1nYy4yMDIxLTEyLTExXzA5LTAzLTI5LmxvZy5nei0tMTMtOC0yMg==&channel=WEB
>>
>> int arrays size corresponds to PNG images size. The biggest are:
>> 678x840 - 569,520 elements = 2,278,104 bytes
>> 452x560 - 253,120 elements = 1,012,480 byte
>>
>> Please see full GC log at https://kilyukhin.github.io/gc.awt.image.log.gz
>>
>> I will run with -verbose:gc and get back to you later.
>>
>> Thank you,
>> Kirill
>>
>> On Mon, 20 Dec 2021 at 20:39, Roman Kennke <rkennke at redhat.com> wrote:
>>
>>> > The heap usage is nearly 100% , with these int[] objects occupying
>>> 87%. The
>>> > JVM process consumes ~100% of CPU, most of which is GC trying to free
>>> up
>>> > some memory. Does this fit into "filler objects" explanation?
>>>
>>> Hmm, no, not really.
>>>
>>> AFAIK, those image objects carry their int[] for image data, and they
>>> are accessed by native code, too. Native access to arrays pins the
>>> arrays and their containing region. It seems plausible that frequent
>>> native access to image data prevents those regions from being collected,
>>> at least as long as the region contains one live/reachable image data
>>> array. Eventually, those *should* be reclaimed.
>>>
>>> Can you post heap configuration that is printed by -verbose:gc when
>>> application starts, and also typical size of the int arrays?
>>>
>>> Thanks,
>>> Roman
>>>
>>>

From fdemeloj at redhat.com  Tue Jan 18 05:30:20 2022
From: fdemeloj at redhat.com (Francisco De Melo Junior)
Date: Tue, 18 Jan 2022 00:30:20 -0500
Subject: Uncollected garbage
In-Reply-To: <CAB944-oHYVYp+zRxkFTzpxTAfsHjbyU8XGQ2RWuCqXPe7PQYGw@mail.gmail.com>
References: <CAB944-ogTvtzO6eeTrO43T8zN9G0AHGkwvn5Y67sOqh10NPqwg@mail.gmail.com>
 <e2071906-856e-0b96-a87c-7f984c10e3b0@redhat.com>
 <CAB944-ou9-XDnb2PF9nbwp3=LXeoDtLFQXPE3HTWrfSCLpZY2w@mail.gmail.com>
 <f53d30df-d428-1192-4e93-66f7e2d724b8@redhat.com>
 <CAB944-rR=LXckyq08yB-s0K4Hyzo+-y3dHpJ9Sbu1i1iYnFNMA@mail.gmail.com>
 <CAB944-oHYVYp+zRxkFTzpxTAfsHjbyU8XGQ2RWuCqXPe7PQYGw@mail.gmail.com>
Message-ID: <CAOW2=JA1Uh6GM7ac347=b_TS7USkKgw6hxQdienbiZ=M=HX7BQ@mail.gmail.com>

Fyi here. GCEasy (Ram's tool) might be misleading on Shenandoah since it
does report exactly the degenerate state as full gcs.
Use  https://github.com/openjdk/shenandoah-visualizer and see the actual gc
logs for more acurate information

-Francisco
On Sun, Dec 26, 2021 at 8:58 PM Kirill Ilyukhin <kilyukhin at gmail.com> wrote:

> Roman, Aleksey,
>
> I have to accept the "filler object" explanation.
> I could not reproduce the issue on a test server. These int arrays keep
> accumulating but the memory is reclaimed when heap usage reaches 70-80%.
>
> Now the question is why did it take that long to reclaim the memory? Before
> a restart the JVM was running about 2 hours 20 minutes with heap usage more
> than 80%, including ~30 minutes with usage ~90%. Please see the GCeasy
> report in my previous mail.
>
> Thank you,
> Kirill
>
> On Mon, 20 Dec 2021 at 23:29, Kirill Ilyukhin <kilyukhin at gmail.com> wrote:
>
> > Roman, Aleksey,
> >
> > Here is what I got at the moment.
> >
> > Looks like these arrays are really eventually reclaimed, but after more
> > than an hour of high GC activity and nearly 100% CPU usage. Seems a bit
> > late.
> > Please see GCeasy report at
> >
> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMTIvMjAvLS1nYy4yMDIxLTEyLTExXzA5LTAzLTI5LmxvZy5nei0tMTMtOC0yMg==&channel=WEB
> >
> > int arrays size corresponds to PNG images size. The biggest are:
> > 678x840 - 569,520 elements = 2,278,104 bytes
> > 452x560 - 253,120 elements = 1,012,480 byte
> >
> > Please see full GC log at
> https://kilyukhin.github.io/gc.awt.image.log.gz
> >
> > I will run with -verbose:gc and get back to you later.
> >
> > Thank you,
> > Kirill
> >
> > On Mon, 20 Dec 2021 at 20:39, Roman Kennke <rkennke at redhat.com> wrote:
> >
> >> > The heap usage is nearly 100% , with these int[] objects occupying
> 87%.
> >> The
> >> > JVM process consumes ~100% of CPU, most of which is GC trying to free
> up
> >> > some memory. Does this fit into "filler objects" explanation?
> >>
> >> Hmm, no, not really.
> >>
> >> AFAIK, those image objects carry their int[] for image data, and they
> >> are accessed by native code, too. Native access to arrays pins the
> >> arrays and their containing region. It seems plausible that frequent
> >> native access to image data prevents those regions from being collected,
> >> at least as long as the region contains one live/reachable image data
> >> array. Eventually, those *should* be reclaimed.
> >>
> >> Can you post heap configuration that is printed by -verbose:gc when
> >> application starts, and also typical size of the int arrays?
> >>
> >> Thanks,
> >> Roman
> >>
> >>
>
>

From gnu.andrew at redhat.com  Wed Jan 19 17:28:06 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 Jan 2022 17:28:06 +0000
Subject: [RFR] [8u] 8u322-b03 Upstream Sync
Message-ID: <YehKJuLiXgqfvsj4@hex.discworld.ac.uk>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/

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

Changes in aarch64-shenandoah-jdk8u322-b03:
  - JDK-8048021: Remove @version tag in jaxp repo
  - JDK-8236897: Fix the copyright header for pkcs11gcm2.h

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

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

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

diffstat for jaxp
 b/.hgtags                                                                                         |    1 +
 b/src/com/sun/org/apache/bcel/internal/classfile/JavaClass.java                                   |    1 -
 b/src/com/sun/org/apache/bcel/internal/util/Class2HTML.java                                       |    1 -
 b/src/com/sun/org/apache/bcel/internal/util/ClassPath.java                                        |    1 -
 b/src/com/sun/org/apache/bcel/internal/util/JavaWrapper.java                                      |    1 -
 b/src/com/sun/org/apache/xalan/internal/XalanConstants.java                                       |    1 -
 b/src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java                                  |    1 -
 b/src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java                                |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/AttrImpl.java                                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/AttrNSImpl.java                                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/AttributeMap.java                                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java                                |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/DOMNormalizer.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java                                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/ElementNSImpl.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java                                |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/NodeListCache.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/dom/ParentNode.java                                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/Constants.java                                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/Version.java                                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLNamespaceBinder.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java                                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/BalancedDTDGrammar.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java                                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDDescription.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDLoader.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDProcessor.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidator.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dtd/models/DFAContentModel.java                     |    2 --
 b/src/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java                                |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/SchemaDVFactory.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/ValidationContext.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/util/ByteListImpl.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/Base64BinaryDV.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseDVFactory.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseSchemaDVFactory.java                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/DateDV.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/DateTimeDV.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/DayDV.java                                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/DayTimeDurationDV.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/DoubleDV.java                                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/DurationDV.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/ExtendedSchemaDVFactoryImpl.java              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/FloatDV.java                                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/HexBinaryDV.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/ListDV.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDV.java                                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDayDV.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDVFactoryImpl.java                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/TimeDV.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDecl.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDelegate.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/YearDV.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDV.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDurationDV.java                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/validation/ValidationState.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xpath/regex/CaseInsensitiveMap.java                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/SchemaGrammar.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeDecl.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeGroupDecl.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeUseImpl.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSComplexTypeDecl.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSConstraints.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSDDescription.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSDeclarationPool.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSElementDecl.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java                             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSGroupDecl.java                                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSLoaderImpl.java                                |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSModelGroupImpl.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSModelImpl.java                                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSNotationDecl.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSParticleDecl.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/XSWildcardDecl.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/identity/Field.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/identity/Selector.java                           |    2 --
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/CMBuilder.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/XSAllCM.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMRepeatingLeaf.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMValidator.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/XSDFACM.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/models/XSEmptyCM.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/opti/AttrImpl.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/opti/ElementImpl.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOM.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMImplementation.java                |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMParser.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/StAXSchemaParser.java                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractIDConstraintTraverser.java |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractParticleTraverser.java     |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractTraverser.java             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeGroupTraverser.java       |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeTraverser.java            |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser.java          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDElementTraverser.java              |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDGroupTraverser.java                |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDKeyrefTraverser.java               |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDNotationTraverser.java             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDSimpleTypeTraverser.java           |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDUniqueOrKeyTraverser.java          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDWildcardTraverser.java             |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDocumentInfo.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/LSInputListImpl.java                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/ObjectListImpl.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/ShortListImpl.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/StringListImpl.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/XSGrammarPool.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/XSInputSource.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMap4Types.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMapImpl.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/impl/xs/util/XSObjectListImpl.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java                                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/SchemaValidatorConfiguration.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/UnparsedEntityHandler.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationImpl.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java              |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/EmptyXMLSchema.java                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java      |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java               |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java                |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorImpl.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java  |    1 -
 b/src/com/sun/org/apache/xerces/internal/jaxp/validation/XSGrammarPoolContainer.java              |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/AbstractDOMParser.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/BasicParserConfiguration.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java                  |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/StandardParserConfiguration.java                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XIncludeAwareParserConfiguration.java            |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java                          |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XML11DTDConfiguration.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XML11NonValidatingConfiguration.java             |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XMLDocumentParser.java                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarCachingConfiguration.java              |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarParser.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java                         |    1 -
 b/src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java                                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/DOMUtil.java                                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java                       |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/JAXPNamespaceContextWrapper.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/ParserConfigurationSettings.java                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/StAXInputSource.java                                |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/StAXLocationWrapper.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/SymbolHash.java                                     |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/XML11Char.java                                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java                              |    1 -
 b/src/com/sun/org/apache/xerces/internal/util/XMLChar.java                                        |    1 -
 b/src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java                                 |    1 -
 b/src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java                            |    1 -
 b/src/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/xni/QName.java                                           |    1 -
 b/src/com/sun/org/apache/xerces/internal/xni/XNIException.java                                    |    1 -
 b/src/com/sun/org/apache/xerces/internal/xni/parser/XMLComponentManager.java                      |    1 -
 b/src/com/sun/org/apache/xerces/internal/xni/parser/XMLConfigurationException.java                |    1 -
 b/src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java                       |    4 ----
 b/src/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java                   |    1 -
 b/src/com/sun/org/apache/xerces/internal/xs/datatypes/ByteList.java                               |    1 -
 b/src/com/sun/org/apache/xerces/internal/xs/datatypes/ObjectList.java                             |    1 -
 b/src/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java                            |    1 -
 b/src/com/sun/org/apache/xml/internal/serialize/EncodingInfo.java                                 |    1 -
 b/src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java                            |    1 -
 b/src/com/sun/org/apache/xml/internal/serializer/Encodings.java                                   |    1 -
 b/src/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java                             |    1 -
 b/src/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java                                |    1 -
 b/src/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java                                       |    1 -
 b/src/javax/xml/XMLConstants.java                                                                 |    1 -
 b/src/javax/xml/datatype/DatatypeFactory.java                                                     |    1 -
 b/src/javax/xml/datatype/package.html                                                             |    1 -
 b/src/javax/xml/namespace/QName.java                                                              |    1 -
 b/src/javax/xml/parsers/DocumentBuilderFactory.java                                               |    3 +--
 b/src/javax/xml/parsers/FactoryConfigurationError.java                                            |    2 +-
 b/src/javax/xml/parsers/SAXParserFactory.java                                                     |    3 +--
 b/src/javax/xml/validation/SchemaFactoryFinder.java                                               |    1 -
 b/src/javax/xml/xpath/XPathFactoryFinder.java                                                     |    1 -
 b/src/javax/xml/xpath/package.html                                                                |    1 -
 229 files changed, 4 insertions(+), 235 deletions(-)

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

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

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

diffstat for jdk
 b/.hgtags                                                   |    1 +
 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11gcm2.h |    6 ++++--
 2 files changed, 5 insertions(+), 2 deletions(-)

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

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

Ok to push?

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

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

From kilyukhin at gmail.com  Sat Jan 22 04:55:20 2022
From: kilyukhin at gmail.com (Kirill Ilyukhin)
Date: Sat, 22 Jan 2022 13:55:20 +0900
Subject: Uncollected garbage
In-Reply-To: <CAOW2=JA1Uh6GM7ac347=b_TS7USkKgw6hxQdienbiZ=M=HX7BQ@mail.gmail.com>
References: <CAB944-ogTvtzO6eeTrO43T8zN9G0AHGkwvn5Y67sOqh10NPqwg@mail.gmail.com>
 <e2071906-856e-0b96-a87c-7f984c10e3b0@redhat.com>
 <CAB944-ou9-XDnb2PF9nbwp3=LXeoDtLFQXPE3HTWrfSCLpZY2w@mail.gmail.com>
 <f53d30df-d428-1192-4e93-66f7e2d724b8@redhat.com>
 <CAB944-rR=LXckyq08yB-s0K4Hyzo+-y3dHpJ9Sbu1i1iYnFNMA@mail.gmail.com>
 <CAB944-oHYVYp+zRxkFTzpxTAfsHjbyU8XGQ2RWuCqXPe7PQYGw@mail.gmail.com>
 <CAOW2=JA1Uh6GM7ac347=b_TS7USkKgw6hxQdienbiZ=M=HX7BQ@mail.gmail.com>
Message-ID: <CAB944-qaqoyLHbe8wEbGfCon11=ThNVzdE2TwiFAhgMNPzWmoA@mail.gmail.com>

Francisco,

Thank you for the note.
Would it help if I make a raw GC log file accessible from the internet?

Thank you,
Kirill

On Tue, 18 Jan 2022 at 14:30, Francisco De Melo Junior <fdemeloj at redhat.com>
wrote:

> Fyi here. GCEasy (Ram's tool) might be misleading on Shenandoah since it
> does report exactly the degenerate state as full gcs.
> Use  https://github.com/openjdk/shenandoah-visualizer and see the actual
> gc logs for more acurate information
>
> -Francisco
> On Sun, Dec 26, 2021 at 8:58 PM Kirill Ilyukhin <kilyukhin at gmail.com>
> wrote:
>
>> Roman, Aleksey,
>>
>> I have to accept the "filler object" explanation.
>> I could not reproduce the issue on a test server. These int arrays keep
>> accumulating but the memory is reclaimed when heap usage reaches 70-80%.
>>
>> Now the question is why did it take that long to reclaim the memory?
>> Before
>> a restart the JVM was running about 2 hours 20 minutes with heap usage
>> more
>> than 80%, including ~30 minutes with usage ~90%. Please see the GCeasy
>> report in my previous mail.
>>
>> Thank you,
>> Kirill
>>
>> On Mon, 20 Dec 2021 at 23:29, Kirill Ilyukhin <kilyukhin at gmail.com>
>> wrote:
>>
>> > Roman, Aleksey,
>> >
>> > Here is what I got at the moment.
>> >
>> > Looks like these arrays are really eventually reclaimed, but after more
>> > than an hour of high GC activity and nearly 100% CPU usage. Seems a bit
>> > late.
>> > Please see GCeasy report at
>> >
>> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjEvMTIvMjAvLS1nYy4yMDIxLTEyLTExXzA5LTAzLTI5LmxvZy5nei0tMTMtOC0yMg==&channel=WEB
>> >
>> > int arrays size corresponds to PNG images size. The biggest are:
>> > 678x840 - 569,520 elements = 2,278,104 bytes
>> > 452x560 - 253,120 elements = 1,012,480 byte
>> >
>> > Please see full GC log at
>> https://kilyukhin.github.io/gc.awt.image.log.gz
>> >
>> > I will run with -verbose:gc and get back to you later.
>> >
>> > Thank you,
>> > Kirill
>> >
>> > On Mon, 20 Dec 2021 at 20:39, Roman Kennke <rkennke at redhat.com> wrote:
>> >
>> >> > The heap usage is nearly 100% , with these int[] objects occupying
>> 87%.
>> >> The
>> >> > JVM process consumes ~100% of CPU, most of which is GC trying to
>> free up
>> >> > some memory. Does this fit into "filler objects" explanation?
>> >>
>> >> Hmm, no, not really.
>> >>
>> >> AFAIK, those image objects carry their int[] for image data, and they
>> >> are accessed by native code, too. Native access to arrays pins the
>> >> arrays and their containing region. It seems plausible that frequent
>> >> native access to image data prevents those regions from being
>> collected,
>> >> at least as long as the region contains one live/reachable image data
>> >> array. Eventually, those *should* be reclaimed.
>> >>
>> >> Can you post heap configuration that is printed by -verbose:gc when
>> >> application starts, and also typical size of the int arrays?
>> >>
>> >> Thanks,
>> >> Roman
>> >>
>> >>
>>
>>
>

From stuefe at openjdk.java.net  Sat Jan 22 18:03:27 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 22 Jan 2022 18:03:27 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp where
 possible
Message-ID: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>

JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.

This patch:
- replaces includes of allocation.hpp with allstatic.hpp where appropiate
- fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.

Changes are trivial but onerous. Done partly with a script, partly manually.

Test:
- Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
- GHAs

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

Commit messages:
 - fix copyrights
 - start

Changes: https://git.openjdk.java.net/jdk/pull/7188/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7188&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280503
  Stats: 365 lines in 170 files changed: 32 ins; 0 del; 333 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7188.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7188/head:pull/7188

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

From dholmes at openjdk.java.net  Mon Jan 24 02:35:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 Jan 2022 02:35:09 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <-rdJfr4oGyamt9-FGQZtAWFm1MraLZMpvtA8rxMjaNY=.e5d31b31-4b10-4373-b95b-b5e27c8d4bde@github.com>

On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

src/hotspot/share/cds/archiveUtils.cpp line 44:

> 42: #include "utilities/debug.hpp"
> 43: #include "utilities/formatBuffer.hpp"
> 44: #include "utilities/globalDefinitions.hpp"

Seems unrelated to this issue.

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

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

From dholmes at openjdk.java.net  Mon Jan 24 02:46:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 24 Jan 2022 02:46:06 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <qDG34hBqqcuepYCLBzJcVgIM5OcO5Wy5WD5sA5OhtLQ=.a15f0dd0-e2b1-4f22-b713-420e1f4ba34c@github.com>

On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

Hi Thomas,

Seems okay - hard to validate (and I expect allocation.hpp to be included somewhere in most cases anyway).

Some of the changes seem to have nothing to do with:

-#include "memory/allocation.hpp"
+#include "memory/allStatic.hpp"

? Are these caused by transitive include changes?

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From iklam at openjdk.java.net  Mon Jan 24 04:22:08 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 24 Jan 2022 04:22:08 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <VzkTlSZo8TZMogULk5kKuWYTYv_QYmGKW1k6cvFSbj8=.b167d903-ac36-411e-b052-7ef6ab157aca@github.com>

On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

Looks good to me. I've validated with these builds locally on my machine: linux-x64-debug linux-aarch64-open-debug linux-arm32 linux-ppc64le-debug linux-s390x-debug linux-aarch64-debug linux-arm32-open-debug linux-aarch64-lic

I am running a mach5 job for tier1 + builds-tier5. That should cover most of the builds done by the Oracle CI. I'll post the results when they are ready.

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

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

From iklam at openjdk.java.net  Mon Jan 24 04:26:08 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 24 Jan 2022 04:26:08 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <WZUuz4qSwZtEDqtSRQKIiInvccLFrnsVB83x_S5GxF0=.dbf64086-1d0d-4fab-a828-33339eb6663a@github.com>

On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

BTW, I have some scripts for checking how often a header file is included. See https://github.com/iklam/tools/tree/main/headers

count_hotspot_headers.tcl shows that allocation.hpp was included by 1006 .o files before this fix, and 996 files afterwards, so not a whole lot of reduction. That's because we have over 300 headers that include allocatons.hpp :-)

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

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

From iklam at openjdk.java.net  Mon Jan 24 04:33:07 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 24 Jan 2022 04:33:07 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <VzkTlSZo8TZMogULk5kKuWYTYv_QYmGKW1k6cvFSbj8=.b167d903-ac36-411e-b052-7ef6ab157aca@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <VzkTlSZo8TZMogULk5kKuWYTYv_QYmGKW1k6cvFSbj8=.b167d903-ac36-411e-b052-7ef6ab157aca@github.com>
Message-ID: <nIxqZJGV922CtROq0cXxQo7z-QRvdXtZwgEtZe6MDUY=.b055c8a3-0ab3-49e2-935d-37a64c0fce5f@github.com>

On Mon, 24 Jan 2022 04:18:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I am running a mach5 job for tier1 + builds-tier5. That should cover most of the builds done by the Oracle CI. I'll post the results when they are ready.

Unfortunately I am seeing failures on macos and windows:

macos:

src/hotspot/os/bsd/gc/z/zNUMA_bsd.cpp:25: src/hotspot/share/gc/z/zNUMA.hpp:39:10: error: unknown type name 'uint32_t'

windows:

src\hotspot\os\windows\threadLocalStorage_windows.cpp(34): error C3861: 'assert': identifier not found

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

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

From stuefe at openjdk.java.net  Mon Jan 24 05:32:03 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 24 Jan 2022 05:32:03 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <qDG34hBqqcuepYCLBzJcVgIM5OcO5Wy5WD5sA5OhtLQ=.a15f0dd0-e2b1-4f22-b713-420e1f4ba34c@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <qDG34hBqqcuepYCLBzJcVgIM5OcO5Wy5WD5sA5OhtLQ=.a15f0dd0-e2b1-4f22-b713-420e1f4ba34c@github.com>
Message-ID: <_8EMCIOMzkM7nBVFjxdnC78Hly4vHMpdyxGuMfoyEN8=.ac9263e8-1859-47d0-8c7e-c1669a0367bb@github.com>

On Mon, 24 Jan 2022 02:43:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> 
> Seems okay - hard to validate (and I expect allocation.hpp to be included somewhere in most cases anyway).
> 

It shouldn't, that's the idea of JDK-8249944.

> Some of the changes seem to have nothing to do with:
> 
> -#include "memory/allocation.hpp" +#include "memory/allStatic.hpp"
> 
> ? Are these caused by transitive include changes?
> 

See my comment in code. All places that needed to be fixed.

> Thanks, David

Thanks for the review,

..Thomas

> src/hotspot/share/cds/archiveUtils.cpp line 44:
> 
>> 42: #include "utilities/debug.hpp"
>> 43: #include "utilities/formatBuffer.hpp"
>> 44: #include "utilities/globalDefinitions.hpp"
> 
> Seems unrelated to this issue.

archiveUtils.cpp misses debug.hpp (since it uses assert) and globalDefinitions.hpp (since it uses types from there) but missed these includes. This had been hidden by one of its includes pulling allocation.hpp. Same goes for the other seemingly unrelated fixups: all missing includes hidden by including allocation.hpp

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

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

From stuefe at openjdk.java.net  Mon Jan 24 05:38:09 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 24 Jan 2022 05:38:09 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <WZUuz4qSwZtEDqtSRQKIiInvccLFrnsVB83x_S5GxF0=.dbf64086-1d0d-4fab-a828-33339eb6663a@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <WZUuz4qSwZtEDqtSRQKIiInvccLFrnsVB83x_S5GxF0=.dbf64086-1d0d-4fab-a828-33339eb6663a@github.com>
Message-ID: <mYZJI-3Dp-0WRSvDouHY5NlBskDU1-5AmWWR8hvyMz0=.c6925089-f0df-4ade-b932-4724f6638a4b@github.com>

On Mon, 24 Jan 2022 04:22:34 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> BTW, I have some scripts for checking how often a header file is included. See https://github.com/iklam/tools/tree/main/headers
> 
> count_hotspot_headers.tcl shows that allocation.hpp was included by 1006 .o files before this fix, and 996 files afterwards, so not a whole lot of reduction. That's because we have over 300 headers that include allocatons.hpp :-)

Yes. allocation.hpp could be split up more. E.g. MEMFLAGS and the NMT categories really should live somewhere else, I saw some places where allocation.hpp was included only because of them. StackObj may also be a good candidate for moving to an own small header.

Does your tool tell you include chokepoints, maybe its just one central include pulling in allocation.hpp?

> Unfortunately I am seeing failures on macos and windows:
> 
> macos:
> 
> src/hotspot/os/bsd/gc/z/zNUMA_bsd.cpp:25: src/hotspot/share/gc/z/zNUMA.hpp:39:10: error: unknown type name 'uint32_t'
> 
> windows:
> 
> src\hotspot\os\windows\threadLocalStorage_windows.cpp(34): error C3861: 'assert': identifier not found

Strange, since the GHAs went through. What are your build flags? We should be able to rely on GHAs for builds at least :(

The bugs are easy to fix though. Thanks for testing.

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

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

From stuefe at openjdk.java.net  Mon Jan 24 05:44:50 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 24 Jan 2022 05:44:50 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v2]
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <5hs6tTRypYuz6tjnj501Xk9rW8v7ORsyr_a9osqZye8=.1f674f0e-deb7-4683-9376-b55901fdc27b@github.com>

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

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

  add missing includes for macos, windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7188/files
  - new: https://git.openjdk.java.net/jdk/pull/7188/files/37fd8fdb..2f60b989

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

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

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

From iklam at openjdk.java.net  Mon Jan 24 05:57:08 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 24 Jan 2022 05:57:08 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v2]
In-Reply-To: <5hs6tTRypYuz6tjnj501Xk9rW8v7ORsyr_a9osqZye8=.1f674f0e-deb7-4683-9376-b55901fdc27b@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <5hs6tTRypYuz6tjnj501Xk9rW8v7ORsyr_a9osqZye8=.1f674f0e-deb7-4683-9376-b55901fdc27b@github.com>
Message-ID: <HwcgbX8cIxUg327irLfBFCseUXDNmPRSZRFxutf3N_Q=.371b8776-0c54-4618-aedc-a212449ef819@github.com>

On Mon, 24 Jan 2022 05:44:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
>> 
>> This patch:
>> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
>> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
>> 
>> Changes are trivial but onerous. Done partly with a script, partly manually.
>> 
>> Test:
>> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
>> - GHAs
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing includes for macos, windows

> > BTW, I have some scripts for checking how often a header file is included. See https://github.com/iklam/tools/tree/main/headers
> 
> Does your tool tell you include chokepoints, maybe its just one central include pulling in allocation.hpp?
> 

The whoincludes.tcl script can do that. Unfortunately it tells us that many popular header (such as ostream.hpp that was itself included 976 times) include allocations.hpp.


src/hotspot$ tclsh whoincludes.tcl allocation.hpp| head -20
scanning    997 allocation.hpp
   2 found    976 ostream.hpp
   3 found    960 exceptions.hpp
   4 found    938 atomic.hpp
   5 found    891 memRegion.hpp
   6 found    877 iterator.hpp
   7 found    871 arena.hpp
   8 found    864 mutex.hpp
   9 found    860 growableArray.hpp
  10 found    855 mutexLocker.hpp
  11 found    855 autoRestore.hpp
  12 found    848 padded.hpp
  13 found    841 linkedlist.hpp
  14 found    835 jfrAllocation.hpp
  15 found    832 resourceHash.hpp
  16 found    829 gcUtil.hpp
  17 found    825 threadHeapSampler.hpp
  18 found    825 thread.hpp
  19 found    825 filterQueue.hpp
  20 found    679 symbol.hpp

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

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

From stuefe at openjdk.java.net  Mon Jan 24 06:08:05 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 24 Jan 2022 06:08:05 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v2]
In-Reply-To: <HwcgbX8cIxUg327irLfBFCseUXDNmPRSZRFxutf3N_Q=.371b8776-0c54-4618-aedc-a212449ef819@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <5hs6tTRypYuz6tjnj501Xk9rW8v7ORsyr_a9osqZye8=.1f674f0e-deb7-4683-9376-b55901fdc27b@github.com>
 <HwcgbX8cIxUg327irLfBFCseUXDNmPRSZRFxutf3N_Q=.371b8776-0c54-4618-aedc-a212449ef819@github.com>
Message-ID: <bpM1IB34nH0-MgtZ765iil2wA2jaH_w6O2iQWdXa4cw=.d8c04040-0ad3-4bbd-b0ae-1ed32aa3060d@github.com>

On Mon, 24 Jan 2022 05:54:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > BTW, I have some scripts for checking how often a header file is included. See https://github.com/iklam/tools/tree/main/headers
> > 
> > 
> > Does your tool tell you include chokepoints, maybe its just one central include pulling in allocation.hpp?
> 
> The whoincludes.tcl script can do that. Unfortunately it tells us that many popular header (such as ostream.hpp that was itself included 976 times) include allocations.hpp.
> 
> ```
> src/hotspot$ tclsh whoincludes.tcl allocation.hpp| head -20
> scanning    997 allocation.hpp
>    2 found    976 ostream.hpp
>    3 found    960 exceptions.hpp
>    4 found    938 atomic.hpp
>    5 found    891 memRegion.hpp
>    6 found    877 iterator.hpp
>    7 found    871 arena.hpp
>    8 found    864 mutex.hpp
>    9 found    860 growableArray.hpp
>   10 found    855 mutexLocker.hpp
>   11 found    855 autoRestore.hpp
>   12 found    848 padded.hpp
>   13 found    841 linkedlist.hpp
>   14 found    835 jfrAllocation.hpp
>   15 found    832 resourceHash.hpp
>   16 found    829 gcUtil.hpp
>   17 found    825 threadHeapSampler.hpp
>   18 found    825 thread.hpp
>   19 found    825 filterQueue.hpp
>   20 found    679 symbol.hpp
> ```

That's a useful script. Well, maybe we can break this up a bit more.

BTW, can you send me your configure line for your breaking builds? I'd like to reproduce them locally.

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

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

From stuefe at openjdk.java.net  Mon Jan 24 07:41:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 24 Jan 2022 07:41:44 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v3]
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <6q0y0ZvuU8cTpnKZqZ92m_aqezIzEYH1-q0jdsXGfcs=.6079f777-aa28-4f1e-8fca-87b00a29c488@github.com>

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

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

  Add missing header to zNUMA.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7188/files
  - new: https://git.openjdk.java.net/jdk/pull/7188/files/2f60b989..e2b9b0d6

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

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

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

From stuefe at openjdk.java.net  Mon Jan 24 07:41:45 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 24 Jan 2022 07:41:45 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v2]
In-Reply-To: <5hs6tTRypYuz6tjnj501Xk9rW8v7ORsyr_a9osqZye8=.1f674f0e-deb7-4683-9376-b55901fdc27b@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <5hs6tTRypYuz6tjnj501Xk9rW8v7ORsyr_a9osqZye8=.1f674f0e-deb7-4683-9376-b55901fdc27b@github.com>
Message-ID: <TlU4M189yAjqL9bExyc8pZi5A3aLQdtM_2XEUkDQHzo=.93fd376a-bf91-4314-bb39-42461fbe6283@github.com>

On Mon, 24 Jan 2022 05:44:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
>> 
>> This patch:
>> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
>> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
>> 
>> Changes are trivial but onerous. Done partly with a script, partly manually.
>> 
>> Test:
>> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
>> - GHAs
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add missing includes for macos, windows

Hi Ioi,

I fixed Windows, but cannot test MacOS since I don't have the hardware. Could you please give this another try?

Found out that the reason we don't see failing builds in GHAs is that GHAs build with precompiled headers. We should change this if possible.

Thanks, Thomas

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

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

From iklam at openjdk.java.net  Mon Jan 24 20:36:06 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 24 Jan 2022 20:36:06 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v3]
In-Reply-To: <6q0y0ZvuU8cTpnKZqZ92m_aqezIzEYH1-q0jdsXGfcs=.6079f777-aa28-4f1e-8fca-87b00a29c488@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <6q0y0ZvuU8cTpnKZqZ92m_aqezIzEYH1-q0jdsXGfcs=.6079f777-aa28-4f1e-8fca-87b00a29c488@github.com>
Message-ID: <I9wVmd7-KSC7ASbzmOCrOWiUw2C9DUvPVjsWKmIHYXQ=.9ccc74b1-9569-4f7c-8740-71438215b109@github.com>

On Mon, 24 Jan 2022 07:41:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
>> 
>> This patch:
>> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
>> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
>> 
>> Changes are trivial but onerous. Done partly with a script, partly manually.
>> 
>> Test:
>> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
>> - GHAs
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing header to zNUMA.hpp

All builds in our CI passed.

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

Marked as reviewed by iklam (Reviewer).

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

From stuefe at openjdk.java.net  Tue Jan 25 09:18:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 25 Jan 2022 09:18:44 GMT
Subject: RFR: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible [v3]
In-Reply-To: <I9wVmd7-KSC7ASbzmOCrOWiUw2C9DUvPVjsWKmIHYXQ=.9ccc74b1-9569-4f7c-8740-71438215b109@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
 <6q0y0ZvuU8cTpnKZqZ92m_aqezIzEYH1-q0jdsXGfcs=.6079f777-aa28-4f1e-8fca-87b00a29c488@github.com>
 <I9wVmd7-KSC7ASbzmOCrOWiUw2C9DUvPVjsWKmIHYXQ=.9ccc74b1-9569-4f7c-8740-71438215b109@github.com>
Message-ID: <PTH-PX_tWev9q801TvMOqkiMMQQ4j-LAMrZh4_dMuIw=.ac588d57-3829-40fd-8f65-aa55d1b7957d@github.com>

On Mon, 24 Jan 2022 20:32:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> All builds in our CI passed.

Thanks a lot, Ioi!

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

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

From stuefe at openjdk.java.net  Tue Jan 25 09:18:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 25 Jan 2022 09:18:44 GMT
Subject: Integrated: JDK-8280503: Use allStatic.hpp instead of allocation.hpp
 where possible
In-Reply-To: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
References: <l3-DkrJ8OKRHZ-bBX5j_5ehiWnWXgNJGQsQt8KbUgqo=.bf57dcc1-de3a-45ec-b995-e5d3874d6864@github.com>
Message-ID: <qQZ25tA5r1b8JsxZ3-7NCEJoUXkctOqpZekcfmcEeBA=.9fb81ba2-0576-4c64-897c-6e829b93987e@github.com>

On Sat, 22 Jan 2022 13:33:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> JDK-8249944 moved AllStatic to its own header. We should use that one instead of allocation.hpp where possible to reduce header dependencies.
> 
> This patch:
> - replaces includes of allocation.hpp with allstatic.hpp where appropiate
> - fixes up resulting errors since this changes uncovers missing dependencies. Mainly, missing includes of debug.hpp, of globalDefinitions.hpp, and missing outputStream definitions.
> 
> Changes are trivial but onerous. Done partly with a script, partly manually.
> 
> Test:
> - Checked the build with gtests on Linux x86, x64, minimal, zero, aarch64, for both fastdebug and release. All builds of course without PCH.
> - GHAs

This pull request has now been integrated.

Changeset: 2155afe2
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2155afe2a87d718757b009d712361d7a63946a7f
Stats:     368 lines in 172 files changed: 35 ins; 0 del; 333 mod

8280503: Use allStatic.hpp instead of allocation.hpp where possible

Reviewed-by: dholmes, iklam

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

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

From duke at openjdk.java.net  Tue Jan 25 10:17:06 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 25 Jan 2022 10:17:06 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset
Message-ID: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>

Can I have review on this small change that skips some unnecessary work in cset choosing?

When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

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

Commit messages:
 - 8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

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

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

From shade at openjdk.java.net  Tue Jan 25 16:00:29 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 25 Jan 2022 16:00:29 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <juDGOxh3csV6bgwp7kI1k7TYMIRY9tRh2Iy4PtPOvcg=.95d7c722-cce4-4f83-a6e5-cc4d05bc485e@github.com>

On Tue, 25 Jan 2022 10:10:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

Huh, this might actually work, let me take a closer look.

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

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

From shade at openjdk.java.net  Tue Jan 25 17:03:34 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 25 Jan 2022 17:03:34 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <TQGysh5-mmGcABC04D8J9EUxQ9gXBv20lRc584vfkTc=.2586e021-127e-470b-a7eb-86004efedb4f@github.com>

On Tue, 25 Jan 2022 10:10:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

I am still not quite convinced about the performance gains here -- my point tests show there is slight regression in "Choose Collection Set" (use `-Xlog:gc+stats` to get it, and look at the table before JVM shutdown). Have you have any promising performance data?

Meanwhile, if we do this, I suggest two things:

1) Update the large "logic" comment like this:


  // Therefore, we start by sorting the regions by garbage. Then we unconditionally add the best candidates
  // before we meet min_garbage. Then we add all candidates that fit with a garbage threshold.
  // If max_cset is hit during that phase, we terminate the cset selection. Note that in this scheme,
  // ShenandoahGarbageThreshold is the soft threshold which would be ignored until min_garbage is hit.

2) Assert sorting invariants like this:


    } else if (cur_garbage >= min_garbage) {
      // Min garbage condition satisfied, and the regions left would never meet
      // the garbage threshold, because we sorted by garbage. Can break here.
#ifdef ASSERT
      for (size_t c_idx = idx; c_idx < size; c_idx++) {
        assert(data[c_idx]._region->garbage() <= garbage_threshold, "Sorting invariant");
      }
#endif
      break;
    }

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

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

From shade at redhat.com  Tue Jan 25 17:26:42 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 25 Jan 2022 18:26:42 +0100
Subject: [RFR] [8u] 8u322-b03 Upstream Sync
In-Reply-To: <YehKJuLiXgqfvsj4@hex.discworld.ac.uk>
References: <YehKJuLiXgqfvsj4@hex.discworld.ac.uk>
Message-ID: <88ba6fa3-542d-13ae-53d3-37ebfb6f074a@redhat.com>

On 1/19/22 6:28 PM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/jaxws/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/jdk/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/hotspot/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/root/merge.changeset

All look fine.

> Ok to push?

Yes!


-- 
Thanks,
-Aleksey


From duke at openjdk.java.net  Wed Jan 26 04:37:00 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Wed, 26 Jan 2022 04:37:00 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v2]
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <rSZGoB2sp8JGvYGshdpK78MyEhjvB66DWgs2yf2bTQM=.ce6a9c02-74e5-41cb-b591-24f40d3baaf1@github.com>

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

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

 - Merge branch 'openjdk:master' into JDK-8280579
 - 8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7211/files
  - new: https://git.openjdk.java.net/jdk/pull/7211/files/5b6738c2..cfa75958

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

  Stats: 11257 lines in 643 files changed: 7224 ins; 2232 del; 1801 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7211.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7211/head:pull/7211

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

From duke at openjdk.java.net  Wed Jan 26 04:44:04 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Wed, 26 Jan 2022 04:44:04 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v3]
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <CwlP2mKgPfQPLC3ar29F11RVN2mPEwfdtdBIB9rMfW8=.87dfa753-0cee-41c0-ba6a-4047f2c3bc7e@github.com>

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

Yude Lin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7211/files
  - new: https://git.openjdk.java.net/jdk/pull/7211/files/cfa75958..6aebfea6

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

  Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7211.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7211/head:pull/7211

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

From duke at openjdk.java.net  Wed Jan 26 04:44:05 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Wed, 26 Jan 2022 04:44:05 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v3]
In-Reply-To: <TQGysh5-mmGcABC04D8J9EUxQ9gXBv20lRc584vfkTc=.2586e021-127e-470b-a7eb-86004efedb4f@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
 <TQGysh5-mmGcABC04D8J9EUxQ9gXBv20lRc584vfkTc=.2586e021-127e-470b-a7eb-86004efedb4f@github.com>
Message-ID: <EfRZgMSQUNbpjdZkQF9w0HBDZ6ILPQCQeW3EUv6WpAE=.f58f9bf0-f28f-415f-9a12-55e0bee8002f@github.com>

On Tue, 25 Jan 2022 17:00:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am still not quite convinced about the performance gains here -- my point tests show there is slight regression in "Choose Collection Set" (use `-Xlog:gc+stats` to get it, and look at the table before JVM shutdown). Have you have any promising performance data?
> 

I found this in a small test case where the algorithm would iterate over tens of regions for nothing. With the change the test goes from ~5us to ~1us, measuring the thread cpu time* of the choosing cset loop. I noticed that most of "Choose Collection Set" (which is ~50us) is taken by the sorting work before the loop. So in general the difference wouldn't be noticeable. I simply think it's wasted some time and the change is the more proper way.

Update with the suggested change.

* I put something like this ``clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tp);`` around the loop.

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

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

From gnu.andrew at redhat.com  Wed Jan 26 16:53:10 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 26 Jan 2022 16:53:10 +0000
Subject: [RFR] [8u] 8u322-b03 Upstream Sync
In-Reply-To: <88ba6fa3-542d-13ae-53d3-37ebfb6f074a@redhat.com>
References: <YehKJuLiXgqfvsj4@hex.discworld.ac.uk>
 <88ba6fa3-542d-13ae-53d3-37ebfb6f074a@redhat.com>
Message-ID: <YfF8dp+HrN/QB9YD@hex.discworld.ac.uk>

On 18:26 Tue 25 Jan     , Aleksey Shipilev wrote:
> On 1/19/22 6:28 PM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/jaxws/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/jdk/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/hotspot/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u322-b03/root/merge.changeset
> 
> All look fine.
> 
> > Ok to push?
> 
> Yes!
> 
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks, pushed. I'll proceed to posting the final hg merge of 8u322-b04.

The GitHub repos are now ready:

* https://github.com/openjdk/shenandoah-jdk8u
* https://github.com/openjdk/shenandoah-jdk8u-dev

and I have the changes in my fork:

https://github.com/gnu-andrew/jdk8u/tree/sh-jdk8u

I think the best way to proceed on the GitHub side is just to do a direct
push of the changes from my fork to the new shenandoah-jdk8u tree and
proceed from there, if you're happy to review what is in my fork directly
rather than a PR. That seems the safest way to make sure it is identical
to what we used for our builds.

The changes from 8u upstream are just an import of sh/jdk8u largely
as is [0].  The only changes I made are listed in the comments:
dropping local changes in the auto-generated common/autoconf/generated-configure.sh
(present only due to a different autoconf being used) and
jdk/test/sun/security/tools/jarsigner/warnings/Test.java
(lost 8166432: Bad 8u112 merge of sun/security/tools/jarsigner/warnings/Test.java in
some merge)

b05 & b06 were then clean merges on top (and much easier in Git!)

Let me know if you're ok with this plan or want to proceed another way.

[0] https://github.com/gnu-andrew/jdk8u/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9

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 wkemper at openjdk.java.net  Thu Jan 27 16:58:36 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 27 Jan 2022 16:58:36 GMT
Subject: RFR: Degenerate to marking phase if cancellation detected after final
 mark
Message-ID: <TAM3EG3UMJMo80e9dMduexb6GeQSD-Ce9kUJV_rBSDo=.9a4ab56e-d87f-46f1-b27a-2532c8d2a5eb@github.com>

If an allocation failure occurs between the end of concurrent mark and the start of final mark, then the degenerate cycle resumes from the 'outside of cycle' degenerated point. For other modes, this is merely a performance problem (as described in [JDK-8261093](https://bugs.openjdk.java.net/browse/JDK-8261093)). For the generational mode, this is a correctness problem because the degenerated cycle will swap the remembered set cards again. Because the concurrent marking was incomplete, this could lose information about which cards should be dirty during the degenerated (re) mark.

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

Commit messages:
 - Degenerate to marking phase if cancellation detected after final mark

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

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

From rkennke at openjdk.java.net  Thu Jan 27 17:27:14 2022
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 27 Jan 2022 17:27:14 GMT
Subject: RFR: Degenerate to marking phase if cancellation detected after
 final mark
In-Reply-To: <TAM3EG3UMJMo80e9dMduexb6GeQSD-Ce9kUJV_rBSDo=.9a4ab56e-d87f-46f1-b27a-2532c8d2a5eb@github.com>
References: <TAM3EG3UMJMo80e9dMduexb6GeQSD-Ce9kUJV_rBSDo=.9a4ab56e-d87f-46f1-b27a-2532c8d2a5eb@github.com>
Message-ID: <cQ6K9YM5LnAvVQipQuthTfJPt16pygru0qSSTfk2wHE=.a69c13de-bc66-4721-8485-047b64c7ecd9@github.com>

On Thu, 27 Jan 2022 16:52:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> If an allocation failure occurs between the end of concurrent mark and the start of final mark, then the degenerate cycle resumes from the 'outside of cycle' degenerated point. For other modes, this is merely a performance problem (as described in [JDK-8261093](https://bugs.openjdk.java.net/browse/JDK-8261093)). For the generational mode, this is a correctness problem because the degenerated cycle will swap the remembered set cards again. Because the concurrent marking was incomplete, this could lose information about which cards should be dirty during the degenerated (re) mark.

Looks correct.

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

Marked as reviewed by rkennke (Lead).

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

From wkemper at openjdk.java.net  Thu Jan 27 18:27:05 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 27 Jan 2022 18:27:05 GMT
Subject: Integrated: Degenerate to marking phase if cancellation detected after
 final mark
In-Reply-To: <TAM3EG3UMJMo80e9dMduexb6GeQSD-Ce9kUJV_rBSDo=.9a4ab56e-d87f-46f1-b27a-2532c8d2a5eb@github.com>
References: <TAM3EG3UMJMo80e9dMduexb6GeQSD-Ce9kUJV_rBSDo=.9a4ab56e-d87f-46f1-b27a-2532c8d2a5eb@github.com>
Message-ID: <mt0yA7sbQSH7cMwCiW62-rsgAXqEk37vLu1CuNXOmwc=.f05cfe4f-3cbc-4461-b9b2-0ee9291d4063@github.com>

On Thu, 27 Jan 2022 16:52:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> If an allocation failure occurs between the end of concurrent mark and the start of final mark, then the degenerate cycle resumes from the 'outside of cycle' degenerated point. For other modes, this is merely a performance problem (as described in [JDK-8261093](https://bugs.openjdk.java.net/browse/JDK-8261093)). For the generational mode, this is a correctness problem because the degenerated cycle will swap the remembered set cards again. Because the concurrent marking was incomplete, this could lose information about which cards should be dirty during the degenerated (re) mark.

This pull request has now been integrated.

Changeset: 7d0a45c3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/7d0a45c3fb58db5be86a52feb320a62af69e3cb5
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

Degenerate to marking phase if cancellation detected after final mark

Reviewed-by: rkennke

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

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

From wkemper at openjdk.java.net  Thu Jan 27 18:42:31 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 27 Jan 2022 18:42:31 GMT
Subject: RFR: Update card table when cycle degenerates during root scan
Message-ID: <nCHrljmv1cz8IDjlJoMA-v9k7lsCqTtCXjcdpWj6V4Y=.7dbb8b70-49a2-46b7-b8bf-c4f689f45c2b@github.com>

If the concurrent cycle degenerates during the root scan (after the card table has been swapped), we need to update the _read_ table (used during the STW mark) with any cards written during the transition to the degenerated cycle. Without this change, the remembered set scan on the STW mark will skip old to young pointers created during the transition.

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

Commit messages:
 - Merge dirty write cards when cycle degenerates during root scan

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

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

From kdnilsen at openjdk.java.net  Thu Jan 27 19:12:15 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 27 Jan 2022 19:12:15 GMT
Subject: RFR: Update card table when cycle degenerates during root scan
In-Reply-To: <nCHrljmv1cz8IDjlJoMA-v9k7lsCqTtCXjcdpWj6V4Y=.7dbb8b70-49a2-46b7-b8bf-c4f689f45c2b@github.com>
References: <nCHrljmv1cz8IDjlJoMA-v9k7lsCqTtCXjcdpWj6V4Y=.7dbb8b70-49a2-46b7-b8bf-c4f689f45c2b@github.com>
Message-ID: <x-ip8M69DHR0Z30T7UuCslHhmuKEKa5u3GjKc1Ca3jc=.5856cf59-043c-481b-ada9-c4445043d764@github.com>

On Thu, 27 Jan 2022 18:32:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

> If the concurrent cycle degenerates during the root scan (after the card table has been swapped), we need to update the _read_ table (used during the STW mark) with any cards written during the transition to the degenerated cycle. Without this change, the remembered set scan on the STW mark will skip old to young pointers created during the transition.

Thanks for this fix.

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

Marked as reviewed by kdnilsen (Committer).

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

From wkemper at openjdk.java.net  Thu Jan 27 19:17:16 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 27 Jan 2022 19:17:16 GMT
Subject: Integrated: Update card table when cycle degenerates during root scan
In-Reply-To: <nCHrljmv1cz8IDjlJoMA-v9k7lsCqTtCXjcdpWj6V4Y=.7dbb8b70-49a2-46b7-b8bf-c4f689f45c2b@github.com>
References: <nCHrljmv1cz8IDjlJoMA-v9k7lsCqTtCXjcdpWj6V4Y=.7dbb8b70-49a2-46b7-b8bf-c4f689f45c2b@github.com>
Message-ID: <Xcq3--UDcWbNiim1SGDD1pvph7qk-cuJZGKmsTBVSto=.154fcb9d-a482-442f-8151-727888a3f7e7@github.com>

On Thu, 27 Jan 2022 18:32:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

> If the concurrent cycle degenerates during the root scan (after the card table has been swapped), we need to update the _read_ table (used during the STW mark) with any cards written during the transition to the degenerated cycle. Without this change, the remembered set scan on the STW mark will skip old to young pointers created during the transition.

This pull request has now been integrated.

Changeset: 915bea80
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/915bea80d628b8dd7e448cfdacdb378261f8e07c
Stats:     59 lines in 4 files changed: 59 ins; 0 del; 0 mod

Update card table when cycle degenerates during root scan

Reviewed-by: kdnilsen

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

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

From duke at openjdk.java.net  Fri Jan 28 03:25:08 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Fri, 28 Jan 2022 03:25:08 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v3]
In-Reply-To: <CwlP2mKgPfQPLC3ar29F11RVN2mPEwfdtdBIB9rMfW8=.87dfa753-0cee-41c0-ba6a-4047f2c3bc7e@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
 <CwlP2mKgPfQPLC3ar29F11RVN2mPEwfdtdBIB9rMfW8=.87dfa753-0cee-41c0-ba6a-4047f2c3bc7e@github.com>
Message-ID: <T4YLKC0cKY2cW8ozI2ZqLcIgEnh-P-JATj1KgOcJ0H4=.94c642de-8915-4311-9350-e4a14c89cc4e@github.com>

On Wed, 26 Jan 2022 04:44:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

>> Can I have review on this small change that skips some unnecessary work in cset choosing?
>> 
>> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.
>
> Yude Lin has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

The original code also use new_garbage instead of cur_garbage in the line

if ((new_garbage < min_garbage) || (r->garbage() > garbage_threshold)) {

It puzzles me. There is a slight chance that GC prefers to recycle region with less garbage than more garbage
due to this. I'm not sure that's what we want. As an example:

Suppose we have regions sorted by garbage:

region_garbage=[800k, 700k, 600k, 100k]

And suppose min_garbage=2000k, garbage_threshold=600k

The algorithm will add the 800k region and the 700k region to the cset, then it skips the 600k region,
because now new_garbage=800+700+600>2000 and it will not pass the if check above. However, it will
continue the iteration and add the 100k region to the cset. Why do we do that? As long as the max_cset
condition is satisfied, the more garbage the merrier right? Should we change ``new_garbage`` to ``cur_garbage``?

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

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

From rkennke at redhat.com  Mon Jan 31 19:29:53 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 31 Jan 2022 20:29:53 +0100
Subject: Merge upstream JDK master into openjdk/shenandoah master?
Message-ID: <98dbd6c4-9467-d5fc-d2bc-1252d9b53e32@redhat.com>

Hello Kelvin & William & all,

it is nice to see progress happening to the generational Shenandoah 
project. However, the baseline JDK version seems a bit old by now. What 
do you think about merging mainline JDK master into openjdk/shenandoah 
master soon? If yes, do you want me to do it, or do you think it's 
better that you do it (because you probably know better how to deal with 
conflicts)?

Cheerio,
Roman


From kemperw at amazon.com  Mon Jan 31 19:34:30 2022
From: kemperw at amazon.com (Kemper, William)
Date: Mon, 31 Jan 2022 19:34:30 +0000
Subject: Merge upstream JDK master into openjdk/shenandoah master?
In-Reply-To: <98dbd6c4-9467-d5fc-d2bc-1252d9b53e32@redhat.com>
References: <98dbd6c4-9467-d5fc-d2bc-1252d9b53e32@redhat.com>
Message-ID: <1643657670354.57246@amazon.com>

I'd like to do this. We've got some changes in progress and I'd like to get those completed before merging upstream master. I expect I can get this merge done by the end of the week. How does that sound?
________________________________________
From: Roman Kennke <rkennke at redhat.com>
Sent: Monday, January 31, 2022 11:29 AM
To: shenandoah-dev at openjdk.java.net; Nilsen, Kelvin; Kemper, William
Subject: [EXTERNAL] Merge upstream JDK master into openjdk/shenandoah master?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hello Kelvin & William & all,

it is nice to see progress happening to the generational Shenandoah
project. However, the baseline JDK version seems a bit old by now. What
do you think about merging mainline JDK master into openjdk/shenandoah
master soon? If yes, do you want me to do it, or do you think it's
better that you do it (because you probably know better how to deal with
conflicts)?

Cheerio,
Roman