From stefank at openjdk.java.net  Mon Nov  1 09:31:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 1 Nov 2021 09:31:14 GMT
Subject: RFR: 8275527: Refactor forward pointer access [v4]
In-Reply-To: <tu8-LJVLLI-0yU9Fsvdnqkx9sTkfarZu3XNIElJ0kak=.6c3578d7-0a9a-447e-a167-27c412ac200f@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
 <tu8-LJVLLI-0yU9Fsvdnqkx9sTkfarZu3XNIElJ0kak=.6c3578d7-0a9a-447e-a167-27c412ac200f@github.com>
Message-ID: <L12GPa4-qxtJlMxtEOEpiVc4v1TJ_-DwFqC5DWOarI4=.35af6235-3555-41e6-b0c6-67e011a83829@github.com>

On Thu, 28 Oct 2021 12:35:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.
>> 
>> This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.
>> 
>> Testing:
>>  - [x] tier
>>  - [x] tier2
>>  - [x] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move forward impl into markWord and add assert

Thanks for doing this change. This looks good to me. I've added a comment below that I think would be nice to get resolved somehow, though I don't need to re-review if you update with any of the suggestions.

src/hotspot/share/oops/markWord.hpp line 253:

> 251:     return cast_to_oop(decode_pointer());
> 252:   }
> 253: };

This brings the forwarded/forwardee terminology into the markWord. The markWord was previously decoupled from those to concepts. I would personally let those function names stay in oopDesc and not leak down into the markWord. If you do want to keep it here, could you update the comments at the top that describes the bits?

//    [ptr             | 11]  marked             used to mark an object

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

Marked as reviewed by stefank (Reviewer).

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

From shade at openjdk.java.net  Mon Nov  1 11:30:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Nov 2021 11:30:09 GMT
Subject: RFR: 8276201: Shenandoah: Race results degenerated GC to enter
 wrong entry point
In-Reply-To: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
References: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
Message-ID: <w1nGzVFK8IRH84TgGmFG5fpW6K36CNyqEeqwqZ45bTA=.a7f11edd-988e-4b50-83c3-1a38040f780b@github.com>

On Sat, 30 Oct 2021 12:56:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point.
> 
> Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion.
> 
> The solution is to consult concurrent_mark_in_progress flag when selects degen-point.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Mon Nov  1 12:21:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 12:21:19 GMT
Subject: RFR: 8276201: Shenandoah: Race results degenerated GC to enter
 wrong entry point
In-Reply-To: <w1nGzVFK8IRH84TgGmFG5fpW6K36CNyqEeqwqZ45bTA=.a7f11edd-988e-4b50-83c3-1a38040f780b@github.com>
References: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
 <w1nGzVFK8IRH84TgGmFG5fpW6K36CNyqEeqwqZ45bTA=.a7f11edd-988e-4b50-83c3-1a38040f780b@github.com>
Message-ID: <z22ZOFiVtF_ap5OK36jVhy25GxDo52Luftl9-SL5Okc=.0adc3d4b-7254-4783-8183-464a8448693f@github.com>

On Mon, 1 Nov 2021 11:27:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point.
>> 
>> Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion.
>> 
>> The solution is to consult concurrent_mark_in_progress flag when selects degen-point.
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>
> Looks fine.

Thanks, @shipilev

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

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

From zgu at openjdk.java.net  Mon Nov  1 12:21:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 12:21:19 GMT
Subject: Integrated: 8276201: Shenandoah: Race results degenerated GC to enter
 wrong entry point
In-Reply-To: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
References: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
Message-ID: <Pmw4HY0RiFymeYUzN_9Syeffw3r7DLa6D9EPjlBF_BY=.619b12c2-af25-4aea-89c4-edc08a2c2806@github.com>

On Sat, 30 Oct 2021 12:56:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point.
> 
> Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion.
> 
> The solution is to consult concurrent_mark_in_progress flag when selects degen-point.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: dbf5100d
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8276201: Shenandoah: Race results degenerated GC to enter wrong entry point

Reviewed-by: shade

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

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

From gnu.andrew at redhat.com  Mon Nov  1 14:07:03 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 1 Nov 2021 14:07:03 +0000
Subject: Fwd: [RFR] [8u] 8u312-b07 Upstream Sync
In-Reply-To: <65e322e5-cc26-68f2-d733-94c4bce24b18@redhat.com>
References: <YXdVWGOwIxXzhxiE@hex.discworld.ac.uk>
 <CABi63P7nGhkjf++br_pjfRRGeRpnctP9-Og=oVwoJ53da+-5Uw@mail.gmail.com>
 <65e322e5-cc26-68f2-d733-94c4bce24b18@redhat.com>
Message-ID: <YX/0h66Y5VLJNPcp@hex.discworld.ac.uk>

On 08:11 Fri 29 Oct     , Aleksey Shipilev wrote:
> On 10/28/21 3:49 PM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jaxws/merge.changeset
> 
> Look trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/jdk/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/hotspot/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u312-b07/root/merge.changeset
> 
> Looks trivially good.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

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

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

From zgu at openjdk.java.net  Mon Nov  1 15:28:24 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 15:28:24 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
Message-ID: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>

There are few bugs in current implementation:
1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.

2) Does not notify waiters upon completion of iteration at safepoints

3) Unnecessary held CodeCache_lock during concurrent code cache iteration.

Test:
- [x] hotspot_gc_shenandoah on Linux x86_64
- [x] hotspot_gc_shenandoah on Linux aarch64

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

Commit messages:
 - v0

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

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

From shade at openjdk.java.net  Mon Nov  1 15:55:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Nov 2021 15:55:09 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
Message-ID: <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>

On Mon, 1 Nov 2021 15:19:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are few bugs in current implementation:
> 1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.
> 
> 2) Does not notify waiters upon completion of iteration at safepoints
> 
> 3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64
> - [x] hotspot_gc_shenandoah on Linux aarch64

Looks okay. Do we miss `_codecache_snapshot = NULL;` in  `~ShenandoahConcurrentRootScanner`?

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

Marked as reviewed by shade (Reviewer).

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

From kdnilsen at openjdk.java.net  Mon Nov  1 16:20:50 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 1 Nov 2021 16:20:50 GMT
Subject: Integrated: Fix preempt old preparation
In-Reply-To: <amV9LBZrzry7BV5IhZFm89PnqrPT8Xfgq0UW0-_9OEI=.69a03b96-da70-4a61-8a3f-1af6f06452c1@github.com>
References: <amV9LBZrzry7BV5IhZFm89PnqrPT8Xfgq0UW0-_9OEI=.69a03b96-da70-4a61-8a3f-1af6f06452c1@github.com>
Message-ID: <EvVyTs2zOg9_8HCj1FnK4eRPn5xMMlvxt04XJ35uiUo=.ceeac87c-7f09-43cc-ab30-4b9a99ec563e@github.com>

On Fri, 29 Oct 2021 21:35:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> To address crashes found following integration of "preempt old preparation", several fixes have been implemented:
> 
> 1. Defer mixed evacuations until after coalesce-and-fill is done
> 2. Fix verification of remembered set to use the marking context whenever old-gen is in the process of preparing for mixed evacuations.
> 3. Cosmetic improvement to change "misleading" function names.

This pull request has now been integrated.

Changeset: 5cba4ba9
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/5cba4ba9546243734ec35946cb93e0498cc6f0b4
Stats:     35 lines in 9 files changed: 14 ins; 8 del; 13 mod

Fix preempt old preparation

Reviewed-by: wkemper

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

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

From zgu at openjdk.java.net  Mon Nov  1 16:53:22 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 16:53:22 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
 <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
Message-ID: <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>

On Mon, 1 Nov 2021 15:52:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ShenandoahConcurrentRootScanner

Does it matter?

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

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

From shade at openjdk.java.net  Mon Nov  1 16:53:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Nov 2021 16:53:22 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
 <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
 <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>
Message-ID: <AWyBBKXOnRf3_PPIk6pkH4lV5qOc1OI6VRHhzqbpCGM=.b3ff8dd8-b74b-47c6-8adf-7355688781a0@github.com>

On Mon, 1 Nov 2021 16:48:03 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > ShenandoahConcurrentRootScanner
> 
> Does it matter?

You tell me, I think it would be full of dangling references after we are done with scanner? The similar reason why we do `_table = NULL` in a similar method in another iterator. You don't have to change it here, but maybe a simple cleanup for later.

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

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

From zgu at openjdk.java.net  Mon Nov  1 19:42:18 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 19:42:18 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <AWyBBKXOnRf3_PPIk6pkH4lV5qOc1OI6VRHhzqbpCGM=.b3ff8dd8-b74b-47c6-8adf-7355688781a0@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
 <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
 <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>
 <AWyBBKXOnRf3_PPIk6pkH4lV5qOc1OI6VRHhzqbpCGM=.b3ff8dd8-b74b-47c6-8adf-7355688781a0@github.com>
Message-ID: <9EKpAOjDkyBJXPSt1VO3U9_tmuXzJLdHVGxbetTYF1g=.cdd67c2e-0ca7-407f-8d88-888d15c1c0b0@github.com>

On Mon, 1 Nov 2021 16:49:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > ShenandoahConcurrentRootScanner
> > 
> > 
> > Does it matter?
> 
> You tell me, I think it would be full of dangling references after we are done with scanner? The similar reason why we do `_table = NULL` in a similar method in another iterator. You don't have to change it here, but maybe a simple cleanup for later.

Yea, there is inconsistent among these iterators. The code is in destructors, I don't see it matters, cause accessing dangling references in a deallocated object is a fatal bug.

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

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

From zgu at openjdk.java.net  Mon Nov  1 19:42:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 19:42:19 GMT
Subject: Integrated: 8276205: Shenandoah: CodeCache_lock should always be held
 for initializing code cache iteration
In-Reply-To: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
Message-ID: <ECwA5mrvfSWvzMRJ3ruY4Zupk81ejq_tZ0F_v2o3Qv8=.bc3897b8-7f98-4b25-b4b0-c2f89c290804@github.com>

On Mon, 1 Nov 2021 15:19:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are few bugs in current implementation:
> 1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.
> 
> 2) Does not notify waiters upon completion of iteration at safepoints
> 
> 3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64
> - [x] hotspot_gc_shenandoah on Linux aarch64

This pull request has now been integrated.

Changeset: 99b7b95e
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99b7b95e014da6e491ba7adfd21de53d6ae166fe
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration

Reviewed-by: shade

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

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

From ihse at openjdk.java.net  Thu Nov  4 10:51:27 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 10:51:27 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
Message-ID: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>

I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

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

Commit messages:
 - 8276628: Use blessed modifier order in serviceability code

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

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

From dholmes at openjdk.java.net  Thu Nov  4 12:23:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Nov 2021 12:23:23 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <U_K0loGNtPPxro0uV5tcd2s8TJvDoA2niwrl2wOp0RE=.6610b7a7-0d97-4172-b7be-35b2f5aba7c2@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Looks fine to me.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Nov  4 14:26:10 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 4 Nov 2021 14:26:10 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <eUAIYw2CAhxBKXU3qG24cChmOkmFuZBtom-XT-XRXkA=.5ac70260-2594-4230-b6e1-103bb5c260b2@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by lmesnik (Reviewer).

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

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

From cjplummer at openjdk.java.net  Thu Nov  4 16:03:21 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Nov 2021 16:03:21 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Copyright updates?

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

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

