From rkennke at redhat.com  Tue Feb  1 14:46:22 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 1 Feb 2022 15:46:22 +0100
Subject: Merge upstream JDK master into openjdk/shenandoah master?
In-Reply-To: <1643657670354.57246@amazon.com>
References: <98dbd6c4-9467-d5fc-d2bc-1252d9b53e32@redhat.com>
 <1643657670354.57246@amazon.com>
Message-ID: <4ddffe22-1052-2aaf-c8f6-1bf3433fd58a@redhat.com>

That sounds great!

I usually merge the latest tag, this has undergone some basic testing. 
By the end of the week, this should be jdk-19+8 I think.

Thank you!
Roman

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


From kdnilsen at openjdk.java.net  Tue Feb  1 21:16:59 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 1 Feb 2022 21:16:59 GMT
Subject: RFR: Simplify crossing map implementation
Message-ID: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>

The crossing map maintains a record of the first and last objects
starting within each remembered set card's range of memory addresses.
The previous implementations used bit-shifts.  It was detected during
testing that the c++ compiler was emitting incorrect code in certain
in-line expansions of the register_object() method.  gdb reports that
there are 56 distinct contexts holding the expansion of this function.
This simplified implementation does not exhibit the same broken
behavior.

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

Commit messages:
 - Simplify crossing map implementation

Changes: https://git.openjdk.java.net/shenandoah/pull/107/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=107&range=00
  Stats: 76 lines in 2 files changed: 20 ins; 31 del; 25 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/107.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/107/head:pull/107

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

From wkemper at openjdk.java.net  Tue Feb  1 21:33:39 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 1 Feb 2022 21:33:39 GMT
Subject: RFR: Simplify crossing map implementation
In-Reply-To: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
References: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
Message-ID: <9Sq-Ne1MmsPHrzRhFDN95gEdCGEjQ3_pJi71qwVbnrc=.d7bfc0ab-d166-44c2-81e6-99ee06c531c9@github.com>

On Tue, 1 Feb 2022 21:11:28 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The crossing map maintains a record of the first and last objects
> starting within each remembered set card's range of memory addresses.
> The previous implementations used bit-shifts.  It was detected during
> testing that the c++ compiler was emitting incorrect code in certain
> in-line expansions of the register_object() method.  gdb reports that
> there are 56 distinct contexts holding the expansion of this function.
> This simplified implementation does not exhibit the same broken
> behavior.

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