From ihse at openjdk.java.net  Thu Nov  4 17:07:24 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:07:24 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>
Message-ID: <NX5Z8gVBGw82IJ7UtNOmZPwzD6D---Nj3uiBZQeEhqU=.8bbccacb-32bd-4bbb-9c66-a6ef20a32eda@github.com>

On Thu, 4 Nov 2021 15:59:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Copyright updates?

@plummercj That's really kind of an edge case, considering the triviality of these changes. But yes, the norm in the JDK is to update the copyright year for all changes, so you're right, I should do that.

(And we *really* ought to wrangle free some resources to write tooling for us to do all the copyright dances...)

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

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

From ihse at openjdk.java.net  Thu Nov  4 17:36:52 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:36:52 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6249/files
  - new: https://git.openjdk.java.net/jdk/pull/6249/files/cf5db105..8a5ff8a5

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

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

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

From cjplummer at openjdk.java.net  Thu Nov  4 18:08:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Nov 2021 18:08:11 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <-iSUoILuWhTb2AgWH-HGAsEm4Nvo8Fl6NIVaiFTY3Lo=.5ec41a0d-e7f3-4f57-b651-7c1971f48e3c@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Marked as reviewed by cjplummer (Reviewer).

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

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

From dholmes at openjdk.java.net  Fri Nov  5 00:38:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 5 Nov 2021 00:38:13 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <7jntohY4FpQYK4L1W1l8wkvamKZhSTjXqtS0CEYIJ7k=.0e5e17bf-d6e5-41dc-8ffd-e30fb4803a29@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Good catch on copyright updates @plummercj ! We always have to update when we modify a file - the one exception is changing the wording of the copyright notice itself.

Looks good.

David

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

Marked as reviewed by dholmes (Reviewer).

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

From ihse at openjdk.java.net  Fri Nov  5 12:11:18 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 12:11:18 GMT
Subject: Integrated: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <2SDPO7MFjKGYKDVlnVRdStd7XwlgsX3XA9PMfIGph5g=.8efd0769-4b5b-4014-b4ea-b6043f45b97f@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has now been integrated.

Changeset: 7023b3f8
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b
Stats:     284 lines in 89 files changed: 0 ins; 0 del; 284 mod

8276628: Use blessed modifier order in serviceability code

Reviewed-by: dholmes, lmesnik, cjplummer

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

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

From asarkar at openjdk.java.net  Mon Nov  8 04:20:39 2021
From: asarkar at openjdk.java.net (Anirvan Sarkar)
Date: Mon, 8 Nov 2021 04:20:39 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <c_E3qAG1nXTRWsQtbzJRtlEfQ7QBdawM4TWIzwaR1Mo=.5d37fd57-cf4f-4193-8ecb-8be0b169b989@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

> (And we _really_ ought to wrangle free some resources to write tooling for us to do all the copyright dances...)

OpenJFX team seems to have a copyright update script[1].
Maybe @kevinrushforth can tell if it can be retrofitted and used by OpenJDK project.

[1] : https://bugs.openjdk.java.net/browse/JDK-8214793?focusedCommentId=14233661&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14233661

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

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

From duke at openjdk.java.net  Tue Nov  9 10:06:42 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 9 Nov 2021 10:06:42 GMT
Subject: Withdrawn: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering
In-Reply-To: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
Message-ID: <fRokf_yhB5g276oiNbLz9gGYTGYn7kygJj5SyGGcFTM=.a09e8aec-64a6-4111-8edd-ce5d00730150@github.com>

On Wed, 10 Feb 2021 08:55:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

From zgu at openjdk.java.net  Tue Nov  9 16:09:56 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 16:09:56 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails intermittently
 with Shenandoah
Message-ID: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>

JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.

This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.

Test:

- [x] hotspot_gc_shenandoah
- [x] Stress test on gc/stress/CriticalNativeStress.java

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

Commit messages:
 - Consistent assert
 - Strength assert
 - v0

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

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

From shade at openjdk.java.net  Tue Nov  9 16:32:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 16:32:36 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>

On Tue, 9 Nov 2021 15:08:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 119:

> 117: 
> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");

I don't understand this change.

This method is called from:


   // Unregister must be done before the state change
  {
    MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
                     Mutex::_no_safepoint_check_flag);
    Universe::heap()->unregister_nmethod(this);
  }


...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.

src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 283:

> 281:     data->update();
> 282:   } else {
> 283:     // For a new nmethod, we can safely append it to the list, cause

Suggestion:

    // For a new nmethod, we can safely append it to the list, because

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

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

From zgu at openjdk.java.net  Tue Nov  9 17:33:04 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 17:33:04 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:

 - Revert assertion for unregister_nmethod
 - Fix comment as Aleksey suggested

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6316/files
  - new: https://git.openjdk.java.net/jdk/pull/6316/files/aaebcb81..0248f1e4

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

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

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

From zgu at openjdk.java.net  Tue Nov  9 17:33:08 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 17:33:08 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
Message-ID: <haHFS3HMAx7NN1Yzk1PziYn_Zdd9HD7XQPbQkAaCnEg=.982cebf4-e325-4fa4-8a96-686677ea9173@github.com>

On Tue, 9 Nov 2021 16:25:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert assertion for unregister_nmethod
>>  - Fix comment as Aleksey suggested
>
> src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 283:
> 
>> 281:     data->update();
>> 282:   } else {
>> 283:     // For a new nmethod, we can safely append it to the list, cause
> 
> Suggestion:
> 
>     // For a new nmethod, we can safely append it to the list, because

Fixed

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

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

From zgu at openjdk.java.net  Tue Nov  9 17:46:38 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 17:46:38 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
Message-ID: <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>

On Tue, 9 Nov 2021 16:29:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert assertion for unregister_nmethod
>>  - Fix comment as Aleksey suggested
>
> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 119:
> 
>> 117: 
>> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
>> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");
> 
> I don't understand this change.
> 
> This method is called from:
> 
> 
>    // Unregister must be done before the state change
>   {
>     MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
>                      Mutex::_no_safepoint_check_flag);
>     Universe::heap()->unregister_nmethod(this);
>   }
> 
> 
> ...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.

Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().

Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 

It is not true for flush_nmethod(), where `CodeCache_lock` must be held.

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

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

From shade at openjdk.java.net  Tue Nov  9 17:53:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 17:53:34 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
 <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
Message-ID: <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>

On Tue, 9 Nov 2021 17:43:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 119:
>> 
>>> 117: 
>>> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
>>> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");
>> 
>> I don't understand this change.
>> 
>> This method is called from:
>> 
>> 
>>    // Unregister must be done before the state change
>>   {
>>     MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
>>                      Mutex::_no_safepoint_check_flag);
>>     Universe::heap()->unregister_nmethod(this);
>>   }
>> 
>> 
>> ...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.
>
> Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().
> 
> Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 
> 
> It is not true for flush_nmethod(), where `CodeCache_lock` must be held.

What about `register_nmethod`? I see it is called from `nmethod::nmethod` that itself does `assert_locked_or_safepoint(CodeCache_lock)`. Is that path guaranteed to always hold the `CodeCache_lock`?

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

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

From zgu at openjdk.java.net  Wed Nov 10 02:13:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 02:13:37 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
 <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
 <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>
Message-ID: <L88acYPMjES7iP1Qja8NmqpC92qZELfmLHVI5c3ULHk=.80fd986c-3bb4-42a7-9db4-f136dd5060d5@github.com>

On Tue, 9 Nov 2021 17:50:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().
>> 
>> Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 
>> 
>> It is not true for flush_nmethod(), where `CodeCache_lock` must be held.
>
> What about `register_nmethod`? I see it is called from `nmethod::nmethod` that itself does `assert_locked_or_safepoint(CodeCache_lock)`. Is that path guaranteed to always hold the `CodeCache_lock`?

I changed assert in `nmethod::nmethod()` to `assert_lock_strong(CodeCache_lock)` and ran tier1, no failure.

`nmethods` is installed by `CompilerThread` and `CompilerThread` is `JavaThread`, so I don't think it is possible to have `register_nmethod()` call at safepoints, because they have to participate in safepoints.

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

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

From shade at openjdk.java.net  Wed Nov 10 07:58:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 07:58:38 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
Message-ID: <9p0dnTkpMvFGxsre3rUtXTWocsPXr_n355G_oVXiY0s=.d68e3f95-f022-4af2-9689-d9ee948dca5e@github.com>

On Tue, 9 Nov 2021 17:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert assertion for unregister_nmethod
>  - Fix comment as Aleksey suggested

I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table (https://github.com/openjdk/jdk/pull/6316/commits/0248f1e4cd6a8311f0532c637a31bd71c9041451), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?

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

Changes requested by shade (Reviewer).

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

From shade at openjdk.java.net  Wed Nov 10 07:58:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 07:58:38 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <L88acYPMjES7iP1Qja8NmqpC92qZELfmLHVI5c3ULHk=.80fd986c-3bb4-42a7-9db4-f136dd5060d5@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
 <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
 <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>
 <L88acYPMjES7iP1Qja8NmqpC92qZELfmLHVI5c3ULHk=.80fd986c-3bb4-42a7-9db4-f136dd5060d5@github.com>
Message-ID: <l6SM550RuUAfOQMDvfngXOztaCHIsfPdzmUeqDzwAN4=.4c1cb2a9-94d9-4327-aa3e-2d17ee344f9a@github.com>

On Wed, 10 Nov 2021 02:11:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> What about `register_nmethod`? I see it is called from `nmethod::nmethod` that itself does `assert_locked_or_safepoint(CodeCache_lock)`. Is that path guaranteed to always hold the `CodeCache_lock`?
>
> I changed assert in `nmethod::nmethod()` to `assert_lock_strong(CodeCache_lock)` and ran tier1, no failure.
> 
> `nmethods` is installed by `CompilerThread` and `CompilerThread` is `JavaThread`, so I don't think it is possible to have `register_nmethod()` call at safepoints, because they have to participate in safepoints.

OK.

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

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

From rkennke at openjdk.java.net  Wed Nov 10 12:52:08 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 10 Nov 2021 12:52:08 GMT
Subject: RFR: 8275527: Refactor forward pointer access [v5]
In-Reply-To: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
Message-ID: <Go6Jy3r74trkRi0_l3mXStP7uky_iN4C6Q3SF5fmkvE=.d754aa25-b4a8-4da0-a9b3-978616814577@github.com>

> Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.
> 
> This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.
> 
> Testing:
>  - [x] tier
>  - [x] tier2
>  - [x] hotspot_gc

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

 - Merge branch 'master' into optimize-fwdptr
 - Don't use forwarded terminology in markWord
 - Move forward impl into markWord and add assert
 - Fix Parallel GC mistake
 - Revert unnecessary changes
 - Update some copyright headers
 - Add missing includes
 - Merge branch 'master' into optimize-fwdptr
 - Add missing includes
 - Rename mwd -> fwd
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a0b84453...d63962a3

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

Changes: https://git.openjdk.java.net/jdk/pull/5955/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=04
  Stats: 46 lines in 9 files changed: 4 ins; 26 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5955.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955

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

From rkennke at openjdk.java.net  Wed Nov 10 12:52:13 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 10 Nov 2021 12:52:13 GMT
Subject: RFR: 8275527: Refactor forward pointer access [v4]
In-Reply-To: <L12GPa4-qxtJlMxtEOEpiVc4v1TJ_-DwFqC5DWOarI4=.35af6235-3555-41e6-b0c6-67e011a83829@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
 <tu8-LJVLLI-0yU9Fsvdnqkx9sTkfarZu3XNIElJ0kak=.6c3578d7-0a9a-447e-a167-27c412ac200f@github.com>
 <L12GPa4-qxtJlMxtEOEpiVc4v1TJ_-DwFqC5DWOarI4=.35af6235-3555-41e6-b0c6-67e011a83829@github.com>
Message-ID: <SGF7uMA7SPhrRgfwADj4Zzge8NjfF5Gc2V4gzYt8JFo=.fd35c039-67b3-4539-824e-281671e2ffef@github.com>

On Mon, 1 Nov 2021 09:25:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move forward impl into markWord and add assert
>
> src/hotspot/share/oops/markWord.hpp line 253:
> 
>> 251:     return cast_to_oop(decode_pointer());
>> 252:   }
>> 253: };
> 
> This brings the forwarded/forwardee terminology into the markWord. The markWord was previously decoupled from those to concepts. I would personally let those function names stay in oopDesc and not leak down into the markWord. If you do want to keep it here, could you update the comments at the top that describes the bits?
> 
> //    [ptr             | 11]  marked             used to mark an object

Yeah, I am not quite sure about this. We have a couple of places where we need to use the markWord direcly, and they read m.is_marked() (when it really means is_forwarded, even though it's the same in the implementation), and then goes on to cast_to_oop(m.decode_pointer()) which reads more ugly than simply m.forwardee() which also comes with an assert and the cast.

I reverted the markWord change and related call-sites now. Maybe this warrants more thinking/discussion.

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

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

From zgu at openjdk.java.net  Wed Nov 10 13:11:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 13:11:37 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
Message-ID: <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>

On Tue, 9 Nov 2021 17:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert assertion for unregister_nmethod
>  - Fix comment as Aleksey suggested

> I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?

It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81) although previous version passed GHA

I will take a further look in separate CR see if we can cleanup a bit.

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

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

From shade at openjdk.java.net  Wed Nov 10 17:00:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 17:00:36 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
 <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>
Message-ID: <N6_Gr8UrKzkJ2qEgGpZENvKiqa0FY0a9gW_MMnGR5EQ=.c70d4bde-23c0-4a1f-93a9-421957e82171@github.com>

On Wed, 10 Nov 2021 13:08:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?
> 
> It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81)
> 
> I will take a further look in separate CR see if we can cleanup a bit.

Why further CR, though? I think current code is guaranteed to fail that new assert during STW unloading? If so, we need to keep `assert_locked_or_safepoint` intact.

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

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

From zgu at openjdk.java.net  Wed Nov 10 17:14:06 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 17:14:06 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v3]
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <UJk--2pUUeXFFjB_CrbrwMwRnI3bAFi9uJ6Lj3-0_CU=.ad036882-4d8f-4dd2-9d06-d3f357fd6c80@github.com>

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

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

  Fixed incomplete inversion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6316/files
  - new: https://git.openjdk.java.net/jdk/pull/6316/files/0248f1e4..8e07b342

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

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

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

From zgu at openjdk.java.net  Wed Nov 10 17:14:07 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 17:14:07 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <N6_Gr8UrKzkJ2qEgGpZENvKiqa0FY0a9gW_MMnGR5EQ=.c70d4bde-23c0-4a1f-93a9-421957e82171@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
 <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>
 <N6_Gr8UrKzkJ2qEgGpZENvKiqa0FY0a9gW_MMnGR5EQ=.c70d4bde-23c0-4a1f-93a9-421957e82171@github.com>
Message-ID: <PD3iZQR0qtO0qWcmnlDDEkDS2Nq6Pyhta6Zy28X41i0=.d721ccdb-2032-43bc-92f8-866c188e73f6@github.com>

On Wed, 10 Nov 2021 16:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?
> > 
> > 
> > It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81)
> > I will take a further look in separate CR see if we can cleanup a bit.
> 
> Why further CR, though? I think current code is guaranteed to fail that new assert during STW unloading? If so, we need to keep `assert_locked_or_safepoint` intact.

Oops, misread you comments. Previous reversion of the assertion was incomplete. Updated.

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

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

From zgu at openjdk.java.net  Wed Nov 10 17:19:55 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 17:19:55 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v4]
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <ty4aZ5Sv0mln8CdyzTLbUAwLE8YqHXHpkA77rNwvK_M=.7ae8c23f-4587-4204-a579-fa884279bc5d@github.com>

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

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

  Reverted wrong method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6316/files
  - new: https://git.openjdk.java.net/jdk/pull/6316/files/8e07b342..0a2ef517

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

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

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

From shade at openjdk.java.net  Wed Nov 10 17:19:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 17:19:56 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v3]
In-Reply-To: <UJk--2pUUeXFFjB_CrbrwMwRnI3bAFi9uJ6Lj3-0_CU=.ad036882-4d8f-4dd2-9d06-d3f357fd6c80@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <UJk--2pUUeXFFjB_CrbrwMwRnI3bAFi9uJ6Lj3-0_CU=.ad036882-4d8f-4dd2-9d06-d3f357fd6c80@github.com>
Message-ID: <TLxzl9pEkjRnkPhrL-9sclBL5UjfcBey2-E3x2jCgJA=.812ecb72-5b31-469d-8328-cc5871930f43@github.com>

On Wed, 10 Nov 2021 17:14:06 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed incomplete inversion

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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

From wkemper at openjdk.java.net  Wed Nov 10 19:14:21 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 10 Nov 2021 19:14:21 GMT
Subject: RFR: Padding used for alignment must fit an object
Message-ID: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>

In some cases, alignment of new plabs on card boundaries may create padding which is too small to fill with an object. When this case is detected, we align on the plab on the next card boundary.

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

Commit messages:
 - Padding used for alignment must fit an object

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

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

From rkennke at openjdk.java.net  Wed Nov 10 19:26:07 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 10 Nov 2021 19:26:07 GMT
Subject: RFR: Padding used for alignment must fit an object
In-Reply-To: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>
References: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>
Message-ID: <id8-NSyaAapT5Ce8q9pm1Pm04ANgENq1OVBi_KFpmM4=.321649ed-0c47-4cac-a1c8-731e22feb18e@github.com>

On Wed, 10 Nov 2021 19:09:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, alignment of new plabs on card boundaries may create padding which is too small to fill with an object. When this case is detected, we align on the plab on the next card boundary.

Marked as reviewed by rkennke (Lead).

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

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

From kdnilsen at openjdk.java.net  Wed Nov 10 19:34:09 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 10 Nov 2021 19:34:09 GMT
Subject: RFR: Padding used for alignment must fit an object
In-Reply-To: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>
References: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>
Message-ID: <xFEtWrWKhSKm4FcugYUtVYq7Qr6Q-0VRep8vPoNB1p4=.f0fd4207-d629-40a6-a850-6ac2fff4ef41@github.com>

On Wed, 10 Nov 2021 19:09:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, alignment of new plabs on card boundaries may create padding which is too small to fill with an object. When this case is detected, we align on the plab on the next card boundary.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Wed Nov 10 19:34:09 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 10 Nov 2021 19:34:09 GMT
Subject: Integrated: Padding used for alignment must fit an object
In-Reply-To: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>
References: <FAVRiBq6Ghjz0SM06SfU4jEAIVra4bQB37Hxl-Kha40=.6158d2c6-f029-4273-ae2f-6242af3dd47b@github.com>
Message-ID: <2XgUz3E-ZNIp4pqX4SsL72CcqNss0ABkMss4YDG_Vug=.0b9aab71-becf-43be-960d-841b3c0a3d7e@github.com>

On Wed, 10 Nov 2021 19:09:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, alignment of new plabs on card boundaries may create padding which is too small to fill with an object. When this case is detected, we align on the plab on the next card boundary.

This pull request has now been integrated.

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

Padding used for alignment must fit an object

Reviewed-by: rkennke

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

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

From zgu at openjdk.java.net  Thu Nov 11 00:18:42 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 11 Nov 2021 00:18:42 GMT
Subject: Integrated: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <ypUNyO8XV3WLEVb4nuEzVHGpK1bl_Yja1sMPAieA0Hg=.5b4a3678-00a5-4b79-9a28-372bab1747cf@github.com>

On Tue, 9 Nov 2021 15:08:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

This pull request has now been integrated.

Changeset: 73e6d7d7
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/73e6d7d74d2ddd27f11775944c6fc4fb5268106d
Stats:     10 lines in 2 files changed: 7 ins; 1 del; 2 mod

8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah

Reviewed-by: shade

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

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

From nradomski at openjdk.java.net  Thu Nov 11 10:16:58 2021
From: nradomski at openjdk.java.net (Niklas Radomski)
Date: Thu, 11 Nov 2021 10:16:58 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
Message-ID: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>

Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.

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

Commit messages:
 - Port shenandoahgc to linux on ppc64le

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

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

From rkennke at openjdk.java.net  Thu Nov 11 12:10:41 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 11 Nov 2021 12:10:41 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
Message-ID: <CYnzc3NijRkUPtdp1X1qypAbyejCK3jNLo2xMKLX9kI=.a7642bbe-d06f-4228-a5de-12abc229ea0e@github.com>

On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.

Hi Niklas,
thanks for this awesome work!
I can't really comment on the actual PPC code, so this needs to be reviewed by somebody else. Structurally the change looks correct. I have one comment about the C1 CAS barrier code, but it's minor.

Thanks & cheers,
Roman

src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:

> 81:     LIRGenerator* gen = access.gen();
> 82: 
> 83:     if (ShenandoahCASBarrier) {

I am not sure, but I almost think we should not even end up in the method with -ShenandoahCASBarrier. If anything, -ShenandoahCASBarrier should result in only calling super to emit regular CAS without any barriers.

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

Marked as reviewed by rkennke (Reviewer).

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

From ihse at openjdk.java.net  Thu Nov 11 12:21:32 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 11 Nov 2021 12:21:32 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
Message-ID: <p5_Yq4EdKsNbeyRzUB6qLuaW0vi5K5lyRz08dd2Facg=.c38b5711-f84b-4692-863c-80628c425002@github.com>

On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.

Build changes look good. Actual code changes needs to be reviewed by someone more knowledgable about this area.

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

Marked as reviewed by ihse (Reviewer).

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

From mdoerr at openjdk.java.net  Thu Nov 11 14:34:39 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 11 Nov 2021 14:34:39 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
Message-ID: <bN4qbfy9l9Ok6oGyT6nFbChiJ1KWcmUdGXnvRzKrKfQ=.89568c7c-64d8-4d5f-b191-64b7f4eea03e@github.com>

On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.

Nice work! Looks correct.
For others: Note that this change already contains feedback from my offline review.

src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 74:

> 72:   // IU barriers are also employed to avoid resurrection of weak references,
> 73:   // even if Shenandoah does not operate in incremental update mode.
> 74:   if (ShenandoahIUBarrier || ShenandoahSATBBarrier) {

Sharing the code for IU and SATB sounds like a good idea, but one needs to be careful. `ShenandoahBarrierSetC1::iu_barrier` only works with `ShenandoahIUBarrier`, so this trick can't be used in C1.
It's a bit confusing, but I'm ok with this version. At least, I don't have any better suggestion at the moment.

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

Marked as reviewed by mdoerr (Reviewer).

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

From mdoerr at openjdk.java.net  Thu Nov 11 14:34:40 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 11 Nov 2021 14:34:40 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <CYnzc3NijRkUPtdp1X1qypAbyejCK3jNLo2xMKLX9kI=.a7642bbe-d06f-4228-a5de-12abc229ea0e@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
 <CYnzc3NijRkUPtdp1X1qypAbyejCK3jNLo2xMKLX9kI=.a7642bbe-d06f-4228-a5de-12abc229ea0e@github.com>
Message-ID: <DTQUurFfPYzfWEKpAn3HoYBP-Prc3fMuqatSgR90jXo=.1de8de99-f815-4f55-ab78-e02979669bbe@github.com>

On Thu, 11 Nov 2021 11:32:49 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.
>
> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
> 
>> 81:     LIRGenerator* gen = access.gen();
>> 82: 
>> 83:     if (ShenandoahCASBarrier) {
> 
> I am not sure, but I almost think we should not even end up in the method with -ShenandoahCASBarrier. If anything, -ShenandoahCASBarrier should result in only calling super to emit regular CAS without any barriers.

We hit this case when running `jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=passive -version`. x86 and aarch64 check for ShenandoahCASBarrier, too. So, looks like these checks are needed and correct.

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

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

From rkennke at openjdk.java.net  Thu Nov 11 15:04:36 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 11 Nov 2021 15:04:36 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <DTQUurFfPYzfWEKpAn3HoYBP-Prc3fMuqatSgR90jXo=.1de8de99-f815-4f55-ab78-e02979669bbe@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
 <CYnzc3NijRkUPtdp1X1qypAbyejCK3jNLo2xMKLX9kI=.a7642bbe-d06f-4228-a5de-12abc229ea0e@github.com>
 <DTQUurFfPYzfWEKpAn3HoYBP-Prc3fMuqatSgR90jXo=.1de8de99-f815-4f55-ab78-e02979669bbe@github.com>
Message-ID: <SGw7obFEhdoysPmULhEO9gbLKMqLpd_eFVwnGgjaH1E=.edf084e8-644b-4c7b-9b1b-c8bb04261291@github.com>

On Thu, 11 Nov 2021 14:30:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
>> 
>>> 81:     LIRGenerator* gen = access.gen();
>>> 82: 
>>> 83:     if (ShenandoahCASBarrier) {
>> 
>> I am not sure, but I almost think we should not even end up in the method with -ShenandoahCASBarrier. If anything, -ShenandoahCASBarrier should result in only calling super to emit regular CAS without any barriers.
>
> We hit this case when running `jdk/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=passive -version`. x86 and aarch64 check for ShenandoahCASBarrier, too. So, looks like these checks are needed and correct.

Ok then.

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

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

From mdoerr at openjdk.java.net  Thu Nov 11 16:35:32 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 11 Nov 2021 16:35:32 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
Message-ID: <R53ktrivQCqxHDKeS6rHMWRb9qjV0fxZi9-4npAOOFE=.b20d0f43-5eaf-4825-a876-74cfecbf1e12@github.com>

On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.

src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 536:

> 534:   if (!preserve_gp_registers) { __ clobber_volatile_gprs(dst); }
> 535:   if (!needs_frame) { __ clobber_carg_stack_slots(tmp1); }
> 536: #endif

This clobber code was certainly good during development and early testing. But is it worth keeping it? Other GCs and other places don't have it any more. So, I'd slightly prefer removal. Feel free to do so if you agree.

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

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

From wkemper at openjdk.java.net  Thu Nov 11 18:51:21 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 11 Nov 2021 18:51:21 GMT
Subject: RFR: Remove assert that plab allocation must succeed
Message-ID: <4EJnudUS7CXN-Y_Hk6agSrxcaeXbR4qQ9dL-PS7ulBI=.5c20755a-d0d6-4e44-be12-4a6598f8cc1b@github.com>

In some cases, plab alignment will eat into the usable free memory for the region so we cannot assert that the allocation must succeed.

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

Commit messages:
 - Remove assert that plab allocation must succeed

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

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

From zgu at redhat.com  Tue Nov 16 19:18:06 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 16 Nov 2021 14:18:06 -0500
Subject: [sh/jdk8u] RFR 8276201: Shenandoah: Race results degenerated GC to
 enter wrong entry point
Message-ID: <9fd16555-6842-35cf-0fed-257a583ba961@redhat.com>

I would like to backport this patch to Shenandoah/8u. This is a day-one bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8276201
Patch: 
https://github.com/openjdk/jdk/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106

The original patch does not apply cleanly, but fix is simple and can 
easily applied to sh/8u tree.

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8276201-8u/webrev.00/

Test:
   hotspot_gc_shenandoah


Thanks,

-Zhengyu


From kdnilsen at openjdk.java.net  Tue Nov 16 20:50:14 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 16 Nov 2021 20:50:14 GMT
Subject: RFR: Remove assert that plab allocation must succeed
In-Reply-To: <4EJnudUS7CXN-Y_Hk6agSrxcaeXbR4qQ9dL-PS7ulBI=.5c20755a-d0d6-4e44-be12-4a6598f8cc1b@github.com>
References: <4EJnudUS7CXN-Y_Hk6agSrxcaeXbR4qQ9dL-PS7ulBI=.5c20755a-d0d6-4e44-be12-4a6598f8cc1b@github.com>
Message-ID: <WJtXgynadP8IgLfZ6iINQpTk_NCigKfCr36R9vnnYmQ=.09538f13-aa43-4a9f-83d5-126ba3acd642@github.com>

On Thu, 11 Nov 2021 18:44:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, plab alignment will eat into the usable free memory for the region so we cannot assert that the allocation must succeed.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Tue Nov 16 21:46:13 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 16 Nov 2021 21:46:13 GMT
Subject: Integrated: Remove assert that plab allocation must succeed
In-Reply-To: <4EJnudUS7CXN-Y_Hk6agSrxcaeXbR4qQ9dL-PS7ulBI=.5c20755a-d0d6-4e44-be12-4a6598f8cc1b@github.com>
References: <4EJnudUS7CXN-Y_Hk6agSrxcaeXbR4qQ9dL-PS7ulBI=.5c20755a-d0d6-4e44-be12-4a6598f8cc1b@github.com>
Message-ID: <RDfvX_6FdcdldPOJGqZ42RNN_43QepN0mcXR1oTgBZ0=.41186442-0009-46f5-b151-46a84038306e@github.com>

On Thu, 11 Nov 2021 18:44:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, plab alignment will eat into the usable free memory for the region so we cannot assert that the allocation must succeed.

This pull request has now been integrated.

Changeset: 641e665c
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/641e665cb30e3296b2f8ee942c00d616c0ca9cd0
Stats:     11 lines in 1 file changed: 0 ins; 1 del; 10 mod

Remove assert that plab allocation must succeed

Reviewed-by: kdnilsen

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

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

From shade at redhat.com  Wed Nov 17 15:06:59 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Nov 2021 16:06:59 +0100
Subject: [sh/jdk8u] RFR 8276201: Shenandoah: Race results degenerated GC
 to enter wrong entry point
In-Reply-To: <9fd16555-6842-35cf-0fed-257a583ba961@redhat.com>
References: <9fd16555-6842-35cf-0fed-257a583ba961@redhat.com>
Message-ID: <249252db-210f-559e-b62d-8a523edef2eb@redhat.com>

On 11/16/21 8:18 PM, Zhengyu Gu wrote:
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8276201-8u/webrev.00/

Looks fine.

This reminds me I forgot to pull upstream 8u to sh/jdk8. Did so now. Please rebase your patch before 
push.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Nov 17 15:05:30 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:30 +0000
Subject: hg: shenandoah/jdk8: 5 new changesets
Message-ID: <202111171505.1AHF5Vvo013949@aojmv0008.oracle.com>

Changeset: a37840571c31
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/a37840571c31

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset 1f8dd58efb0f

! .hgtags

Changeset: dcb218f54ca1
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/dcb218f54ca1

Added tag jdk8u312-b06 for changeset 7159d482bda2

! .hgtags

Changeset: 49aed62b0e39
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/49aed62b0e39

Added tag jdk8u312-b07 for changeset dcb218f54ca1

! .hgtags

Changeset: eb72fe580cd2
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/eb72fe580cd2

Merge jdk8u312-b07

! .hgtags

Changeset: 72daf280becf
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/72daf280becf

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset eb72fe580cd2

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:29 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:29 +0000
Subject: hg: shenandoah/jdk8/langtools: 5 new changesets
Message-ID: <202111171505.1AHF5T9A013794@aojmv0008.oracle.com>

Changeset: a545dc4b024f
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a545dc4b024f

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset a5506f237c4b

! .hgtags

Changeset: 67e50991d2ff
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/67e50991d2ff

Added tag jdk8u312-b06 for changeset 9472308f16d4

! .hgtags

Changeset: 4b0799427490
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/4b0799427490

Added tag jdk8u312-b07 for changeset 67e50991d2ff

! .hgtags

Changeset: 459b3c362e66
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/459b3c362e66

Merge jdk8u312-b07

! .hgtags

Changeset: bbaf262470b0
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/bbaf262470b0

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset 459b3c362e66

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:31 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:31 +0000
Subject: hg: shenandoah/jdk8/jaxws: 5 new changesets
Message-ID: <202111171505.1AHF5VL7013975@aojmv0008.oracle.com>

Changeset: 19a777a04209
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/19a777a04209

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset 6f4c9005f4f4

! .hgtags

Changeset: c31b33f7a368
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/c31b33f7a368

Added tag jdk8u312-b06 for changeset 70fa0fdf6a6c

! .hgtags

Changeset: b98d99c3e6fe
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/b98d99c3e6fe

Added tag jdk8u312-b07 for changeset c31b33f7a368

! .hgtags

Changeset: d36337b02346
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/d36337b02346

Merge jdk8u312-b07

! .hgtags

Changeset: 8ad98ba26069
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/8ad98ba26069

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset d36337b02346

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:29 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:29 +0000
Subject: hg: shenandoah/jdk8/corba: 5 new changesets
Message-ID: <202111171505.1AHF5TTL013793@aojmv0008.oracle.com>

Changeset: 0987d8a85696
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/0987d8a85696

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset 43c755ea428a

! .hgtags

Changeset: fc16e4d4edb4
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/fc16e4d4edb4

Added tag jdk8u312-b06 for changeset d514245c66bd

! .hgtags

Changeset: b532b79eed6e
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/b532b79eed6e

Added tag jdk8u312-b07 for changeset fc16e4d4edb4

! .hgtags

Changeset: 60ab28bf1d7e
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/60ab28bf1d7e

Merge jdk8u312-b07

! .hgtags

Changeset: 33c9dcad53c1
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/33c9dcad53c1

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset 60ab28bf1d7e

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:30 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:30 +0000
Subject: hg: shenandoah/jdk8/jaxp: 5 new changesets
Message-ID: <202111171505.1AHF5UQf013853@aojmv0008.oracle.com>

Changeset: 63ba10daa156
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/63ba10daa156

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset 167bbbcabde9

! .hgtags

Changeset: 0a8784c38f09
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/0a8784c38f09

Added tag jdk8u312-b06 for changeset 2ffc0e316b15

! .hgtags

Changeset: e5889d27a5cb
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/e5889d27a5cb

Added tag jdk8u312-b07 for changeset 0a8784c38f09

! .hgtags

Changeset: 9484479d4a1f
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/9484479d4a1f

Merge jdk8u312-b07

! .hgtags

Changeset: f07ab447214c
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxp/rev/f07ab447214c

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset 9484479d4a1f

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:33 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:33 +0000
Subject: hg: shenandoah/jdk8/hotspot: 9 new changesets
Message-ID: <202111171505.1AHF5X1M013982@aojmv0008.oracle.com>

Changeset: f0f274f48367
Author:    shade
Date:      2021-10-07 17:04 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f0f274f48367

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset 17d6c475d565

! .hgtags

Changeset: 35002b4e84f9
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/35002b4e84f9

Added tag jdk8u312-b06 for changeset e2ac513ec7b3

! .hgtags

Changeset: 78565a54a256
Author:    mbalao
Date:      2015-07-09 12:36 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/78565a54a256

8130183: InnerClasses: VM permits wrong Throw ClassFormatError if InnerClasses attribute's inner_class_info_index is 0
Reviewed-by: acorn, lfoltan, andrew

! src/share/vm/classfile/classFileParser.cpp

Changeset: 09099f70d11e
Author:    mbalao
Date:      2021-08-03 06:57 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/09099f70d11e

8269624: Enhance method selection support
Reviewed-by: andrew

! src/share/vm/code/dependencies.cpp

Changeset: fe198a8a1cab
Author:    avoitylov
Date:      2021-08-09 18:12 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fe198a8a1cab

8270398: Enhance canonicalization
Reviewed-by: rhalade, mschoene, coleenp, andrew

! src/share/vm/classfile/verifier.cpp

Changeset: 8aac6d08b58e
Author:    avoitylov
Date:      2021-08-09 18:12 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8aac6d08b58e

8270404: Better canonicalization
Reviewed-by: coleenp, rhalade, mschoene, andrew

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvm.cpp

Changeset: d2ac58d4fe66
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d2ac58d4fe66

Added tag jdk8u312-b07 for changeset 8aac6d08b58e

! .hgtags

Changeset: 55c41dea0d82
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/55c41dea0d82

Merge jdk8u312-b07

! .hgtags
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/verifier.cpp
! src/share/vm/code/dependencies.cpp
! src/share/vm/prims/jvm.cpp

Changeset: 9be9a829ad9e
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9be9a829ad9e

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset 55c41dea0d82

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:33 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:33 +0000
Subject: hg: shenandoah/jdk8/nashorn: 5 new changesets
Message-ID: <202111171505.1AHF5XMJ013985@aojmv0008.oracle.com>

Changeset: 1a36b818699d
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/1a36b818699d

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset ef6521ddf176

! .hgtags

Changeset: a3ee9cc1edc5
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/a3ee9cc1edc5

Added tag jdk8u312-b06 for changeset c0cd14e232ae

! .hgtags

Changeset: 105c362e618e
Author:    andrew
Date:      2021-10-15 02:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/105c362e618e

Added tag jdk8u312-b07 for changeset a3ee9cc1edc5

! .hgtags

Changeset: 6b12f7da7be6
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/6b12f7da7be6

Merge jdk8u312-b07

! .hgtags

Changeset: ced1d0a7a7cb
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ced1d0a7a7cb

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset 6b12f7da7be6

! .hgtags


From shade at redhat.com  Wed Nov 17 15:05:34 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 17 Nov 2021 15:05:34 +0000
Subject: hg: shenandoah/jdk8/jdk: 30 new changesets
Message-ID: <202111171505.1AHF5Zk4013990@aojmv0008.oracle.com>

Changeset: 253587e9db44
Author:    shade
Date:      2021-10-07 09:33 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/253587e9db44

Added tag aarch64-shenandoah-jdk8u312-b05-shenandoah-merge-2021-10-07 for changeset cfb19b3c2111

! .hgtags

Changeset: c466b0a5a4b9
Author:    abakhtin
Date:      2021-09-14 00:14 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/c466b0a5a4b9

8272643: Backout JDK-8176837 from 8u312
Reviewed-by: andrew

! src/share/classes/sun/security/ssl/SSLSocketImpl.java
- test/sun/security/ssl/SSLSocketImpl/SSLSocketReset.java

Changeset: ece88aba26eb
Author:    abakhtin
Date:      2019-09-20 21:33 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ece88aba26eb

8268965: TCP Connection Reset when connecting simple socket to SSL server
Reviewed-by: xuelei, andrew

! src/share/classes/sun/security/ssl/SSLSocketImpl.java
+ test/sun/security/ssl/SSLSocketImpl/SSLSocketReset.java

Changeset: 6f1875b6f29f
Author:    andrew
Date:      2021-09-14 00:27 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6f1875b6f29f

Added tag jdk8u312-b06 for changeset ece88aba26eb

! .hgtags

Changeset: 7ca196c6cebe
Author:    mbalao
Date:      2021-08-05 10:00 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7ca196c6cebe

8263314: Enhance XML Dsig modes
Reviewed-by: coffeys, pkoppula, andrew

! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java
! test/javax/xml/crypto/dsig/GenerationTests.java

Changeset: f60ef263eb92
Author:    mbalao
Date:      2021-07-01 07:04 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f60ef263eb92

8163326: Update the default enabled cipher suites preference
Reviewed-by: avoitylov, andrew

! src/share/classes/sun/security/ssl/CipherSuite.java
! test/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java
! test/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java

Changeset: 6573d0696a48
Author:    alvdavi
Date:      2021-08-05 10:00 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6573d0696a48

8265167: Richer Text Editors
Reviewed-by: mbalao, andrew

! src/share/classes/javax/swing/text/rtf/RTFParser.java

Changeset: 7e0a831ae291
Author:    alvdavi
Date:      2021-10-14 01:28 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7e0a831ae291

8269763: The JEditorPane is blank after JDK-8265167
Reviewed-by: mbalao, andrew

! src/share/classes/javax/swing/text/rtf/RTFParser.java

Changeset: 3225e407ffbd
Author:    alvdavi
Date:      2021-10-14 01:33 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/3225e407ffbd

8265574: Improve handling of sheets
Reviewed-by: mbalao, andrew

! src/share/classes/javax/swing/text/rtf/RTFReader.java

Changeset: b27642b17f65
Author:    mbalao
Date:      2021-07-16 16:57 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b27642b17f65

8265580: Enhanced style for RTF kit
Reviewed-by: andrew

! src/share/classes/javax/swing/text/rtf/RTFReader.java

Changeset: 1b77223b4674
Author:    avoitylov
Date:      2021-08-19 18:38 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1b77223b4674

8265776: Improve Stream handling for SSL
Reviewed-by: dfuchs, chegar, rhalade, ahgross, mbalao, andrew

! src/share/classes/sun/net/httpserver/SSLStreams.java

Changeset: f143814b41fb
Author:    yan
Date:      2021-08-26 14:33 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f143814b41fb

8266097: Better hashing support
Reviewed-by: mbalao, andrew

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/HashSet.java

Changeset: 4074e9c839a3
Author:    mbalao
Date:      2021-08-05 09:45 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4074e9c839a3

8266103: Better specified spec values
Reviewed-by: andrew

! src/share/classes/javax/crypto/spec/IvParameterSpec.java
! src/share/classes/javax/crypto/spec/RC5ParameterSpec.java
! src/share/classes/javax/crypto/spec/SecretKeySpec.java

Changeset: a091e059c56c
Author:    yan
Date:      2021-06-18 20:26 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a091e059c56c

8266109: More Resilient Classloading
Reviewed-by: mbalao, andrew

! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/sun/misc/Resource.java
! src/share/classes/sun/misc/URLClassPath.java

Changeset: ec2304b38a41
Author:    yan
Date:      2021-08-27 15:27 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ec2304b38a41

8266115: More Manifest Jar Loading
Reviewed-by: mbalao, andrew

! src/share/classes/java/util/jar/JarFile.java

Changeset: d336b7025712
Author:    mbalao
Date:      2021-08-05 09:10 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d336b7025712

8266689: More Constrained Delegation
Reviewed-by: andrew

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/sun/security/jgss/krb5/SubjectComber.java

Changeset: 2a9b223440e5
Author:    mbalao
Date:      2021-10-14 02:52 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2a9b223440e5

8157404: Unable to read certain PKCS12 keystores from SequenceInputStream
Reviewed-by: andrew

! src/share/classes/sun/security/util/DerIndefLenConverter.java
! src/share/classes/sun/security/util/DerInputStream.java
! src/share/classes/sun/security/util/DerValue.java

Changeset: d7f231bee1f6
Author:    mbalao
Date:      2019-04-23 00:34 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d7f231bee1f6

8222751: closed/test/jdk/sun/security/util/DerIndefLenConverter/IndefBerPkcs12.java fail
Reviewed-by: andrew

! src/share/classes/sun/security/provider/KeyStoreDelegator.java
! src/share/classes/sun/security/util/DerIndefLenConverter.java

Changeset: 033f37d82bba
Author:    mbalao
Date:      2021-10-14 03:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/033f37d82bba

8267086: ArrayIndexOutOfBoundsException in java.security.KeyFactory.generatePublic
Reviewed-by: andrew

! src/share/classes/sun/security/util/DerIndefLenConverter.java

Changeset: 8c553f12bece
Author:    abakhtin
Date:      2021-09-08 16:43 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8c553f12bece

8267712: Better LDAP reference processing
Reviewed-by: mbalao, andrew

! src/share/classes/com/sun/jndi/ldap/Obj.java
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java

Changeset: 446338ed795d
Author:    mbalao
Date:      2021-09-16 14:49 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/446338ed795d

8267729: Improve TLS client handshaking
Reviewed-by: andrew

! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
! src/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
! src/share/classes/sun/security/ssl/KeyShareExtension.java
! src/share/classes/sun/security/ssl/SSLLogger.java

Changeset: 12b0c54cc6b1
Author:    bae
Date:      2021-09-18 09:27 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/12b0c54cc6b1

8267735: Better BMP support
Reviewed-by: mbalao, andrew

! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties

Changeset: 2bcd8e015059
Author:    cverghese
Date:      2021-10-14 22:19 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2bcd8e015059

8268193: Improve requests of certificates
Reviewed-by: mbalao, andrew

! src/share/classes/sun/security/ssl/CertificateRequest.java
! src/share/classes/sun/security/ssl/ClientHandshakeContext.java
! src/share/classes/sun/security/ssl/ServerKeyExchange.java

Changeset: abcb7407f153
Author:    cverghese
Date:      2021-10-14 22:36 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/abcb7407f153

8268199: Correct certificate requests
Reviewed-by: mbalao, andrew

! src/share/classes/sun/security/ssl/CertificateRequest.java
! src/share/classes/sun/security/ssl/X509Authentication.java

Changeset: 6de43823dd11
Author:    yan
Date:      2021-09-10 15:01 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6de43823dd11

8268506: More Manifest Digests
Reviewed-by: andrew

! src/share/classes/sun/security/util/SignatureFileVerifier.java

Changeset: 54441ec952f7
Author:    cverghese
Date:      2021-10-15 03:11 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/54441ec952f7

8269618: Better session identification
Reviewed-by: andrew

! src/share/classes/sun/security/ssl/HelloCookieManager.java
! src/share/classes/sun/security/ssl/PreSharedKeyExtension.java
! src/share/classes/sun/security/ssl/RandomCookie.java
! src/share/classes/sun/security/ssl/RenegoInfoExtension.java
! src/share/classes/sun/security/ssl/SessionId.java
! src/share/classes/sun/security/ssl/Utilities.java
+ src/share/classes/sun/security/util/ByteArrays.java

Changeset: 132377e2edb2
Author:    yan
Date:      2021-09-01 17:33 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/132377e2edb2

8266137: Improve Keystore integrity
Reviewed-by: mbalao, andrew

! src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
! src/share/classes/sun/security/tools/keytool/Main.java

Changeset: a15c739dfd79
Author:    andrew
Date:      2021-10-15 03:13 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a15c739dfd79

Added tag jdk8u312-b07 for changeset 132377e2edb2

! .hgtags

Changeset: 0fdfce14a6d9
Author:    andrew
Date:      2021-10-15 04:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0fdfce14a6d9

Merge jdk8u312-b07

! .hgtags
! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/java/net/URLClassLoader.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/tools/keytool/Main.java

Changeset: b2dfa021c7c3
Author:    andrew
Date:      2021-10-15 04:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b2dfa021c7c3

Added tag aarch64-shenandoah-jdk8u312-b07 for changeset 0fdfce14a6d9

! .hgtags


From zgu at redhat.com  Wed Nov 17 16:01:33 2021
From: zgu at redhat.com (zgu at redhat.com)
Date: Wed, 17 Nov 2021 16:01:33 +0000
Subject: hg: shenandoah/jdk8/hotspot: 8276201: Shenandoah: Race results
 degenerated GC to enter wrong entry point
Message-ID: <202111171601.1AHG1XrQ024744@aojmv0008.oracle.com>

Changeset: ccd5bf1e8725
Author:    zgu
Date:      2021-11-16 17:33 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ccd5bf1e8725

8276201: Shenandoah: Race results degenerated GC to enter wrong entry point
Reviewed-by: shade

! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp


From zgu at redhat.com  Wed Nov 17 16:02:21 2021
From: zgu at redhat.com (zgu at redhat.com)
Date: Wed, 17 Nov 2021 16:02:21 +0000
Subject: hg: shenandoah/jdk8/hotspot: 8275051: Shenandoah: Correct ordering of
 requested gc cause and gc request flag
Message-ID: <202111171602.1AHG2Lox024900@aojmv0008.oracle.com>

Changeset: 46866ecf53de
Author:    zgu
Date:      2021-10-12 11:58 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/46866ecf53de

8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag
Reviewed-by: shade

! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp


From nradomski at openjdk.java.net  Thu Nov 18 17:22:28 2021
From: nradomski at openjdk.java.net (Niklas Radomski)
Date: Thu, 18 Nov 2021 17:22:28 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le [v2]
In-Reply-To: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
Message-ID: <-yZ-CH3Zdp9FbqRbcKA908KaXU7dWIuzy_SCyMluDr4=.31797995-8447-4902-89bd-693948925e49@github.com>

> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.

Niklas Radomski has updated the pull request incrementally with one additional commit since the last revision:

  Remove debug clobber code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6325/files
  - new: https://git.openjdk.java.net/jdk/pull/6325/files/1dec8885..c504b66d

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

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

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

From mdoerr at openjdk.java.net  Thu Nov 18 18:35:43 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 18 Nov 2021 18:35:43 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le [v2]
In-Reply-To: <-yZ-CH3Zdp9FbqRbcKA908KaXU7dWIuzy_SCyMluDr4=.31797995-8447-4902-89bd-693948925e49@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
 <-yZ-CH3Zdp9FbqRbcKA908KaXU7dWIuzy_SCyMluDr4=.31797995-8447-4902-89bd-693948925e49@github.com>
Message-ID: <6ikSOeIWtJPZbIzHuiiEbSmpT60lFaZgOWejMxyAg80=.378fb020-a2e1-42f9-8e38-0985408f87f1@github.com>

On Thu, 18 Nov 2021 17:22:28 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

>> Port the Shenandoah garbage collector (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug clobber code

Thanks for the update! I think it's good to go.

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

Marked as reviewed by mdoerr (Reviewer).

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

From nradomski at openjdk.java.net  Thu Nov 18 18:58:39 2021
From: nradomski at openjdk.java.net (Niklas Radomski)
Date: Thu, 18 Nov 2021 18:58:39 GMT
Subject: RFR: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le [v2]
In-Reply-To: <-yZ-CH3Zdp9FbqRbcKA908KaXU7dWIuzy_SCyMluDr4=.31797995-8447-4902-89bd-693948925e49@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
 <-yZ-CH3Zdp9FbqRbcKA908KaXU7dWIuzy_SCyMluDr4=.31797995-8447-4902-89bd-693948925e49@github.com>
Message-ID: <Mj2c6LxP7k_x__IZAeDx6fDLv7JWFqEZnnon2RqQF4k=.fe19ebbb-701b-4874-b2d1-991d273c5478@github.com>

On Thu, 18 Nov 2021 17:22:28 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

>> Port the Shenandoah garbage collector [JDK-8241457](https://bugs.openjdk.java.net/browse/JDK-8241457) to linux on ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug clobber code

Thank you for your reviews! Happy to see that the change has been so well received.

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

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

From nradomski at openjdk.java.net  Thu Nov 18 19:07:46 2021
From: nradomski at openjdk.java.net (Niklas Radomski)
Date: Thu, 18 Nov 2021 19:07:46 GMT
Subject: Integrated: 8276927: [PPC64] Port shenandoahgc to linux on ppc64le
In-Reply-To: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
References: <Nt7KC3zC3ERbpcjIda_FrsJYNuDtzbd_khX75A1x4aE=.676a48b5-c7f4-4798-a3b8-516bb60dfaa4@github.com>
Message-ID: <fpMaWjJQo80qCIEj3niuU2LH0vqrhR2DgNoJYMSbTGA=.89aa4d63-dd18-4f55-ba53-274ffaddf9fc@github.com>

On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski <nradomski at openjdk.org> wrote:

> Port the Shenandoah garbage collector [JDK-8241457](https://bugs.openjdk.java.net/browse/JDK-8241457) to linux on ppc64le.

This pull request has now been integrated.

Changeset: 57eb8647
Author:    Niklas Radomski <nradomski at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57eb864765f38185f8db8f1d37681d6cfe2a3c73
Stats:     1521 lines in 8 files changed: 1519 ins; 0 del; 2 mod

8276927: [PPC64] Port shenandoahgc to linux on ppc64le

Reviewed-by: rkennke, ihse, mdoerr

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

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

From wkemper at openjdk.java.net  Thu Nov 18 19:50:24 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 18 Nov 2021 19:50:24 GMT
Subject: RFR: Clear young generation reference to old mark queues when starting
 global collect
Message-ID: <-tCztfhJzZWTI1SachwHa8buH3qxXS00sb1xKWSlUbU=.f9f896b9-1ac4-4dbd-a1ff-477e3d09d300@github.com>

If concurrent marking in old is preempted by a _global_ collection, the old mark is abandoned. The young generation should no longer hold a reference to the old mark queues.  Without this fix, collections in young generation may erroneously behave as though concurrent mark in old is still running.

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

Commit messages:
 - Young generation should not hold reference to old mark queues after a global collect

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

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

From rkennke at openjdk.java.net  Thu Nov 18 20:13:19 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 18 Nov 2021 20:13:19 GMT
Subject: RFR: Clear young generation reference to old mark queues when
 starting global collect
In-Reply-To: <-tCztfhJzZWTI1SachwHa8buH3qxXS00sb1xKWSlUbU=.f9f896b9-1ac4-4dbd-a1ff-477e3d09d300@github.com>
References: <-tCztfhJzZWTI1SachwHa8buH3qxXS00sb1xKWSlUbU=.f9f896b9-1ac4-4dbd-a1ff-477e3d09d300@github.com>
Message-ID: <GLazXaTY_9dfE7LU0LpypI_FrSXlVR-pcZ03WlEBxOo=.689be3e8-4942-4a63-b093-b95b9efa644c@github.com>

On Thu, 18 Nov 2021 19:45:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> If concurrent marking in old is preempted by a _global_ collection, the old mark is abandoned. The young generation should no longer hold a reference to the old mark queues.  Without this fix, collections in young generation may erroneously behave as though concurrent mark in old is still running.

Marked as reviewed by rkennke (Lead).

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

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

From wkemper at openjdk.java.net  Thu Nov 18 21:22:15 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 18 Nov 2021 21:22:15 GMT
Subject: git: openjdk/shenandoah: master: Clear young generation reference to
 old mark queues when starting global collect
Message-ID: <5e666635-432c-4b4e-b0e6-1c2fe0467640@openjdk.org>

Changeset: 191dd79a
Author:    William Kemper <wkemper at openjdk.org>
Date:      2021-11-18 21:21:50 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/191dd79a7efad684898f43e534caa0dd8c211d7c

Clear young generation reference to old mark queues when starting global collect

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp


From wkemper at openjdk.java.net  Thu Nov 18 21:25:23 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 18 Nov 2021 21:25:23 GMT
Subject: Integrated: Clear young generation reference to old mark queues when
 starting global collect
In-Reply-To: <-tCztfhJzZWTI1SachwHa8buH3qxXS00sb1xKWSlUbU=.f9f896b9-1ac4-4dbd-a1ff-477e3d09d300@github.com>
References: <-tCztfhJzZWTI1SachwHa8buH3qxXS00sb1xKWSlUbU=.f9f896b9-1ac4-4dbd-a1ff-477e3d09d300@github.com>
Message-ID: <50DGrUZtiKl1SZ9lI4apNsEm4uXxSgmp_5zsvuzQT-A=.3098f9cf-8819-4e4c-a7f9-e22feb12f37b@github.com>

On Thu, 18 Nov 2021 19:45:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> If concurrent marking in old is preempted by a _global_ collection, the old mark is abandoned. The young generation should no longer hold a reference to the old mark queues.  Without this fix, collections in young generation may erroneously behave as though concurrent mark in old is still running.

This pull request has now been integrated.

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

Clear young generation reference to old mark queues when starting global collect

Reviewed-by: rkennke

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

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

From rkennke at openjdk.java.net  Thu Nov 18 21:35:51 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 18 Nov 2021 21:35:51 GMT
Subject: Integrated: 8275527: Refactor forward pointer access
In-Reply-To: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
Message-ID: <ABql1QFqXem4aRwxCiAqQiDqrAkZCXvtgoHhd20k70Y=.31336a91-c57f-4af5-a97c-5efe8a47cf4d@github.com>

On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.
> 
> This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.
> 
> Testing:
>  - [x] tier
>  - [x] tier2
>  - [x] hotspot_gc

This pull request has now been integrated.

Changeset: 89b125f4
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/89b125f4d4d6a467185b4b39861fd530a738e67f
Stats:     46 lines in 9 files changed: 4 ins; 26 del; 16 mod

8275527: Refactor forward pointer access

Reviewed-by: tschatzl, stefank

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

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

From eosterlund at openjdk.java.net  Mon Nov 22 14:03:34 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 22 Nov 2021 14:03:34 GMT
Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in
 VM_HeapDumper
Message-ID: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>

The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used.

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

Commit messages:
 - 8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper

Changes: https://git.openjdk.java.net/jdk/pull/6501/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6501&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276696
  Stats: 70 lines in 15 files changed: 35 ins; 11 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6501.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6501/head:pull/6501

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

From pliden at openjdk.java.net  Tue Nov 23 09:45:10 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 23 Nov 2021 09:45:10 GMT
Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in
 VM_HeapDumper
In-Reply-To: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
References: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
Message-ID: <OsysZVCzNnOKdfs-cZZ7r3FcY4pEX3O_KVxjNxxHops=.81564c11-59fe-4725-945d-533b58aca44d@github.com>

On Mon, 22 Nov 2021 13:49:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used.

Looks good.

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

Marked as reviewed by pliden (Reviewer).

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

From stefank at openjdk.java.net  Tue Nov 23 09:52:06 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 23 Nov 2021 09:52:06 GMT
Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in
 VM_HeapDumper
In-Reply-To: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
References: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
Message-ID: <k_Zya4UXwRmphJwmoc2zlAZSNUDYSR9sz4wwPA1eUjk=.38d5bd42-ae7f-4aaa-8c5b-a00f2c8f8504@github.com>

On Mon, 22 Nov 2021 13:49:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used.

Marked as reviewed by stefank (Reviewer).

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

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

From eosterlund at openjdk.java.net  Tue Nov 23 13:42:06 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 23 Nov 2021 13:42:06 GMT
Subject: RFR: 8276696: ParallelObjectIterator freed at the wrong time in
 VM_HeapDumper
In-Reply-To: <OsysZVCzNnOKdfs-cZZ7r3FcY4pEX3O_KVxjNxxHops=.81564c11-59fe-4725-945d-533b58aca44d@github.com>
References: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
 <OsysZVCzNnOKdfs-cZZ7r3FcY4pEX3O_KVxjNxxHops=.81564c11-59fe-4725-945d-533b58aca44d@github.com>
Message-ID: <8246XgMZ_pumK-BgCx9osG0N9jvJxNGmcJVw8s_0oqo=.d723b7d4-ac0e-4897-af9f-65524377ab87@github.com>

On Tue, 23 Nov 2021 09:42:10 GMT, Per Liden <pliden at openjdk.org> wrote:

>> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used.
>
> Looks good.

Thanks for the reviews, @pliden and @stefank!

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

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

From eosterlund at openjdk.java.net  Tue Nov 23 14:38:15 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 23 Nov 2021 14:38:15 GMT
Subject: Integrated: 8276696: ParallelObjectIterator freed at the wrong time in
 VM_HeapDumper
In-Reply-To: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
References: <JFVjS5PCXDGX5jmjraERwlIfpyJBrSSH001s9CaO_DE=.6d8b489a-cb67-4ed9-86b2-ee9fe94df314@github.com>
Message-ID: <RU1WUNJVx1eqBs8mKDW0CaW5HtJGn7sFG7noGQsCAIQ=.538901b5-02a8-4bbf-896b-fa70b7424abf@github.com>

On Mon, 22 Nov 2021 13:49:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is constructed right before running a parallel operation with a work gang, but freed in the destructor of the VM_HeapDumper. This means it is created on one thread and deleted on another thread. This becomes a bit problematic when a parallel object iterator implementation uses a ThreadsListHandle (which is indeed the case for ZGC). This patch changes ParallelObjectIterator to be a StackObj, carrying a ParallelObjectIteratorImpl object, which is never exposed publicly. This ensures that construction and destruction of the internal object iterator is scoped like RAII objects, hence complying with how ThreadsListHandle is supposed to be used.

This pull request has now been integrated.

Changeset: f4dc03ea
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4dc03ea6de327425ff265c3d2ec16ea7b0e1634
Stats:     70 lines in 15 files changed: 35 ins; 11 del; 24 mod

8276696: ParallelObjectIterator freed at the wrong time in VM_HeapDumper

Reviewed-by: pliden, stefank

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

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

From jiefu at openjdk.java.net  Tue Nov 23 16:04:23 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 23 Nov 2021 16:04:23 GMT
Subject: RFR: 8277652: SIGSEGV in ShenandoahBarrierC2Support::verify_raw_mem
 for malformed control flow graph
Message-ID: <kXZWFS0Yj4qU3UF_PEmFY5ca1r7yYiCcgpSb2Yn7qFQ=.d9b39b03-5b46-4c3d-ad2a-605f07d83f3f@github.com>

Hi all,

`ShenandoahBarrierC2Support::verify_raw_mem` crashes due to `u->unique_ctrl_out()` [1] returns NULL for malformed control flow graph.
It can be reproduced by running `compiler/vectorapi/TestIntrinsicBailOut.java` with `-XX:+UseShenandoahGC`.
It would be better to fix it.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp#L1925

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

Commit messages:
 - 8277652: SIGSEGV in ShenandoahBarrierC2Support::verify_raw_mem for malformed control flow graph

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

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

From rkennke at openjdk.java.net  Tue Nov 23 16:24:07 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 23 Nov 2021 16:24:07 GMT
Subject: RFR: 8277652: SIGSEGV in
 ShenandoahBarrierC2Support::verify_raw_mem for malformed control flow graph
In-Reply-To: <kXZWFS0Yj4qU3UF_PEmFY5ca1r7yYiCcgpSb2Yn7qFQ=.d9b39b03-5b46-4c3d-ad2a-605f07d83f3f@github.com>
References: <kXZWFS0Yj4qU3UF_PEmFY5ca1r7yYiCcgpSb2Yn7qFQ=.d9b39b03-5b46-4c3d-ad2a-605f07d83f3f@github.com>
Message-ID: <81o2YKFQvTE2C9qqBBDBjC5L1dNyPMRTJw1CcTdD2SA=.6946cbb3-de08-46b7-9724-7c39a989efc3@github.com>

On Tue, 23 Nov 2021 15:59:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> `ShenandoahBarrierC2Support::verify_raw_mem` crashes due to `u->unique_ctrl_out()` [1] returns NULL for malformed control flow graph.
> It can be reproduced by running `compiler/vectorapi/TestIntrinsicBailOut.java` with `-XX:+UseShenandoahGC`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp#L1925

Thank you, Jie!
I am currently working on a change that would make LRB runtime call not consume or produce raw memory at all, and would obsolete your change. See #6526 .

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

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

From duke at openjdk.java.net  Wed Nov 24 18:56:55 2021
From: duke at openjdk.java.net (David Alvarez)
Date: Wed, 24 Nov 2021 18:56:55 GMT
Subject: RFR: Split Generational Shenandoah memory pools
Message-ID: <N3Du8fN2j7rK7qW1nhjAs42IH1MICQK2Z1VyF8X3BlQ=.63ba742d-dbfe-4362-a17f-4639aca73e0e@github.com>

Expose the Young Generation and the Old Generation as independent memory pools when running in generational mode

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

Commit messages:
 - Split Generational Shenandoah memory pools

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

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

From rkennke at openjdk.java.net  Fri Nov 26 09:38:19 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 26 Nov 2021 09:38:19 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call
Message-ID: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>

The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)

Testing:
 - [x] hotspot_gc_shenandoah
 - [x] specjvm -XX:+UseShenandoahGC
 - [x] tier1
 - [x] tier2
 - [x] tier3

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

Commit messages:
 - 8277654: Shenandoah: Don't produce new memory state in C2 LRB runtime call

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

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

From rkennke at openjdk.java.net  Fri Nov 26 09:42:34 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 26 Nov 2021 09:42:34 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
Message-ID: <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>

> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] specjvm -XX:+UseShenandoahGC
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove verify_raw_mem()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6526/files
  - new: https://git.openjdk.java.net/jdk/pull/6526/files/294389df..06c2b9eb

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

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

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

From roland at openjdk.java.net  Fri Nov 26 16:28:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 26 Nov 2021 16:28:07 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
 <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
Message-ID: <ViZGo0LhHdIfxeS14Q3UtH-iMHD-XkJ2AYgSJvw2A_E=.c8dc9c16-f994-4db8-a8f9-c0b7f5685cd7@github.com>

On Fri, 26 Nov 2021 09:42:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] specjvm -XX:+UseShenandoahGC
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove verify_raw_mem()

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

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

From rkennke at openjdk.java.net  Fri Nov 26 18:14:32 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 26 Nov 2021 18:14:32 GMT
Subject: RFR: Split Generational Shenandoah memory pools
In-Reply-To: <N3Du8fN2j7rK7qW1nhjAs42IH1MICQK2Z1VyF8X3BlQ=.63ba742d-dbfe-4362-a17f-4639aca73e0e@github.com>
References: <N3Du8fN2j7rK7qW1nhjAs42IH1MICQK2Z1VyF8X3BlQ=.63ba742d-dbfe-4362-a17f-4639aca73e0e@github.com>
Message-ID: <8lpCuabJN3KmM8loGt4SFCH50iRKJxG-NerE5gZiTqw=.7f37cf47-548b-49ad-9585-93a266681aea@github.com>

On Wed, 24 Nov 2021 18:51:12 GMT, David Alvarez <duke at openjdk.java.net> wrote:

> Expose the Young Generation and the Old Generation as independent memory pools when running in generational mode

Looks good!

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

Marked as reviewed by rkennke (Lead).

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

From shade at openjdk.java.net  Mon Nov 29 14:31:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Nov 2021 14:31:09 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
 <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
Message-ID: <2uy1V5LOa4NxChUSC3jJ7XHPmG2cOcDUShnE774alPA=.589d3dd4-0a3d-4ec3-b401-5366536ee247@github.com>

On Fri, 26 Nov 2021 09:42:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] specjvm -XX:+UseShenandoahGC
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove verify_raw_mem()

Looks okay. Does it affect performance in any way?

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.java.net  Mon Nov 29 14:41:12 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 29 Nov 2021 14:41:12 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <2uy1V5LOa4NxChUSC3jJ7XHPmG2cOcDUShnE774alPA=.589d3dd4-0a3d-4ec3-b401-5366536ee247@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
 <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
 <2uy1V5LOa4NxChUSC3jJ7XHPmG2cOcDUShnE774alPA=.589d3dd4-0a3d-4ec3-b401-5366536ee247@github.com>
Message-ID: <BdHaTko-_ktvriT9ojNzLJRZdKLL7h8S2HTibgGmaCg=.cb54bcf9-20f8-42c3-9bd2-a52cba2c0f13@github.com>

On Mon, 29 Nov 2021 14:28:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks okay. Does it affect performance in any way?

I couldn't see any benefits or regressions in specjvm.

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

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

From rkennke at openjdk.java.net  Mon Nov 29 16:03:11 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 29 Nov 2021 16:03:11 GMT
Subject: Integrated: 8277654: Shenandoah: Don't produce new memory state in C2
 LRB runtime call
In-Reply-To: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
Message-ID: <tr--15bPZD9R1jxunipOy9brBMsVRFwwP_AFROHiL1U=.369e2174-7702-4d39-8f52-f6aa7ded0e40@github.com>

On Tue, 23 Nov 2021 16:20:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] specjvm -XX:+UseShenandoahGC
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3

This pull request has now been integrated.

Changeset: 3d39f09c
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d39f09c6cdc875b44147b4e84e496b6abf93996
Stats:     132 lines in 2 files changed: 0 ins; 127 del; 5 mod

8277654: Shenandoah: Don't produce new memory state in C2 LRB runtime call

Reviewed-by: roland, shade

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

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

From wkemper at openjdk.java.net  Mon Nov 29 17:25:02 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 29 Nov 2021 17:25:02 GMT
Subject: RFR: Add missing override keyword to fix MacOS (clang) builds
Message-ID: <KHfe5j5LU_mGhyTl8nfE50HvMC31Tf__UT1yBDfKivw=.cbf95b5f-6c20-40cb-8035-6406efbac7d3@github.com>

Adding the `override` keyword for overriding virtual methods to fix Mac builds.

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

Commit messages:
 - Add more missing override keywords for MacOS build
 - Add missing override keyword to fix macos build

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

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

From duke at openjdk.java.net  Mon Nov 29 20:02:38 2021
From: duke at openjdk.java.net (David Alvarez)
Date: Mon, 29 Nov 2021 20:02:38 GMT
Subject: Integrated: Split Generational Shenandoah memory pools
In-Reply-To: <N3Du8fN2j7rK7qW1nhjAs42IH1MICQK2Z1VyF8X3BlQ=.63ba742d-dbfe-4362-a17f-4639aca73e0e@github.com>
References: <N3Du8fN2j7rK7qW1nhjAs42IH1MICQK2Z1VyF8X3BlQ=.63ba742d-dbfe-4362-a17f-4639aca73e0e@github.com>
Message-ID: <QNGyb7vxNcO1PYjpEDjTQAjIqtMSc6X92hm2PKZPXeE=.66965267-d3a1-46bc-b245-98b3354445e4@github.com>

On Wed, 24 Nov 2021 18:51:12 GMT, David Alvarez <duke at openjdk.java.net> wrote:

> Expose the Young Generation and the Old Generation as independent memory pools when running in generational mode

This pull request has now been integrated.

Changeset: 0dfb0a3e
Author:    David Alvarez <alvdavi at amazon.com>
Committer: Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/0dfb0a3eede0f8a20286ff0edf4d50349633bff5
Stats:     122 lines in 4 files changed: 110 ins; 0 del; 12 mod

Split Generational Shenandoah memory pools

Reviewed-by: rkennke

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

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

From gnu.andrew at redhat.com  Tue Nov 30 03:28:08 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 03:28:08 +0000
Subject: How To Solve a Problem Like Shenandoah 8u
In-Reply-To: <7ef2da88-b46f-5462-785f-0a89d08f252d@redhat.com>
References: <YWcE6TTvzMnZlGrt@hex.discworld.ac.uk>
 <3a951ce6-274f-7e8b-9783-0c419051371f@redhat.com>
 <7ef2da88-b46f-5462-785f-0a89d08f252d@redhat.com>
Message-ID: <YaWaSPaR5xBnjbjS@hex.discworld.ac.uk>

On 10:29 Thu 14 Oct     , Aleksey Shipilev wrote:
> On 10/13/21 9:54 PM, Roman Kennke wrote:
> > Others who do more frequent backports than me (Aleksey maybe?) might
> > have more insights.?
> 
> Our backport tracking machinery parses the changesets in that HG repo. That's the only option for 
> tracking, because 8u Shenandoah backports are not tracked in JBS. I suspect it would be fine to keep 
> the read-only snapshot of old Mercurial repo, so that backports-monitor can still read it.
> 
> FWIW, we did the similar history-losing-squash commit when moving sh/jdk9 -> sh/jdk10 for the 
> monorepo migration, and that was not very painful.
> 
> -- 
> Thanks,
> -Aleksey
> 

So we now have 8u hg monorepos:

https://hg.openjdk.java.net/jdk8u/monojdk8u/
https://hg.openjdk.java.net/jdk8u/monojdk8u-dev/

and live read-only git mirrors:

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

What I would suggest for aarch64/shenandoah-jdk8u going forward is:

1. We merge the 8u322 build promotions as usual, so we are in sync with the new repositories
2. Fork the jdk8u git repository to sh/jdk8u and apply the Shenandoah changes as one patch on top
3. Future merges to the new git repo are from the read-only 8u git mirror (which will become live next year)

I don't see a need to temporarily have a Shenandoah hg monorepo as
there are few commits directly to these repositories. It will actually
be a good test of the 8u git repo to use it before it goes live for
development.

I guess you'll also want a sh/jdk8u-dev git repository as an equivalent
of the current sh/jdk8u for working on 8u backports.

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

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

From jiefu at openjdk.java.net  Tue Nov 30 03:42:09 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 30 Nov 2021 03:42:09 GMT
Subject: Withdrawn: 8277652: SIGSEGV in
 ShenandoahBarrierC2Support::verify_raw_mem for malformed control flow graph
In-Reply-To: <kXZWFS0Yj4qU3UF_PEmFY5ca1r7yYiCcgpSb2Yn7qFQ=.d9b39b03-5b46-4c3d-ad2a-605f07d83f3f@github.com>
References: <kXZWFS0Yj4qU3UF_PEmFY5ca1r7yYiCcgpSb2Yn7qFQ=.d9b39b03-5b46-4c3d-ad2a-605f07d83f3f@github.com>
Message-ID: <sAopOys0czOI8rcAZhRPxl6xn2slgAXacSZiseZ7wjg=.31d91e8b-834d-4e53-8e99-31f7ca5192ab@github.com>

On Tue, 23 Nov 2021 15:59:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> `ShenandoahBarrierC2Support::verify_raw_mem` crashes due to `u->unique_ctrl_out()` [1] returns NULL for malformed control flow graph.
> It can be reproduced by running `compiler/vectorapi/TestIntrinsicBailOut.java` with `-XX:+UseShenandoahGC`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp#L1925

This pull request has been closed without being integrated.

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

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

From jiefu at openjdk.java.net  Tue Nov 30 03:42:09 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 30 Nov 2021 03:42:09 GMT
Subject: RFR: 8277652: SIGSEGV in
 ShenandoahBarrierC2Support::verify_raw_mem for malformed control flow graph
In-Reply-To: <81o2YKFQvTE2C9qqBBDBjC5L1dNyPMRTJw1CcTdD2SA=.6946cbb3-de08-46b7-9724-7c39a989efc3@github.com>
References: <kXZWFS0Yj4qU3UF_PEmFY5ca1r7yYiCcgpSb2Yn7qFQ=.d9b39b03-5b46-4c3d-ad2a-605f07d83f3f@github.com>
 <81o2YKFQvTE2C9qqBBDBjC5L1dNyPMRTJw1CcTdD2SA=.6946cbb3-de08-46b7-9724-7c39a989efc3@github.com>
Message-ID: <I3G6lhCUL4lGXDayxqP9iyN8WHbrosOpVfHcKOnG7xU=.c4bffb1c-672a-446f-b342-bf2199efd54c@github.com>

On Tue, 23 Nov 2021 16:20:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Thank you, Jie! I am currently working on a change that would make LRB runtime call not consume or produce raw memory at all, and would obsolete your change. See #6526 .

Thanks @rkennke for fixing it.
So it's time to close this pr.

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

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

From rkennke at redhat.com  Tue Nov 30 13:07:35 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 30 Nov 2021 14:07:35 +0100
Subject: How To Solve a Problem Like Shenandoah 8u
In-Reply-To: <YaWaSPaR5xBnjbjS@hex.discworld.ac.uk>
References: <YWcE6TTvzMnZlGrt@hex.discworld.ac.uk>
 <3a951ce6-274f-7e8b-9783-0c419051371f@redhat.com>
 <7ef2da88-b46f-5462-785f-0a89d08f252d@redhat.com>
 <YaWaSPaR5xBnjbjS@hex.discworld.ac.uk>
Message-ID: <9fa33f61-878a-6d8f-8883-5082db6e660c@redhat.com>

Hi Andrew,

>>> Others who do more frequent backports than me (Aleksey maybe?) might
>>> have more insights.?
>>
>> Our backport tracking machinery parses the changesets in that HG repo. That's the only option for
>> tracking, because 8u Shenandoah backports are not tracked in JBS. I suspect it would be fine to keep
>> the read-only snapshot of old Mercurial repo, so that backports-monitor can still read it.
>>
>> FWIW, we did the similar history-losing-squash commit when moving sh/jdk9 -> sh/jdk10 for the
>> monorepo migration, and that was not very painful.
>>
>> -- 
>> Thanks,
>> -Aleksey
>>
> 
> So we now have 8u hg monorepos:
> 
> https://hg.openjdk.java.net/jdk8u/monojdk8u/
> https://hg.openjdk.java.net/jdk8u/monojdk8u-dev/
> 
> and live read-only git mirrors:
> 
> https://github.com/openjdk/jdk8u
> https://github.com/openjdk/jdk8u-dev

Nice!

> What I would suggest for aarch64/shenandoah-jdk8u going forward is:
> 
> 1. We merge the 8u322 build promotions as usual, so we are in sync with the new repositories
> 2. Fork the jdk8u git repository to sh/jdk8u and apply the Shenandoah changes as one patch on top
> 3. Future merges to the new git repo are from the read-only 8u git mirror (which will become live next year)

This sounds reasonable to me.

> I don't see a need to temporarily have a Shenandoah hg monorepo as
> there are few commits directly to these repositories. It will actually
> be a good test of the 8u git repo to use it before it goes live for
> development.

Yes, that makes sense.

> I guess you'll also want a sh/jdk8u-dev git repository as an equivalent
> of the current sh/jdk8u for working on 8u backports.

Yeah, that makes sense, too, IMO.

Thank you!
Roman


From kdnilsen at openjdk.java.net  Tue Nov 30 16:32:43 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 30 Nov 2021 16:32:43 GMT
Subject: RFR: Add missing override keyword to fix MacOS (clang) builds
In-Reply-To: <KHfe5j5LU_mGhyTl8nfE50HvMC31Tf__UT1yBDfKivw=.cbf95b5f-6c20-40cb-8035-6406efbac7d3@github.com>
References: <KHfe5j5LU_mGhyTl8nfE50HvMC31Tf__UT1yBDfKivw=.cbf95b5f-6c20-40cb-8035-6406efbac7d3@github.com>
Message-ID: <ELqQEBPsjktLD2xzO56TuvX-Qtj_piQgN9o1K4JJD9c=.56e66795-421d-4721-a059-f386f5d402fa@github.com>

On Mon, 29 Nov 2021 17:19:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Adding the `override` keyword for overriding virtual methods to fix Mac builds.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Tue Nov 30 17:22:40 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 30 Nov 2021 17:22:40 GMT
Subject: Integrated: Add missing override keyword to fix MacOS (clang) builds
In-Reply-To: <KHfe5j5LU_mGhyTl8nfE50HvMC31Tf__UT1yBDfKivw=.cbf95b5f-6c20-40cb-8035-6406efbac7d3@github.com>
References: <KHfe5j5LU_mGhyTl8nfE50HvMC31Tf__UT1yBDfKivw=.cbf95b5f-6c20-40cb-8035-6406efbac7d3@github.com>
Message-ID: <knzW39R4nZJbQ3ZTEGDLpTQA6Wc-P5NECKOw4vpTosE=.2bf7cdf4-e151-4039-a5dd-99c5f1718aaa@github.com>

On Mon, 29 Nov 2021 17:19:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Adding the `override` keyword for overriding virtual methods to fix Mac builds.

This pull request has now been integrated.

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

Add missing override keyword to fix MacOS (clang) builds

Reviewed-by: kdnilsen

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

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