> 568:   ~ShenandoahCardCluster() {
> 569:     if (object_starts != nullptr)
> 570:       free(object_starts);

I know `ShenandoahCardCluster` is a singleton so this is a nit pick, but we should set `object_starts` to `nullptr` here to avoid double deletes.

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

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

From wkemper at openjdk.java.net  Tue Feb  1 21:38:54 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 1 Feb 2022 21:38:54 GMT
Subject: RFR: Simplify crossing map implementation
In-Reply-To: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
References: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
Message-ID: <7n9_QKn_QUgRLqWwcwCTDMcjVcTka7Z1pL_fFigx_vM=.934eec57-8579-4d91-a678-83d803c39c9d@github.com>

On Tue, 1 Feb 2022 21:11:28 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The crossing map maintains a record of the first and last objects
> starting within each remembered set card's range of memory addresses.
> The previous implementations used bit-shifts.  It was detected during
> testing that the c++ compiler was emitting incorrect code in certain
> in-line expansions of the register_object() method.  gdb reports that
> there are 56 distinct contexts holding the expansion of this function.
> This simplified implementation does not exhibit the same broken
> behavior.

Marked as reviewed by wkemper (Committer).

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

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

From kdnilsen at openjdk.java.net  Tue Feb  1 21:47:05 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 1 Feb 2022 21:47:05 GMT
Subject: RFR: Simplify crossing map implementation [v2]
In-Reply-To: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
References: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
Message-ID: <KtC6xdrCzWXigm_tg_E1RhAH1kqPdF4Kh8682ku4y1o=.81237c1c-ad4f-4c01-b907-678993c1677a@github.com>

> The crossing map maintains a record of the first and last objects
> starting within each remembered set card's range of memory addresses.
> The previous implementations used bit-shifts.  It was detected during
> testing that the c++ compiler was emitting incorrect code in certain
> in-line expansions of the register_object() method.  gdb reports that
> there are 56 distinct contexts holding the expansion of this function.
> This simplified implementation does not exhibit the same broken
> behavior.

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

  Respond to reviewer feedback
  
  null out object_starts reference in ShenandoahCardCluster destructor.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/107/files
  - new: https://git.openjdk.java.net/shenandoah/pull/107/files/b562a0b4..8e94bfbd

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

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

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

From kdnilsen at openjdk.java.net  Tue Feb  1 21:47:06 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 1 Feb 2022 21:47:06 GMT
Subject: RFR: Simplify crossing map implementation [v2]
In-Reply-To: <9Sq-Ne1MmsPHrzRhFDN95gEdCGEjQ3_pJi71qwVbnrc=.d7bfc0ab-d166-44c2-81e6-99ee06c531c9@github.com>
References: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
 <9Sq-Ne1MmsPHrzRhFDN95gEdCGEjQ3_pJi71qwVbnrc=.d7bfc0ab-d166-44c2-81e6-99ee06c531c9@github.com>
Message-ID: <Q7CGOB9DRPpOY2nJhLz3cgaBYtKeS8yr-hSEgQBsj68=.6b0e527c-c42f-4151-b18b-1dbf1a4b0cfc@github.com>

On Tue, 1 Feb 2022 21:30:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer feedback
>>   
>>   null out object_starts reference in ShenandoahCardCluster destructor.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 570:
> 
>> 568:   ~ShenandoahCardCluster() {
>> 569:     if (object_starts != nullptr)
>> 570:       free(object_starts);
> 
> I know `ShenandoahCardCluster` is a singleton so this is a nit pick, but we should set `object_starts` to `nullptr` here to avoid double deletes.

fixed.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  1 22:00:46 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 1 Feb 2022 22:00:46 GMT
Subject: Integrated: Simplify crossing map implementation
In-Reply-To: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
References: <9Fy5eJEO9sKf_T_qKJTjNOPnepXVDjYoCP2AbWSygJc=.651f92eb-3973-454b-9ab1-8d6800f1b73e@github.com>
Message-ID: <HtGujDfKurKmDKNzbpvbZGWsz9pMRfMHOZ0jH0OW4WU=.1f389a96-1937-4509-87fb-43a511c97d55@github.com>

On Tue, 1 Feb 2022 21:11:28 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The crossing map maintains a record of the first and last objects
> starting within each remembered set card's range of memory addresses.
> The previous implementations used bit-shifts.  It was detected during
> testing that the c++ compiler was emitting incorrect code in certain
> in-line expansions of the register_object() method.  gdb reports that
> there are 56 distinct contexts holding the expansion of this function.
> This simplified implementation does not exhibit the same broken
> behavior.

This pull request has now been integrated.

Changeset: e91c55cc
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/e91c55ccd5885e23d4666ab915860a1f61558f94
Stats:     77 lines in 2 files changed: 21 ins; 31 del; 25 mod

Simplify crossing map implementation

Reviewed-by: wkemper

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

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

From wkemper at openjdk.java.net  Tue Feb  1 22:12:50 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 1 Feb 2022 22:12:50 GMT
Subject: RFR: Coalesce and fill objects immediately after final mark
Message-ID: <qY_ZSjZRKIuBgXidgFckanKC3JNr904hDYVriVouobY=.0e71a283-5e15-4e38-93a2-722c96e27080@github.com>

Before this change, an allocation failure during a global concurrent cycle _after_ final mark would resume the degenerate cycle for evacuation. However, the degenerated cycle cleans up unmarked old objects during the marking phase. This scenario would leave pointers from unmarked objects into reclaimed memory and could lead to a crash when scanning the remembered set.

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

Commit messages:
 - Coalesce and fill objects immediately after final mark

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

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

From kdnilsen at openjdk.java.net  Tue Feb  1 22:16:33 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 1 Feb 2022 22:16:33 GMT
Subject: RFR: Coalesce and fill objects immediately after final mark
In-Reply-To: <qY_ZSjZRKIuBgXidgFckanKC3JNr904hDYVriVouobY=.0e71a283-5e15-4e38-93a2-722c96e27080@github.com>
References: <qY_ZSjZRKIuBgXidgFckanKC3JNr904hDYVriVouobY=.0e71a283-5e15-4e38-93a2-722c96e27080@github.com>
Message-ID: <KRLhyzG_XzZn-jmRT1iOhHjYdR5XFqJuJrDLYz5AHDM=.742069f4-a0c7-4150-9933-36bc0a184778@github.com>

On Tue, 1 Feb 2022 22:06:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Before this change, an allocation failure during a global concurrent cycle _after_ final mark would resume the degenerate cycle for evacuation. However, the degenerated cycle cleans up unmarked old objects during the marking phase. This scenario would leave pointers from unmarked objects into reclaimed memory and could lead to a crash when scanning the remembered set.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Tue Feb  1 22:49:38 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 1 Feb 2022 22:49:38 GMT
Subject: Integrated: Coalesce and fill objects immediately after final mark
In-Reply-To: <qY_ZSjZRKIuBgXidgFckanKC3JNr904hDYVriVouobY=.0e71a283-5e15-4e38-93a2-722c96e27080@github.com>
References: <qY_ZSjZRKIuBgXidgFckanKC3JNr904hDYVriVouobY=.0e71a283-5e15-4e38-93a2-722c96e27080@github.com>
Message-ID: <EYMdsIFlHMWk9HeX_-8EeDaiIxQ1lbqBfHTfHvthzAI=.56f6b3ff-f849-4f6d-af09-16898232b8aa@github.com>

On Tue, 1 Feb 2022 22:06:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Before this change, an allocation failure during a global concurrent cycle _after_ final mark would resume the degenerate cycle for evacuation. However, the degenerated cycle cleans up unmarked old objects during the marking phase. This scenario would leave pointers from unmarked objects into reclaimed memory and could lead to a crash when scanning the remembered set.

This pull request has now been integrated.

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

Coalesce and fill objects immediately after final mark

Reviewed-by: kdnilsen

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

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

From wkemper at openjdk.java.net  Thu Feb  3 22:47:58 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 3 Feb 2022 22:47:58 GMT
Subject: RFR: Improve handling of cancellation after final mark
Message-ID: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>

Handle case when gc is cancelled _after_ final mark but _before_ the control thread checks for cancellation. If final mark completes before the cancellation is detected, we can no longer degenerate to the marking phase.

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

Commit messages:
 - Improve handling of cancellation after final mark

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

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

From kdnilsen at openjdk.java.net  Thu Feb  3 23:23:42 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 3 Feb 2022 23:23:42 GMT
Subject: RFR: Improve handling of cancellation after final mark
In-Reply-To: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
References: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
Message-ID: <0LXL0kgqXaUy5_okHBus-DdCnqNTSkRMUC-stEMf5Ho=.cc47e569-7578-4bda-bbbd-cf13cabc7114@github.com>

On Thu, 3 Feb 2022 22:42:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Handle case when gc is cancelled _after_ final mark but _before_ the control thread checks for cancellation. If final mark completes before the cancellation is detected, we can no longer degenerate to the marking phase.

I think this needs a comment to explain how it works.  I'm also confused by the original code, but we don't really need to describe that if we are replacing it.  Would like a comment to clarify how concurrent_mark_in_progress() is still true after we're back from vmop_entry_final_mark(), and then how we assure that the condition that we want has not changed before we check_cancellation_and_abort().

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

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

From wkemper at openjdk.java.net  Fri Feb  4 00:11:08 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 4 Feb 2022 00:11:08 GMT
Subject: RFR: Improve handling of cancellation after final mark [v2]
In-Reply-To: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
References: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
Message-ID: <mc_psbqTtOS9CQgdy5YKhI3kEl9RRxdN253RrJp313s=.b2a79447-a885-4d7a-907c-4e2b5a51a55b@github.com>

> Handle case when gc is cancelled _after_ final mark but _before_ the control thread checks for cancellation. If final mark completes before the cancellation is detected, we can no longer degenerate to the marking phase.

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

  Add clarifying comment

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/109/files
  - new: https://git.openjdk.java.net/shenandoah/pull/109/files/7bba584c..0a332758

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

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

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

From kdnilsen at openjdk.java.net  Fri Feb  4 16:49:43 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 4 Feb 2022 16:49:43 GMT
Subject: RFR: Improve handling of cancellation after final mark [v2]
In-Reply-To: <mc_psbqTtOS9CQgdy5YKhI3kEl9RRxdN253RrJp313s=.b2a79447-a885-4d7a-907c-4e2b5a51a55b@github.com>
References: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
 <mc_psbqTtOS9CQgdy5YKhI3kEl9RRxdN253RrJp313s=.b2a79447-a885-4d7a-907c-4e2b5a51a55b@github.com>
Message-ID: <9WvbbbVBz1tfxVbEFcmDfXJZSVkSkLh2E5F41dGGZKE=.4dc7bf8d-e1e1-40ad-8ec1-4597806cf8aa@github.com>

On Fri, 4 Feb 2022 00:11:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Handle case when gc is cancelled _after_ final mark but _before_ the control thread checks for cancellation. If final mark completes before the cancellation is detected, we can no longer degenerate to the marking phase.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add clarifying comment

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Fri Feb  4 17:02:49 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 4 Feb 2022 17:02:49 GMT
Subject: Integrated: Improve handling of cancellation after final mark
In-Reply-To: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
References: <6QxEFrAVeIfYurwqlcejBCFwWauPNTjOrFzJjgnqoVM=.608b16f6-5170-40e2-a93f-eb5009ce5b75@github.com>
Message-ID: <A9FgFNV37rnfMlsk8SOlizhPh5vjOgLam23uLToUrHU=.74fc3956-0838-4c93-8d12-756e1d69a0c4@github.com>

On Thu, 3 Feb 2022 22:42:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Handle case when gc is cancelled _after_ final mark but _before_ the control thread checks for cancellation. If final mark completes before the cancellation is detected, we can no longer degenerate to the marking phase.

This pull request has now been integrated.

Changeset: b233fe7c
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/b233fe7c6cdbbfb721b5d3b1ef1e4e50a861faff
Stats:     17 lines in 5 files changed: 11 ins; 4 del; 2 mod

Improve handling of cancellation after final mark

Reviewed-by: kdnilsen

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

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

From kdnilsen at openjdk.java.net  Sat Feb  5 01:24:03 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Sat, 5 Feb 2022 01:24:03 GMT
Subject: RFR: Borrow from old gen
Message-ID: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>

This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.

Specific improvements are described in individual commit log messages.

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

Commit messages:
 - Whitespace
 - Fix whitespace and other cosmetics
 - Remove debugging instrumentation
 - Simplify crossing map implementation
 - Restore young-gen->used() and capacities at end of degenerated GC
 - Claim credit for Old and Young GC following GLOBAL/Full GC
 - Fix pad accounting for plab alignment
 - Three changes:
 - Fix argument in instrumentation calls
 - Fix bug in ShenandoahCardCluster::coalesce_objects()
 - ... and 6 more: https://git.openjdk.java.net/shenandoah/compare/b233fe7c...dc8a6654

Changes: https://git.openjdk.java.net/shenandoah/pull/110/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=110&range=00
  Stats: 1473 lines in 33 files changed: 1264 ins; 79 del; 130 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/110.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/110/head:pull/110

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

From wkemper at openjdk.java.net  Mon Feb  7 23:02:40 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 7 Feb 2022 23:02:40 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
Message-ID: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>

On Fri, 4 Feb 2022 22:52:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
> 
> Specific improvements are described in individual commit log messages.

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 341:

> 339:   size_t penultimate_live_memory = get_penultimate_live_memory();
> 340:   double original_cycle_time = avg_cycle_time;
> 341:   if ((penultimate_live_memory < last_live_memory) && (penultimate_live_memory != 0)) {

The heuristic uses an exponentially weighted average for cycle times. The decay factor can be adjusted from the command line. The margin of error for estimating cycle times is also adjusted in response to degenerated cycles or successful concurrent cycles. Perhaps we should have the heuristic also adjust the decay factor? Have we evaluated the results of these changes on a variety of work loads?

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 50:

> 48:   size_t                _used;
> 49:   size_t                _region_count;
> 50:   size_t                _immediate_trash;

Might consider having collection set itself manage these new members through `add_region` API - rather than having similar looking code in each of the heuristics when the collection set is populated.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 120:

> 118:       // GCLABs are for evacuation so we must be in evacuation phase.  If this allocation is successful, increment
> 119:       // the relevant evac_expended rather than used value.
> 120:       allocating_gclab = true;

Do we really need a new parameter here? The information is carried in the type of the allocation request (`req`) which is also passed to `allocate_with_affiliation` (the request goes all the way down to `try_allocate_in`).

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

> 80:   ShenandoahFreeSet(ShenandoahHeap* heap, size_t max_regions);
> 81: 
> 82:   // How many regions dedicated to GC allocations (for evacuation or promotion) are currently free?

I agree with these comments - let's delete the question marks?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 362:

> 360:   // At the end of update references, we perform the following bookkeeping activities:
> 361:   //
> 362:   // 1. Unadjust the capacity within young-gen and old-gen

Does "unadjust" mean we remove the evacuation reserve from the capacity?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 385:

> 383: 
> 384:   size_t _old_evac_reserve;            // Bytes reserved within old-gen to hold evacuated objects from old-gen collection set
> 385:   size_t _old_evac_expended;           // Bytes of old-gen memory expended on old-gen evacuations?

Why do these descriptive comments end with a question mark?

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 394:

> 392:                // the desired PLAB size and retry PLAB allocation to avoid cascading of shared memory allocations.
> 393:                ShenandoahThreadLocalData::set_plab_size(thread, PLAB::min_size());
> 394:                copy = allocate_from_gclab(thread, size);

Should this be `allocate_from_plab` as above?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 253:

> 251: void ShenandoahHeapRegion::make_cset() {
> 252:   shenandoah_assert_heaplocked();
> 253:   // Leave age untouched.  We need to consult the age when we are deciding whether to promote evacuated objects.

Many other state transitions also `reset_age` and I'm not sure it's necessary. Seems sufficient to do it only for `make_trash`.

src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 74:

> 72:         r->reset_age();
> 73:       } else if (ShenandoahHeap::heap()->is_aging_cycle()) {
> 74:         r->increment_age();

Hmm, we used to increment age for every region during final mark, but now we are doing it during final update refs. This means no regions will be aged for cycles that skip evacuation. Is that what we want? this will have the effect of lowering the promotion rate.

src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp line 176:

> 174:   }
> 175: 
> 176:   static void disable_plab_promotions(Thread* thread) {

This looks wrong - shouldn't it set `_plab_allows_promotion` to false here? It's also not clear to me how this relates to the other changes here. When would we disable plab promotion?

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

> 307:           range(1,100)                                                      \
> 308:                                                                             \
> 309:   product(uintx, ShenandoahOldEvacRatioPer128, 16, EXPERIMENTAL,            \

These `Per128` options are evaluated once per cycle? I would just take the floating point hit for a more user friendly percentage.

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

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

From kdnilsen at openjdk.java.net  Mon Feb  7 23:30:40 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 7 Feb 2022 23:30:40 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <RUmEVtI3Y9bhLUmTJr7Lea6L6PYPTkmTZKSz6UX1QVw=.9bbba825-a780-495f-b1e9-2ba0f82cc114@github.com>

On Mon, 7 Feb 2022 21:45:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 362:
> 
>> 360:   // At the end of update references, we perform the following bookkeeping activities:
>> 361:   //
>> 362:   // 1. Unadjust the capacity within young-gen and old-gen
> 
> Does "unadjust" mean we remove the evacuation reserve from the capacity?

We remove the "borrowed memory" from capacity.  But by the time we get to here, we have finished evacuating and updating, so the entirety of the collection set is added back in to the allocation capacity.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 385:
> 
>> 383: 
>> 384:   size_t _old_evac_reserve;            // Bytes reserved within old-gen to hold evacuated objects from old-gen collection set
>> 385:   size_t _old_evac_expended;           // Bytes of old-gen memory expended on old-gen evacuations?
> 
> Why do these descriptive comments end with a question mark?

Thanks for noticing.  I'll change this.

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

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

From kdnilsen at openjdk.java.net  Mon Feb  7 23:36:42 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 7 Feb 2022 23:36:42 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <MKOwBM_OwB_FIAU4Y3CZA-VFj4SWH50bpF4k_jByPv4=.0a832dca-d38b-4fa9-8ff9-d529c6e163b8@github.com>

On Mon, 7 Feb 2022 21:52:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp line 176:
> 
>> 174:   }
>> 175: 
>> 176:   static void disable_plab_promotions(Thread* thread) {
> 
> This looks wrong - shouldn't it set `_plab_allows_promotion` to false here? It's also not clear to me how this relates to the other changes here. When would we disable plab promotion?

Good catch.  I got careless with copy and paste.  Thanks.

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

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

From kdnilsen at openjdk.java.net  Mon Feb  7 23:43:43 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 7 Feb 2022 23:43:43 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <MZtYiiJjRlEe2qvzhK2B7nJ4LHj2CmNYoUUpk-AbaeY=.f6bba6fc-f902-43c0-9897-7e62e260f50f@github.com>

On Mon, 7 Feb 2022 22:08:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 341:
> 
>> 339:   size_t penultimate_live_memory = get_penultimate_live_memory();
>> 340:   double original_cycle_time = avg_cycle_time;
>> 341:   if ((penultimate_live_memory < last_live_memory) && (penultimate_live_memory != 0)) {
> 
> The heuristic uses an exponentially weighted average for cycle times. The decay factor can be adjusted from the command line. The margin of error for estimating cycle times is also adjusted in response to degenerated cycles or successful concurrent cycles. Perhaps we should have the heuristic also adjust the decay factor? Have we evaluated the results of these changes on a variety of work loads?

Exposure to variety of workload conditions is very limited.  All of our work on heuristics needs much more attention.  Maybe we don't want to fiddle with these "quick and dirty" fixes until after we can do more thorough experimentation with different workloads.

One important observation I've made is that being too aggressive with heuristics is more harmful with generational mode than traditional mode.  With traditional mode, being too aggressive means we spend a few more cycles in GC.  With generational mode, it might mean we "starve" old-gen GC, and that might result in degenerated or Full STW pauses.

I'm ok to pull out these heuristic tweaks.  I expect this will all be re-done eventually.  I'm not sure how to deliver the best out-of-box experience to early evaluators.

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

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

From kdnilsen at openjdk.java.net  Mon Feb  7 23:47:37 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 7 Feb 2022 23:47:37 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <aYujc2cMZywYE-7FnPRavZcO8JudAYHGICYR6hUqVN8=.6c31fe32-0d82-4108-afd6-95e4923479c7@github.com>

On Mon, 7 Feb 2022 22:24:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 50:
> 
>> 48:   size_t                _used;
>> 49:   size_t                _region_count;
>> 50:   size_t                _immediate_trash;
> 
> Might consider having collection set itself manage these new members through `add_region` API - rather than having similar looking code in each of the heuristics when the collection set is populated.

This is a good idea.  I'll work on this change.

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

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

From kdnilsen at openjdk.java.net  Mon Feb  7 23:53:38 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 7 Feb 2022 23:53:38 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <6ghDKvoYlCJq6dv7HnBIN5CCt5_ME9fL29NFXH26oss=.06bf4f63-04aa-40de-bc0b-dd4dcbc4f942@github.com>

On Mon, 7 Feb 2022 22:30:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 82:
> 
>> 80:   ShenandoahFreeSet(ShenandoahHeap* heap, size_t max_regions);
>> 81: 
>> 82:   // How many regions dedicated to GC allocations (for evacuation or promotion) are currently free?
> 
> I agree with these comments - let's delete the question marks?

Fixed.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 394:
> 
>> 392:                // the desired PLAB size and retry PLAB allocation to avoid cascading of shared memory allocations.
>> 393:                ShenandoahThreadLocalData::set_plab_size(thread, PLAB::min_size());
>> 394:                copy = allocate_from_gclab(thread, size);
> 
> Should this be `allocate_from_plab` as above?

Yes. Thank you for catching that.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 00:02:36 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 00:02:36 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <VXXSo9oZ-8xMiT_NGCOzv45F6UH1P2wYRO7fdhMM4lo=.91ff07aa-35f4-4d8e-9e59-220da5cd2004@github.com>

On Mon, 7 Feb 2022 22:45:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 253:
> 
>> 251: void ShenandoahHeapRegion::make_cset() {
>> 252:   shenandoah_assert_heaplocked();
>> 253:   // Leave age untouched.  We need to consult the age when we are deciding whether to promote evacuated objects.
> 
> Many other state transitions also `reset_age` and I'm not sure it's necessary. Seems sufficient to do it only for `make_trash`.

This is the only case that was causing me "trouble".  Here are the other scenarios found by grep:
  shenandoahHeap.cpp: 2559: ShenandoahFinalUpdateRefsUpdateRegionStateClosure::heap_region_do()

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 00:25:32 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 00:25:32 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <v4gFJwgYHqOnmXNJuTDyruZ6lOh6E851cizwJhyw6ec=.ece74377-0f9a-4ee6-8605-782fdf56dc0e@github.com>

On Mon, 7 Feb 2022 22:51:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 74:
> 
>> 72:         r->reset_age();
>> 73:       } else if (ShenandoahHeap::heap()->is_aging_cycle()) {
>> 74:         r->increment_age();
> 
> Hmm, we used to increment age for every region during final mark, but now we are doing it during final update refs. This means no regions will be aged for cycles that skip evacuation. Is that what we want? this will have the effect of lowering the promotion rate.

This is a good point.  I guess we can increment age in final_mark for any region that is not placed into the collection set.  In the case that there is sufficient immediate trash that we do not have to evacuate any regions, then all region ages can be incremented.  That would be better.  I'll work on this change.

> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 309:
> 
>> 307:           range(1,100)                                                      \
>> 308:                                                                             \
>> 309:   product(uintx, ShenandoahOldEvacRatioPer128, 16, EXPERIMENTAL,            \
> 
> These `Per128` options are evaluated once per cycle? I would just take the floating point hit for a more user friendly percentage.

That's a good improvement.  I'll work on this.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 00:34:45 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 00:34:45 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
Message-ID: <2k1kpfP1MpeeJulKqXs0BIGYstB89-lDAKCvDTW9klA=.51633a48-4141-4382-adc0-6879b2a329eb@github.com>

On Mon, 7 Feb 2022 22:27:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 120:
> 
>> 118:       // GCLABs are for evacuation so we must be in evacuation phase.  If this allocation is successful, increment
>> 119:       // the relevant evac_expended rather than used value.
>> 120:       allocating_gclab = true;
> 
> Do we really need a new parameter here? The information is carried in the type of the allocation request (`req`) which is also passed to `allocate_with_affiliation` (the request goes all the way down to `try_allocate_in`).

Thank you.  I will change this.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 01:39:34 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 01:39:34 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <aYujc2cMZywYE-7FnPRavZcO8JudAYHGICYR6hUqVN8=.6c31fe32-0d82-4108-afd6-95e4923479c7@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
 <aYujc2cMZywYE-7FnPRavZcO8JudAYHGICYR6hUqVN8=.6c31fe32-0d82-4108-afd6-95e4923479c7@github.com>
Message-ID: <Aj83yuTdGAUq5-NY1Fw9Kebb1O2WWq--pGFBwDp1z3c=.259bf326-b11b-4b3c-8550-02299eddc040@github.com>

On Mon, 7 Feb 2022 23:44:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 50:
>> 
>>> 48:   size_t                _used;
>>> 49:   size_t                _region_count;
>>> 50:   size_t                _immediate_trash;
>> 
>> Might consider having collection set itself manage these new members through `add_region` API - rather than having similar looking code in each of the heuristics when the collection set is populated.
>
> This is a good idea.  I'll work on this change.

This change will be incorporated in next commit.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 02:39:42 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 02:39:42 GMT
Subject: RFR: Borrow from old gen
In-Reply-To: <v4gFJwgYHqOnmXNJuTDyruZ6lOh6E851cizwJhyw6ec=.ece74377-0f9a-4ee6-8605-782fdf56dc0e@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
 <v4gFJwgYHqOnmXNJuTDyruZ6lOh6E851cizwJhyw6ec=.ece74377-0f9a-4ee6-8605-782fdf56dc0e@github.com>
Message-ID: <T_tzafFbAJaGBZs63Zpue7z1K4eAc0VwWzYH4SL8pBg=.91016744-539f-41a8-8dc5-530c9c59cdb6@github.com>

On Tue, 8 Feb 2022 00:21:35 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 74:
>> 
>>> 72:         r->reset_age();
>>> 73:       } else if (ShenandoahHeap::heap()->is_aging_cycle()) {
>>> 74:         r->increment_age();
>> 
>> Hmm, we used to increment age for every region during final mark, but now we are doing it during final update refs. This means no regions will be aged for cycles that skip evacuation. Is that what we want? this will have the effect of lowering the promotion rate.
>
> This is a good point.  I guess we can increment age in final_mark for any region that is not placed into the collection set.  In the case that there is sufficient immediate trash that we do not have to evacuate any regions, then all region ages can be incremented.  That would be better.  I'll work on this change.

It's a bit more complicated than at first glance.  We don't want to increment age before we choose the collection set because that would influence what goes into the collection set.  Also, we don't want the age of the region to be added to the object age when deciding whether to promote until after all the objects in this region have not been evacuaetd during an aging cycle.  I've made a change that implements the desired behavior.  It is basically some special fixup in the case that we short-circuit evacuation.  What do you think?

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 16:22:22 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 16:22:22 GMT
Subject: RFR: Borrow from old gen [v2]
In-Reply-To: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
Message-ID: <fki-aGlplARYRxBLy36UR_kjhoA7Bfh-HqJbb3GXI4A=.b3769c21-7133-4ad8-a640-f186aaeff058@github.com>

> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
> 
> Specific improvements are described in individual commit log messages.

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

  Respond to reviewer feedback

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/110/files
  - new: https://git.openjdk.java.net/shenandoah/pull/110/files/dc8a6654..4129539b

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

  Stats: 140 lines in 24 files changed: 44 ins; 51 del; 45 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/110.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/110/head:pull/110

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

From wkemper at openjdk.java.net  Tue Feb  8 16:34:58 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 16:34:58 GMT
Subject: RFR: Borrow from old gen [v2]
In-Reply-To: <fki-aGlplARYRxBLy36UR_kjhoA7Bfh-HqJbb3GXI4A=.b3769c21-7133-4ad8-a640-f186aaeff058@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <fki-aGlplARYRxBLy36UR_kjhoA7Bfh-HqJbb3GXI4A=.b3769c21-7133-4ad8-a640-f186aaeff058@github.com>
Message-ID: <uIDL1NFdaHWhwWu4kh12O23ZT8t-LWDR8X74uL-RixI=.18a9b121-dfb6-4df9-975a-ab1f3401135b@github.com>

On Tue, 8 Feb 2022 16:22:22 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer feedback

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp line 64:

> 62: }
> 63: 
> 64: #ifdef KELVIN_VERBOSE

Some instrumentation sneaked in here.

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

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

From wkemper at openjdk.java.net  Tue Feb  8 16:42:51 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 16:42:51 GMT
Subject: RFR: Borrow from old gen [v2]
In-Reply-To: <fki-aGlplARYRxBLy36UR_kjhoA7Bfh-HqJbb3GXI4A=.b3769c21-7133-4ad8-a640-f186aaeff058@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <fki-aGlplARYRxBLy36UR_kjhoA7Bfh-HqJbb3GXI4A=.b3769c21-7133-4ad8-a640-f186aaeff058@github.com>
Message-ID: <1GpA5ErtTUNfjlR5wohbISbhq1mIro3WGSwp6lUfnPY=.ea7ffae6-4d92-41a6-8bd3-63c3315e0d59@github.com>

On Tue, 8 Feb 2022 16:22:22 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer feedback

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp line 93:

> 91:   if (ShenandoahHeap::heap()->mode()->is_generational()) {
> 92:     if (ShenandoahHeap::heap()->is_aging_cycle()) {
> 93:       r->decrement_age();

Why are we decreasing the age here? Putting the region in the collection set will call `make_cset` on the region which sets the age to zero.

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

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

From wkemper at openjdk.java.net  Tue Feb  8 16:42:53 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 16:42:53 GMT
Subject: RFR: Borrow from old gen [v2]
In-Reply-To: <MKOwBM_OwB_FIAU4Y3CZA-VFj4SWH50bpF4k_jByPv4=.0a832dca-d38b-4fa9-8ff9-d529c6e163b8@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
 <MKOwBM_OwB_FIAU4Y3CZA-VFj4SWH50bpF4k_jByPv4=.0a832dca-d38b-4fa9-8ff9-d529c6e163b8@github.com>
Message-ID: <MkmD-BUok6ISKLrFLOXPXQ204md5A4nkoYLj510QtLw=.cf612288-8f9f-4a55-bce9-aaafcf3df903@github.com>

On Mon, 7 Feb 2022 23:33:41 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp line 176:
>> 
>>> 174:   }
>>> 175: 
>>> 176:   static void disable_plab_promotions(Thread* thread) {
>> 
>> This looks wrong - shouldn't it set `_plab_allows_promotion` to false here? It's also not clear to me how this relates to the other changes here. When would we disable plab promotion?
>
> Good catch.  I got careless with copy and paste.  Thanks.

I didn't see where this is called. Is the used? Why would we disable plab promotion?

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

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

From wkemper at openjdk.java.net  Tue Feb  8 16:53:50 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 16:53:50 GMT
Subject: RFR: Coalesce and fill dead objects after class unloading
Message-ID: <6Tqg_RmWGWZR06APkq_xYVAyxZITu1mnXJWCX9h9gs4=.1f3da6da-5d3e-4620-bdd5-547b3fd91da1@github.com>

This reverts a recent change to coalesce and fill dead objects immediately after final mark. These objects cannot be filled until after class unloading to support a use case where the LRB needs to access from-space objects. So, rather than coalesce and fill during the concurrent mark phase, we move it to the evacuation phase of a degenerated cycle.

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

Commit messages:
 - Coalesce and fill dead objects after class unloading

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 17:10:48 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 17:10:48 GMT
Subject: RFR: Coalesce and fill dead objects after class unloading
In-Reply-To: <6Tqg_RmWGWZR06APkq_xYVAyxZITu1mnXJWCX9h9gs4=.1f3da6da-5d3e-4620-bdd5-547b3fd91da1@github.com>
References: <6Tqg_RmWGWZR06APkq_xYVAyxZITu1mnXJWCX9h9gs4=.1f3da6da-5d3e-4620-bdd5-547b3fd91da1@github.com>
Message-ID: <uZN1iYwAPs1FIh5-0dXJPcP4XAHM98fTJMDo4Hrjb7I=.c41ab5d9-c01a-44ac-8662-4ce36e4e1b70@github.com>

On Tue, 8 Feb 2022 16:48:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This reverts a recent change to coalesce and fill dead objects immediately after final mark. These objects cannot be filled until after class unloading to support a use case where the LRB needs to access from-space objects. So, rather than coalesce and fill during the concurrent mark phase, we move it to the evacuation phase of a degenerated cycle.

Marked as reviewed by kdnilsen (Committer).

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 17:11:49 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 17:11:49 GMT
Subject: RFR: Borrow from old gen [v2]
In-Reply-To: <v4gFJwgYHqOnmXNJuTDyruZ6lOh6E851cizwJhyw6ec=.ece74377-0f9a-4ee6-8605-782fdf56dc0e@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4xVFgmAiLYdr0QnfEporegxYXj5hwyVBSxUi94cvakI=.7319748e-d1e0-46f6-aee4-c0ba50aa8793@github.com>
 <v4gFJwgYHqOnmXNJuTDyruZ6lOh6E851cizwJhyw6ec=.ece74377-0f9a-4ee6-8605-782fdf56dc0e@github.com>
Message-ID: <-Cu5uTIVentvxzI8-2N44EAtEX5BnGyvQJHGUmJfCO8=.655f2631-ca09-426d-abdb-b1b5756ccc07@github.com>

On Tue, 8 Feb 2022 00:22:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 309:
>> 
>>> 307:           range(1,100)                                                      \
>>> 308:                                                                             \
>>> 309:   product(uintx, ShenandoahOldEvacRatioPer128, 16, EXPERIMENTAL,            \
>> 
>> These `Per128` options are evaluated once per cycle? I would just take the floating point hit for a more user friendly percentage.
>
> That's a good improvement.  I'll work on this.

This has been addressed.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 17:16:48 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 17:16:48 GMT
Subject: RFR: Borrow from old gen [v2]
In-Reply-To: <1GpA5ErtTUNfjlR5wohbISbhq1mIro3WGSwp6lUfnPY=.ea7ffae6-4d92-41a6-8bd3-63c3315e0d59@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <fki-aGlplARYRxBLy36UR_kjhoA7Bfh-HqJbb3GXI4A=.b3769c21-7133-4ad8-a640-f186aaeff058@github.com>
 <1GpA5ErtTUNfjlR5wohbISbhq1mIro3WGSwp6lUfnPY=.ea7ffae6-4d92-41a6-8bd3-63c3315e0d59@github.com>
Message-ID: <hzoeN3bpmd3hpQexKzptw_Rk4atAqpiy-6YZ1YVC47U=.d9807ec5-9583-4962-8e75-ad441abd87d7@github.com>

On Tue, 8 Feb 2022 16:37:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer feedback
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp line 93:
> 
>> 91:   if (ShenandoahHeap::heap()->mode()->is_generational()) {
>> 92:     if (ShenandoahHeap::heap()->is_aging_cycle()) {
>> 93:       r->decrement_age();
> 
> Why are we decreasing the age here? Putting the region in the collection set will call `make_cset` on the region which sets the age to zero.

Sorry.  Thanks for catching this.  This was my "compensation" that I had inserted when I was trying to increment all ages right after final mark.  When I backed out that change, I forgot to remove this.  Gone now.

> src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp line 64:
> 
>> 62: }
>> 63: 
>> 64: #ifdef KELVIN_VERBOSE
> 
> Some instrumentation sneaked in here.

Thanks.  These two methods are now removed with refactoring to account for evacuation reserve inside the add_region() method.

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 17:26:30 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 17:26:30 GMT
Subject: RFR: Borrow from old gen [v3]
In-Reply-To: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
Message-ID: <4D-nPJT6L0oaX5nKtc8eCXunOuoYTd_P77D5X5-tJX4=.865de64a-111f-44b2-ad13-1eb0d6b28b29@github.com>

> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
> 
> Specific improvements are described in individual commit log messages.

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

  Fixup mistakes from previous commit

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/110/files
  - new: https://git.openjdk.java.net/shenandoah/pull/110/files/4129539b..56a27bef

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

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

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

From wkemper at openjdk.java.net  Tue Feb  8 17:48:49 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 17:48:49 GMT
Subject: RFR: Borrow from old gen [v3]
In-Reply-To: <4D-nPJT6L0oaX5nKtc8eCXunOuoYTd_P77D5X5-tJX4=.865de64a-111f-44b2-ad13-1eb0d6b28b29@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
 <4D-nPJT6L0oaX5nKtc8eCXunOuoYTd_P77D5X5-tJX4=.865de64a-111f-44b2-ad13-1eb0d6b28b29@github.com>
Message-ID: <5vOZ5CCvFQ6E14RR1TxbkmIPvdp-PKs3DmEUq24sndM=.8dafd0a6-40be-4cee-b3c7-8fcc690032b2@github.com>

On Tue, 8 Feb 2022 17:26:30 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
>> 
>> Specific improvements are described in individual commit log messages.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixup mistakes from previous commit

Marked as reviewed by wkemper (Committer).

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

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

From wkemper at openjdk.java.net  Tue Feb  8 17:52:45 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 17:52:45 GMT
Subject: Integrated: Coalesce and fill dead objects after class unloading
In-Reply-To: <6Tqg_RmWGWZR06APkq_xYVAyxZITu1mnXJWCX9h9gs4=.1f3da6da-5d3e-4620-bdd5-547b3fd91da1@github.com>
References: <6Tqg_RmWGWZR06APkq_xYVAyxZITu1mnXJWCX9h9gs4=.1f3da6da-5d3e-4620-bdd5-547b3fd91da1@github.com>
Message-ID: <stJyKsI-TCbTf2VL2HpdHAJYxF3YlUGK0njjb2aU3yg=.a64333d6-db81-4008-8661-6baffaa0c38b@github.com>

On Tue, 8 Feb 2022 16:48:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This reverts a recent change to coalesce and fill dead objects immediately after final mark. These objects cannot be filled until after class unloading to support a use case where the LRB needs to access from-space objects. So, rather than coalesce and fill during the concurrent mark phase, we move it to the evacuation phase of a degenerated cycle.

This pull request has now been integrated.

Changeset: c4bafaeb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/c4bafaebea4f85e35c025b2205d7978213ce66e1
Stats:     15 lines in 2 files changed: 8 ins; 7 del; 0 mod

Coalesce and fill dead objects after class unloading

Reviewed-by: kdnilsen

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 17:53:47 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 17:53:47 GMT
Subject: Integrated: Borrow from old gen
In-Reply-To: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
References: <SbtizwnIzuEYE9ivG7GybYy7K0c_c-NsTZXJVSuKbxs=.ace20f50-f473-4f85-9652-df6211f3a8e4@github.com>
Message-ID: <VicVt41xXk3j4u3a5mC1qun9Ugw3MOC01b0-maH-uYw=.a8b0ce8c-f681-4742-b206-f22072c20f01@github.com>

On Fri, 4 Feb 2022 22:52:01 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This commit represents multiple months of incremental performance improvements to allow generational shenandoah to run more efficiently, especially with larger heap sizes and high memory utilization.
> 
> Specific improvements are described in individual commit log messages.

This pull request has now been integrated.

Changeset: e1d15c1f
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/e1d15c1f23d51933f89be2224221af3b5482e87c
Stats:     1450 lines in 36 files changed: 1243 ins; 80 del; 127 mod

Borrow from old gen

Reviewed-by: wkemper

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

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

From wkemper at openjdk.java.net  Tue Feb  8 18:44:01 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 8 Feb 2022 18:44:01 GMT
Subject: RFR: Fix two errors in recent commit
In-Reply-To: <SmDvsRODdIMkyzeT0qSqCiq6U4si3vSz3FLMmoeRRKo=.cdf6ca34-ebb2-4211-9ae5-4c4b0583932b@github.com>
References: <SmDvsRODdIMkyzeT0qSqCiq6U4si3vSz3FLMmoeRRKo=.cdf6ca34-ebb2-4211-9ae5-4c4b0583932b@github.com>
Message-ID: <J9cX_JqpT6h_8Cm635oYTgM729krnM7zo5myMsx_V-s=.00af1275-662c-4953-87ea-1c6baa656b2d@github.com>

On Tue, 8 Feb 2022 18:37:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> 1. An assert expression is missing class qualifier so code will not
>    compile in debug mode
> 2. A minor spelling error in a comment

Marked as reviewed by wkemper (Committer).

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 18:44:01 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 18:44:01 GMT
Subject: RFR: Fix two errors in recent commit
Message-ID: <SmDvsRODdIMkyzeT0qSqCiq6U4si3vSz3FLMmoeRRKo=.cdf6ca34-ebb2-4211-9ae5-4c4b0583932b@github.com>

1. An assert expression is missing class qualifier so code will not
   compile in debug mode
2. A minor spelling error in a comment

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

Commit messages:
 - Fix two errors in recent commit

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

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

From kdnilsen at openjdk.java.net  Tue Feb  8 18:47:35 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 8 Feb 2022 18:47:35 GMT
Subject: Integrated: Fix two errors in recent commit
In-Reply-To: <SmDvsRODdIMkyzeT0qSqCiq6U4si3vSz3FLMmoeRRKo=.cdf6ca34-ebb2-4211-9ae5-4c4b0583932b@github.com>
References: <SmDvsRODdIMkyzeT0qSqCiq6U4si3vSz3FLMmoeRRKo=.cdf6ca34-ebb2-4211-9ae5-4c4b0583932b@github.com>
Message-ID: <xay8TdCWq0Rc4Gh8nhKU8lu409jUcBPoJLiZYUpo3DM=.d65a5de4-2cdb-460f-acfe-83ff126bd0ab@github.com>

On Tue, 8 Feb 2022 18:37:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> 1. An assert expression is missing class qualifier so code will not
>    compile in debug mode
> 2. A minor spelling error in a comment

This pull request has now been integrated.

Changeset: dc9d7d0a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/dc9d7d0ab4a5acc144ab4bba9d4608a29e96cac4
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

Fix two errors in recent commit

Reviewed-by: wkemper

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

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

From gnu.andrew at redhat.com  Wed Feb  9 03:23:32 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 9 Feb 2022 03:23:32 +0000
Subject: [RFR] [8u] 8u322-b0{4,5,6} Upstream Sync
Message-ID: <YgMztDpMajrNN2kF@hex.discworld.ac.uk>

First, the last Mercurial merge:

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

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

Changes in aarch64-shenandoah-jdk8u322-b04:
  - JDK-8274407: (tz) Update Timezone Data to 2021c
  - JDK-8274467: TestZoneInfo310.java fails with tzdata2021b
  - JDK-8274468: TimeZoneTest.java fails with tzdata2021b

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

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

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

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

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

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

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

diffstat for jdk
 b/.hgtags                                               |    1 
 b/make/data/tzdata/VERSION                              |    2 
 b/make/data/tzdata/africa                               |  124 +------
 b/make/data/tzdata/antarctica                           |   29 -
 b/make/data/tzdata/asia                                 |   26 +
 b/make/data/tzdata/australasia                          |  117 ++++++-
 b/make/data/tzdata/backward                             |   11 
 b/make/data/tzdata/europe                               |   20 -
 b/make/data/tzdata/leapseconds                          |    8 
 b/make/data/tzdata/northamerica                         |  266 +++++-----------
 b/make/data/tzdata/southamerica                         |   87 ++---
 b/make/data/tzdata/zone.tab                             |    9 
 b/src/share/classes/sun/util/calendar/ZoneInfoFile.java |    8 
 b/test/java/util/TimeZone/TimeZoneTest.java             |    6 
 b/test/sun/util/calendar/zi/tzdata/VERSION              |    2 
 b/test/sun/util/calendar/zi/tzdata/africa               |  124 +------
 b/test/sun/util/calendar/zi/tzdata/antarctica           |   29 -
 b/test/sun/util/calendar/zi/tzdata/asia                 |   26 +
 b/test/sun/util/calendar/zi/tzdata/australasia          |  117 ++++++-
 b/test/sun/util/calendar/zi/tzdata/backward             |   11 
 b/test/sun/util/calendar/zi/tzdata/europe               |   20 -
 b/test/sun/util/calendar/zi/tzdata/leapseconds          |    8 
 b/test/sun/util/calendar/zi/tzdata/northamerica         |  266 +++++-----------
 b/test/sun/util/calendar/zi/tzdata/southamerica         |   87 ++---
 b/test/sun/util/calendar/zi/tzdata/zone.tab             |    9 
 25 files changed, 608 insertions(+), 805 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?

Secondly, the Shenandoah changes are applied to this tree on top of 8u322-b04
to create (nearly) the same code as explained in my last e-mail. b05 & b06
are then merged on top:

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

Ok to push this to https://github.com/openjdk/shenandoah-jdk8u once I have
direct push access?

Changes in aarch64-shenandoah-jdk8u322-b05:
  - JDK-8275766: (tz) Update Timezone Data to 2021e
  - JDK-8275849: TestZoneInfo310.java fails with tzdata2021e
  - JDK-8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766

Changes in aarch64-shenandoah-jdk8u322-b06:
  - JDK-8264934: Enhance cross VM serialization
  - JDK-8268488: More valuable DerValues
  - JDK-8268494: Better inlining of inlined interfaces
  - JDK-8268512: More content for ContentInfo
  - JDK-8268795: Enhance digests of Jar files
  - JDK-8268801: Improve PKCS attribute handling
  - JDK-8268813: Better String matching
  - JDK-8269151: Better construction of EncryptedPrivateKeyInfo
  - JDK-8269944: Better HTTP transport redux
  - JDK-8270392: Improve String constructions
  - JDK-8270416: Enhance construction of Identity maps
  - JDK-8270492: Better resolution of URIs
  - JDK-8270498: Improve SAX Parser configuration management
  - JDK-8270646: Improved scanning of XML entities
  - JDK-8271962: Better TrueType font loading
  - JDK-8271968: Better canonical naming
  - JDK-8271987: Manifest improved manifest entries
  - JDK-8272014: Better array indexing
  - JDK-8272026: Verify Jar Verification
  - JDK-8272236: Improve serial forms for transport
  - JDK-8272272: Enhance jcmd communication
  - JDK-8272462: Enhance image handling
  - JDK-8273290: Enhance sound handling
  - JDK-8273308: PatternMatchTest.java fails on CI
  - JDK-8273748: Improve Solaris font rendering
  - JDK-8273756: Enhance BMP image support
  - JDK-8273838: Enhanced BMP processing
  - JDK-8273968: JCK javax_xml tests fail in CI

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 redestad at openjdk.java.net  Wed Feb  9 14:06:48 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Feb 2022 14:06:48 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives
Message-ID: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>

I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.

Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904

- Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.

- An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.

- There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

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

Commit messages:
 - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
 - Simplify changes to encodeUTF8
 - Fix little-endian error caught by testing
 - Reduce jumps in the ascii path
 - Remove unused tail_mask
 - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
 - Add more comments, simplify tail branching in AVX512 variant
 - Resolve issues in the precise implementation
 - Add shortMixed micros, cleanups
 - Adjust the countPositives intrinsic to count the bytes exactly.
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/cab59051...2a855eb6

Changes: https://git.openjdk.java.net/jdk/pull/7231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281146
  Stats: 806 lines in 24 files changed: 586 ins; 84 del; 136 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From shade at redhat.com  Wed Feb  9 16:07:43 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 9 Feb 2022 19:07:43 +0300
Subject: [RFR] [8u] 8u322-b0{4,5,6} Upstream Sync
In-Reply-To: <YgMztDpMajrNN2kF@hex.discworld.ac.uk>
References: <YgMztDpMajrNN2kF@hex.discworld.ac.uk>
Message-ID: <7f6b88db-7d3d-c5d3-eefc-0f2bf8890b1e@redhat.com>

On 2/9/22 06:23, Andrew Hughes wrote:
> Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
> ppc64, ppc64le, aarch32 (Zero) & aarch64.
> 
> Ok to push?

OK.

> Secondly, the Shenandoah changes are applied to this tree on top of 8u322-b04
> to create (nearly) the same code as explained in my last e-mail. b05 & b06
> are then merged on top:
> 
> https://github.com/gnu-andrew/jdk8u/tree/sh-jdk8u
> 
> Ok to push this to https://github.com/openjdk/shenandoah-jdk8u once I have
> direct push access?

OK.

-- 
Thanks,
-Aleksey


From wkemper at openjdk.java.net  Wed Feb  9 18:41:20 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 9 Feb 2022 18:41:20 GMT
Subject: RFR: Use active generation,
 rather than young exclusively when preparing for update refs
Message-ID: <elR1yCHQ4QTQ_EbFjx_xGdP2shOySGcTyVQBdp2hfcw=.00c64d0c-aa63-4a6d-9c6a-027ed961172e@github.com>

Without this code, global collections will not function correctly.

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

Commit messages:
 - Use active generation, rather than young exclusively when preparing for update refs

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

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

From kdnilsen at openjdk.java.net  Wed Feb  9 21:51:45 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 9 Feb 2022 21:51:45 GMT
Subject: RFR: Use active generation,
 rather than young exclusively when preparing for update refs
In-Reply-To: <elR1yCHQ4QTQ_EbFjx_xGdP2shOySGcTyVQBdp2hfcw=.00c64d0c-aa63-4a6d-9c6a-027ed961172e@github.com>
References: <elR1yCHQ4QTQ_EbFjx_xGdP2shOySGcTyVQBdp2hfcw=.00c64d0c-aa63-4a6d-9c6a-027ed961172e@github.com>
Message-ID: <kjHzE-Xv-8dbvsNTAggv_wpXc8wzakt901WMU2DpuuE=.5a0e1251-0170-4c66-abc5-8181298c9248@github.com>

On Wed, 9 Feb 2022 18:35:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Without this code, global collections will not function correctly.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Wed Feb  9 23:33:41 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 9 Feb 2022 23:33:41 GMT
Subject: Integrated: Use active generation,
 rather than young exclusively when preparing for update refs
In-Reply-To: <elR1yCHQ4QTQ_EbFjx_xGdP2shOySGcTyVQBdp2hfcw=.00c64d0c-aa63-4a6d-9c6a-027ed961172e@github.com>
References: <elR1yCHQ4QTQ_EbFjx_xGdP2shOySGcTyVQBdp2hfcw=.00c64d0c-aa63-4a6d-9c6a-027ed961172e@github.com>
Message-ID: <__q98Z2gIMRDKPXuCPShDF206vZC_rra0J1V2jxt06k=.af46d9a8-a516-471b-b817-e1b817e4adf8@github.com>

On Wed, 9 Feb 2022 18:35:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Without this code, global collections will not function correctly.

This pull request has now been integrated.

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

Use active generation, rather than young exclusively when preparing for update refs

Reviewed-by: kdnilsen

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

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

From wkemper at openjdk.java.net  Thu Feb 10 16:35:09 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 10 Feb 2022 16:35:09 GMT
Subject: RFR: Fixes for running in non-generational modes
Message-ID: <1KwD0whjXQwOfghJq5ZpvfwRD-O79s78TEDlLBlvBXs=.0a53de13-b6ea-4664-8a0d-7e74c4dc94e5@github.com>

A couple of spots that need to be guarded with a check for generational mode.

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

Commit messages:
 - Fixes for running in non-generational modes

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

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

From kdnilsen at openjdk.java.net  Thu Feb 10 17:37:47 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 10 Feb 2022 17:37:47 GMT
Subject: RFR: Fixes for running in non-generational modes
In-Reply-To: <1KwD0whjXQwOfghJq5ZpvfwRD-O79s78TEDlLBlvBXs=.0a53de13-b6ea-4664-8a0d-7e74c4dc94e5@github.com>
References: <1KwD0whjXQwOfghJq5ZpvfwRD-O79s78TEDlLBlvBXs=.0a53de13-b6ea-4664-8a0d-7e74c4dc94e5@github.com>
Message-ID: <WEGIbMLBRYAp7cQ8HEqBzeVf4sz8iBAcCbhRaja5EOU=.698f7ce6-913b-4048-88d4-e473764c9a92@github.com>

On Thu, 10 Feb 2022 16:29:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A couple of spots that need to be guarded with a check for generational mode.

Thanks for fixing these...

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

Marked as reviewed by kdnilsen (Committer).

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

From mdoerr at openjdk.java.net  Thu Feb 10 17:46:08 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 10 Feb 2022 17:46:08 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <kQIeMXXaN7ec1LcVHEVNHqh0v7rAhWwuUq4HpLzS1js=.8eb9906a-e068-467b-b151-218ae34db944@github.com>

On Wed, 26 Jan 2022 12:51:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Hi Claes, it can get implemented similarly on PPC64: https://github.com/openjdk/jdk/pull/7430
You can integrate it if you prefer that, but better after it got a Review.

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

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

From wkemper at openjdk.java.net  Thu Feb 10 18:12:45 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 10 Feb 2022 18:12:45 GMT
Subject: Integrated: Fixes for running in non-generational modes
In-Reply-To: <1KwD0whjXQwOfghJq5ZpvfwRD-O79s78TEDlLBlvBXs=.0a53de13-b6ea-4664-8a0d-7e74c4dc94e5@github.com>
References: <1KwD0whjXQwOfghJq5ZpvfwRD-O79s78TEDlLBlvBXs=.0a53de13-b6ea-4664-8a0d-7e74c4dc94e5@github.com>
Message-ID: <A8P6pyIA3_EPXMOngAQ-mFYfbnm7rCslwu1ZZk-1JRQ=.dd8da0cc-6677-4194-9116-e9da8f7f9130@github.com>

On Thu, 10 Feb 2022 16:29:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> A couple of spots that need to be guarded with a check for generational mode.

This pull request has now been integrated.

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

Fixes for running in non-generational modes

Reviewed-by: kdnilsen

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

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

From redestad at openjdk.java.net  Fri Feb 11 11:40:07 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 11 Feb 2022 11:40:07 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <phrOwRfOHWB0534sOpCrPyNKtKPblEbmZYHJ6N75hQU=.220ce4be-02ba-4625-ad83-5e04a1be2458@github.com>

On Wed, 26 Jan 2022 12:51:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

> Hi Claes, it can get implemented similarly on PPC64: #7430 You can integrate it if you prefer that, but better after it got a Review.

Hi Martin, perfect!

Ideally we can get all platforms that has a `hasNegatives` intrinsic moved over so we can just switch it over big-bang style: remove the `@IntrinsicCandidate`, avoid contortions to pick the "right" implementation on the Java level based on which intrinsic is available and drop all VM-internal scaffolding for `hasNegatives`. Then it makes perfect sense to fold your patch into this PR, rather than have a tail of follow-ups.

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

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

From redestad at openjdk.java.net  Fri Feb 11 12:11:54 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 11 Feb 2022 12:11:54 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad 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 23 additional commits since the last revision:

 - Merge branch 'master' into count_positives
 - Restore partial vector checks in AVX2 and SSE intrinsic variants
 - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
 - Simplify changes to encodeUTF8
 - Fix little-endian error caught by testing
 - Reduce jumps in the ascii path
 - Remove unused tail_mask
 - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
 - Add more comments, simplify tail branching in AVX512 variant
 - Resolve issues in the precise implementation
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/42073fce...c4bb3612

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/2a855eb6..c4bb3612

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

  Stats: 18287 lines in 533 files changed: 12765 ins; 2983 del; 2539 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From mdoerr at openjdk.java.net  Fri Feb 11 15:38:16 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 11 Feb 2022 15:38:16 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
Message-ID: <TeSpphTYf2qYgZS8OOuE1obj5n5-lE8K9a09Z6QsE5s=.1f13f488-38cd-4632-a31d-9becbe7ae2d2@github.com>

On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - Fix little-endian error caught by testing
>  - Reduce jumps in the ascii path
>  - Remove unused tail_mask
>  - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
>  - Add more comments, simplify tail branching in AVX512 variant
>  - Resolve issues in the precise implementation
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/811eb365...c4bb3612

Hi Claes,
doing it for all platforms and cleaning it up sounds good. My PPC64 contribution is already tested and reviewed. I'll try to find a volunteer for s390 which uses exactly the same algorithm as PPC64.

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

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

From redestad at openjdk.java.net  Fri Feb 11 15:45:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 11 Feb 2022 15:45:10 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
Message-ID: <FD5ToNyofDPRfnDbGlxnLgrcWugJyLC-hU4ISA4bogI=.eb5b81bf-4f76-47ff-8e5e-2d1eb16b0171@github.com>

On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - Fix little-endian error caught by testing
>  - Reduce jumps in the ascii path
>  - Remove unused tail_mask
>  - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
>  - Add more comments, simplify tail branching in AVX512 variant
>  - Resolve issues in the precise implementation
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/690b05fa...c4bb3612

Good! I'm currently reading up on aarch64 asm and trying to port that intrinsic over. It might take some time..

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

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

From lucy at openjdk.java.net  Tue Feb 15 08:29:16 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 15 Feb 2022 08:29:16 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
Message-ID: <hdbQsNLm2usoweGnu_qCOhj6C5e1CLMw2mp9zB5KMVQ=.60c3ab86-dc05-46d9-afe8-f41c1038eb48@github.com>

On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - Fix little-endian error caught by testing
>  - Reduce jumps in the ascii path
>  - Remove unused tail_mask
>  - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
>  - Add more comments, simplify tail branching in AVX512 variant
>  - Resolve issues in the precise implementation
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/d4fb8919...c4bb3612

Hi Claes,
I'm working on the s390 implementation. I hoped to have it ready, but tests are failing. I'll post a PR (similar to Martin's) once I believe my work is worth to be looked at. 

Just for clarification: the return value must be the index of the first negative byte?

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

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

From redestad at openjdk.java.net  Tue Feb 15 10:41:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 15 Feb 2022 10:41:10 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <hdbQsNLm2usoweGnu_qCOhj6C5e1CLMw2mp9zB5KMVQ=.60c3ab86-dc05-46d9-afe8-f41c1038eb48@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
 <hdbQsNLm2usoweGnu_qCOhj6C5e1CLMw2mp9zB5KMVQ=.60c3ab86-dc05-46d9-afe8-f41c1038eb48@github.com>
Message-ID: <I7-qeKjNAXtLbPz6CodawyDO9V3rUZj3dThIV3fZdhU=.6799f1c6-1579-4600-999b-9b39a2f1d39b@github.com>

On Tue, 15 Feb 2022 08:25:29 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Hi Claes, I'm working on the s390 implementation. 

Awesome, thanks!

> 
> Just for clarification: the return value must be the index of the first negative byte?

Yes, or the length if there are no such bytes. 

I've considered (and am still considering) writing the spec of `countPositives` to allow intrinsics to do an early return of a value that is less than the index if it's prohibitively expensive or complicated to implement the intrinsic to be precise in the case where it finds a negative byte. While it must be precise w.r.t. returning the full length if it's all positive bytes, no call site would break if the intrinsic returned 0 or some convenient number less than the first negative index (my first experiments with the x86 intrinsic did it like this, but since the semantics of the intrinsic would then differ from the java code I was asked to try and make it precise). The aarch64 algorithm is proving to be a challenge to work with and I might ask again for some leeway in a first implementation there.

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

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

From lucy at openjdk.java.net  Tue Feb 15 11:24:18 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 15 Feb 2022 11:24:18 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
Message-ID: <G06mbYFS2Yq2nxAgOPyb7WDlcsnFRTb3dhVjf-A0hxY=.4e57344c-2a41-482e-aa7a-cd093501558f@github.com>

On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad 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 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - Fix little-endian error caught by testing
>  - Reduce jumps in the ascii path
>  - Remove unused tail_mask
>  - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
>  - Add more comments, simplify tail branching in AVX512 variant
>  - Resolve issues in the precise implementation
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/cee17570...c4bb3612

Well, with the existing implementations for ppc and s390, I do not see a complexity advantage with a relaxed spec. The code would have to be there anyway. 

When it comes to cost, the worst case would be an array of length n, a loop unroll factor of (u==n) and the first (and only) negative byte at index (n-1). All bytes would then be checked twice. With growing n, the overhead diminishes. After all, you want profile-based stub generation - with actual load matching the profile, of course.

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

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

From redestad at openjdk.java.net  Tue Feb 15 13:45:07 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 15 Feb 2022 13:45:07 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v2]
In-Reply-To: <G06mbYFS2Yq2nxAgOPyb7WDlcsnFRTb3dhVjf-A0hxY=.4e57344c-2a41-482e-aa7a-cd093501558f@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <aEVwA9aHody4Vbk2M3x2KBeJyCv_VuRY2VmQzeI0EHI=.9ce9c90a-44b8-4a93-a732-62f18c3163ac@github.com>
 <G06mbYFS2Yq2nxAgOPyb7WDlcsnFRTb3dhVjf-A0hxY=.4e57344c-2a41-482e-aa7a-cd093501558f@github.com>
Message-ID: <k2MSLiT28qQu5GPEjz_dkEHAHNqdNmUOv0wWDGvlMiY=.cf0e2a97-ac71-4654-990c-1920cd7ce796@github.com>

On Tue, 15 Feb 2022 11:20:55 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Well, with the existing implementations for ppc and s390, I do not see a complexity advantage with a relaxed spec. The code would have to be there anyway.

Same for x86, but we could avoid going into and checking the tail on a negative byte in a vector and instead an early return that returns `N * vector_size` where `N` is the number of vectors we've checked that were all positive. This could save a few ns in some cases.

> 
> When it comes to cost, the worst case would be an array of length n, a loop unroll factor of (u==n) and the first (and only) negative byte at index (n-1). All bytes would then be checked twice. With growing n, the overhead diminishes. After all, you want profile-based stub generation - with actual load matching the profile, of course.

Sounds about right. I've explored the cost of this in a few microbenchmarks. In `StringDecode/-Encode` such double-checking would happen anyhow later on in the java code. So for most of the prominent use such double-checking is performance neutral even in the worst case. 

There are a few places where we don't productively use the count and continue to lean on a `hasNegatives` predicate which calls into `countPositives`. This will mean a small amount of useless computation on certain inputs. For the 16- and 32-byte vectors I've benchmarked extensively on x86 (AVX2) the worst case overhead landed in the vicinity of 20 cycles (7.5-15ns @ 2.4Ghz). Allowing for imprecision _could_ improve a few such corner cases, but I've not found a performance sensitive place where it would really matter.

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

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

From andrew at openjdk.java.net  Tue Feb 15 17:26:47 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:26:47 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag
 aarch64-shenandoah-jdk8u322-b05 for changeset ac89ca95
Message-ID: <43ecd20b-3c8f-4e9e-b914-5b4a312bc689@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:01 +0000

Merge jdk8u322-b05
Changeset: ac89ca95
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:41 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/ac89ca956d86edd2fbe1952ee9e2ee5db9861899


From andrew at openjdk.java.net  Tue Feb 15 17:26:38 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:26:38 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u332-b00 for changeset
 7d3c0bed
Message-ID: <64808807-b09f-4211-9487-a1bcd1bcb9ef@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-02-01 19:54:57 +0000


Changeset: 7d3c0bed
Author:    J. Duke <duke at openjdk.org>
Date:      2021-11-29 07:12:19 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/7d3c0bede34930cadd76644e58bf56f2a83c3d01


From andrew at openjdk.java.net  Tue Feb 15 17:26:41 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:26:41 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag
 aarch64-shenandoah-jdk8u322-b04 for changeset d475f9eb
Message-ID: <2221da1e-91c9-4b7f-bc55-e072a6c5f8fa@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:33 +0000

Merge jdk8u322-b04
Changeset: d475f9eb
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:01 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9


From andrew at openjdk.java.net  Tue Feb 15 17:26:53 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:26:53 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag
 aarch64-shenandoah-jdk8u322-b06 for changeset d56198b0
Message-ID: <c2bdbcd0-a40e-40f3-97ad-12d8d0ceb0e4@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:39 +0000

Merge jdk8u322-b06
Changeset: d56198b0
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:28 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/d56198b0d6f27c09b878c2c52eadc33ab872607d


From andrew at openjdk.java.net  Tue Feb 15 17:26:57 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:26:57 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u322-ga for changeset
 236b800c
Message-ID: <fb761295-1b27-4f80-9ec7-f5198d98a702@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-28 02:05:31 +0000


Changeset: 236b800c
Author:    Andrew Brygin <bae at openjdk.org>
Date:      2021-09-28 13:30:27 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/236b800cf26b8e138c925334371681e6b0a099ab


From andrew at openjdk.java.net  Tue Feb 15 17:27:19 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:27:19 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 4 new changesets
Message-ID: <6dea28b2-299f-4fb9-9664-c72a2e780176@openjdk.org>

Changeset: d475f9eb
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:01 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9

Import of aarch64-shenandoah-jdk8u322-b04

Local changes to common/autoconf/generated-configure.sh and jdk/test/sun/security/tools/jarsigner/warnings/Test.java discarded

- .jcheck/conf
! THIRD_PARTY_README
- corba/.jcheck/conf
! corba/THIRD_PARTY_README
- hotspot/.jcheck/conf
! hotspot/THIRD_PARTY_README
! hotspot/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
+ hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java
+ hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeapRegion.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_interface/GCCause.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_interface/GCName.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/VMOps.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! hotspot/make/bsd/makefiles/gcc.make
! hotspot/make/excludeSrc.make
! hotspot/make/linux/makefiles/gcc.make
! hotspot/make/linux/makefiles/rules.make
! hotspot/make/linux/makefiles/vm.make
! hotspot/make/solaris/makefiles/gcc.make
! hotspot/make/windows/create_obj_files.sh
! hotspot/make/windows/makefiles/vm.make
! hotspot/src/cpu/aarch64/vm/aarch64.ad
! hotspot/src/cpu/aarch64/vm/assembler_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! hotspot/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
+ hotspot/src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp
+ hotspot/src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp
! hotspot/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/templateTable_aarch64.cpp
! hotspot/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! hotspot/src/cpu/x86/vm/assembler_x86.cpp
! hotspot/src/cpu/x86/vm/assembler_x86.hpp
! hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! hotspot/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp
! hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp
! hotspot/src/cpu/x86/vm/macroAssembler_x86.hpp
! hotspot/src/cpu/x86/vm/nativeInst_x86.cpp
! hotspot/src/cpu/x86/vm/nativeInst_x86.hpp
! hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
+ hotspot/src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp
+ hotspot/src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp
! hotspot/src/cpu/x86/vm/stubGenerator_x86_32.cpp
! hotspot/src/cpu/x86/vm/stubGenerator_x86_64.cpp
! hotspot/src/cpu/x86/vm/stubRoutines_x86_32.hpp
! hotspot/src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! hotspot/src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! hotspot/src/cpu/x86/vm/templateTable_x86_32.cpp
! hotspot/src/cpu/x86/vm/templateTable_x86_64.cpp
! hotspot/src/cpu/x86/vm/x86_32.ad
! hotspot/src/cpu/x86/vm/x86_64.ad
! hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp
! hotspot/src/share/vm/adlc/formssel.cpp
! hotspot/src/share/vm/adlc/formssel.hpp
! hotspot/src/share/vm/adlc/output_c.cpp
! hotspot/src/share/vm/adlc/output_h.cpp
! hotspot/src/share/vm/c1/c1_LIR.hpp
! hotspot/src/share/vm/c1/c1_LIRAssembler.cpp
! hotspot/src/share/vm/c1/c1_LIRAssembler.hpp
! hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
! hotspot/src/share/vm/c1/c1_LIRGenerator.hpp
! hotspot/src/share/vm/c1/c1_Runtime1.cpp
! hotspot/src/share/vm/c1/c1_Runtime1.hpp
! hotspot/src/share/vm/ci/ciObjectFactory.cpp
! hotspot/src/share/vm/classfile/classLoaderData.hpp
! hotspot/src/share/vm/classfile/classLoaderStats.hpp
! hotspot/src/share/vm/classfile/javaClasses.cpp
! hotspot/src/share/vm/classfile/symbolTable.cpp
! hotspot/src/share/vm/classfile/symbolTable.hpp
! hotspot/src/share/vm/code/codeCache.cpp
! hotspot/src/share/vm/code/codeCache.hpp
! hotspot/src/share/vm/code/nmethod.cpp
! hotspot/src/share/vm/compiler/oopMap.hpp
! hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! hotspot/src/share/vm/gc_implementation/g1/satbQueue.cpp
! hotspot/src/share/vm/gc_implementation/g1/satbQueue.hpp
+ hotspot/src/share/vm/gc_implementation/shared/markBitMap.cpp
+ hotspot/src/share/vm/gc_implementation/shared/markBitMap.hpp
+ hotspot/src/share/vm/gc_implementation/shared/markBitMap.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/preservedMarks.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/preservedMarks.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/preservedMarks.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahAllocRequest.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetAssembler_stub.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahClosures.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahJfrSupport.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahJfrSupport.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahLogging.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahLogging.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahNumberSeq.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahNumberSeq.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPadding.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupThread.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupThread.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahSynchronizerIterator.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahSynchronizerIterator.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerDataArray.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerDataArray.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerDataArray.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoah_globals.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoah_specialized_oop_closures.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp
! hotspot/src/share/vm/gc_interface/collectedHeap.cpp
! hotspot/src/share/vm/gc_interface/collectedHeap.hpp
! hotspot/src/share/vm/gc_interface/gcCause.cpp
! hotspot/src/share/vm/gc_interface/gcCause.hpp
! hotspot/src/share/vm/gc_interface/gcName.hpp
! hotspot/src/share/vm/jfr/metadata/metadata.xml
! hotspot/src/share/vm/jfr/periodic/jfrPeriodic.cpp
! hotspot/src/share/vm/memory/barrierSet.cpp
! hotspot/src/share/vm/memory/barrierSet.hpp
! hotspot/src/share/vm/memory/barrierSet.inline.hpp
! hotspot/src/share/vm/memory/binaryTreeDictionary.hpp
! hotspot/src/share/vm/memory/metaspace.hpp
! hotspot/src/share/vm/memory/referenceProcessor.cpp
! hotspot/src/share/vm/memory/referenceProcessor.hpp
! hotspot/src/share/vm/memory/specialized_oop_closures.hpp
! hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp
! hotspot/src/share/vm/memory/threadLocalAllocBuffer.hpp
! hotspot/src/share/vm/memory/universe.cpp
! hotspot/src/share/vm/oops/instanceKlass.cpp
! hotspot/src/share/vm/oops/instanceMirrorKlass.cpp
! hotspot/src/share/vm/oops/instanceRefKlass.cpp
! hotspot/src/share/vm/oops/klass.cpp
! hotspot/src/share/vm/oops/klass.hpp
! hotspot/src/share/vm/oops/objArrayKlass.cpp
! hotspot/src/share/vm/oops/objArrayOop.hpp
! hotspot/src/share/vm/oops/oop.hpp
! hotspot/src/share/vm/oops/oop.inline.hpp
! hotspot/src/share/vm/opto/addnode.cpp
! hotspot/src/share/vm/opto/callnode.cpp
! hotspot/src/share/vm/opto/callnode.hpp
! hotspot/src/share/vm/opto/cfgnode.cpp
! hotspot/src/share/vm/opto/cfgnode.hpp
! hotspot/src/share/vm/opto/classes.cpp
! hotspot/src/share/vm/opto/classes.hpp
! hotspot/src/share/vm/opto/compile.cpp
! hotspot/src/share/vm/opto/compile.hpp
! hotspot/src/share/vm/opto/connode.cpp
! hotspot/src/share/vm/opto/connode.hpp
! hotspot/src/share/vm/opto/escape.cpp
! hotspot/src/share/vm/opto/gcm.cpp
! hotspot/src/share/vm/opto/graphKit.cpp
! hotspot/src/share/vm/opto/ifnode.cpp
! hotspot/src/share/vm/opto/lcm.cpp
! hotspot/src/share/vm/opto/library_call.cpp
! hotspot/src/share/vm/opto/loopPredicate.cpp
! hotspot/src/share/vm/opto/loopnode.cpp
! hotspot/src/share/vm/opto/loopnode.hpp
! hotspot/src/share/vm/opto/loopopts.cpp
! hotspot/src/share/vm/opto/machnode.cpp
! hotspot/src/share/vm/opto/machnode.hpp
! hotspot/src/share/vm/opto/macro.cpp
! hotspot/src/share/vm/opto/matcher.cpp
! hotspot/src/share/vm/opto/matcher.hpp
! hotspot/src/share/vm/opto/memnode.cpp
! hotspot/src/share/vm/opto/memnode.hpp
! hotspot/src/share/vm/opto/mulnode.cpp
! hotspot/src/share/vm/opto/multnode.cpp
! hotspot/src/share/vm/opto/multnode.hpp
! hotspot/src/share/vm/opto/node.cpp
! hotspot/src/share/vm/opto/node.hpp
! hotspot/src/share/vm/opto/parse2.cpp
! hotspot/src/share/vm/opto/parse3.cpp
! hotspot/src/share/vm/opto/phaseX.cpp
! hotspot/src/share/vm/opto/runtime.cpp
! hotspot/src/share/vm/opto/runtime.hpp
! hotspot/src/share/vm/opto/subnode.cpp
! hotspot/src/share/vm/opto/superword.cpp
! hotspot/src/share/vm/opto/superword.hpp
! hotspot/src/share/vm/precompiled/precompiled.hpp
! hotspot/src/share/vm/prims/jni.cpp
! hotspot/src/share/vm/prims/jvm.cpp
! hotspot/src/share/vm/prims/jvmtiGetLoadedClasses.cpp
! hotspot/src/share/vm/prims/jvmtiTagMap.cpp
! hotspot/src/share/vm/prims/unsafe.cpp
! hotspot/src/share/vm/runtime/arguments.cpp
! hotspot/src/share/vm/runtime/arguments.hpp
! hotspot/src/share/vm/runtime/fieldDescriptor.hpp
! hotspot/src/share/vm/runtime/globals.cpp
! hotspot/src/share/vm/runtime/globals.hpp
! hotspot/src/share/vm/runtime/globals_extension.hpp
! hotspot/src/share/vm/runtime/jniHandles.cpp
! hotspot/src/share/vm/runtime/mutexLocker.cpp
! hotspot/src/share/vm/runtime/objectMonitor.hpp
! hotspot/src/share/vm/runtime/os.hpp
! hotspot/src/share/vm/runtime/safepoint.cpp
! hotspot/src/share/vm/runtime/sharedRuntime.cpp
! hotspot/src/share/vm/runtime/sharedRuntime.hpp
! hotspot/src/share/vm/runtime/stackValue.cpp
! hotspot/src/share/vm/runtime/synchronizer.hpp
! hotspot/src/share/vm/runtime/thread.cpp
! hotspot/src/share/vm/runtime/thread.hpp
! hotspot/src/share/vm/runtime/thread.inline.hpp
! hotspot/src/share/vm/runtime/vmStructs.cpp
! hotspot/src/share/vm/runtime/vm_operations.hpp
! hotspot/src/share/vm/services/heapDumper.cpp
! hotspot/src/share/vm/services/memoryManager.cpp
! hotspot/src/share/vm/services/memoryManager.hpp
! hotspot/src/share/vm/services/memoryService.cpp
! hotspot/src/share/vm/services/memoryService.hpp
+ hotspot/src/share/vm/services/shenandoahMemoryPool.cpp
+ hotspot/src/share/vm/services/shenandoahMemoryPool.hpp
! hotspot/src/share/vm/utilities/globalDefinitions.hpp
! hotspot/src/share/vm/utilities/macros.hpp
! hotspot/src/share/vm/utilities/taskqueue.hpp
! hotspot/src/share/vm/utilities/top.hpp
! hotspot/test/TEST.groups
+ hotspot/test/compiler/gcbarriers/EqvUncastStepOverBarrier.java
! hotspot/test/gc/TestSystemGC.java
! hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java
! hotspot/test/gc/arguments/TestUseCompressedOopsErgo.java
! hotspot/test/gc/logging/TestGCId.java
! hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java
! hotspot/test/gc/metaspace/TestPerfCountersAndMemoryPools.java
+ hotspot/test/gc/shenandoah/TestAllocHumongousFragment.java
+ hotspot/test/gc/shenandoah/TestAllocIntArrays.java
+ hotspot/test/gc/shenandoah/TestAllocObjectArrays.java
+ hotspot/test/gc/shenandoah/TestAllocObjects.java
+ hotspot/test/gc/shenandoah/TestArrayCopyCheckCast.java
+ hotspot/test/gc/shenandoah/TestArrayCopyStress.java
+ hotspot/test/gc/shenandoah/TestDynamicSoftMaxHeapSize.java
+ hotspot/test/gc/shenandoah/TestElasticTLAB.java
+ hotspot/test/gc/shenandoah/TestEvilSyncBug.java
+ hotspot/test/gc/shenandoah/TestGCThreadGroups.java
+ hotspot/test/gc/shenandoah/TestHeapUncommit.java
+ hotspot/test/gc/shenandoah/TestHumongousThreshold.java
+ hotspot/test/gc/shenandoah/TestLargeObjectAlignment.java
+ hotspot/test/gc/shenandoah/TestLotsOfCycles.java
+ hotspot/test/gc/shenandoah/TestObjItrWithHeapDump.java
+ hotspot/test/gc/shenandoah/TestParallelRefprocSanity.java
+ hotspot/test/gc/shenandoah/TestPeriodicGC.java
+ hotspot/test/gc/shenandoah/TestRefprocSanity.java
+ hotspot/test/gc/shenandoah/TestRegionSampling.java
+ hotspot/test/gc/shenandoah/TestRetainObjects.java
+ hotspot/test/gc/shenandoah/TestSieveObjects.java
+ hotspot/test/gc/shenandoah/TestSmallHeap.java
+ hotspot/test/gc/shenandoah/TestStringDedup.java
+ hotspot/test/gc/shenandoah/TestStringDedupStress.java
+ hotspot/test/gc/shenandoah/TestStringInternCleanup.java
+ hotspot/test/gc/shenandoah/TestVerifyJCStress.java
+ hotspot/test/gc/shenandoah/TestVerifyLevels.java
+ hotspot/test/gc/shenandoah/TestWithLogLevel.java
+ hotspot/test/gc/shenandoah/TestWrongArrayMember.java
+ hotspot/test/gc/shenandoah/compiler/BarrierInInfiniteLoop.java
+ hotspot/test/gc/shenandoah/compiler/CallMultipleCatchProjs.java
+ hotspot/test/gc/shenandoah/compiler/LRBRightAfterMemBar.java
+ hotspot/test/gc/shenandoah/compiler/TestC1VectorizedMismatch.java
+ hotspot/test/gc/shenandoah/compiler/TestClone.java
+ hotspot/test/gc/shenandoah/compiler/TestExpandedWBLostNullCheckDep.java
+ hotspot/test/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java
+ hotspot/test/gc/shenandoah/compiler/TestNullCheck.java
+ hotspot/test/gc/shenandoah/compiler/TestReferenceCAS.java
+ hotspot/test/gc/shenandoah/compiler/TestShenandoahCmpPAfterCall.java
+ hotspot/test/gc/shenandoah/compiler/TestUnsafeOffheapSwap.java
+ hotspot/test/gc/shenandoah/compiler/TestWriteBarrierClearControl.java
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeArgs.java
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeArgs.sh
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeStress.java
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeStress.sh
+ hotspot/test/gc/shenandoah/jni/TestJNICritical.java
+ hotspot/test/gc/shenandoah/jni/TestJNICritical.sh
+ hotspot/test/gc/shenandoah/jni/TestJNIGlobalRefs.java
+ hotspot/test/gc/shenandoah/jni/TestJNIGlobalRefs.sh
+ hotspot/test/gc/shenandoah/jni/TestPinnedGarbage.java
+ hotspot/test/gc/shenandoah/jni/TestPinnedGarbage.sh
+ hotspot/test/gc/shenandoah/jni/libTestCriticalNative.c
+ hotspot/test/gc/shenandoah/jni/libTestJNICritical.c
+ hotspot/test/gc/shenandoah/jni/libTestJNIGlobalRefs.c
+ hotspot/test/gc/shenandoah/jni/libTestPinnedGarbage.c
+ hotspot/test/gc/shenandoah/jvmti/TestGetLoadedClasses.java
+ hotspot/test/gc/shenandoah/jvmti/TestGetLoadedClasses.sh
+ hotspot/test/gc/shenandoah/jvmti/TestHeapDump.java
+ hotspot/test/gc/shenandoah/jvmti/TestHeapDump.sh
+ hotspot/test/gc/shenandoah/jvmti/libTestGetLoadedClasses.c
+ hotspot/test/gc/shenandoah/jvmti/libTestHeapDump.c
+ hotspot/test/gc/shenandoah/mxbeans/TestChurnNotifications.java
+ hotspot/test/gc/shenandoah/mxbeans/TestMemoryMXBeans.java
+ hotspot/test/gc/shenandoah/mxbeans/TestMemoryPools.java
+ hotspot/test/gc/shenandoah/mxbeans/TestPauseNotifications.java
+ hotspot/test/gc/shenandoah/oom/TestAllocLargeObj.java
+ hotspot/test/gc/shenandoah/oom/TestAllocLargerThanHeap.java
+ hotspot/test/gc/shenandoah/oom/TestAllocSmallObj.java
+ hotspot/test/gc/shenandoah/oom/TestClassLoaderLeak.java
+ hotspot/test/gc/shenandoah/oom/TestThreadFailure.java
+ hotspot/test/gc/shenandoah/options/TestAlwaysPreTouch.java
+ hotspot/test/gc/shenandoah/options/TestArgumentRanges.java
+ hotspot/test/gc/shenandoah/options/TestClassUnloadingArguments.java
+ hotspot/test/gc/shenandoah/options/TestCodeCacheRootStyles.java
+ hotspot/test/gc/shenandoah/options/TestEnabled.java
+ hotspot/test/gc/shenandoah/options/TestExplicitGC.java
+ hotspot/test/gc/shenandoah/options/TestExplicitGCNoConcurrent.java
+ hotspot/test/gc/shenandoah/options/TestHeuristicsUnlock.java
+ hotspot/test/gc/shenandoah/options/TestHumongousMoves.java
+ hotspot/test/gc/shenandoah/options/TestHumongousThresholdArgs.java
+ hotspot/test/gc/shenandoah/options/TestLargePages.java
+ hotspot/test/gc/shenandoah/options/TestLargePagesWithSmallHeap.java
+ hotspot/test/gc/shenandoah/options/TestModeUnlock.java
+ hotspot/test/gc/shenandoah/options/TestObjectAlignment.java
+ hotspot/test/gc/shenandoah/options/TestPacing.java
+ hotspot/test/gc/shenandoah/options/TestParallelRegionStride.java
+ hotspot/test/gc/shenandoah/options/TestRegionSizeArgs.java
+ hotspot/test/gc/shenandoah/options/TestSelectiveBarrierFlags.java
+ hotspot/test/gc/shenandoah/options/TestSingleThreaded.java
+ hotspot/test/gc/shenandoah/options/TestSoftMaxHeapSize.java
+ hotspot/test/gc/shenandoah/options/TestThreadCounts.java
+ hotspot/test/gc/shenandoah/options/TestThreadCountsOverride.java
+ hotspot/test/gc/shenandoah/options/TestVerboseGC.java
+ hotspot/test/gc/shenandoah/options/TestWrongBarrierDisable.java
+ hotspot/test/gc/shenandoah/options/TestWrongBarrierEnable.java
+ hotspot/test/gc/startup_warnings/TestShenandoah.java
! hotspot/test/gc/survivorAlignment/TestAllocationInEden.java
! hotspot/test/gc/survivorAlignment/TestPromotionFromEdenToTenured.java
! hotspot/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java
! hotspot/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java
! hotspot/test/gc/survivorAlignment/TestPromotionToSurvivor.java
! hotspot/test/gc/whitebox/TestWBGC.java
- jaxp/.jcheck/conf
! jaxp/THIRD_PARTY_README
- jaxws/.jcheck/conf
! jaxws/THIRD_PARTY_README
- jdk/.jcheck/conf
! jdk/THIRD_PARTY_README
! jdk/src/share/classes/java/io/ObjectInputStream.java
! jdk/src/share/classes/java/lang/invoke/LambdaFormEditor.java
- langtools/.jcheck/conf
! langtools/THIRD_PARTY_README
- nashorn/.jcheck/conf
! nashorn/THIRD_PARTY_README

Changeset: ac89ca95
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:41 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/ac89ca956d86edd2fbe1952ee9e2ee5db9861899

Merge tag 'jdk8u322-b05' into sh-jdk8u

Added tag jdk8u322-b05 for changeset 5aadb44300e0


Changeset: d56198b0
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:28 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/d56198b0d6f27c09b878c2c52eadc33ab872607d

Merge tag 'jdk8u322-b06' into sh-jdk8u

Added tag jdk8u322-b06 for changeset f75aee4df47a

! hotspot/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! jdk/src/share/classes/java/io/ObjectInputStream.java
! hotspot/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! jdk/src/share/classes/java/io/ObjectInputStream.java

Changeset: 8936e2ef
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:52:38 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/8936e2ef6c534cce48a764a4802345d225a96e9b

Merge remote-tracking branch 'refs/remotes/origin/master' into sh-jdk8u



From andrew at openjdk.java.net  Tue Feb 15 17:31:18 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:31:18 GMT
Subject: git: openjdk/shenandoah-jdk8u-dev: Added tag jdk8u332-b00 for
 changeset 7d3c0bed
Message-ID: <88eb6d7d-86f8-4ad8-9b65-c42b8217125d@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-02-01 19:54:57 +0000


Changeset: 7d3c0bed
Author:    J. Duke <duke at openjdk.org>
Date:      2021-11-29 07:12:19 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/7d3c0bede34930cadd76644e58bf56f2a83c3d01


From andrew at openjdk.java.net  Tue Feb 15 17:31:22 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:31:22 GMT
Subject: git: openjdk/shenandoah-jdk8u-dev: Added tag
 aarch64-shenandoah-jdk8u322-b04 for changeset d475f9eb
Message-ID: <a89f62b1-b373-4721-be63-77014d13747d@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:33 +0000

Merge jdk8u322-b04
Changeset: d475f9eb
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:01 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9


From andrew at openjdk.java.net  Tue Feb 15 17:31:27 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:31:27 GMT
Subject: git: openjdk/shenandoah-jdk8u-dev: Added tag
 aarch64-shenandoah-jdk8u322-b05 for changeset ac89ca95
Message-ID: <67274a72-49d0-4589-8a18-f7bcd50d5f44@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:01 +0000

Merge jdk8u322-b05
Changeset: ac89ca95
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:41 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/ac89ca956d86edd2fbe1952ee9e2ee5db9861899


From andrew at openjdk.java.net  Tue Feb 15 17:31:34 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:31:34 GMT
Subject: git: openjdk/shenandoah-jdk8u-dev: Added tag
 aarch64-shenandoah-jdk8u322-b06 for changeset d56198b0
Message-ID: <ad028c4e-b591-4279-858d-72b46fde1ad3@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:39 +0000

Merge jdk8u322-b06
Changeset: d56198b0
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:28 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/d56198b0d6f27c09b878c2c52eadc33ab872607d


From andrew at openjdk.java.net  Tue Feb 15 17:31:37 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:31:37 GMT
Subject: git: openjdk/shenandoah-jdk8u-dev: Added tag jdk8u322-ga for changeset
 236b800c
Message-ID: <a51eebf0-2dc0-4c84-bb0a-8cc7c6d0609f@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-28 02:05:31 +0000


Changeset: 236b800c
Author:    Andrew Brygin <bae at openjdk.org>
Date:      2021-09-28 13:30:27 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/236b800cf26b8e138c925334371681e6b0a099ab


From gnu.andrew at redhat.com  Tue Feb 15 17:31:50 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 15 Feb 2022 17:31:50 +0000
Subject: [RFR] [8u] 8u322-b0{4,5,6} Upstream Sync
In-Reply-To: <7f6b88db-7d3d-c5d3-eefc-0f2bf8890b1e@redhat.com>
References: <YgMztDpMajrNN2kF@hex.discworld.ac.uk>
 <7f6b88db-7d3d-c5d3-eefc-0f2bf8890b1e@redhat.com>
Message-ID: <YgvjhmgFsSmNYHyO@hex.discworld.ac.uk>

On 19:07 Wed 09 Feb     , Aleksey Shipilev wrote:
> On 2/9/22 06:23, Andrew Hughes wrote:
> > Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
> > ppc64, ppc64le, aarch32 (Zero) & aarch64.
> > 
> > Ok to push?
> 
> OK.
>

Done.

> > Secondly, the Shenandoah changes are applied to this tree on top of 8u322-b04
> > to create (nearly) the same code as explained in my last e-mail. b05 & b06
> > are then merged on top:
> > 
> > https://github.com/gnu-andrew/jdk8u/tree/sh-jdk8u
> > 
> > Ok to push this to https://github.com/openjdk/shenandoah-jdk8u once I have
> > direct push access?
> 
> OK.
>

Pushed to both:

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

> -- 
> Thanks,
> -Aleksey
> 

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 andrew at openjdk.java.net  Tue Feb 15 17:31:59 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 15 Feb 2022 17:31:59 GMT
Subject: git: openjdk/shenandoah-jdk8u-dev: master: 4 new changesets
Message-ID: <3f1f0fa7-0c2a-4bfa-9a19-629560f226ce@openjdk.org>

Changeset: d475f9eb
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:01 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9

Import of aarch64-shenandoah-jdk8u322-b04

Local changes to common/autoconf/generated-configure.sh and jdk/test/sun/security/tools/jarsigner/warnings/Test.java discarded

- .jcheck/conf
! THIRD_PARTY_README
- corba/.jcheck/conf
! corba/THIRD_PARTY_README
- hotspot/.jcheck/conf
! hotspot/THIRD_PARTY_README
! hotspot/agent/src/share/classes/sun/jvm/hotspot/HSDB.java
+ hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java
+ hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeapRegion.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_interface/CollectedHeapName.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_interface/GCCause.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/gc_interface/GCName.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/runtime/VMOps.java
! hotspot/agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! hotspot/make/bsd/makefiles/gcc.make
! hotspot/make/excludeSrc.make
! hotspot/make/linux/makefiles/gcc.make
! hotspot/make/linux/makefiles/rules.make
! hotspot/make/linux/makefiles/vm.make
! hotspot/make/solaris/makefiles/gcc.make
! hotspot/make/windows/create_obj_files.sh
! hotspot/make/windows/makefiles/vm.make
! hotspot/src/cpu/aarch64/vm/aarch64.ad
! hotspot/src/cpu/aarch64/vm/assembler_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp
! hotspot/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp
+ hotspot/src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp
+ hotspot/src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp
! hotspot/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp
! hotspot/src/cpu/aarch64/vm/templateTable_aarch64.cpp
! hotspot/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! hotspot/src/cpu/x86/vm/assembler_x86.cpp
! hotspot/src/cpu/x86/vm/assembler_x86.hpp
! hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! hotspot/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp
! hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp
! hotspot/src/cpu/x86/vm/macroAssembler_x86.hpp
! hotspot/src/cpu/x86/vm/nativeInst_x86.cpp
! hotspot/src/cpu/x86/vm/nativeInst_x86.hpp
! hotspot/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
+ hotspot/src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp
+ hotspot/src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp
! hotspot/src/cpu/x86/vm/stubGenerator_x86_32.cpp
! hotspot/src/cpu/x86/vm/stubGenerator_x86_64.cpp
! hotspot/src/cpu/x86/vm/stubRoutines_x86_32.hpp
! hotspot/src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! hotspot/src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! hotspot/src/cpu/x86/vm/templateTable_x86_32.cpp
! hotspot/src/cpu/x86/vm/templateTable_x86_64.cpp
! hotspot/src/cpu/x86/vm/x86_32.ad
! hotspot/src/cpu/x86/vm/x86_64.ad
! hotspot/src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp
! hotspot/src/share/vm/adlc/formssel.cpp
! hotspot/src/share/vm/adlc/formssel.hpp
! hotspot/src/share/vm/adlc/output_c.cpp
! hotspot/src/share/vm/adlc/output_h.cpp
! hotspot/src/share/vm/c1/c1_LIR.hpp
! hotspot/src/share/vm/c1/c1_LIRAssembler.cpp
! hotspot/src/share/vm/c1/c1_LIRAssembler.hpp
! hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
! hotspot/src/share/vm/c1/c1_LIRGenerator.hpp
! hotspot/src/share/vm/c1/c1_Runtime1.cpp
! hotspot/src/share/vm/c1/c1_Runtime1.hpp
! hotspot/src/share/vm/ci/ciObjectFactory.cpp
! hotspot/src/share/vm/classfile/classLoaderData.hpp
! hotspot/src/share/vm/classfile/classLoaderStats.hpp
! hotspot/src/share/vm/classfile/javaClasses.cpp
! hotspot/src/share/vm/classfile/symbolTable.cpp
! hotspot/src/share/vm/classfile/symbolTable.hpp
! hotspot/src/share/vm/code/codeCache.cpp
! hotspot/src/share/vm/code/codeCache.hpp
! hotspot/src/share/vm/code/nmethod.cpp
! hotspot/src/share/vm/compiler/oopMap.hpp
! hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp
! hotspot/src/share/vm/gc_implementation/g1/satbQueue.cpp
! hotspot/src/share/vm/gc_implementation/g1/satbQueue.hpp
+ hotspot/src/share/vm/gc_implementation/shared/markBitMap.cpp
+ hotspot/src/share/vm/gc_implementation/shared/markBitMap.hpp
+ hotspot/src/share/vm/gc_implementation/shared/markBitMap.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/preservedMarks.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/preservedMarks.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/preservedMarks.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahAllocRequest.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetAssembler_stub.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahClosures.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahJfrSupport.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahJfrSupport.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahLogging.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahLogging.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahNumberSeq.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahNumberSeq.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPadding.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupThread.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupThread.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahSynchronizerIterator.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahSynchronizerIterator.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerDataArray.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerDataArray.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerDataArray.inline.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoah_globals.cpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/shenandoah_specialized_oop_closures.hpp
+ hotspot/src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp
! hotspot/src/share/vm/gc_interface/collectedHeap.cpp
! hotspot/src/share/vm/gc_interface/collectedHeap.hpp
! hotspot/src/share/vm/gc_interface/gcCause.cpp
! hotspot/src/share/vm/gc_interface/gcCause.hpp
! hotspot/src/share/vm/gc_interface/gcName.hpp
! hotspot/src/share/vm/jfr/metadata/metadata.xml
! hotspot/src/share/vm/jfr/periodic/jfrPeriodic.cpp
! hotspot/src/share/vm/memory/barrierSet.cpp
! hotspot/src/share/vm/memory/barrierSet.hpp
! hotspot/src/share/vm/memory/barrierSet.inline.hpp
! hotspot/src/share/vm/memory/binaryTreeDictionary.hpp
! hotspot/src/share/vm/memory/metaspace.hpp
! hotspot/src/share/vm/memory/referenceProcessor.cpp
! hotspot/src/share/vm/memory/referenceProcessor.hpp
! hotspot/src/share/vm/memory/specialized_oop_closures.hpp
! hotspot/src/share/vm/memory/threadLocalAllocBuffer.cpp
! hotspot/src/share/vm/memory/threadLocalAllocBuffer.hpp
! hotspot/src/share/vm/memory/universe.cpp
! hotspot/src/share/vm/oops/instanceKlass.cpp
! hotspot/src/share/vm/oops/instanceMirrorKlass.cpp
! hotspot/src/share/vm/oops/instanceRefKlass.cpp
! hotspot/src/share/vm/oops/klass.cpp
! hotspot/src/share/vm/oops/klass.hpp
! hotspot/src/share/vm/oops/objArrayKlass.cpp
! hotspot/src/share/vm/oops/objArrayOop.hpp
! hotspot/src/share/vm/oops/oop.hpp
! hotspot/src/share/vm/oops/oop.inline.hpp
! hotspot/src/share/vm/opto/addnode.cpp
! hotspot/src/share/vm/opto/callnode.cpp
! hotspot/src/share/vm/opto/callnode.hpp
! hotspot/src/share/vm/opto/cfgnode.cpp
! hotspot/src/share/vm/opto/cfgnode.hpp
! hotspot/src/share/vm/opto/classes.cpp
! hotspot/src/share/vm/opto/classes.hpp
! hotspot/src/share/vm/opto/compile.cpp
! hotspot/src/share/vm/opto/compile.hpp
! hotspot/src/share/vm/opto/connode.cpp
! hotspot/src/share/vm/opto/connode.hpp
! hotspot/src/share/vm/opto/escape.cpp
! hotspot/src/share/vm/opto/gcm.cpp
! hotspot/src/share/vm/opto/graphKit.cpp
! hotspot/src/share/vm/opto/ifnode.cpp
! hotspot/src/share/vm/opto/lcm.cpp
! hotspot/src/share/vm/opto/library_call.cpp
! hotspot/src/share/vm/opto/loopPredicate.cpp
! hotspot/src/share/vm/opto/loopnode.cpp
! hotspot/src/share/vm/opto/loopnode.hpp
! hotspot/src/share/vm/opto/loopopts.cpp
! hotspot/src/share/vm/opto/machnode.cpp
! hotspot/src/share/vm/opto/machnode.hpp
! hotspot/src/share/vm/opto/macro.cpp
! hotspot/src/share/vm/opto/matcher.cpp
! hotspot/src/share/vm/opto/matcher.hpp
! hotspot/src/share/vm/opto/memnode.cpp
! hotspot/src/share/vm/opto/memnode.hpp
! hotspot/src/share/vm/opto/mulnode.cpp
! hotspot/src/share/vm/opto/multnode.cpp
! hotspot/src/share/vm/opto/multnode.hpp
! hotspot/src/share/vm/opto/node.cpp
! hotspot/src/share/vm/opto/node.hpp
! hotspot/src/share/vm/opto/parse2.cpp
! hotspot/src/share/vm/opto/parse3.cpp
! hotspot/src/share/vm/opto/phaseX.cpp
! hotspot/src/share/vm/opto/runtime.cpp
! hotspot/src/share/vm/opto/runtime.hpp
! hotspot/src/share/vm/opto/subnode.cpp
! hotspot/src/share/vm/opto/superword.cpp
! hotspot/src/share/vm/opto/superword.hpp
! hotspot/src/share/vm/precompiled/precompiled.hpp
! hotspot/src/share/vm/prims/jni.cpp
! hotspot/src/share/vm/prims/jvm.cpp
! hotspot/src/share/vm/prims/jvmtiGetLoadedClasses.cpp
! hotspot/src/share/vm/prims/jvmtiTagMap.cpp
! hotspot/src/share/vm/prims/unsafe.cpp
! hotspot/src/share/vm/runtime/arguments.cpp
! hotspot/src/share/vm/runtime/arguments.hpp
! hotspot/src/share/vm/runtime/fieldDescriptor.hpp
! hotspot/src/share/vm/runtime/globals.cpp
! hotspot/src/share/vm/runtime/globals.hpp
! hotspot/src/share/vm/runtime/globals_extension.hpp
! hotspot/src/share/vm/runtime/jniHandles.cpp
! hotspot/src/share/vm/runtime/mutexLocker.cpp
! hotspot/src/share/vm/runtime/objectMonitor.hpp
! hotspot/src/share/vm/runtime/os.hpp
! hotspot/src/share/vm/runtime/safepoint.cpp
! hotspot/src/share/vm/runtime/sharedRuntime.cpp
! hotspot/src/share/vm/runtime/sharedRuntime.hpp
! hotspot/src/share/vm/runtime/stackValue.cpp
! hotspot/src/share/vm/runtime/synchronizer.hpp
! hotspot/src/share/vm/runtime/thread.cpp
! hotspot/src/share/vm/runtime/thread.hpp
! hotspot/src/share/vm/runtime/thread.inline.hpp
! hotspot/src/share/vm/runtime/vmStructs.cpp
! hotspot/src/share/vm/runtime/vm_operations.hpp
! hotspot/src/share/vm/services/heapDumper.cpp
! hotspot/src/share/vm/services/memoryManager.cpp
! hotspot/src/share/vm/services/memoryManager.hpp
! hotspot/src/share/vm/services/memoryService.cpp
! hotspot/src/share/vm/services/memoryService.hpp
+ hotspot/src/share/vm/services/shenandoahMemoryPool.cpp
+ hotspot/src/share/vm/services/shenandoahMemoryPool.hpp
! hotspot/src/share/vm/utilities/globalDefinitions.hpp
! hotspot/src/share/vm/utilities/macros.hpp
! hotspot/src/share/vm/utilities/taskqueue.hpp
! hotspot/src/share/vm/utilities/top.hpp
! hotspot/test/TEST.groups
+ hotspot/test/compiler/gcbarriers/EqvUncastStepOverBarrier.java
! hotspot/test/gc/TestSystemGC.java
! hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java
! hotspot/test/gc/arguments/TestUseCompressedOopsErgo.java
! hotspot/test/gc/logging/TestGCId.java
! hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java
! hotspot/test/gc/metaspace/TestPerfCountersAndMemoryPools.java
+ hotspot/test/gc/shenandoah/TestAllocHumongousFragment.java
+ hotspot/test/gc/shenandoah/TestAllocIntArrays.java
+ hotspot/test/gc/shenandoah/TestAllocObjectArrays.java
+ hotspot/test/gc/shenandoah/TestAllocObjects.java
+ hotspot/test/gc/shenandoah/TestArrayCopyCheckCast.java
+ hotspot/test/gc/shenandoah/TestArrayCopyStress.java
+ hotspot/test/gc/shenandoah/TestDynamicSoftMaxHeapSize.java
+ hotspot/test/gc/shenandoah/TestElasticTLAB.java
+ hotspot/test/gc/shenandoah/TestEvilSyncBug.java
+ hotspot/test/gc/shenandoah/TestGCThreadGroups.java
+ hotspot/test/gc/shenandoah/TestHeapUncommit.java
+ hotspot/test/gc/shenandoah/TestHumongousThreshold.java
+ hotspot/test/gc/shenandoah/TestLargeObjectAlignment.java
+ hotspot/test/gc/shenandoah/TestLotsOfCycles.java
+ hotspot/test/gc/shenandoah/TestObjItrWithHeapDump.java
+ hotspot/test/gc/shenandoah/TestParallelRefprocSanity.java
+ hotspot/test/gc/shenandoah/TestPeriodicGC.java
+ hotspot/test/gc/shenandoah/TestRefprocSanity.java
+ hotspot/test/gc/shenandoah/TestRegionSampling.java
+ hotspot/test/gc/shenandoah/TestRetainObjects.java
+ hotspot/test/gc/shenandoah/TestSieveObjects.java
+ hotspot/test/gc/shenandoah/TestSmallHeap.java
+ hotspot/test/gc/shenandoah/TestStringDedup.java
+ hotspot/test/gc/shenandoah/TestStringDedupStress.java
+ hotspot/test/gc/shenandoah/TestStringInternCleanup.java
+ hotspot/test/gc/shenandoah/TestVerifyJCStress.java
+ hotspot/test/gc/shenandoah/TestVerifyLevels.java
+ hotspot/test/gc/shenandoah/TestWithLogLevel.java
+ hotspot/test/gc/shenandoah/TestWrongArrayMember.java
+ hotspot/test/gc/shenandoah/compiler/BarrierInInfiniteLoop.java
+ hotspot/test/gc/shenandoah/compiler/CallMultipleCatchProjs.java
+ hotspot/test/gc/shenandoah/compiler/LRBRightAfterMemBar.java
+ hotspot/test/gc/shenandoah/compiler/TestC1VectorizedMismatch.java
+ hotspot/test/gc/shenandoah/compiler/TestClone.java
+ hotspot/test/gc/shenandoah/compiler/TestExpandedWBLostNullCheckDep.java
+ hotspot/test/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java
+ hotspot/test/gc/shenandoah/compiler/TestNullCheck.java
+ hotspot/test/gc/shenandoah/compiler/TestReferenceCAS.java
+ hotspot/test/gc/shenandoah/compiler/TestShenandoahCmpPAfterCall.java
+ hotspot/test/gc/shenandoah/compiler/TestUnsafeOffheapSwap.java
+ hotspot/test/gc/shenandoah/compiler/TestWriteBarrierClearControl.java
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeArgs.java
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeArgs.sh
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeStress.java
+ hotspot/test/gc/shenandoah/jni/TestCriticalNativeStress.sh
+ hotspot/test/gc/shenandoah/jni/TestJNICritical.java
+ hotspot/test/gc/shenandoah/jni/TestJNICritical.sh
+ hotspot/test/gc/shenandoah/jni/TestJNIGlobalRefs.java
+ hotspot/test/gc/shenandoah/jni/TestJNIGlobalRefs.sh
+ hotspot/test/gc/shenandoah/jni/TestPinnedGarbage.java
+ hotspot/test/gc/shenandoah/jni/TestPinnedGarbage.sh
+ hotspot/test/gc/shenandoah/jni/libTestCriticalNative.c
+ hotspot/test/gc/shenandoah/jni/libTestJNICritical.c
+ hotspot/test/gc/shenandoah/jni/libTestJNIGlobalRefs.c
+ hotspot/test/gc/shenandoah/jni/libTestPinnedGarbage.c
+ hotspot/test/gc/shenandoah/jvmti/TestGetLoadedClasses.java
+ hotspot/test/gc/shenandoah/jvmti/TestGetLoadedClasses.sh
+ hotspot/test/gc/shenandoah/jvmti/TestHeapDump.java
+ hotspot/test/gc/shenandoah/jvmti/TestHeapDump.sh
+ hotspot/test/gc/shenandoah/jvmti/libTestGetLoadedClasses.c
+ hotspot/test/gc/shenandoah/jvmti/libTestHeapDump.c
+ hotspot/test/gc/shenandoah/mxbeans/TestChurnNotifications.java
+ hotspot/test/gc/shenandoah/mxbeans/TestMemoryMXBeans.java
+ hotspot/test/gc/shenandoah/mxbeans/TestMemoryPools.java
+ hotspot/test/gc/shenandoah/mxbeans/TestPauseNotifications.java
+ hotspot/test/gc/shenandoah/oom/TestAllocLargeObj.java
+ hotspot/test/gc/shenandoah/oom/TestAllocLargerThanHeap.java
+ hotspot/test/gc/shenandoah/oom/TestAllocSmallObj.java
+ hotspot/test/gc/shenandoah/oom/TestClassLoaderLeak.java
+ hotspot/test/gc/shenandoah/oom/TestThreadFailure.java
+ hotspot/test/gc/shenandoah/options/TestAlwaysPreTouch.java
+ hotspot/test/gc/shenandoah/options/TestArgumentRanges.java
+ hotspot/test/gc/shenandoah/options/TestClassUnloadingArguments.java
+ hotspot/test/gc/shenandoah/options/TestCodeCacheRootStyles.java
+ hotspot/test/gc/shenandoah/options/TestEnabled.java
+ hotspot/test/gc/shenandoah/options/TestExplicitGC.java
+ hotspot/test/gc/shenandoah/options/TestExplicitGCNoConcurrent.java
+ hotspot/test/gc/shenandoah/options/TestHeuristicsUnlock.java
+ hotspot/test/gc/shenandoah/options/TestHumongousMoves.java
+ hotspot/test/gc/shenandoah/options/TestHumongousThresholdArgs.java
+ hotspot/test/gc/shenandoah/options/TestLargePages.java
+ hotspot/test/gc/shenandoah/options/TestLargePagesWithSmallHeap.java
+ hotspot/test/gc/shenandoah/options/TestModeUnlock.java
+ hotspot/test/gc/shenandoah/options/TestObjectAlignment.java
+ hotspot/test/gc/shenandoah/options/TestPacing.java
+ hotspot/test/gc/shenandoah/options/TestParallelRegionStride.java
+ hotspot/test/gc/shenandoah/options/TestRegionSizeArgs.java
+ hotspot/test/gc/shenandoah/options/TestSelectiveBarrierFlags.java
+ hotspot/test/gc/shenandoah/options/TestSingleThreaded.java
+ hotspot/test/gc/shenandoah/options/TestSoftMaxHeapSize.java
+ hotspot/test/gc/shenandoah/options/TestThreadCounts.java
+ hotspot/test/gc/shenandoah/options/TestThreadCountsOverride.java
+ hotspot/test/gc/shenandoah/options/TestVerboseGC.java
+ hotspot/test/gc/shenandoah/options/TestWrongBarrierDisable.java
+ hotspot/test/gc/shenandoah/options/TestWrongBarrierEnable.java
+ hotspot/test/gc/startup_warnings/TestShenandoah.java
! hotspot/test/gc/survivorAlignment/TestAllocationInEden.java
! hotspot/test/gc/survivorAlignment/TestPromotionFromEdenToTenured.java
! hotspot/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java
! hotspot/test/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java
! hotspot/test/gc/survivorAlignment/TestPromotionToSurvivor.java
! hotspot/test/gc/whitebox/TestWBGC.java
- jaxp/.jcheck/conf
! jaxp/THIRD_PARTY_README
- jaxws/.jcheck/conf
! jaxws/THIRD_PARTY_README
- jdk/.jcheck/conf
! jdk/THIRD_PARTY_README
! jdk/src/share/classes/java/io/ObjectInputStream.java
! jdk/src/share/classes/java/lang/invoke/LambdaFormEditor.java
- langtools/.jcheck/conf
! langtools/THIRD_PARTY_README
- nashorn/.jcheck/conf
! nashorn/THIRD_PARTY_README

Changeset: ac89ca95
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:41 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/ac89ca956d86edd2fbe1952ee9e2ee5db9861899

Merge tag 'jdk8u322-b05' into sh-jdk8u

Added tag jdk8u322-b05 for changeset 5aadb44300e0


Changeset: d56198b0
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:28 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/d56198b0d6f27c09b878c2c52eadc33ab872607d

Merge tag 'jdk8u322-b06' into sh-jdk8u

Added tag jdk8u322-b06 for changeset f75aee4df47a

! hotspot/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! jdk/src/share/classes/java/io/ObjectInputStream.java
! hotspot/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! jdk/src/share/classes/java/io/ObjectInputStream.java

Changeset: 8936e2ef
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:52:38 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u-dev/commit/8936e2ef6c534cce48a764a4802345d225a96e9b

Merge remote-tracking branch 'refs/remotes/origin/master' into sh-jdk8u



From wkemper at openjdk.java.net  Tue Feb 15 17:48:43 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 15 Feb 2022 17:48:43 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <z2NMYRRNPYeeompPCJDLY6romVFxYJZXSMBIg4gzkPM=.9082f807-bb32-4b87-8e22-81c519381f62@github.com>

This is a merge of jdk-19+8 into Shenandoah.

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

Commit messages:
 - Remove extraneous whitespace
 - Merge branch 'shenandoah-master' into merge-upstream-jdk-19-8
 - Merge branch 'shenandoah-master' into merge-upstream-jdk-19-8
 - Merge tag 'jdk-19+8' into upstream-merge
 - 8278254: Cleanup doclint warnings in java.desktop module
 - 8280600: C2: assert(!had_error) failed: bad dominance
 - 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116
 - 8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path"
 - 8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift.
 - 8280842: Access violation in ciTypeFlow::profiled_count
 - ... and 1833 more: https://git.openjdk.java.net/shenandoah/compare/dc9d7d0a...91d771f0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=115&range=00.0
 - openjdk/jdk:master: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=115&range=00.1

Changes: https://git.openjdk.java.net/shenandoah/pull/115/files
  Stats: 1075070 lines in 5612 files changed: 585534 ins; 458093 del; 31443 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/115.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/115/head:pull/115

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

From rkennke at openjdk.java.net  Tue Feb 15 17:48:43 2022
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 15 Feb 2022 17:48:43 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <z2NMYRRNPYeeompPCJDLY6romVFxYJZXSMBIg4gzkPM=.9082f807-bb32-4b87-8e22-81c519381f62@github.com>
References: <z2NMYRRNPYeeompPCJDLY6romVFxYJZXSMBIg4gzkPM=.9082f807-bb32-4b87-8e22-81c519381f62@github.com>
Message-ID: <lYZmf8P3Jq91BggJ5wK9iMRu6WA5Cb4FtOssMgZNhGw=.1f2d250f-03c7-457e-ac18-731ed82dbc9a@github.com>

On Mon, 14 Feb 2022 23:19:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a merge of jdk-19+8 into Shenandoah.

Go for it!

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

Marked as reviewed by rkennke (Lead).

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

From wkemper at openjdk.java.net  Tue Feb 15 18:01:57 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 15 Feb 2022 18:01:57 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <z2NMYRRNPYeeompPCJDLY6romVFxYJZXSMBIg4gzkPM=.9082f807-bb32-4b87-8e22-81c519381f62@github.com>
References: <z2NMYRRNPYeeompPCJDLY6romVFxYJZXSMBIg4gzkPM=.9082f807-bb32-4b87-8e22-81c519381f62@github.com>
Message-ID: <WgxXpkyDgOw6RzZIVLDQDKVwN0cVy95HYw0vmdlCWaI=.c4cba1a4-f73f-46a8-a0a4-2dede87ce320@github.com>

On Mon, 14 Feb 2022 23:19:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a merge of jdk-19+8 into Shenandoah.

This pull request has now been integrated.

Changeset: 0a5a3695
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/0a5a3695d7a9606a4c52239d095fcb4a04b80a52
Stats:     1075070 lines in 5612 files changed: 585534 ins; 458093 del; 31443 mod

Merge openjdk/jdk:master

Reviewed-by: rkennke

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

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

From jiefu at openjdk.java.net  Wed Feb 16 23:17:17 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 23:17:17 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is assumed to
 be unique after JDK-8281732
Message-ID: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>

Hi all,

The following tests fail after JDK-8281732.

compiler/gcbarriers/UnsafeIntrinsicsTest.java
gc/metaspace/TestMetaspacePerfCounters.java
gc/shenandoah/TestEvilSyncBug.java
gc/stringdedup/TestStringDeduplicationFullGC.java
gc/stringdedup/TestStringDeduplicationTableResize.java
gc/stringdedup/TestStringDeduplicationYoungGC.java
serviceability/dcmd/gc/HeapDumpCompressedTest.java
jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
jdk/jfr/event/oldobject/TestShenandoah.java
sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
sun/tools/jmap/BasicJMapTest.java
``` 

The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.

Testing:
 - All failing tests passed after this patch

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732

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

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

From kvn at openjdk.java.net  Wed Feb 16 23:26:04 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 23:26:04 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <Mo41yYEMxSLQvLlgNaKQ24v8qKaZdOIVBB-DxNpqkwI=.74364577-e684-4936-adf2-5dd7242d5383@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From thartmann at openjdk.java.net  Thu Feb 17 07:35:13 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 17 Feb 2022 07:35:13 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <b-lB7PP0iFWpWhmIdglFuT3XbB0QVSCXxZohcgWdTJw=.743071de-8886-41cf-b299-1e3052552d0d@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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

From chagedorn at openjdk.java.net  Thu Feb 17 07:51:12 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 17 Feb 2022 07:51:12 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <0wCWILIHTgSlt6XRlmnB17FA8kikE_CT8lkRe-YaFOQ=.0c69c785-588e-466f-84d4-5024a24f13d5@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From redestad at openjdk.java.net  Thu Feb 17 15:28:57 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Feb 2022 15:28:57 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v3]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <7kC4xxWon70YnYlqH_KJFTa2eEJf-P3VQ1L9ahugJgk=.0943bcaa-b53d-4216-afa1-69496dac248a@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad 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 25 additional commits since the last revision:

 - Revert micro changes, split out to #7516
 - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
 - Merge branch 'master' into count_positives
 - Restore partial vector checks in AVX2 and SSE intrinsic variants
 - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
 - Simplify changes to encodeUTF8
 - Fix little-endian error caught by testing
 - Reduce jumps in the ascii path
 - Remove unused tail_mask
 - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives)
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/1ca44ef9...531139a1

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/c4bb3612..531139a1

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

  Stats: 10910 lines in 329 files changed: 7340 ins; 2150 del; 1420 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From jiefu at openjdk.java.net  Thu Feb 17 22:55:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 22:55:06 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <c1yE7XU9inJfcYqG5Wny5QR7py5KdQ32IIxufH0Se-I=.f6b52576-3dac-4661-9703-504ee5a6152d@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Thank you all for the review.

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

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

From jiefu at openjdk.java.net  Thu Feb 17 23:00:02 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 23:00:02 GMT
Subject: Integrated: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <OJIk7dxbKtf_LXPdqkciNhgNE7H6JrARxofxi1a1pdw=.eed26895-3d1b-4cea-bda9-373090947673@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: fdce35f3
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fdce35f3a1c12a64238d0c76c02451a25b0b4abb
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732

Reviewed-by: kvn, thartmann, chagedorn

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

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

From redestad at openjdk.java.net  Fri Feb 18 15:57:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 18 Feb 2022 15:57:40 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v4]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <GcSawWkc8_paTY2GS3mVA6ZKWgqdEOVFErLVR1YATOw=.cc22549d-713f-4379-9340-6ebe33afe804@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/531139a1..a5e28b32

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

  Stats: 59 lines in 8 files changed: 7 ins; 14 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From wkemper at openjdk.java.net  Mon Feb 21 23:54:37 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 21 Feb 2022 23:54:37 GMT
Subject: RFR: Coalesce dead objects in pinned old regions during full gc
Message-ID: <yGVz5LefZHs4T_i2xM1SwxBcMeNj1sEE3II_DDDWBJ0=.7405efb1-fc95-4438-8bad-3a2e82bbe2e0@github.com>

Pinned regions are not compacted during a full gc. For old regions, this may leave references in unmarked objects pointing into relocated or reclaimed memory. These unmarked objects need to be filled in to prevent the remembered set scan from following bad pointers.

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

Commit messages:
 - Coalesce and fill pinned regions during update reference phase of full gc
 - Make post compaction step multi threaded
 - Coalesce and fill pinned old regions during full gc

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

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

From kdnilsen at openjdk.java.net  Mon Feb 21 23:54:37 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 21 Feb 2022 23:54:37 GMT
Subject: RFR: Coalesce dead objects in pinned old regions during full gc
In-Reply-To: <yGVz5LefZHs4T_i2xM1SwxBcMeNj1sEE3II_DDDWBJ0=.7405efb1-fc95-4438-8bad-3a2e82bbe2e0@github.com>
References: <yGVz5LefZHs4T_i2xM1SwxBcMeNj1sEE3II_DDDWBJ0=.7405efb1-fc95-4438-8bad-3a2e82bbe2e0@github.com>
Message-ID: <OTbFMPLd2coRz_wmzHS23DgmOTrqtSJCv_gZx1vNQL8=.ef23c1c9-1443-4c1e-b07d-a12d8e23d38d@github.com>

On Mon, 21 Feb 2022 23:46:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pinned regions are not compacted during a full gc. For old regions, this may leave references in unmarked objects pointing into relocated or reclaimed memory. These unmarked objects need to be filled in to prevent the remembered set scan from following bad pointers.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Tue Feb 22 00:17:26 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 22 Feb 2022 00:17:26 GMT
Subject: Integrated: Coalesce dead objects in pinned old regions during full gc
In-Reply-To: <yGVz5LefZHs4T_i2xM1SwxBcMeNj1sEE3II_DDDWBJ0=.7405efb1-fc95-4438-8bad-3a2e82bbe2e0@github.com>
References: <yGVz5LefZHs4T_i2xM1SwxBcMeNj1sEE3II_DDDWBJ0=.7405efb1-fc95-4438-8bad-3a2e82bbe2e0@github.com>
Message-ID: <4xUn5jL-VO0Qwr6GDwLwZLP4uq9rw2vwoeEibTP2CZg=.dd75cadb-de62-414c-b3ab-50f40b0a14c1@github.com>

On Mon, 21 Feb 2022 23:46:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pinned regions are not compacted during a full gc. For old regions, this may leave references in unmarked objects pointing into relocated or reclaimed memory. These unmarked objects need to be filled in to prevent the remembered set scan from following bad pointers.

This pull request has now been integrated.

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

Coalesce dead objects in pinned old regions during full gc

Reviewed-by: kdnilsen

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

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

From kdnilsen at openjdk.java.net  Tue Feb 22 00:30:51 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 22 Feb 2022 00:30:51 GMT
Subject: Integrated: Mutator may fail to evacuate
Message-ID: <4kYhp1dHgaiW2xq_SWfuSkCfyGrneI_wMEcqg9FamOg=.2f8e140d-fc64-4ea0-b9c9-3f1029cc9918@github.com>

In the case that a mutator thread fails to evacuate, this patch transitions the Java thread into a VM thread before blocking the thread.  Otherwise, an assertion error is raised.

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

Commit messages:
 - Remove gratuitous new line
 - Undo JRT_ENTRY prologue attempts
 - Retreat to original solution
 - Let write_ref_field_pre_entry use JRT_LEAF protocol
 - Change LRB implementations for mutators
 - is_Java_thread() does not imply thread->thread_state() == thread_in_Java
 - Transition Java thread to VM thread Before Blocking Thread

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

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

From wkemper at openjdk.java.net  Tue Feb 22 00:30:52 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 22 Feb 2022 00:30:52 GMT
Subject: Integrated: Mutator may fail to evacuate
In-Reply-To: <4kYhp1dHgaiW2xq_SWfuSkCfyGrneI_wMEcqg9FamOg=.2f8e140d-fc64-4ea0-b9c9-3f1029cc9918@github.com>
References: <4kYhp1dHgaiW2xq_SWfuSkCfyGrneI_wMEcqg9FamOg=.2f8e140d-fc64-4ea0-b9c9-3f1029cc9918@github.com>
Message-ID: <XSpInTZFhONalSd-ozUOmOhOuSz2Yk-6PrOkvTDZ5jA=.bdd0ecbd-88ba-4906-a981-4a1f3aef4767@github.com>

On Tue, 22 Feb 2022 00:18:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> In the case that a mutator thread fails to evacuate, this patch transitions the Java thread into a VM thread before blocking the thread.  Otherwise, an assertion error is raised.

Looks good to me.

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

Marked as reviewed by wkemper (Committer).

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

From kdnilsen at openjdk.java.net  Tue Feb 22 00:30:52 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 22 Feb 2022 00:30:52 GMT
Subject: Integrated: Mutator may fail to evacuate
In-Reply-To: <4kYhp1dHgaiW2xq_SWfuSkCfyGrneI_wMEcqg9FamOg=.2f8e140d-fc64-4ea0-b9c9-3f1029cc9918@github.com>
References: <4kYhp1dHgaiW2xq_SWfuSkCfyGrneI_wMEcqg9FamOg=.2f8e140d-fc64-4ea0-b9c9-3f1029cc9918@github.com>
Message-ID: <5QZfp_pw6IRSFgo-kMBNV9jnBhdXhPqQwTy04E9Pyi0=.83d9f53d-2396-4b12-94a8-1e975abd059e@github.com>

On Tue, 22 Feb 2022 00:18:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> In the case that a mutator thread fails to evacuate, this patch transitions the Java thread into a VM thread before blocking the thread.  Otherwise, an assertion error is raised.

This pull request has now been integrated.

Changeset: 2132a6d1
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/2132a6d151e4c46b71a220100fa478a8be676f13
Stats:     12 lines in 1 file changed: 8 ins; 0 del; 4 mod

Mutator may fail to evacuate

Reviewed-by: wkemper

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

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

From redestad at openjdk.java.net  Wed Feb 23 12:59:31 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 23 Feb 2022 12:59:31 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v5]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <iboUFKnizUJJqKKF5r316fQmgc6cdwkTGJ4xlfpiTZE=.d7488f69-2e18-4062-bd69-c655fa0a0e11@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
 - aarch64: fix issue with short inputs divisible by wordSize

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/a5e28b32..a95680cb

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

  Stats: 23 lines in 3 files changed: 3 ins; 4 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From mdoerr at openjdk.java.net  Wed Feb 23 13:16:53 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 23 Feb 2022 13:16:53 GMT
Subject: RFR: Generational ShenandoahGC on PPC64
Message-ID: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>

PPC64 code for Generational ShenandoahGC.

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

Commit messages:
 - Generational ShenandoahGC on PPC64

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

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

From redestad at openjdk.java.net  Wed Feb 23 14:19:20 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 23 Feb 2022 14:19:20 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Resolve merge conflict
 - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
 - aarch64: fix issue with short inputs divisible by wordSize
 - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
 - Revert micro changes, split out to #7516
 - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
 - Merge branch 'master' into count_positives
 - Restore partial vector checks in AVX2 and SSE intrinsic variants
 - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
 - Simplify changes to encodeUTF8
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce

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

Changes: https://git.openjdk.java.net/jdk/pull/7231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=05
  Stats: 532 lines in 29 files changed: 308 ins; 53 del; 171 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From wkemper at openjdk.java.net  Wed Feb 23 22:15:32 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 23 Feb 2022 22:15:32 GMT
Subject: RFR: Clear cards for old regions when they are put into service
Message-ID: <Ez3nFAIK8eyECW2cn1nVuSpMCO6vc3yWnJMcBYg5chA=.c1fbafb3-ccbf-4d2f-924f-a3c947add1d5@github.com>

Preemptively clearing cards during recycle for every region adds considerable overhead to the concurrent clean up phase. Moving card clearing transfers the cost of card clearing to the evacuation phase and reduces the cost to only those regions that will be used by the old generation.

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

Commit messages:
 - Remove vestigial instrumentation
 - Only clear cards for regions that transition from free to old

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

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

From kdnilsen at openjdk.java.net  Wed Feb 23 23:28:46 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 23 Feb 2022 23:28:46 GMT
Subject: RFR: Clear cards for old regions when they are put into service
In-Reply-To: <Ez3nFAIK8eyECW2cn1nVuSpMCO6vc3yWnJMcBYg5chA=.c1fbafb3-ccbf-4d2f-924f-a3c947add1d5@github.com>
References: <Ez3nFAIK8eyECW2cn1nVuSpMCO6vc3yWnJMcBYg5chA=.c1fbafb3-ccbf-4d2f-924f-a3c947add1d5@github.com>
Message-ID: <Oy99kRCA3aT-VPXJZD23pwOiM-r288hlL14Zokmh7Zo=.bf033036-9f11-43cc-9ee3-665019a1e780@github.com>

On Wed, 23 Feb 2022 21:54:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Preemptively clearing cards during recycle for every region adds considerable overhead to the concurrent clean up phase. Moving card clearing transfers the cost of card clearing to the evacuation phase and reduces the cost to only those regions that will be used by the old generation.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Thu Feb 24 00:00:48 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 24 Feb 2022 00:00:48 GMT
Subject: Integrated: Clear cards for old regions when they are put into service
In-Reply-To: <Ez3nFAIK8eyECW2cn1nVuSpMCO6vc3yWnJMcBYg5chA=.c1fbafb3-ccbf-4d2f-924f-a3c947add1d5@github.com>
References: <Ez3nFAIK8eyECW2cn1nVuSpMCO6vc3yWnJMcBYg5chA=.c1fbafb3-ccbf-4d2f-924f-a3c947add1d5@github.com>
Message-ID: <-9MxbAMsvx3drggR6pdsgg93SwWIf3zW9Htxtlb4IKw=.de7c8795-c7b0-447c-9dea-1027c4d696f5@github.com>

On Wed, 23 Feb 2022 21:54:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Preemptively clearing cards during recycle for every region adds considerable overhead to the concurrent clean up phase. Moving card clearing transfers the cost of card clearing to the evacuation phase and reduces the cost to only those regions that will be used by the old generation.

This pull request has now been integrated.

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

Clear cards for old regions when they are put into service

Reviewed-by: kdnilsen

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

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

From kdnilsen at openjdk.java.net  Fri Feb 25 00:11:38 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 25 Feb 2022 00:11:38 GMT
Subject: RFR: Generational ShenandoahGC on PPC64
In-Reply-To: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>
References: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>
Message-ID: <3p6yIDvFlzVNMgD_WyHE8wrEdbqlyp0M-eLwaOYdw60=.bed633f5-a662-474a-8ecb-debae281f0b4@github.com>

On Tue, 22 Feb 2022 14:32:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 code for Generational ShenandoahGC.

Marked as reviewed by kdnilsen (Committer).

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

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

From kemperw at amazon.com  Mon Feb 28 23:05:40 2022
From: kemperw at amazon.com (Kemper, William)
Date: Mon, 28 Feb 2022 23:05:40 +0000
Subject: Trouble with LRB cancelling GC and safepoints
Message-ID: <1646089541010.75871@amazon.com>

During testing, we hit an assert caused when a mutator thread failed to evacuate an object and tried to cancel gc:

assert(thread->thread_state() == _thread_in_vm, "coming from wrong thread state");

We reckon this is because the JRT_LEAF macro used for the load reference barrier entry point (shenandoahRuntime.cpp) does not transition threads to the _thread_in_vm state. Threads which enter by means of JRT_LEAF should not take safepoints, hold locks, allocate on the heap, etc. (at least, according to the comments in interfaceSupport.inline.hpp). We tried to fix the issue here: https://github.com/openjdk/shenandoah/pull/117?- but this has just given us a new assert because JRT_LEAF sets up the NoSafepointVerifier and this is directly incompatible with ThreadBlockInVM:


  if (_no_safepoint_count > 0) {
    print_owned_locks();
    assert(false, "Possible safepoint reached by thread that does not allow it");
  }

Do we really need to take a safepoint in ShenandoahHeap::try_cancel_gc? If so, should we use JRT_ENTRY instead of JRT_LEAF? This would mean changing the JIT call sites to pass in the current thread to the mutator LRB.

Thanks,
William


From wkemper at openjdk.java.net  Mon Feb 28 23:40:26 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 28 Feb 2022 23:40:26 GMT
Subject: RFR: Remove young generation access to old generation mark queues
 earlier
Message-ID: <yhnw2hMYJSCtlnksdSO--UH86c5Sl78SpScXy2hXAzM=.45235624-0583-4d02-b7bb-3135f7d53db1@github.com>

Prior to this change, we removed access to the old generation mark queues if (and only if) the old generation cycle completed. However, in some cases, the old generation cycle may be interrupted _after_ it has finished marking but _before_ it has finished preparing for mixed collections. This error may cause young generation cycles to enqueue old objects into the old generation mark queues that may become invalid as mixed collections execute. With this change, we remove access to old generation mark queues as soon as old generation marking is complete.

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

Commit messages:
 - Remove young generation access to old generation mark queues when old marking is complete

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

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

From kdnilsen at openjdk.java.net  Mon Feb 28 23:53:26 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 28 Feb 2022 23:53:26 GMT
Subject: RFR: Remove young generation access to old generation mark queues
 earlier
In-Reply-To: <yhnw2hMYJSCtlnksdSO--UH86c5Sl78SpScXy2hXAzM=.45235624-0583-4d02-b7bb-3135f7d53db1@github.com>
References: <yhnw2hMYJSCtlnksdSO--UH86c5Sl78SpScXy2hXAzM=.45235624-0583-4d02-b7bb-3135f7d53db1@github.com>
Message-ID: <gMU6o-LQ5r8RwlCMGI37Yt2dRgJNIXA7oRwS9tlBo4M=.c1fa5061-5b9c-4b50-a7ac-8111cd76510d@github.com>

On Mon, 28 Feb 2022 23:34:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Prior to this change, we removed access to the old generation mark queues if (and only if) the old generation cycle completed. However, in some cases, the old generation cycle may be interrupted _after_ it has finished marking but _before_ it has finished preparing for mixed collections. This error may cause young generation cycles to enqueue old objects into the old generation mark queues that may become invalid as mixed collections execute. With this change, we remove access to old generation mark queues as soon as old generation marking is complete.

Marked as reviewed by kdnilsen (Committer).

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

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