From wkemper at openjdk.org  Thu Sep  1 16:57:47 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Sep 2022 16:57:47 GMT
Subject: RFR: Log rotation
In-Reply-To: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
Message-ID: <D6WggiJOjhfnFiRXNVD6i4SFzu3kI-E50_3tTveE2OY=.2008cb6b-4ea6-4044-a41a-1249909ac35d@github.com>

On Fri, 26 Aug 2022 17:06:42 GMT, cfumiwu <duke at openjdk.org> wrote:

> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

Marked as reviewed by wkemper (Committer).

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

PR: https://git.openjdk.org/shenandoah/pull/158

From shade at openjdk.org  Thu Sep  1 17:02:44 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 17:02:44 GMT
Subject: RFR: Log rotation
In-Reply-To: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
Message-ID: <Cz36fl-I_YG-rFvIoH9qRu0Ye56GllwwHuOXKTFYIYw=.030f406c-a2fc-4251-a4e3-6954f4c18bac@github.com>

On Fri, 26 Aug 2022 17:06:42 GMT, cfumiwu <duke at openjdk.org> wrote:

> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

I am not sure why this facility even exists, as Unified Logging from the JVM is supposed to take care of this?

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

PR: https://git.openjdk.org/shenandoah/pull/158

From wkemper at openjdk.org  Thu Sep  1 17:40:50 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Sep 2022 17:40:50 GMT
Subject: RFR: Log rotation
In-Reply-To: <Cz36fl-I_YG-rFvIoH9qRu0Ye56GllwwHuOXKTFYIYw=.030f406c-a2fc-4251-a4e3-6954f4c18bac@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
 <Cz36fl-I_YG-rFvIoH9qRu0Ye56GllwwHuOXKTFYIYw=.030f406c-a2fc-4251-a4e3-6954f4c18bac@github.com>
Message-ID: <1MObXA9E7tfAD0e_y9BwWkR_Gq5Phe6T3C34a6Km6xg=.7b83d2ce-ea11-4cf1-a9c9-f622ac43a3b0@github.com>

On Thu, 1 Sep 2022 16:58:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.
>
> I am not sure why this facility even exists, as Unified Logging from the JVM is supposed to take care of this?

Thank you for reviewing this @shipilev . The log messages emitted here aren't intended to be read by humans, so we didn't want them interspersed with other messages. That being said, that design decision has led to an uncomfortable amount of code duplication. We could try something like using the `gc+region` tags at the trace level?

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

PR: https://git.openjdk.org/shenandoah/pull/158

From shade at openjdk.org  Thu Sep  1 18:01:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Sep 2022 18:01:11 GMT
Subject: RFR: Log rotation
In-Reply-To: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
Message-ID: <ZnhAVHjElyIDlH3gip6hTkiwnyyB47zv77wfDbzM20c=.10341a2a-0f39-4907-8f6d-3e2eecac9313@github.com>

On Fri, 26 Aug 2022 17:06:42 GMT, cfumiwu <duke at openjdk.org> wrote:

> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

Yes, it should be folded in UL somehow. Not necessarily in this PR, but something to be done before going upstream.

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

PR: https://git.openjdk.org/shenandoah/pull/158

From wkemper at openjdk.org  Thu Sep  1 18:16:46 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Sep 2022 18:16:46 GMT
Subject: RFR: Log rotation
In-Reply-To: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
Message-ID: <bv9MSXxFex53Ib67J-ZU1Ujvissu8Yl009Rfr12R3wg=.f4094f7c-ece5-4686-876d-a0a368a841b4@github.com>

On Fri, 26 Aug 2022 17:06:42 GMT, cfumiwu <duke at openjdk.org> wrote:

> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

Okay, we'll make those UL improvements under another PR. Thanks.

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

PR: https://git.openjdk.org/shenandoah/pull/158

From duke at openjdk.org  Thu Sep  1 19:40:49 2022
From: duke at openjdk.org (cfumiwu)
Date: Thu, 1 Sep 2022 19:40:49 GMT
Subject: Integrated: Log rotation
In-Reply-To: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
Message-ID: <yw5WTUV980-O-M-kpXMYMTkTw0D4_BB8ovyd1Jm6Suw=.27943766-56dc-4237-87c3-2be078e932cf@github.com>

On Fri, 26 Aug 2022 17:06:42 GMT, cfumiwu <duke at openjdk.org> wrote:

> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

This pull request has now been integrated.

Changeset: 2bc25de7
Author:    Celine Wu <cfumiwu at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/2bc25de76aa6e8434c2b0ccfe9ac8a86f21e38cb
Stats:     320 lines in 6 files changed: 309 ins; 0 del; 11 mod

Log rotation

Reviewed-by: wkemper

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

PR: https://git.openjdk.org/shenandoah/pull/158

From heidinga at openjdk.org  Thu Sep  1 19:52:02 2022
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 1 Sep 2022 19:52:02 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <rDO36g3Se2r5QFl1v29RVJalNbQGOWVSWh0cKPNWTX0=.fe9c3a88-8bd5-4733-b0c0-311453678210@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
 <rDO36g3Se2r5QFl1v29RVJalNbQGOWVSWh0cKPNWTX0=.fe9c3a88-8bd5-4733-b0c0-311453678210@github.com>
Message-ID: <IO2MKS9eUQhvcvo-A5OelNtiA5dyUE9-EpJ9chaS7kA=.91b51ef4-7fb5-418c-8ed7-4556def2d130@github.com>

On Tue, 30 Aug 2022 23:48:07 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
>> 
>> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
>> 
>> Testing with fastdebug build:
>> 
>> - [x] hotspot_loom
>> - [x] jdk_loom
>> - [x] hotspot_loom in Shenandoah IU mode
>> - [x] jdk_loom in Shenandoah IU mode
>> - [x] hotspot_loom in Shenandoah IU + aggressive
>> - [x] jdk_loom in Shenandoah IU + aggressive
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> @fisk @rkennke if these changes look good, I will close the previous [PR](https://github.com/openjdk/jdk/pull/9982).

@ashu-mehra I opened https://bugs.openjdk.org/browse/JDK-8293252 for the ThreadMXBean crashes mentioned in https://github.com/openjdk/jdk/pull/10089#issuecomment-1232283744

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

PR: https://git.openjdk.org/jdk/pull/10089

From wkemper at openjdk.org  Thu Sep  1 23:35:08 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Sep 2022 23:35:08 GMT
Subject: RFR: Enhancements for Shenandoah's generational mode [v2]
In-Reply-To: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>
References: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>
Message-ID: <BAIzzuTHuCP4OoSlkByn_74E4IpTlmo1VLUZRA7snx0=.5b38cf1a-c2dd-4f1a-b9b5-d265b45037b7@github.com>

> During the course of the development of the generational mode for Shenandoah, we have found this tool useful to demonstrate progress and changes in behavior. We have also found this tool useful for troubleshooting performance issues and debugging crashes. There are many changes here, but these are the highlights:
> * The age and affiliation of a region are encoded in the border and shape of the region (respectively).
> * Phases are encoded with different colors for different generations and whether they have degenerated.
> * A mechanism to record and replay session has been added (record feature is implemented in hotspot and is not yet upstream).
> * Popup windows can be opened for additional detail on regions, as well as their history.
> * The legend shows the number of regions in the state described by the legend item.
> * Visualizer can now 'find' VMs running Shenandoah with region sampling enabled.
> Many months ago we broke backward compatibility on our branch, but we have recently restored it so the time seems right for a PR. Thank you for looking and sorry for the massive number of changes.

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

  Graph panel improvements
  
  Add time scale for graph panel and change the placement for different phase

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

Changes:
  - all: https://git.openjdk.org/shenandoah-visualizer/pull/1/files
  - new: https://git.openjdk.org/shenandoah-visualizer/pull/1/files/ab6ccb70..414c0b9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=00-01

  Stats: 197 lines in 3 files changed: 142 ins; 9 del; 46 mod
  Patch: https://git.openjdk.org/shenandoah-visualizer/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-visualizer pull/1/head:pull/1

PR: https://git.openjdk.org/shenandoah-visualizer/pull/1

From fyang at openjdk.org  Fri Sep  2 03:43:04 2022
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 2 Sep 2022 03:43:04 GMT
Subject: RFR: 8293290: RISC-V: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
Message-ID: <M6dYDQLz-_w1v9Dlw55sAW0E8b_laN30tJid1nKudUc=.cf97945b-f1e7-4e0b-bed7-b7074a9996a9@github.com>

Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv.

This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186).
This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API.

Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board.

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

Commit messages:
 - 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop

Changes: https://git.openjdk.org/jdk/pull/10137/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293290
  Stats: 71 lines in 16 files changed: 2 ins; 0 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/10137.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10137/head:pull/10137

PR: https://git.openjdk.org/jdk/pull/10137

From duke at openjdk.org  Fri Sep  2 11:30:24 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 2 Sep 2022 11:30:24 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable
Message-ID: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>

Hi!

Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.

This passes tier1, tier2 tests.

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

Commit messages:
 - Attempt to document base()
 - Change out as_string to base where applicable

Changes: https://git.openjdk.org/jdk/pull/10142/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293251
  Stats: 69 lines in 27 files changed: 4 ins; 8 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/10142.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142

PR: https://git.openjdk.org/jdk/pull/10142

From shade at openjdk.org  Fri Sep  2 12:50:41 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 2 Sep 2022 12:50:41 GMT
Subject: RFR: 8293290: RISC-V: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
In-Reply-To: <M6dYDQLz-_w1v9Dlw55sAW0E8b_laN30tJid1nKudUc=.cf97945b-f1e7-4e0b-bed7-b7074a9996a9@github.com>
References: <M6dYDQLz-_w1v9Dlw55sAW0E8b_laN30tJid1nKudUc=.cf97945b-f1e7-4e0b-bed7-b7074a9996a9@github.com>
Message-ID: <pEsolrJoLO-WHjcE6juKfwl7k-JFlyslARWTcQjH5FQ=.31c054f3-5107-4ed4-b59d-3345ed3f7281@github.com>

On Fri, 2 Sep 2022 03:34:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv.
> 
> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186).
> This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API.
> 
> Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board.

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10137

From stuefe at openjdk.org  Fri Sep  2 13:40:48 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Sep 2022 13:40:48 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <FY5OLFTC3N7K_AepdTHz-8CxrGOUfEeVmYMNnwfMxik=.34e914bd-cecd-4542-9d28-8fe6bb087a00@github.com>

On Fri, 2 Sep 2022 11:20:59 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Hi @jdksjolen,

Generally good, see remarks inline.

Cheers, Thomas

src/hotspot/share/code/codeCache.cpp line 1485:

> 1483:                  get_code_heap_flag_name(code_blob_type));
> 1484:       const char *msg1 = msg1_stream.base();
> 1485:       const char *msg2 = msg2_stream.base();

I would do this only in places where it's super-obvious nothing bad will happen and where it cannot bitrot. Here it's not, since you assign it to a temporary variable. Someone inattentive may modify it in the future, forgetting about why this is special. 

Since the error is hard to catch and the benefit tiny, I would leave this as `as_string`. This is just my gut feeling, others may disagree.

src/hotspot/share/utilities/ostream.hpp line 221:

> 219:   // A stringStream may free the pointer returned
> 220:   // if any of its methods are called, therefore
> 221:   // take care in using this method.

Comment is a bit misleading, what does "borrow" mean? 

Suggestion: "Returns internal buffer. Returned buffer is only guaranteed to be valid as long as stream is not modified"

src/hotspot/share/utilities/vmError.cpp line 576:

> 574:       stringStream message;
> 575:       message.print("This is a message with no ResourceMark");
> 576:       tty->print_cr("%s", message.base());

I think the intent was to use as_string deliberately to get an mark-missing crash.

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

Changes requested by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10142

From wkemper at openjdk.org  Fri Sep  2 16:52:21 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 16:52:21 GMT
Subject: RFR: Use os::malloc instead of malloc [v2]
In-Reply-To: <SiRKKWEjF6iQHNREwPnomEFI8-U5eb8pQ1FgkhdUjX4=.fcff46d3-5338-4582-af58-abe67fbc50be@github.com>
References: <SlxM_DfnC58LRn7SUHIbMPyd_Ioe3q8IADHBuer1AW4=.03b0c8b2-3b33-4ab1-87cb-32e90faf4551@github.com>
 <SiRKKWEjF6iQHNREwPnomEFI8-U5eb8pQ1FgkhdUjX4=.fcff46d3-5338-4582-af58-abe67fbc50be@github.com>
Message-ID: <DDbny3hRBNL0iAsk5JcRxfQpNigrUoq0boF-mDaIR_U=.05e569ec-34cd-4e4e-80e4-fb91d39fd48d@github.com>

On Tue, 2 Aug 2022 22:53:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This fixes a compiler error with gcc-10.3.0 used by github actions
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update another use of global malloc/free

I'm closing this PR in favor of a [new PR](https://github.com/openjdk/shenandoah/pull/160) which address the original build issue and another, latent issue in verification of the remembered set.

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

PR: https://git.openjdk.org/shenandoah/pull/155

From wkemper at openjdk.org  Fri Sep  2 16:52:21 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 16:52:21 GMT
Subject: Withdrawn: Use os::malloc instead of malloc
In-Reply-To: <SlxM_DfnC58LRn7SUHIbMPyd_Ioe3q8IADHBuer1AW4=.03b0c8b2-3b33-4ab1-87cb-32e90faf4551@github.com>
References: <SlxM_DfnC58LRn7SUHIbMPyd_Ioe3q8IADHBuer1AW4=.03b0c8b2-3b33-4ab1-87cb-32e90faf4551@github.com>
Message-ID: <Gi6zQDdiM-Bw1KCo2ibfLl4EU6Jmyj4jmGw7lf9W5UE=.86cb65fb-4d3b-4358-b976-606dc60834f6@github.com>

On Tue, 2 Aug 2022 19:34:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This fixes a compiler error with gcc-10.3.0 used by github actions

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah/pull/155

From wkemper at openjdk.org  Fri Sep  2 17:01:42 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 17:01:42 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations
Message-ID: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>

This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.

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

Commit messages:
 - Removed unused header
 - Merge branch 'shenandoah-master' into fix-verifier-off-by-one
 - Do not attempt to validate cards beyond the lost valid card
 - Remove unused overreach map
 - Merge branch 'shenandoah-master' into use-os-malloc
 - Revert to global malloc
 - Update another use of global malloc/free
 - Use os::malloc instead of malloc

Changes: https://git.openjdk.org/shenandoah/pull/160/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=160&range=00
  Stats: 116 lines in 5 files changed: 21 ins; 88 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/160/head:pull/160

PR: https://git.openjdk.org/shenandoah/pull/160

From duke at openjdk.org  Fri Sep  2 17:15:53 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 2 Sep 2022 17:15:53 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <EADzidTGXyUQwBuq2Cwqq-qlH92Q8dJGVsCk2EcBGAU=.6f208b8e-157d-4547-87bd-156f22b8a9ac@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> 
> Testing with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

@fisk can you please review the changes

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

PR: https://git.openjdk.org/jdk/pull/10089

From kdnilsen at openjdk.org  Fri Sep  2 17:23:07 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Sep 2022 17:23:07 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations
In-Reply-To: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
Message-ID: <riN75EY-SDInl_1toAg6JwvMCcUeHIcgfpLlK2IW1s8=.cc617e1a-1978-43d3-a527-25e78ee1acbb@github.com>

On Fri, 2 Sep 2022 16:47:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.

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

> 401:     size_t end_card_index = index + offset / CardTable::card_size_in_words();
> 402: 
> 403:     if (end_card_index > index && end_card_index < _rs->last_valid_index()) {

If _rs->last_valid_index() is actually a valid index, why couldn't we make this test <=?  Or should we rename the last_valid_index() to be index_beyond_end()?

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

PR: https://git.openjdk.org/shenandoah/pull/160

From wkemper at openjdk.org  Fri Sep  2 17:47:21 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 17:47:21 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations
In-Reply-To: <riN75EY-SDInl_1toAg6JwvMCcUeHIcgfpLlK2IW1s8=.cc617e1a-1978-43d3-a527-25e78ee1acbb@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
 <riN75EY-SDInl_1toAg6JwvMCcUeHIcgfpLlK2IW1s8=.cc617e1a-1978-43d3-a527-25e78ee1acbb@github.com>
Message-ID: <E7kDMDtUohvV-PJ_YY6AqUMbcBLYwMkc4MKyYyTQbRc=.6be29d14-6372-4ef4-b1b7-8455509429c7@github.com>

On Fri, 2 Sep 2022 17:19:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 403:
> 
>> 401:     size_t end_card_index = index + offset / CardTable::card_size_in_words();
>> 402: 
>> 403:     if (end_card_index > index && end_card_index < _rs->last_valid_index()) {
> 
> If _rs->last_valid_index() is actually a valid index, why couldn't we make this test <=?  Or should we rename the last_valid_index() to be index_beyond_end()?

Good catch. I will test that.

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

PR: https://git.openjdk.org/shenandoah/pull/160

From stuefe at openjdk.org  Fri Sep  2 18:07:13 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 2 Sep 2022 18:07:13 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations
In-Reply-To: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
Message-ID: <065UNcP1aF-WXTEb3Uyk6rSWSf97UUAk5tnkxB8Ld1s=.c00bb184-c89a-4c56-b09e-497a8b6abbf9@github.com>

On Fri, 2 Sep 2022 16:47:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.

Just some drive-by-comments, I'm not a shenandoah developer.

Note that the trailing information after os::malloc/NEW_C_HEAP_ARRAY confusing your reader are canaries we set in NMT to catch overflow errors.

Cheers, Thomas

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

> 544:     // the card entries that correspond to old-gen memory.  But for now, let's be quick and dirty.
> 545:     object_starts = NEW_C_HEAP_ARRAY(crossing_info, rs->total_cards(), mtGC);
> 546:     if (object_starts == nullptr) {

Not necessary. NEW_C_HEAP_ARRAY handles OOMs by exiting the VM with a fatal error, unless you explicitly tell it otherwise.

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

> 553: 
> 554:   ~ShenandoahCardCluster() {
> 555:     if (object_starts != nullptr) {

Strictly speaking also not needed, since free(NULL) is a noop (also os::free, FREE_C_HEAP_ARRAY, etc)

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

PR: https://git.openjdk.org/shenandoah/pull/160

From wkemper at openjdk.org  Fri Sep  2 18:32:49 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 18:32:49 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <HhZe7u16S8fRzcZCXo75bOXMRE7bV3L5STpYtobFMYI=.c925600d-9f4c-4c2d-b61f-06320861eb20@github.com>

Sync up with upstream

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

Commit messages:
 - Merge branch 'shenandoah-master' into upstream-merge-test
 - Merge tag 'jdk-20+12' into upstream-merge-test
 - 8289764: gc/lock tests failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
 - 8292329: Enable CDS shared heap for zero builds
 - 8292739: Invalid legacy entries may be returned by Provider.getServices() call
 - 8290469: Add new positioning options to PassFailJFrame test framework
 - 8292679: Simplify thread creation in gtest and port 2 tests to new way
 - 8215916: The failure reason of an optional JAAS LoginModule is not logged
 - 8292816: GPL Classpath exception missing from assemblyprefix.h
 - 8292713: Unsafe.allocateInstance should be intrinsified without UseUnalignedAccesses
 - ... and 313 more: https://git.openjdk.org/shenandoah/compare/b4ff060b...ef4ddacf

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

Changes: https://git.openjdk.org/shenandoah/pull/161/files
  Stats: 71080 lines in 1430 files changed: 34589 ins; 29655 del; 6836 mod
  Patch: https://git.openjdk.org/shenandoah/pull/161.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/161/head:pull/161

PR: https://git.openjdk.org/shenandoah/pull/161

From wkemper at openjdk.org  Fri Sep  2 18:45:14 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 18:45:14 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <HhZe7u16S8fRzcZCXo75bOXMRE7bV3L5STpYtobFMYI=.c925600d-9f4c-4c2d-b61f-06320861eb20@github.com>
References: <HhZe7u16S8fRzcZCXo75bOXMRE7bV3L5STpYtobFMYI=.c925600d-9f4c-4c2d-b61f-06320861eb20@github.com>
Message-ID: <AM_UQtK1szuvpXNh76LgIoXhskT_g-u9PPysn_LrAuQ=.a43b50ac-ea7c-4cce-9b4f-c81506eff9fa@github.com>

> Sync up with upstream

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

 - Merge branch 'shenandoah-master' into upstream-merge-test
 - Fix budgeting assertion
   
   Reviewed-by: wkemper
 - Handle old, pinned regions
   
   Reviewed-by: ysr, kdnilsen
 - Include old humongous start regions when counting immediate garbage
   
   Reviewed-by: ysr, kdnilsen
 - Merge openjdk/jdk:master
   
   Reviewed-by: rkennke
 - Merge tag 'jdk-20+12' into upstream-merge-test
   
   Added tag jdk-20+12 for changeset 7b81a9c7
 - Merge tag 'jdk-20+9' into upstream-merge-test
   
   Added tag jdk-20+9 for changeset 13f0f126
 - Merge branch 'shenandoah-master' into upstream-merge-test
 - Load balance remembered set scanning
   
   Reviewed-by: wkemper
 - Merge branch 'shenandoah-master' into upstream-merge-test
 - ... and 166 more: https://git.openjdk.org/shenandoah/compare/7b81a9c7...ef4ddacf

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

Changes: https://git.openjdk.org/shenandoah/pull/161/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=161&range=01
  Stats: 14619 lines in 141 files changed: 13399 ins; 485 del; 735 mod
  Patch: https://git.openjdk.org/shenandoah/pull/161.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/161/head:pull/161

PR: https://git.openjdk.org/shenandoah/pull/161

From wkemper at openjdk.org  Fri Sep  2 18:45:15 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 18:45:15 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <HhZe7u16S8fRzcZCXo75bOXMRE7bV3L5STpYtobFMYI=.c925600d-9f4c-4c2d-b61f-06320861eb20@github.com>
References: <HhZe7u16S8fRzcZCXo75bOXMRE7bV3L5STpYtobFMYI=.c925600d-9f4c-4c2d-b61f-06320861eb20@github.com>
Message-ID: <DiaVmv-1J42sDN2iGt1Dz0SuxU_VjcfH_DtsDkAWQ40=.577091f0-e422-4191-9694-3e4f90aa58b0@github.com>

On Fri, 2 Sep 2022 18:25:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Sync up with upstream

This pull request has now been integrated.

Changeset: 7bf65f1d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/7bf65f1dde179e1a11cb1357137875e139bb1229
Stats:     71080 lines in 1430 files changed: 34589 ins; 29655 del; 6836 mod

Merge openjdk/jdk:master

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

PR: https://git.openjdk.org/shenandoah/pull/161

From eosterlund at openjdk.org  Fri Sep  2 19:48:44 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 2 Sep 2022 19:48:44 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <ni3OahHgXGWbJSne_psYQZ99Nfb9HKSIh6xvWp6v3vg=.7a4f62a9-eeb9-4c97-88fa-7cb8c84e431f@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> 
> Testing with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Looks great!

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

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10089

From wkemper at openjdk.org  Fri Sep  2 21:36:11 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 21:36:11 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations [v2]
In-Reply-To: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
Message-ID: <bJq-SPGuZDiDvM6Vxqf5eZuKhiqGrjykw4SQb1rScLc=.51a97df5-cf16-4c89-aa58-57f6f7bae60b@github.com>

> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.

William Kemper has updated the pull request incrementally with two additional commits since the last revision:

 - Fix zero build
 - Fix off-by-one error in off-by-one fix

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/160/files
  - new: https://git.openjdk.org/shenandoah/pull/160/files/28945aca..b8abe52e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=160&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=160&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/160/head:pull/160

PR: https://git.openjdk.org/shenandoah/pull/160

From wkemper at openjdk.org  Fri Sep  2 21:54:13 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 21:54:13 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations [v3]
In-Reply-To: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
Message-ID: <gGwBW7M34szhnEFm6JoEfjQISGl7lekObbph2bfWR0I=.3c27532b-1530-40ef-ac71-b8030e913224@github.com>

> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.

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

  Remove unnecessary allocate/free checks

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/160/files
  - new: https://git.openjdk.org/shenandoah/pull/160/files/b8abe52e..74ef669c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=160&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=160&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/160/head:pull/160

PR: https://git.openjdk.org/shenandoah/pull/160

From wkemper at openjdk.org  Fri Sep  2 21:54:14 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 21:54:14 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations [v3]
In-Reply-To: <065UNcP1aF-WXTEb3Uyk6rSWSf97UUAk5tnkxB8Ld1s=.c00bb184-c89a-4c56-b09e-497a8b6abbf9@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
 <065UNcP1aF-WXTEb3Uyk6rSWSf97UUAk5tnkxB8Ld1s=.c00bb184-c89a-4c56-b09e-497a8b6abbf9@github.com>
Message-ID: <cle-1xkj_Ts8645fJ2tl2Ub6M_de5QfdCXi1vltx-og=.f785ba40-dd62-4f5d-977f-7f5907558e15@github.com>

On Fri, 2 Sep 2022 18:03:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary allocate/free checks
>
> Just some drive-by-comments, I'm not a shenandoah developer.
> 
> Note that the trailing information after os::malloc/NEW_C_HEAP_ARRAY confusing your reader are canaries we set in NMT to catch overflow errors.
> 
> Cheers, Thomas

Appreciate you stopping by @tstuefe , thanks for the review.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 555:
> 
>> 553: 
>> 554:   ~ShenandoahCardCluster() {
>> 555:     if (object_starts != nullptr) {
> 
> Strictly speaking also not needed, since free(NULL) is a noop (also os::free, FREE_C_HEAP_ARRAY, etc)

Thank you, I've cleaned this up.

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

PR: https://git.openjdk.org/shenandoah/pull/160

From kdnilsen at openjdk.org  Fri Sep  2 22:59:22 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Sep 2022 22:59:22 GMT
Subject: RFR: Fix off-by-one error when verifying object registrations [v3]
In-Reply-To: <gGwBW7M34szhnEFm6JoEfjQISGl7lekObbph2bfWR0I=.3c27532b-1530-40ef-ac71-b8030e913224@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
 <gGwBW7M34szhnEFm6JoEfjQISGl7lekObbph2bfWR0I=.3c27532b-1530-40ef-ac71-b8030e913224@github.com>
Message-ID: <SNRKpGyB2zRUwgJiIzwwFGRc_ZcftLfKMO4EK_3LRm8=.d05e258d-6a2d-4ecd-9c3e-43f9157f4fa7@github.com>

On Fri, 2 Sep 2022 21:54:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary allocate/free checks

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.org/shenandoah/pull/160

From wkemper at openjdk.org  Fri Sep  2 23:11:08 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Sep 2022 23:11:08 GMT
Subject: Integrated: Fix off-by-one error when verifying object registrations
In-Reply-To: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
References: <ia0jNtI3jOgbjTi1hX4co249pgJGbM8M1cb6xsyh7-E=.be7d9694-d087-4c29-a0a6-473a124e2dcf@github.com>
Message-ID: <WlipPRji7Qegx6wWw9ko40kal2HakwYOru2CdHmAuJ8=.1c6972df-91ac-41e5-b560-38d936eefce2@github.com>

On Fri, 2 Sep 2022 16:47:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change originally started with an effort to fix a build error caused by using the global `malloc` and `free` calls. Replacing these calls with hotspot idioms caused remembered set verification errors. The verification errors were, ultimately, due to the verification code reading past the end of an array. The `NEW_C_HEAP_ARRAY` macro tacks a bit of information onto the allocated array for the purpose of tracking native memory use (NMT). This was enough to change the behavior when the verifier read past the end of the array. This PR subsumes https://github.com/openjdk/shenandoah/pull/155 and fixes the root cause of the verification errors. This change also removes the unused `overreach_map` as this was also using global `malloc` and `free` calls.

This pull request has now been integrated.

Changeset: 791b74dd
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/791b74dd7645198dfc9c7f98bfab1602b94bbb8b
Stats:     116 lines in 6 files changed: 20 ins; 91 del; 5 mod

Fix off-by-one error when verifying object registrations

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.org/shenandoah/pull/160

From duke at openjdk.org  Fri Sep  2 23:24:53 2022
From: duke at openjdk.org (cfumiwu)
Date: Fri, 2 Sep 2022 23:24:53 GMT
Subject: RFR: Shenandoah unified logging
Message-ID: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>

Writing the Shenandoah log file to the log stream without creating a new stream for it.

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

Commit messages:
 - Delete the ShenandoahLogRegionSampling from the globals.hpp
 - Change the log target to debug tag
 - Using unified logging for shenandoah log file output

Changes: https://git.openjdk.org/shenandoah/pull/162/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=162&range=00
  Stats: 575 lines in 7 files changed: 27 ins; 542 del; 6 mod
  Patch: https://git.openjdk.org/shenandoah/pull/162.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/162/head:pull/162

PR: https://git.openjdk.org/shenandoah/pull/162

From duke at openjdk.org  Mon Sep  5 07:49:32 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 5 Sep 2022 07:49:32 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable
In-Reply-To: <FY5OLFTC3N7K_AepdTHz-8CxrGOUfEeVmYMNnwfMxik=.34e914bd-cecd-4542-9d28-8fe6bb087a00@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <FY5OLFTC3N7K_AepdTHz-8CxrGOUfEeVmYMNnwfMxik=.34e914bd-cecd-4542-9d28-8fe6bb087a00@github.com>
Message-ID: <C_7odyDmklw8DbWj9IcbLGiS9bSJzsbDilt-VIhC0xs=.534c2f22-6ecf-430f-8e02-358d42762c4c@github.com>

On Fri, 2 Sep 2022 13:31:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> src/hotspot/share/code/codeCache.cpp line 1485:
> 
>> 1483:                  get_code_heap_flag_name(code_blob_type));
>> 1484:       const char *msg1 = msg1_stream.base();
>> 1485:       const char *msg2 = msg2_stream.base();
> 
> I would do this only in places where it's super-obvious nothing bad will happen and where it cannot bitrot. Here it's not, since you assign it to a temporary variable. Someone inattentive may modify it in the future, forgetting about why this is special. 
> 
> Since the error is hard to catch and the benefit tiny, I would leave this as `as_string`. This is just my gut feeling, others may disagree.

I think it's a very good idea.

> src/hotspot/share/utilities/ostream.hpp line 221:
> 
>> 219:   // A stringStream may free the pointer returned
>> 220:   // if any of its methods are called, therefore
>> 221:   // take care in using this method.
> 
> Comment is a bit misleading, what does "borrow" mean? 
> 
> Suggestion: "Returns internal buffer. Returned buffer is only guaranteed to be valid as long as stream is not modified"

That's much clearer, thank you for the suggestion.

> src/hotspot/share/utilities/vmError.cpp line 576:
> 
>> 574:       stringStream message;
>> 575:       message.print("This is a message with no ResourceMark");
>> 576:       tty->print_cr("%s", message.base());
> 
> I think the intent was to use as_string deliberately to get an mark-missing crash.

Thank you!

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Mon Sep  5 08:22:23 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 5 Sep 2022 08:22:23 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v2]
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <g9_fuhuwJe1kjJLuB31fwCpDeqR8qAAIxDI3xT9KYgM=.81da3b8c-29a2-4319-abae-d892ec1f35fa@github.com>

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Fix review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10142/files
  - new: https://git.openjdk.org/jdk/pull/10142/files/2fe12418..24dd048c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=00-01

  Stats: 8 lines in 3 files changed: 1 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10142.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Mon Sep  5 08:22:25 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 5 Sep 2022 08:22:25 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v2]
In-Reply-To: <FY5OLFTC3N7K_AepdTHz-8CxrGOUfEeVmYMNnwfMxik=.34e914bd-cecd-4542-9d28-8fe6bb087a00@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <FY5OLFTC3N7K_AepdTHz-8CxrGOUfEeVmYMNnwfMxik=.34e914bd-cecd-4542-9d28-8fe6bb087a00@github.com>
Message-ID: <0ijpBLniU8SAOKHxosyjaT2aR3pDdiQYg1r6rEEwrnc=.94072329-396b-442c-b16a-e5cc91e3e607@github.com>

On Fri, 2 Sep 2022 13:37:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review comments
>
> Hi @jdksjolen,
> 
> Generally good, see remarks inline.
> 
> Cheers, Thomas

Thank you for going through all of the changes @tstuefe , I am well aware that it's not very exciting stuff :-).

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

PR: https://git.openjdk.org/jdk/pull/10142

From stuefe at openjdk.org  Mon Sep  5 08:35:47 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 5 Sep 2022 08:35:47 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v2]
In-Reply-To: <g9_fuhuwJe1kjJLuB31fwCpDeqR8qAAIxDI3xT9KYgM=.81da3b8c-29a2-4319-abae-d892ec1f35fa@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <g9_fuhuwJe1kjJLuB31fwCpDeqR8qAAIxDI3xT9KYgM=.81da3b8c-29a2-4319-abae-d892ec1f35fa@github.com>
Message-ID: <u1d4v4mxXEvhe6xKipqHd0ZUj31rwGBpHwCglCC9T90=.2effe05e-9445-4ae7-98ea-23d87ff0869c@github.com>

On Mon, 5 Sep 2022 08:22:23 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

All good!

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10142

From fyang at openjdk.org  Mon Sep  5 10:04:48 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 5 Sep 2022 10:04:48 GMT
Subject: RFR: 8293290: RISC-V: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
In-Reply-To: <pEsolrJoLO-WHjcE6juKfwl7k-JFlyslARWTcQjH5FQ=.31c054f3-5107-4ed4-b59d-3345ed3f7281@github.com>
References: <M6dYDQLz-_w1v9Dlw55sAW0E8b_laN30tJid1nKudUc=.cf97945b-f1e7-4e0b-bed7-b7074a9996a9@github.com>
 <pEsolrJoLO-WHjcE6juKfwl7k-JFlyslARWTcQjH5FQ=.31c054f3-5107-4ed4-b59d-3345ed3f7281@github.com>
Message-ID: <RqfRV9r0thhnWiNvFA3agnMBxgTBTpMEGFlOkm8ESjI=.87c77b79-3bdb-4615-ad81-0bb2ffe03f09@github.com>

On Fri, 2 Sep 2022 12:47:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv.
>> 
>> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186).
>> This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API.
>> 
>> Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board.
>
> Looks fine.

@shipilev : Thanks for the review. Also passed Tier2 test. Integrate then.

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

PR: https://git.openjdk.org/jdk/pull/10137

From fyang at openjdk.org  Mon Sep  5 10:04:49 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 5 Sep 2022 10:04:49 GMT
Subject: Integrated: 8293290: RISC-V: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
In-Reply-To: <M6dYDQLz-_w1v9Dlw55sAW0E8b_laN30tJid1nKudUc=.cf97945b-f1e7-4e0b-bed7-b7074a9996a9@github.com>
References: <M6dYDQLz-_w1v9Dlw55sAW0E8b_laN30tJid1nKudUc=.cf97945b-f1e7-4e0b-bed7-b7074a9996a9@github.com>
Message-ID: <o6bVgf8CrFhBbTvBbx031EsPM4mqPpgyeOOFmZiF_CA=.39e45a9f-e60b-4d16-b864-892ddaa3f715@github.com>

On Fri, 2 Sep 2022 03:34:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv.
> 
> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186).
> This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API.
> 
> Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board.

This pull request has now been integrated.

Changeset: 5bed9f76
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5bed9f767507bb0f123247d149ead84d2d635f52
Stats:     71 lines in 16 files changed: 2 ins; 0 del; 69 mod

8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop

Reviewed-by: shade

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

PR: https://git.openjdk.org/jdk/pull/10137

From aboldtch at openjdk.org  Mon Sep  5 10:16:26 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 10:16:26 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at
Message-ID: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>

Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.

Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.

Testing: Oracle platforms tier 1-3

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

Commit messages:
 - 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at

Changes: https://git.openjdk.org/jdk/pull/10161/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293351
  Stats: 88 lines in 14 files changed: 7 ins; 2 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/10161.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10161/head:pull/10161

PR: https://git.openjdk.org/jdk/pull/10161

From aph at openjdk.org  Mon Sep  5 10:40:44 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 5 Sep 2022 10:40:44 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <x2kx2iV7FEnSTfKKhMX5KwLS6I2gKRv12L-KA2_iDz0=.a2c9361d-b08e-430a-b181-d87288b99228@github.com>

On Mon, 5 Sep 2022 10:09:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

This is s welcome improvement. Thanks.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10161

From fyang at openjdk.org  Mon Sep  5 12:30:40 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 5 Sep 2022 12:30:40 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <rnoMNvyL_H_X8lJd_zbw2uWIA29k7c-03CPJJYwI0-E=.03260fd5-5448-4aeb-b093-7225457f6d7d@github.com>

On Mon, 5 Sep 2022 10:09:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2466:

> 2464: #endif
> 2465: 
> 2466: void MacroAssembler::resolve_jobject(Register value, Register tmp1, Register tmp2) {

You might want to rename the second parameter for its declaration in file macroAssembler_aarch64.hpp

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Mon Sep  5 12:49:14 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 12:49:14 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix argument names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10161/files
  - new: https://git.openjdk.org/jdk/pull/10161/files/ebcd8ebe..bfc33939

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Mon Sep  5 12:49:15 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 12:49:15 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <rnoMNvyL_H_X8lJd_zbw2uWIA29k7c-03CPJJYwI0-E=.03260fd5-5448-4aeb-b093-7225457f6d7d@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <rnoMNvyL_H_X8lJd_zbw2uWIA29k7c-03CPJJYwI0-E=.03260fd5-5448-4aeb-b093-7225457f6d7d@github.com>
Message-ID: <mnCn7EDzSiLiJg7oqt7mVivSdXvDCVN8bzLbmnjXqDs=.a12da8ec-d45f-4d31-84b2-6aff3eca9465@github.com>

On Mon, 5 Sep 2022 12:26:53 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix argument names
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2466:
> 
>> 2464: #endif
>> 2465: 
>> 2466: void MacroAssembler::resolve_jobject(Register value, Register tmp1, Register tmp2) {
> 
> You might want to rename the second parameter for its declaration in file macroAssembler_aarch64.hpp

Good catch ? . Fixed

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

PR: https://git.openjdk.org/jdk/pull/10161

From tschatzl at openjdk.org  Mon Sep  5 13:05:44 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 5 Sep 2022 13:05:44 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
Message-ID: <aEP9F6GEKN3nYlaUZToMMF8JaL0lHvT2yzb0d8vOA_A=.fe276240-a817-4a8e-bc34-ba7e40092e6e@github.com>

On Mon, 5 Sep 2022 12:49:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix argument names

Marked as reviewed by tschatzl (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10161

From fyang at openjdk.org  Mon Sep  5 13:53:43 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 5 Sep 2022 13:53:43 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
Message-ID: <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>

On Mon, 5 Sep 2022 12:49:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix argument names

Would you mind a few more tweaks? Thanks.

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 73:

> 71: 
> 72:   void load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type,
> 73:                Register dst, Address src, Register tmp1, Register tmp2);

Need similar modification for function definition in file barrierSetAssembler_aarch64.cpp

src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 288:

> 286: 
> 287:   // Is it a weak but alive CLD?
> 288:   __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));

No need to save r11 then?

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

Changes requested by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Mon Sep  5 14:57:32 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 14:57:32 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v3]
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <s60_JiGZWqNsXdF1sWWJMrImJJft3SeBsdnUlfqa5nk=.18b19d16-8362-42fd-b0ed-f80ee7514664@github.com>

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix argument name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10161/files
  - new: https://git.openjdk.org/jdk/pull/10161/files/bfc33939..7f604f84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Mon Sep  5 14:57:34 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 14:57:34 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
Message-ID: <K4MCUHxXHsOlJLb6CR1tzdqE3QTSnX_YpAmnEIGt7A4=.c6464810-67b0-44bc-abfc-b33080799021@github.com>

On Mon, 5 Sep 2022 13:45:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix argument names
>
> src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 73:
> 
>> 71: 
>> 72:   void load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type,
>> 73:                Register dst, Address src, Register tmp1, Register tmp2);
> 
> Need similar modification for function definition in file barrierSetAssembler_aarch64.cpp

? . Fixed

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Mon Sep  5 15:00:06 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 5 Sep 2022 15:00:06 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
Message-ID: <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>

On Mon, 5 Sep 2022 13:46:24 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix argument names
>
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 288:
> 
>> 286: 
>> 287:   // Is it a weak but alive CLD?
>> 288:   __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));
> 
> No need to save r11 then?

As `resolve_weak_handle` may call into the VM `r11` may still be clobbered. The reason that `rscratch[1/2]` was not used previously was because  some GC in the `resolve_weak_handle` call graph used them implicitly. This is all explicit now so `rscratch` is used instead as it seems like it is the way the GC API has gone, with all registers being explicit. 

There is still some room for improvement here with regards to being more consistent with what registers are used.

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

PR: https://git.openjdk.org/jdk/pull/10161

From haosun at openjdk.org  Tue Sep  6 00:24:45 2022
From: haosun at openjdk.org (Hao Sun)
Date: Tue, 6 Sep 2022 00:24:45 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v3]
In-Reply-To: <s60_JiGZWqNsXdF1sWWJMrImJJft3SeBsdnUlfqa5nk=.18b19d16-8362-42fd-b0ed-f80ee7514664@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <s60_JiGZWqNsXdF1sWWJMrImJJft3SeBsdnUlfqa5nk=.18b19d16-8362-42fd-b0ed-f80ee7514664@github.com>
Message-ID: <GhpUuxatZsakIxh8pKZQIJgWLrL6NEP1VowuKNXWEi0=.1977cf60-f212-430f-be55-bcb4cbca8368@github.com>

On Mon, 5 Sep 2022 14:57:32 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix argument name

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 48:

> 46:                             Register pre_val,
> 47:                             Register thread,
> 48:                             Register tmp,

It would be better to use `tmp1` as the definition site does.

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

PR: https://git.openjdk.org/jdk/pull/10161

From fyang at openjdk.org  Tue Sep  6 03:40:42 2022
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 6 Sep 2022 03:40:42 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
 <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
Message-ID: <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>

On Mon, 5 Sep 2022 14:58:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 288:
>> 
>>> 286: 
>>> 287:   // Is it a weak but alive CLD?
>>> 288:   __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));
>> 
>> No need to save r11 then?
>
> As `resolve_weak_handle` may call into the VM `r11` may still be clobbered. The reason that `rscratch[1/2]` was not used previously was because  some GC in the `resolve_weak_handle` call graph used them implicitly. This is all explicit now so `rscratch` is used instead as it seems like it is the way the GC API has gone, with all registers being explicit. 
> 
> There is still some room for improvement here with regards to being more consistent with what registers are used.

"As resolve_weak_handle may call into the VM r11 may still be clobbered. "
-- I don't quite understand this.  If this is the case, shouldn't r11 be saved & restored immediate before and after the VM call together with other live caller-save registers?

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 06:24:38 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 06:24:38 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v4]
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Make tmp register names consistent g1BarrierSetAssembler_aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10161/files
  - new: https://git.openjdk.org/jdk/pull/10161/files/7f604f84..ad5a7694

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 06:24:40 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 06:24:40 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v3]
In-Reply-To: <GhpUuxatZsakIxh8pKZQIJgWLrL6NEP1VowuKNXWEi0=.1977cf60-f212-430f-be55-bcb4cbca8368@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <s60_JiGZWqNsXdF1sWWJMrImJJft3SeBsdnUlfqa5nk=.18b19d16-8362-42fd-b0ed-f80ee7514664@github.com>
 <GhpUuxatZsakIxh8pKZQIJgWLrL6NEP1VowuKNXWEi0=.1977cf60-f212-430f-be55-bcb4cbca8368@github.com>
Message-ID: <K6ZjQQ9hxgA4pLYi0pI_Pzn3MFw3KZPLJEQ3JG_mZrI=.b718a512-8a48-4c12-9c86-d4702ef9be63@github.com>

On Tue, 6 Sep 2022 00:15:08 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix argument name
>
> src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 48:
> 
>> 46:                             Register pre_val,
>> 47:                             Register thread,
>> 48:                             Register tmp,
> 
> It would be better to use `tmp1` as the definition site does.

? Fixed. Made all two temporary register names consistent across g1BarrierSetAssembler

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 06:38:46 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 06:38:46 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
 <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
 <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>
Message-ID: <d0N_2q9BpQEvvbwWbgWNjdKl7btXB-w5gaczG6hLp0c=.36959be0-0940-4dbc-b35a-fb5f67aab00f@github.com>

On Tue, 6 Sep 2022 03:38:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> As `resolve_weak_handle` may call into the VM `r11` may still be clobbered. The reason that `rscratch[1/2]` was not used previously was because  some GC in the `resolve_weak_handle` call graph used them implicitly. This is all explicit now so `rscratch` is used instead as it seems like it is the way the GC API has gone, with all registers being explicit. 
>> 
>> There is still some room for improvement here with regards to being more consistent with what registers are used.
>
> "As resolve_weak_handle may call into the VM r11 may still be clobbered. "
> -- I don't quite understand this.  If this is the case, shouldn't r11 be saved & restored immediate before and after the VM call together with other live caller-save registers?

Maybe? Actually looking at it a second time it seems like r0-r7 and r9-r17 are pushed to the stack at the vm call I was looking at. 
I am probably missing something. I do not fully understand the reason for pushing the registers at this point, not earlier or later. Would have to investigate further. I do however think that such a change belongs to a separate issue/PR. This PR should not change the instruction emission, only which registers are used.

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

PR: https://git.openjdk.org/jdk/pull/10161

From fyang at openjdk.org  Tue Sep  6 06:57:44 2022
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 6 Sep 2022 06:57:44 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v4]
In-Reply-To: <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
Message-ID: <3_Z3Lkc5c0detzCU9-j4ps0Eyr_qMf4mOB3fNy0QPyM=.3e3579ad-ce26-4b6f-97e6-90fafd20be09@github.com>

On Tue, 6 Sep 2022 06:24:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make tmp register names consistent g1BarrierSetAssembler_aarch64

Marked as reviewed by fyang (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10161

From fyang at openjdk.org  Tue Sep  6 06:57:45 2022
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 6 Sep 2022 06:57:45 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <d0N_2q9BpQEvvbwWbgWNjdKl7btXB-w5gaczG6hLp0c=.36959be0-0940-4dbc-b35a-fb5f67aab00f@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
 <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
 <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>
 <d0N_2q9BpQEvvbwWbgWNjdKl7btXB-w5gaczG6hLp0c=.36959be0-0940-4dbc-b35a-fb5f67aab00f@github.com>
Message-ID: <AxUzT1BqjBKY3o0XD0D2Ci0GhbCV_eamkYNg4GBU2wo=.3d49c36d-1342-4adc-8c4f-7c2b0178c9c5@github.com>

On Tue, 6 Sep 2022 06:35:13 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> "As resolve_weak_handle may call into the VM r11 may still be clobbered. "
>> -- I don't quite understand this.  If this is the case, shouldn't r11 be saved & restored immediate before and after the VM call together with other live caller-save registers?
>
> Maybe? Actually looking at it a second time it seems like r0-r7 and r9-r17 are pushed to the stack at the vm call I was looking at. 
> I am probably missing something. I do not fully understand the reason for pushing the registers at this point, not earlier or later. Would have to investigate further. I do however think that such a change belongs to a separate issue/PR. This PR should not change the instruction emission, only which registers are used.

I think the reason is that register r11 was used as temp register (and thus gets clobbered) by resolve_weak_handle previously. That's why this register was saved/restored here. But this has changed since it not used here anymore with your change. I am OK if you want to handle that in another PR. Just reminds. Thanks.

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 07:28:43 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 07:28:43 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <AxUzT1BqjBKY3o0XD0D2Ci0GhbCV_eamkYNg4GBU2wo=.3d49c36d-1342-4adc-8c4f-7c2b0178c9c5@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
 <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
 <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>
 <d0N_2q9BpQEvvbwWbgWNjdKl7btXB-w5gaczG6hLp0c=.36959be0-0940-4dbc-b35a-fb5f67aab00f@github.com>
 <AxUzT1BqjBKY3o0XD0D2Ci0GhbCV_eamkYNg4GBU2wo=.3d49c36d-1342-4adc-8c4f-7c2b0178c9c5@github.com>
Message-ID: <Q-M7SwsjDKEBCRxUB3YXHBvOo1wtDfUzm-3YQOM3LS4=.358a46e7-38db-404d-8e31-3b2c97dec7ef@github.com>

On Tue, 6 Sep 2022 06:52:53 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Maybe? Actually looking at it a second time it seems like r0-r7 and r9-r17 are pushed to the stack at the vm call I was looking at. 
>> I am probably missing something. I do not fully understand the reason for pushing the registers at this point, not earlier or later. Would have to investigate further. I do however think that such a change belongs to a separate issue/PR. This PR should not change the instruction emission, only which registers are used.
>
> I think the reason is that register r11 was used as temp register (and thus gets clobbered) by resolve_weak_handle previously. That's why this register was saved/restored here. But this has changed since it not used here anymore with your change. I am OK if you want to handle that in another PR. Just reminds. Thanks.

I looked into it some further. You are correct. The reason I thought it was important was because this change hard crashed.

+ __ str(r10, Address(__ pre(sp, -wordSize)));
- __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));

But I guess it is because I am misaligning the stack or there is some other reason `sp` cannot be bumped by `8`, only `16`. As this change is fine.

+ __ str(r10, Address(__ pre(sp, -2 * wordSize)));
- __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));

Maybe using the RegSets and `push` would do this correctly, or it is some special invariant for these adapters.

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

PR: https://git.openjdk.org/jdk/pull/10161

From smonteith at openjdk.org  Tue Sep  6 10:51:59 2022
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 6 Sep 2022 10:51:59 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v4]
In-Reply-To: <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
Message-ID: <2UVNEbi5HyCGK7dTdnd9fhCvoE8_xSfmTjgZ7SrtNnI=.e758be5a-ea7d-45f8-bb3f-0877c10ad2f3@github.com>

On Tue, 6 Sep 2022 06:24:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make tmp register names consistent g1BarrierSetAssembler_aarch64

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 277:

> 275:                          dst /* pre_val */,
> 276:                          rthread /* thread */,
> 277:                          tmp1 /* tmp */,

For tmp1 and tmp2 the comments, to match the paramter names, would also be "/* tmp1 */" and "/* tmp2 */".

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

PR: https://git.openjdk.org/jdk/pull/10161

From smonteith at openjdk.org  Tue Sep  6 11:04:53 2022
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 6 Sep 2022 11:04:53 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v4]
In-Reply-To: <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
Message-ID: <GNhAhcp3RFVbuY9bcEbOyXc7zWXYoW10nWy18i-YV0U=.f411e40b-d628-4be3-9ca6-873787cc1ac9@github.com>

On Tue, 6 Sep 2022 06:24:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make tmp register names consistent g1BarrierSetAssembler_aarch64

src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 301:

> 299:                        rthread /* thread */,
> 300:                        tmp1  /* tmp */,
> 301:                        rscratch2  /* tmp */,

"tmp1 /* tmp1 */," and "rscratch2 /* tmp2 */," to match the signature argument names.

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

PR: https://git.openjdk.org/jdk/pull/10161

From smonteith at openjdk.org  Tue Sep  6 11:04:54 2022
From: smonteith at openjdk.org (Stuart Monteith)
Date: Tue, 6 Sep 2022 11:04:54 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <Q-M7SwsjDKEBCRxUB3YXHBvOo1wtDfUzm-3YQOM3LS4=.358a46e7-38db-404d-8e31-3b2c97dec7ef@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
 <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
 <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>
 <d0N_2q9BpQEvvbwWbgWNjdKl7btXB-w5gaczG6hLp0c=.36959be0-0940-4dbc-b35a-fb5f67aab00f@github.com>
 <AxUzT1BqjBKY3o0XD0D2Ci0GhbCV_eamkYNg4GBU2wo=.3d49c36d-1342-4adc-8c4f-7c2b0178c9c5@github.com>
 <Q-M7SwsjDKEBCRxUB3YXHBvOo1wtDfUzm-3YQOM3LS4=.358a46e7-38db-404d-8e31-3b2c97dec7ef@github.com>
Message-ID: <g_YLpV-guw2rKxLzm78RkNnm1nAfujfGcVUlX_nEz7k=.9fb25d69-4587-4da7-9e3c-54e701872b02@github.com>

On Tue, 6 Sep 2022 07:26:39 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> I think the reason is that register r11 was used as temp register (and thus gets clobbered) by resolve_weak_handle previously. That's why this register was saved/restored here. But this has changed since it not used here anymore with your change. I am OK if you want to handle that in another PR. Just reminds. Thanks.
>
> I looked into it some further. You are correct. The reason I thought it was important was because this change hard crashed.
> 
> + __ str(r10, Address(__ pre(sp, -wordSize)));
> - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));
> 
> But I guess it is because I am misaligning the stack or there is some other reason `sp` cannot be bumped by `8`, only `16`. As this change is fine.
> 
> + __ str(r10, Address(__ pre(sp, -2 * wordSize)));
> - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));
> 
> Maybe using the RegSets and `push` would do this correctly, or it is some special invariant for these adapters.

The stackpointer needs 128 bit/64 byte alignment. use RegSets and` MacroAssembler::push(RegSet, sp);`, which will only push pairs of register. In this case: ` stp(r10, zr, Address(__ pre(sp, -2 * wordSize)));`

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 12:06:38 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 12:06:38 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v5]
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:

 - Push r10 using push and pop
 - Fix Argument Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10161/files
  - new: https://git.openjdk.org/jdk/pull/10161/files/ad5a7694..1572b08a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 12:06:42 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 12:06:42 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v4]
In-Reply-To: <2UVNEbi5HyCGK7dTdnd9fhCvoE8_xSfmTjgZ7SrtNnI=.e758be5a-ea7d-45f8-bb3f-0877c10ad2f3@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <X2N8Lv5hxt2HUqCQV6CgLwgNo7iVgw_Gc5qBZgzAaiA=.e9c2ed4b-3484-4331-9460-4c4dc02ac695@github.com>
 <2UVNEbi5HyCGK7dTdnd9fhCvoE8_xSfmTjgZ7SrtNnI=.e758be5a-ea7d-45f8-bb3f-0877c10ad2f3@github.com>
Message-ID: <eMHxjGS0ojKopWfKsRtWa6Bc8vk7pWcbqWg05xI33NU=.3a7dc36d-705c-418a-9646-7bf5acd02c79@github.com>

On Tue, 6 Sep 2022 10:49:06 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make tmp register names consistent g1BarrierSetAssembler_aarch64
>
> src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 277:
> 
>> 275:                          dst /* pre_val */,
>> 276:                          rthread /* thread */,
>> 277:                          tmp1 /* tmp */,
> 
> For tmp1 and tmp2 the comments, to match the paramter names, would also be "/* tmp1 */" and "/* tmp2 */".

Fixed ?

> src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 301:
> 
>> 299:                        rthread /* thread */,
>> 300:                        tmp1  /* tmp */,
>> 301:                        rscratch2  /* tmp */,
> 
> "tmp1 /* tmp1 */," and "rscratch2 /* tmp2 */," to match the signature argument names.

Fixed ?

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep  6 12:06:43 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 6 Sep 2022 12:06:43 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v2]
In-Reply-To: <g_YLpV-guw2rKxLzm78RkNnm1nAfujfGcVUlX_nEz7k=.9fb25d69-4587-4da7-9e3c-54e701872b02@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <uJeOju43zKudnosbI8ptmrjLeggY1orPS1Tx1w08o9E=.0b517593-ca8e-468f-83f8-5ccab1741830@github.com>
 <SFOA1Xf_youtfofow4dECewKtN_GTONXgdu1bqhwts8=.10b5b770-55ff-41a9-ad64-eb4df27cb675@github.com>
 <H37XzQafywxcmH_Kia66L1REZQVqEtx-5AME_ix4QW8=.bf709e74-0289-470a-ad79-6818784c1ada@github.com>
 <f_RptkBNloIgkr6Tjk6Ku8eDUjEB8vvRKeAjFAXw9nU=.912d3b2b-a2f4-4fa5-b79f-deeeffd578e4@github.com>
 <d0N_2q9BpQEvvbwWbgWNjdKl7btXB-w5gaczG6hLp0c=.36959be0-0940-4dbc-b35a-fb5f67aab00f@github.com>
 <AxUzT1BqjBKY3o0XD0D2Ci0GhbCV_eamkYNg4GBU2wo=.3d49c36d-1342-4adc-8c4f-7c2b0178c9c5@github.com>
 <Q-M7SwsjDKEBCRxUB3YXHBvOo1wtDfUzm-3YQOM3LS4=.358a46e7-38db-404d-8e31-3b2c97dec7ef@github.com>
 <g_YLpV-guw2rKxLzm78RkNnm1nAfujfGcVUlX_nEz7k=.9fb25d69-4587-4da7-9e3c-54e701872b02@github.com>
Message-ID: <fK0HgPJymdLBEvs9uo-Bt41MNxBPeJZsm9A_CGEvzEo=.929ec1a0-d746-4a62-9481-b9796779fe07@github.com>

On Tue, 6 Sep 2022 10:57:47 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> I looked into it some further. You are correct. The reason I thought it was important was because this change hard crashed.
>> 
>> + __ str(r10, Address(__ pre(sp, -wordSize)));
>> - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));
>> 
>> But I guess it is because I am misaligning the stack or there is some other reason `sp` cannot be bumped by `8`, only `16`. As this change is fine.
>> 
>> + __ str(r10, Address(__ pre(sp, -2 * wordSize)));
>> - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize)));
>> 
>> Maybe using the RegSets and `push` would do this correctly, or it is some special invariant for these adapters.
>
> The stackpointer needs 128 bit/64 byte alignment. use RegSets and` MacroAssembler::push(RegSet, sp);`, which will only push pairs of register. In this case: ` stp(r10, zr, Address(__ pre(sp, -2 * wordSize)));`

Fix using `MacroAssembler::push(RegSet, sp);`

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

PR: https://git.openjdk.org/jdk/pull/10161

From wkemper at openjdk.org  Tue Sep  6 16:27:54 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 6 Sep 2022 16:27:54 GMT
Subject: RFR: Shenandoah unified logging
In-Reply-To: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
References: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
Message-ID: <RSB7qwJNVj9nZ8FDwahZOmqsCAfasbqgMrqJ-QOfM0k=.70499e05-df3e-4fbd-8c70-be27f170bc6b@github.com>

On Fri, 2 Sep 2022 23:19:11 GMT, cfumiwu <duke at openjdk.org> wrote:

> Writing the Shenandoah log file to the log stream without creating a new stream for it.

This looks great. Thank you.

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

Marked as reviewed by wkemper (Committer).

PR: https://git.openjdk.org/shenandoah/pull/162

From shade at openjdk.org  Tue Sep  6 16:33:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Sep 2022 16:33:39 GMT
Subject: RFR: Shenandoah unified logging
In-Reply-To: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
References: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
Message-ID: <yUopRFGyD84FVAcxcgrkpDdNoLPe2MKze8i_J4EX8H0=.b0cb1c8e-43f4-43e6-b899-bf577f472ecd@github.com>

On Fri, 2 Sep 2022 23:19:11 GMT, cfumiwu <duke at openjdk.org> wrote:

> Writing the Shenandoah log file to the log stream without creating a new stream for it.

Yes, see how UL is more convenient than ad-hoc logging system :)

src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 103:

> 101:         }
> 102:         ls.cr();
> 103:     }

I think the indenting style is 2 spaces.

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

Marked as reviewed by shade (Committer).

PR: https://git.openjdk.org/shenandoah/pull/162

From duke at openjdk.org  Tue Sep  6 16:50:57 2022
From: duke at openjdk.org (cfumiwu)
Date: Tue, 6 Sep 2022 16:50:57 GMT
Subject: RFR: Shenandoah unified logging [v2]
In-Reply-To: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
References: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
Message-ID: <7rmpNqTmXKzRqYV9cN7IocbJSTR9hAtkLXp4MlGKV9Q=.e90722cc-e64e-40a0-b353-9ece549b35a8@github.com>

> Writing the Shenandoah log file to the log stream without creating a new stream for it.

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

  Fixing indenting problem

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/162/files
  - new: https://git.openjdk.org/shenandoah/pull/162/files/22dfc26a..5bdc1229

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=162&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=162&range=00-01

  Stats: 15 lines in 1 file changed: 2 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/shenandoah/pull/162.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/162/head:pull/162

PR: https://git.openjdk.org/shenandoah/pull/162

From wkemper at openjdk.org  Tue Sep  6 16:50:57 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 6 Sep 2022 16:50:57 GMT
Subject: RFR: Shenandoah unified logging [v2]
In-Reply-To: <yUopRFGyD84FVAcxcgrkpDdNoLPe2MKze8i_J4EX8H0=.b0cb1c8e-43f4-43e6-b899-bf577f472ecd@github.com>
References: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
 <yUopRFGyD84FVAcxcgrkpDdNoLPe2MKze8i_J4EX8H0=.b0cb1c8e-43f4-43e6-b899-bf577f472ecd@github.com>
Message-ID: <TgMowIQ1hGQ_t9y3fJCLzKr4Njpcy1zDxYmN3qrLtaE=.33efe514-d322-4f73-a9ec-263255bde894@github.com>

On Tue, 6 Sep 2022 16:28:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> cfumiwu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing indenting problem
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 103:
> 
>> 101:         }
>> 102:         ls.cr();
>> 103:     }
> 
> I think the indenting style is 2 spaces.

Thank you @shipilev . We have a PR open on the visualizer itself with changes that compliment these: https://github.com/openjdk/shenandoah-visualizer/pull/1. We would really appreciate it if you could find time to also review that PR.

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

PR: https://git.openjdk.org/shenandoah/pull/162

From duke at openjdk.org  Tue Sep  6 17:14:14 2022
From: duke at openjdk.org (cfumiwu)
Date: Tue, 6 Sep 2022 17:14:14 GMT
Subject: Integrated: Shenandoah unified logging
In-Reply-To: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
References: <JNhkWpG42HiWaO0TJ7qWhe6AtJrH7Mr_yxXxrowi_vc=.54bb4363-f24e-49a9-a2df-bd00f84cbe4b@github.com>
Message-ID: <DGP8KkCssn3WDKGl8JqOKDSf0I2LvDjR5pVKAtm1Ui8=.540ddc78-7663-41f5-b1db-1cdf3e57fb4c@github.com>

On Fri, 2 Sep 2022 23:19:11 GMT, cfumiwu <duke at openjdk.org> wrote:

> Writing the Shenandoah log file to the log stream without creating a new stream for it.

This pull request has now been integrated.

Changeset: a3799c8d
Author:    Celine Wu <cfumiwu at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/a3799c8d61920f58f03d0c88bd923ab53de51690
Stats:     575 lines in 7 files changed: 27 ins; 542 del; 6 mod

Shenandoah unified logging

Reviewed-by: wkemper, shade

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

PR: https://git.openjdk.org/shenandoah/pull/162

From duke at openjdk.org  Tue Sep  6 19:24:40 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 6 Sep 2022 19:24:40 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <o23Pennw6uTvjKP0cTvrN3E74CeGhUyEgiHvRoqJBNk=.37b9458f-e547-4c15-b2e8-b5080503c5ae@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> 
> Testing with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

@rkennke ping to get your review :-)

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

PR: https://git.openjdk.org/jdk/pull/10089

From wkemper at openjdk.org  Tue Sep  6 21:05:13 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 6 Sep 2022 21:05:13 GMT
Subject: RFR: Enhancements for Shenandoah's generational mode [v3]
In-Reply-To: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>
References: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>
Message-ID: <s74wMg1-B3mH7nWkm-PqgTWRnSjhm15kaqT6WfZDdDA=.a7ccbf83-c618-464c-a14e-012dc07f41d9@github.com>

> During the course of the development of the generational mode for Shenandoah, we have found this tool useful to demonstrate progress and changes in behavior. We have also found this tool useful for troubleshooting performance issues and debugging crashes. There are many changes here, but these are the highlights:
> * The age and affiliation of a region are encoded in the border and shape of the region (respectively).
> * Phases are encoded with different colors for different generations and whether they have degenerated.
> * A mechanism to record and replay session has been added (record feature is implemented in hotspot and is not yet upstream).
> * Popup windows can be opened for additional detail on regions, as well as their history.
> * The legend shows the number of regions in the state described by the legend item.
> * Visualizer can now 'find' VMs running Shenandoah with region sampling enabled.
> 
> Many months ago we broke backward compatibility on our branch, but we have recently restored it so the time seems right for a PR. Thank you for looking and sorry for the massive number of changes.

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

  Process log lines that may include decorators

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

Changes:
  - all: https://git.openjdk.org/shenandoah-visualizer/pull/1/files
  - new: https://git.openjdk.org/shenandoah-visualizer/pull/1/files/414c0b9f..b051f8ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=01-02

  Stats: 76 lines in 2 files changed: 76 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-visualizer/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-visualizer pull/1/head:pull/1

PR: https://git.openjdk.org/shenandoah-visualizer/pull/1

From wkemper at openjdk.org  Tue Sep  6 21:07:44 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 6 Sep 2022 21:07:44 GMT
Subject: RFR: Enhancements for Shenandoah's generational mode [v4]
In-Reply-To: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>
References: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>
Message-ID: <uP1OtHAN7cHP3OxOxPrIGFfpXxTSg1dFSDQJ3q566XE=.566a1de7-b871-40f6-a453-25fa251104bb@github.com>

> During the course of the development of the generational mode for Shenandoah, we have found this tool useful to demonstrate progress and changes in behavior. We have also found this tool useful for troubleshooting performance issues and debugging crashes. There are many changes here, but these are the highlights:
> * The age and affiliation of a region are encoded in the border and shape of the region (respectively).
> * Phases are encoded with different colors for different generations and whether they have degenerated.
> * A mechanism to record and replay session has been added (record feature is implemented in hotspot and is not yet upstream).
> * Popup windows can be opened for additional detail on regions, as well as their history.
> * The legend shows the number of regions in the state described by the legend item.
> * Visualizer can now 'find' VMs running Shenandoah with region sampling enabled.
> 
> Many months ago we broke backward compatibility on our branch, but we have recently restored it so the time seems right for a PR. Thank you for looking and sorry for the massive number of changes.

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

  Update README to describe latest features and improvements

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

Changes:
  - all: https://git.openjdk.org/shenandoah-visualizer/pull/1/files
  - new: https://git.openjdk.org/shenandoah-visualizer/pull/1/files/b051f8ed..f40f81fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=03
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=02-03

  Stats: 25 lines in 4 files changed: 18 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-visualizer/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-visualizer pull/1/head:pull/1

PR: https://git.openjdk.org/shenandoah-visualizer/pull/1

From fyang at openjdk.org  Wed Sep  7 08:44:37 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 7 Sep 2022 08:44:37 GMT
Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer
Message-ID: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>

Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions.
For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function:
  li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow)

But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function:
  mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans))

Use of 'mv' here calls 'movptr' and will emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' thus unifying the way of moving function pointer.

Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board.

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

Commit messages:
 - 8293474: RISC-V: Unify the way of moving function pointer

Changes: https://git.openjdk.org/jdk/pull/10194/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10194&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293474
  Stats: 31 lines in 3 files changed: 2 ins; 10 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10194.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10194/head:pull/10194

PR: https://git.openjdk.org/jdk/pull/10194

From yadongwang at openjdk.org  Wed Sep  7 09:41:56 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Wed, 7 Sep 2022 09:41:56 GMT
Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer
In-Reply-To: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
References: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
Message-ID: <-lTrZCCdVIsgaxcmQmEz1jwQVM88Ca_YsFi_Dy0HObA=.f4ad4367-aa1a-485c-b6b0-d548c527fc69@github.com>

On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions.
> For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function:
>   li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow)
> 
> But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function:
>   mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans))
> 
> Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer.
> 
> Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board.

lgtm

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

Marked as reviewed by yadongwang (Author).

PR: https://git.openjdk.org/jdk/pull/10194

From fjiang at openjdk.org  Wed Sep  7 11:01:40 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 7 Sep 2022 11:01:40 GMT
Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer
In-Reply-To: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
References: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
Message-ID: <vQXpKkJB3gAYyfRb9RcyzIqkb8vyoGMzrnCaHpf4rSQ=.e6b3ba22-7c3f-436a-aba4-9be89f62a209@github.com>

On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions.
> For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function:
>   li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow)
> 
> But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function:
>   mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans))
> 
> Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer.
> 
> Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board.

Looks Good. (Not a JDK reviewer)

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

Marked as reviewed by fjiang (Author).

PR: https://git.openjdk.org/jdk/pull/10194

From shade at openjdk.org  Wed Sep  7 13:11:40 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Sep 2022 13:11:40 GMT
Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer
In-Reply-To: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
References: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
Message-ID: <9hZhFVshKxsAt5NIeyQREh5nOv2miazYEUt-EYi1UeQ=.3c445083-124a-4749-86b7-26bb55c27ccd@github.com>

On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions.
> For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function:
>   li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow)
> 
> But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function:
>   mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans))
> 
> Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer.
> 
> Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board.

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10194

From duke at openjdk.org  Wed Sep  7 15:32:46 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 Sep 2022 15:32:46 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 [v2]
In-Reply-To: <9ah9SD1YhJdPEqRlH4n9k1NqWha3eTTuNaiQhywVP_Q=.9ab53e2a-4c10-4e2b-be4e-cf1483c2f12d@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <9ah9SD1YhJdPEqRlH4n9k1NqWha3eTTuNaiQhywVP_Q=.9ab53e2a-4c10-4e2b-be4e-cf1483c2f12d@github.com>
Message-ID: <0FNcAv6JKl-l2gzKYkB2F8Zs_r68rUK6k_FBJS_eKWk=.65ccbb69-d9a2-48d5-9b30-d4e7587e4fda@github.com>

On Fri, 26 Aug 2022 20:22:57 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
>> 
>> When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at:
>> 
>> 
>>    1 #
>>    2 # A fatal error has been detected by the Java Runtime Environment:
>>    3 #
>>    4 #  Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156
>>    5 #  Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents
>>    6 
>>    7 Referenced from:
>>    8   interior location: 0x00007f0a40000090
>>    9   0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>>   10         allocated after mark start
>>   11     not after update watermark
>>   12         marked strong
>>   13         marked weak
>>   14     not in collection set
>>   15   mark: mark(is_neutral no_hash age=0)
>>   16   region: |    0|R  |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U  2046K|T  2046K|G     0B|S     0B|L  2046K|CP   0
>>   17 
>>   18 Object:
>>   19   0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>>   20     not allocated after mark start
>>   21     not after update watermark
>>   22     not marked strong
>>   23     not marked weak
>>   24         in collection set
>>   25   mark: mark(is_neutral no_hash age=0)
>>   26   region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U  2048K|T     0B|G  2048K|S     0B|L  1612K|CP   0
>>   27 
>>   28 Forwardee:
>>   29   (the object itself)
>> 
>> 
>> The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`.
>> The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does:
>> 
>> 
>> 	continuationWrapper::_tail = stackChunk1
>> 	stackChunk2 = allocate new StackChunk
>> 	stackChunk2::parent = continuationWrapper::_tail
>> 	continuationWrapper::_tail = stackChunk2
>> 
>> 
>> At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification.
>> 
>> This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224)
>> 
>> There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems:
>> 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2]
>> 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header
>> 
>> To fix these two issues, we need the following changes:
>> 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494).
>> 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header.
>> 
>> [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201
>> [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable loom for ShenandoahGC IU mode
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Closing it in favor of #10089

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

PR: https://git.openjdk.org/jdk/pull/9982

From duke at openjdk.org  Wed Sep  7 15:32:48 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 Sep 2022 15:32:48 GMT
Subject: Withdrawn: 8288129: Shenandoah: Skynet test crashed with iu +
 aggressive
In-Reply-To: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
Message-ID: <WGMEUUwa2tbpy-HNhGfa2ejhWg-r7fYEbIui9juuGik=.782e6c05-e8f3-48e3-a022-63414c6adc4e@github.com>

On Tue, 23 Aug 2022 15:05:48 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at:
> 
> 
>    1 #
>    2 # A fatal error has been detected by the Java Runtime Environment:
>    3 #
>    4 #  Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156
>    5 #  Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents
>    6 
>    7 Referenced from:
>    8   interior location: 0x00007f0a40000090
>    9   0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>   10         allocated after mark start
>   11     not after update watermark
>   12         marked strong
>   13         marked weak
>   14     not in collection set
>   15   mark: mark(is_neutral no_hash age=0)
>   16   region: |    0|R  |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U  2046K|T  2046K|G     0B|S     0B|L  2046K|CP   0
>   17 
>   18 Object:
>   19   0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>   20     not allocated after mark start
>   21     not after update watermark
>   22     not marked strong
>   23     not marked weak
>   24         in collection set
>   25   mark: mark(is_neutral no_hash age=0)
>   26   region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U  2048K|T     0B|G  2048K|S     0B|L  1612K|CP   0
>   27 
>   28 Forwardee:
>   29   (the object itself)
> 
> 
> The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`.
> The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does:
> 
> 
> 	continuationWrapper::_tail = stackChunk1
> 	stackChunk2 = allocate new StackChunk
> 	stackChunk2::parent = continuationWrapper::_tail
> 	continuationWrapper::_tail = stackChunk2
> 
> 
> At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification.
> 
> This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224)
> 
> There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems:
> 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2]
> 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header
> 
> To fix these two issues, we need the following changes:
> 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494).
> 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header.
> 
> [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201
> [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9982

From duke at openjdk.org  Wed Sep  7 18:07:49 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 7 Sep 2022 18:07:49 GMT
Subject: RFR: 8293492: ShenandoahControlThread missing from hs-err log and
 thread dump
Message-ID: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Commit messages:
 - 8293492: ShenandoahControlThread missing from hs-err log and thread dump

Changes: https://git.openjdk.org/jdk/pull/10205/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10205&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293492
  Stats: 18 lines in 3 files changed: 1 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10205.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10205/head:pull/10205

PR: https://git.openjdk.org/jdk/pull/10205

From zgu at openjdk.org  Thu Sep  8 01:07:39 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 8 Sep 2022 01:07:39 GMT
Subject: RFR: 8293492: ShenandoahControlThread missing from hs-err log and
 thread dump
In-Reply-To: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
References: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
Message-ID: <wmw-EQUsuT84dn_bfuKn_Hsj_l9SW09PM6N5txtiNps=.b6a69254-bbd1-4ec8-8f50-db0803f17ab8@github.com>

On Wed, 7 Sep 2022 17:59:53 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this patch to add ShenandoahControlThread to the thread list in hs_err log file and thread dump.
> 
> With this change, the hs_err log file contains the entry for `ShenandoahControlThread` in "Other Threads" section:
> 
> 
> Other Threads:
> =>0x00007f84d41c5d50 VMThread "VM Thread" [stack: 0x00007f84d8e8e000,0x00007f84d8f8e000] [id=278151]
>   0x00007f84d42d5e00 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f84d8280000,0x00007f84d8380000] [id=278163]
>   0x00007f84d4107d80 ConcurrentGCThread "Shenandoah Control Thread" [stack: 0x00007f84d933a000,0x00007f84d943a000] [id=278150]
>   0x00007f84d40b4dc0 WorkerThread "Shenandoah GC Threads#0" [stack: 0x00007f84d97bc000,0x00007f84d98bc000] [id=278145]
>   ...
> 
> and Thread.print command (using jcmd) also has the entry for the thread:
> 
> 
> "VM Thread" os_prio=0 cpu=0.46ms elapsed=6.85s tid=0x00007fe6dc1ca750 nid=265830 runnable  
> 
> "Shenandoah Control Thread" os_prio=0 cpu=13.34ms elapsed=6.87s tid=0x00007fe6dc10c780 nid=265829 runnable**  
> 
> "Shenandoah GC Threads#0" os_prio=0 cpu=0.12ms elapsed=6.91s tid=0x00007fe6dc0b3730 nid=265827 runnable  
> 
> 
> 
> I also cleaned up the code a bit to be consistent naming this thread.
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10205

From fyang at openjdk.org  Thu Sep  8 01:15:57 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 8 Sep 2022 01:15:57 GMT
Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer
In-Reply-To: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
References: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
Message-ID: <ZQZT9gEfI-ZLGbre2wZZXQWyM3CiUm5dgN5VbUA2yCs=.f01254cc-c5bc-45ff-b1a8-601d747f3bf8@github.com>

On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions.
> For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function:
>   li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow)
> 
> While in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function:
>   mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans))
> 
> Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer.
> 
> Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board.

Thanks all for the review. Integrate then.

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

PR: https://git.openjdk.org/jdk/pull/10194

From fyang at openjdk.org  Thu Sep  8 01:17:48 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 8 Sep 2022 01:17:48 GMT
Subject: Integrated: 8293474: RISC-V: Unify the way of moving function pointer
In-Reply-To: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
References: <YnUQVIua4SKu25jmV3xCGpWCxqGEP5-VBBOveCDHNdg=.cd772a23-1e1d-4bc7-bed7-7de815fb5d71@github.com>
Message-ID: <Ng0T1RLU1_BHsvV7zKcg3ugrOmPpTxCBndVyv1do7Dk=.76b4966e-df10-4971-911f-a69d536344e8@github.com>

On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions.
> For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function:
>   li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow)
> 
> While in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function:
>   mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans))
> 
> Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer.
> 
> Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board.

This pull request has now been integrated.

Changeset: fc5f97fe
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fc5f97fe379825cb927666ae26aef00082cfae56
Stats:     31 lines in 3 files changed: 2 ins; 10 del; 19 mod

8293474: RISC-V: Unify the way of moving function pointer

Reviewed-by: yadongwang, fjiang, shade

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

PR: https://git.openjdk.org/jdk/pull/10194

From fyang at openjdk.org  Thu Sep  8 03:30:12 2022
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 8 Sep 2022 03:30:12 GMT
Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate
Message-ID: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>

Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant.

Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board.

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

Commit messages:
 - 8293524: RISC-V: Use macro-assembler functions as appropriate

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

PR: https://git.openjdk.org/jdk/pull/10210

From shade at openjdk.org  Thu Sep  8 06:18:43 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Sep 2022 06:18:43 GMT
Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate
In-Reply-To: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
References: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
Message-ID: <2yxPwlehWfNYflxKSv56dY9JAUZQFUTXIUGIW4tqZNk=.d41a9b56-3862-42b2-bcc1-75c4cd077484@github.com>

On Thu, 8 Sep 2022 03:20:41 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant.
> 
> Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board.

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10210

From shade at openjdk.org  Thu Sep  8 06:33:00 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Sep 2022 06:33:00 GMT
Subject: RFR: 8293492: ShenandoahControlThread missing from hs-err log and
 thread dump
In-Reply-To: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
References: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
Message-ID: <89T0tI6WMCnGTu02KIjKWRPIUqXXLsVh_c9snObzABI=.ee7564ce-5010-49c9-bc66-92727e009b99@github.com>

On Wed, 7 Sep 2022 17:59:53 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this patch to add ShenandoahControlThread to the thread list in hs_err log file and thread dump.
> 
> With this change, the hs_err log file contains the entry for `ShenandoahControlThread` in "Other Threads" section:
> 
> 
> Other Threads:
> =>0x00007f84d41c5d50 VMThread "VM Thread" [stack: 0x00007f84d8e8e000,0x00007f84d8f8e000] [id=278151]
>   0x00007f84d42d5e00 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f84d8280000,0x00007f84d8380000] [id=278163]
>   0x00007f84d4107d80 ConcurrentGCThread "Shenandoah Control Thread" [stack: 0x00007f84d933a000,0x00007f84d943a000] [id=278150]
>   0x00007f84d40b4dc0 WorkerThread "Shenandoah GC Threads#0" [stack: 0x00007f84d97bc000,0x00007f84d98bc000] [id=278145]
>   ...
> 
> and Thread.print command (using jcmd) also has the entry for the thread:
> 
> 
> "VM Thread" os_prio=0 cpu=0.46ms elapsed=6.85s tid=0x00007fe6dc1ca750 nid=265830 runnable  
> 
> "Shenandoah Control Thread" os_prio=0 cpu=13.34ms elapsed=6.87s tid=0x00007fe6dc10c780 nid=265829 runnable**  
> 
> "Shenandoah GC Threads#0" os_prio=0 cpu=0.12ms elapsed=6.91s tid=0x00007fe6dc0b3730 nid=265827 runnable  
> 
> 
> 
> I also cleaned up the code a bit to be consistent naming this thread.
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Looks fine, thanks!

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10205

From fjiang at openjdk.org  Thu Sep  8 08:32:58 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Thu, 8 Sep 2022 08:32:58 GMT
Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate
In-Reply-To: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
References: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
Message-ID: <-nTSe9WMC2M2GneKjFB9H66TI5vpj45XeLvMfK38EQE=.95b1bb6a-0654-49fe-9c5a-cd8bfce7465e@github.com>

On Thu, 8 Sep 2022 03:20:41 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant.
> 
> Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board.

Nice clean up, thanks! (Not a JDK reviewer)

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

Marked as reviewed by fjiang (Author).

PR: https://git.openjdk.org/jdk/pull/10210

From aboldtch at openjdk.org  Thu Sep  8 09:02:51 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 8 Sep 2022 09:02:51 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v5]
In-Reply-To: <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>
Message-ID: <m3OqFfQQCosg7_b-2nIQClw0HZzz5Ne5KVdD1FhIbnM=.1e9bbdbb-31f5-4d33-a4db-a9d63717ac2f@github.com>

On Tue, 6 Sep 2022 12:06:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Push r10 using push and pop
>  - Fix Argument Comments

@shqking @stooart-mon Your feedback have been addressed with code changes. Is there anything more you would like to add?
@tschatzl @theRealAph @RealFYang The only change since your approval has been to change comments and argument names, as well as changed from `stp/ldp` to `push/pop` with `RegSet` for correctness.

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

PR: https://git.openjdk.org/jdk/pull/10161

From aph at openjdk.org  Thu Sep  8 09:22:46 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 Sep 2022 09:22:46 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v5]
In-Reply-To: <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>
Message-ID: <CknSmJnbv4T6roUJ-SF3WS5C9t8xq-gLRJ0_TRpwJV0=.30bcbb03-4966-4859-bc43-da48b3c12bd1@github.com>

On Tue, 6 Sep 2022 12:06:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Push r10 using push and pop
>  - Fix Argument Comments

Marked as reviewed by aph (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10161

From duke at openjdk.org  Thu Sep  8 14:06:33 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 8 Sep 2022 14:06:33 GMT
Subject: Integrated: 8293492: ShenandoahControlThread missing from hs-err log
 and thread dump
In-Reply-To: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
References: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
Message-ID: <wo3aBB-7WgUiAzyNG7S_nUWY6M3zjPZBo7sDwIRYUk8=.cc79a1ba-bf55-455e-a481-005447c82eba@github.com>

On Wed, 7 Sep 2022 17:59:53 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this patch to add ShenandoahControlThread to the thread list in hs_err log file and thread dump.
> 
> With this change, the hs_err log file contains the entry for `ShenandoahControlThread` in "Other Threads" section:
> 
> 
> Other Threads:
> =>0x00007f84d41c5d50 VMThread "VM Thread" [stack: 0x00007f84d8e8e000,0x00007f84d8f8e000] [id=278151]
>   0x00007f84d42d5e00 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f84d8280000,0x00007f84d8380000] [id=278163]
>   0x00007f84d4107d80 ConcurrentGCThread "Shenandoah Control Thread" [stack: 0x00007f84d933a000,0x00007f84d943a000] [id=278150]
>   0x00007f84d40b4dc0 WorkerThread "Shenandoah GC Threads#0" [stack: 0x00007f84d97bc000,0x00007f84d98bc000] [id=278145]
>   ...
> 
> and Thread.print command (using jcmd) also has the entry for the thread:
> 
> 
> "VM Thread" os_prio=0 cpu=0.46ms elapsed=6.85s tid=0x00007fe6dc1ca750 nid=265830 runnable  
> 
> "Shenandoah Control Thread" os_prio=0 cpu=13.34ms elapsed=6.87s tid=0x00007fe6dc10c780 nid=265829 runnable
> 
> "Shenandoah GC Threads#0" os_prio=0 cpu=0.12ms elapsed=6.91s tid=0x00007fe6dc0b3730 nid=265827 runnable  
> 
> 
> 
> I also cleaned up the code a bit to be consistent naming this thread.
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

This pull request has now been integrated.

Changeset: 85ec1f8d
Author:    Ashutosh Mehra <asmehra at redhat.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85ec1f8d020cf2a9d7dfcc9ed75e43f0cd61c1f2
Stats:     18 lines in 3 files changed: 1 ins; 16 del; 1 mod

8293492: ShenandoahControlThread missing from hs-err log and thread dump

Reviewed-by: zgu, shade

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

PR: https://git.openjdk.org/jdk/pull/10205

From duke at openjdk.org  Thu Sep  8 14:12:44 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 8 Sep 2022 14:12:44 GMT
Subject: RFR: 8293492: ShenandoahControlThread missing from hs-err log and
 thread dump
In-Reply-To: <89T0tI6WMCnGTu02KIjKWRPIUqXXLsVh_c9snObzABI=.ee7564ce-5010-49c9-bc66-92727e009b99@github.com>
References: <OHa5MIWyRiqfcnEI6CdjKof_IAeMWP4al-qZ_tWDM1w=.f70c0f7e-c067-403a-8fff-86212b0aaa15@github.com>
 <89T0tI6WMCnGTu02KIjKWRPIUqXXLsVh_c9snObzABI=.ee7564ce-5010-49c9-bc66-92727e009b99@github.com>
Message-ID: <ViKx_Iim7iK0fIojNEoTrPRcZdVHC5ePhy1fL0uVEQE=.8ccd6b66-817d-4ca6-88a9-4053f169ba2a@github.com>

On Thu, 8 Sep 2022 06:30:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please review this patch to add ShenandoahControlThread to the thread list in hs_err log file and thread dump.
>> 
>> With this change, the hs_err log file contains the entry for `ShenandoahControlThread` in "Other Threads" section:
>> 
>> 
>> Other Threads:
>> =>0x00007f84d41c5d50 VMThread "VM Thread" [stack: 0x00007f84d8e8e000,0x00007f84d8f8e000] [id=278151]
>>   0x00007f84d42d5e00 WatcherThread "VM Periodic Task Thread" [stack: 0x00007f84d8280000,0x00007f84d8380000] [id=278163]
>>   0x00007f84d4107d80 ConcurrentGCThread "Shenandoah Control Thread" [stack: 0x00007f84d933a000,0x00007f84d943a000] [id=278150]
>>   0x00007f84d40b4dc0 WorkerThread "Shenandoah GC Threads#0" [stack: 0x00007f84d97bc000,0x00007f84d98bc000] [id=278145]
>>   ...
>> 
>> and Thread.print command (using jcmd) also has the entry for the thread:
>> 
>> 
>> "VM Thread" os_prio=0 cpu=0.46ms elapsed=6.85s tid=0x00007fe6dc1ca750 nid=265830 runnable  
>> 
>> "Shenandoah Control Thread" os_prio=0 cpu=13.34ms elapsed=6.87s tid=0x00007fe6dc10c780 nid=265829 runnable
>> 
>> "Shenandoah GC Threads#0" os_prio=0 cpu=0.12ms elapsed=6.91s tid=0x00007fe6dc0b3730 nid=265827 runnable  
>> 
>> 
>> 
>> I also cleaned up the code a bit to be consistent naming this thread.
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Looks fine, thanks!

@shipilev @zhengyu123 thanks for reviewing the changes and sponsoring it.

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

PR: https://git.openjdk.org/jdk/pull/10205

From fyang at openjdk.org  Fri Sep  9 00:19:48 2022
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 9 Sep 2022 00:19:48 GMT
Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate
In-Reply-To: <2yxPwlehWfNYflxKSv56dY9JAUZQFUTXIUGIW4tqZNk=.d41a9b56-3862-42b2-bcc1-75c4cd077484@github.com>
References: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
 <2yxPwlehWfNYflxKSv56dY9JAUZQFUTXIUGIW4tqZNk=.d41a9b56-3862-42b2-bcc1-75c4cd077484@github.com>
Message-ID: <y34_6KW_K72lBjBLmop94DvrgCah-OIfVBkNM5dTjUk=.ab4f561f-ba1c-4365-b864-3dff2f4b3ecd@github.com>

On Thu, 8 Sep 2022 06:16:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant.
>> 
>> Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board.
>
> Marked as reviewed by shade (Reviewer).

@shipilev @feilongjiang : Thanks for reviewing this.

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

PR: https://git.openjdk.org/jdk/pull/10210

From fyang at openjdk.org  Fri Sep  9 00:22:46 2022
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 9 Sep 2022 00:22:46 GMT
Subject: Integrated: 8293524: RISC-V: Use macro-assembler functions as
 appropriate
In-Reply-To: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
References: <TJk7PQ7rMP567f_rpk-nsn_EByScEOWiU4Wecn3aKjk=.bb93259d-25ae-41bb-8473-2de0731283ba@github.com>
Message-ID: <tQ6D_vtBeQDjuYwIFfbq8BppsG_DVi9UzmrOr-bAVY4=.e51ef4dc-11b4-481b-83e1-ffcc25aae661@github.com>

On Thu, 8 Sep 2022 03:20:41 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant.
> 
> Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board.

This pull request has now been integrated.

Changeset: 43e191d6
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43e191d64b0094cc1ece61929c32e017ee90c0c8
Stats:     78 lines in 13 files changed: 0 ins; 0 del; 78 mod

8293524: RISC-V: Use macro-assembler functions as appropriate

Reviewed-by: shade, fjiang

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

PR: https://git.openjdk.org/jdk/pull/10210

From duke at openjdk.org  Mon Sep 12 08:49:18 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 12 Sep 2022 08:49:18 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v3]
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <XfCefHcQtZfDCcFU2bGx5x328UzTBaLo6OvpQBEOMg0=.028fb816-7cd9-44dc-b490-8d7e94f84934@github.com>

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Track invariant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10142/files
  - new: https://git.openjdk.org/jdk/pull/10142/files/24dd048c..0532bedf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Mon Sep 12 10:05:52 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 12 Sep 2022 10:05:52 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v4]
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <IqSTk5Lrp8yMpFUi3hW6dA47MidcCfNAjNN0ITNfleI=.5449ee13-3fe7-44e4-a36a-4f264291b96f@github.com>

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Remove invariant tracking
  
  Too much depends on this invariant not being met.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10142/files
  - new: https://git.openjdk.org/jdk/pull/10142/files/0532bedf..700f91b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Mon Sep 12 11:14:41 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 12 Sep 2022 11:14:41 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v4]
In-Reply-To: <IqSTk5Lrp8yMpFUi3hW6dA47MidcCfNAjNN0ITNfleI=.5449ee13-3fe7-44e4-a36a-4f264291b96f@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <IqSTk5Lrp8yMpFUi3hW6dA47MidcCfNAjNN0ITNfleI=.5449ee13-3fe7-44e4-a36a-4f264291b96f@github.com>
Message-ID: <u-3EXUKoE840MsT05EbQvj4eYGnBxJs0bcOE245z8LI=.ee66c4c0-3667-49f5-a91c-4c7355fe983e@github.com>

On Mon, 12 Sep 2022 10:05:52 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove invariant tracking
>   
>   Too much depends on this invariant not being met.

I wanted to add an invariant that the stringStream is not used after ``::base()` is called, but that invariant is broken in production (in a safe manner), so it can't be added.

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

PR: https://git.openjdk.org/jdk/pull/10142

From fyang at openjdk.org  Mon Sep 12 13:40:48 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 12 Sep 2022 13:40:48 GMT
Subject: RFR: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at [v5]
In-Reply-To: <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
 <LOWKOtSd2IjCGcOezaD7d4uDIlEFvBlZ54sWwjQIds0=.5434cdaa-4798-4b27-8b12-6fd2e07c1b14@github.com>
Message-ID: <QZuMN6At4uszBYJeQZimChykkRP2FR3f8US3RD80TCk=.dcd69020-35c5-4c07-ad5e-d62f2be52746@github.com>

On Tue, 6 Sep 2022 12:06:38 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
>> 
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Oracle platforms tier 1-3
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Push r10 using push and pop
>  - Fix Argument Comments

Marked as reviewed by fyang (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10161

From aboldtch at openjdk.org  Tue Sep 13 11:25:33 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Sep 2022 11:25:33 GMT
Subject: Integrated: 8293351: Add second tmp register to aarch64
 BarrierSetAssembler::load_at
In-Reply-To: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
References: <wZbr4xpFgDAcrbPYnV1hbSeoOXDoTuefmWCGOVUjBzE=.da81f20e-e6dd-441f-b783-e0af0ac6a203@github.com>
Message-ID: <hYQ65d_JNl5kmY9fm7PtD8FCRs8nQK7rQdGiiBEmOQ8=.f38947ac-404b-4295-bd62-33812fea85b3@github.com>

On Mon, 5 Sep 2022 10:09:09 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64.
> 
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Oracle platforms tier 1-3

This pull request has now been integrated.

Changeset: 725f41ff
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Committer: Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/725f41ffd4b137aef3f83700b4e181e9d93368d4
Stats:     104 lines in 14 files changed: 7 ins; 2 del; 95 mod

8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at

Reviewed-by: aph, tschatzl, fyang

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

PR: https://git.openjdk.org/jdk/pull/10161

From fyang at openjdk.org  Wed Sep 14 03:17:23 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 14 Sep 2022 03:17:23 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
Message-ID: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>

This is similar to https://bugs.openjdk.org/browse/JDK-8293351
Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.

Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.

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

Commit messages:
 - 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at

Changes: https://git.openjdk.org/jdk/pull/10261/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293769
  Stats: 327 lines in 13 files changed: 9 ins; 108 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/10261.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10261/head:pull/10261

PR: https://git.openjdk.org/jdk/pull/10261

From fjiang at openjdk.org  Wed Sep 14 03:42:42 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 14 Sep 2022 03:42:42 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
Message-ID: <YwWCSq_AYX7L1OIzPwagI3ZraTgmElIyKVnIV4brzRs=.deb28600-081f-4986-8f1a-9e2a38386220@github.com>

On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This is similar to https://bugs.openjdk.org/browse/JDK-8293351
> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.

Looks good to me. Thanks for the cleanup.

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

Marked as reviewed by fjiang (Author).

PR: https://git.openjdk.org/jdk/pull/10261

From shade at openjdk.org  Wed Sep 14 06:43:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Sep 2022 06:43:35 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
Message-ID: <Hys4MjpH3KkMZeGPaCCwbiH2iQ_PPZwFqKw14pJSGk0=.2020c218-9338-4150-88c4-9f27085027b3@github.com>

On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This is similar to https://bugs.openjdk.org/browse/JDK-8293351
> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.

Looks fine, but I have a question.

src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 318:

> 316:     __ push_call_clobbered_registers();
> 317: 
> 318:     satb_write_barrier_pre(masm, noreg, dst, xthread, tmp, t0, true, false);

Is `tmp` not `t0` here? I expected to see `t1` in this diff. Maybe I am missing something.

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

PR: https://git.openjdk.org/jdk/pull/10261

From duke at openjdk.org  Wed Sep 14 07:11:27 2022
From: duke at openjdk.org (Tongbao Zhang)
Date: Wed, 14 Sep 2022 07:11:27 GMT
Subject: RFR: 8293782: Shenandoah: some tests failed on lock rank check
Message-ID: <IsHbyB070WglVTjvGBDcMfQlwarxV7YDrMZUOzFMNvg=.de4b78a1-a06d-42fe-9a1a-29de58688718@github.com>

After [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025), some tests using ShenandoahGC failed on the lock rank check between AdapterHandlerLibrary_lock and ShenandoahRequestedGC_lock

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

Commit messages:
 - 8293782: Shenandoah: some tests failed on lock rank check

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

PR: https://git.openjdk.org/jdk/pull/10264

From duke at openjdk.org  Wed Sep 14 07:32:34 2022
From: duke at openjdk.org (duke)
Date: Wed, 14 Sep 2022 07:32:34 GMT
Subject: Withdrawn: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <rEYlxR65gLk4O94gm1c7MBHnHOsWc_VN4yoGAtChL3c=.55253532-4be4-4445-94ae-c617171c89fa@github.com>

On Tue, 7 Jun 2022 23:36:23 GMT, Cesar Soares <duke at openjdk.org> wrote:

> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
> 
> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
> 
> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
> 
> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
> 
> Thanks in advance,
> Cesar

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9074

From fyang at openjdk.org  Wed Sep 14 08:11:32 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 14 Sep 2022 08:11:32 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <Hys4MjpH3KkMZeGPaCCwbiH2iQ_PPZwFqKw14pJSGk0=.2020c218-9338-4150-88c4-9f27085027b3@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
 <Hys4MjpH3KkMZeGPaCCwbiH2iQ_PPZwFqKw14pJSGk0=.2020c218-9338-4150-88c4-9f27085027b3@github.com>
Message-ID: <JdJBVlO9G7EBUYPuEsFUNSuTrCPdQ9UClRKAK99_1PI=.bf863af7-3837-4ddc-b873-94f06846d036@github.com>

On Wed, 14 Sep 2022 06:41:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is similar to https://bugs.openjdk.org/browse/JDK-8293351
>> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.
>
> src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 318:
> 
>> 316:     __ push_call_clobbered_registers();
>> 317: 
>> 318:     satb_write_barrier_pre(masm, noreg, dst, xthread, tmp, t0, true, false);
> 
> Is `tmp` not `t0` here? I expected to see `t1` in this diff. Maybe I am missing something.

I don't think 'tmp' is 't0' here since we are asserting they are different registers in ShenandoahBarrierSetAssembler::satb_write_barrier_pre [1]. And I also run non-trivial benchmark work loads like Dacapo, Specjvm and Specjbb using ShenandoahGC with fastdebug build for these changes. 

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L111

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

PR: https://git.openjdk.org/jdk/pull/10261

From fyang at openjdk.org  Wed Sep 14 09:04:28 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 14 Sep 2022 09:04:28 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <JdJBVlO9G7EBUYPuEsFUNSuTrCPdQ9UClRKAK99_1PI=.bf863af7-3837-4ddc-b873-94f06846d036@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
 <Hys4MjpH3KkMZeGPaCCwbiH2iQ_PPZwFqKw14pJSGk0=.2020c218-9338-4150-88c4-9f27085027b3@github.com>
 <JdJBVlO9G7EBUYPuEsFUNSuTrCPdQ9UClRKAK99_1PI=.bf863af7-3837-4ddc-b873-94f06846d036@github.com>
Message-ID: <UMK66ic8lTFMotc8IcJSke6Cubknaffqcm0FR-6_Be0=.3b89da18-d325-4d9b-839a-7637b97aad87@github.com>

On Wed, 14 Sep 2022 08:03:12 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 318:
>> 
>>> 316:     __ push_call_clobbered_registers();
>>> 317: 
>>> 318:     satb_write_barrier_pre(masm, noreg, dst, xthread, tmp, t0, true, false);
>> 
>> Is `tmp` not `t0` here? I expected to see `t1` in this diff. Maybe I am missing something.
>
> I don't think 'tmp' is 't0' here since we are asserting they are different registers in ShenandoahBarrierSetAssembler::satb_write_barrier_pre [1]. And I also run non-trivial benchmark work loads like Dacapo, Specjvm and Specjbb using ShenandoahGC with fastdebug build for these changes. 
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L111

PS: Also eyeballed all possible callers of ShenandoahBarrierSetAssembler::satb_write_barrier_pre and I think we are safe here :-)

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

PR: https://git.openjdk.org/jdk/pull/10261

From shade at openjdk.org  Wed Sep 14 09:28:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Sep 2022 09:28:35 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
Message-ID: <JWXq0PL7KMV7Ipko-jdBkdKqSPvAMk7PNLybBP33ABg=.93dce6bc-994b-4f34-baf0-5fac284df3ae@github.com>

On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This is similar to https://bugs.openjdk.org/browse/JDK-8293351
> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10261

From shade at openjdk.org  Wed Sep 14 09:28:38 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Sep 2022 09:28:38 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <UMK66ic8lTFMotc8IcJSke6Cubknaffqcm0FR-6_Be0=.3b89da18-d325-4d9b-839a-7637b97aad87@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
 <Hys4MjpH3KkMZeGPaCCwbiH2iQ_PPZwFqKw14pJSGk0=.2020c218-9338-4150-88c4-9f27085027b3@github.com>
 <JdJBVlO9G7EBUYPuEsFUNSuTrCPdQ9UClRKAK99_1PI=.bf863af7-3837-4ddc-b873-94f06846d036@github.com>
 <UMK66ic8lTFMotc8IcJSke6Cubknaffqcm0FR-6_Be0=.3b89da18-d325-4d9b-839a-7637b97aad87@github.com>
Message-ID: <2q-VKmsT6PcBevvtunpKXHP0ejDr-yzBVsFmn_0gYg4=.6e06020d-2a15-4ca1-90bc-0b159446a8ad@github.com>

On Wed, 14 Sep 2022 09:01:12 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I don't think 'tmp' is 't0' here since we are asserting they are different registers in ShenandoahBarrierSetAssembler::satb_write_barrier_pre [1]. And I also run non-trivial benchmark work loads like Dacapo, Specjvm and Specjbb using ShenandoahGC with fastdebug build for these changes. 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L111
>
> PS: Also eyeballed all possible callers of ShenandoahBarrierSetAssembler::satb_write_barrier_pre and I think we are safe here :-)

Okay then!

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

PR: https://git.openjdk.org/jdk/pull/10261

From duke at openjdk.org  Wed Sep 14 12:01:42 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 14 Sep 2022 12:01:42 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v5]
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <GRGRt85YsYKXPlyN5VDftLRWKgel9gitBhyxxAFZ5mo=.40377cdd-001b-4c66-9a7c-268b3ae0910d@github.com>

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:

 - Change base to internal_string
 - Add invariant tracking in new method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10142/files
  - new: https://git.openjdk.org/jdk/pull/10142/files/700f91b4..4685ff32

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=03-04

  Stats: 62 lines in 27 files changed: 8 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/10142.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Wed Sep 14 12:01:44 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 14 Sep 2022 12:01:44 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v4]
In-Reply-To: <IqSTk5Lrp8yMpFUi3hW6dA47MidcCfNAjNN0ITNfleI=.5449ee13-3fe7-44e4-a36a-4f264291b96f@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <IqSTk5Lrp8yMpFUi3hW6dA47MidcCfNAjNN0ITNfleI=.5449ee13-3fe7-44e4-a36a-4f264291b96f@github.com>
Message-ID: <DSh4sdZY_7Jusu2ryUC1Gta81l9xmJo5i-M5_0cblVc=.d16e45db-be5f-4c04-9c82-75fb2ede21aa@github.com>

On Mon, 12 Sep 2022 10:05:52 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove invariant tracking
>   
>   Too much depends on this invariant not being met.

Having a 2nd go at invariant tracking by introducing a new function `internal_string`.

I imagine that a future RFE would rename `base` to `raw_string` and that `as_string` is split into `heap_string` and `resource_string`. This would make the interface clearer, imho.

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Wed Sep 14 12:03:52 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 14 Sep 2022 12:03:52 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v6]
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <eF1tI6dH4eEg0UCW_1EwY9ZxYaykni0YH6QiBD5dWN8=.3296c3db-18db-43ab-9aa8-17c0b01d27ab@github.com>

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Missed fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10142/files
  - new: https://git.openjdk.org/jdk/pull/10142/files/4685ff32..f7e2a8a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/10142

From stuefe at openjdk.org  Wed Sep 14 12:57:37 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 14 Sep 2022 12:57:37 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v6]
In-Reply-To: <eF1tI6dH4eEg0UCW_1EwY9ZxYaykni0YH6QiBD5dWN8=.3296c3db-18db-43ab-9aa8-17c0b01d27ab@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <eF1tI6dH4eEg0UCW_1EwY9ZxYaykni0YH6QiBD5dWN8=.3296c3db-18db-43ab-9aa8-17c0b01d27ab@github.com>
Message-ID: <7GN_5qAEZr9HjWItusy4UGLENSTyGRDADf7pVFdES84=.0567293e-927d-4281-ac99-500b767c9c3b@github.com>

On Wed, 14 Sep 2022 12:03:52 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed fixes

Hi Johan,

please be aware that changes like these across the code base makes downporting more painful. So I would only do wholesale renames and replacements where the benefit clearly outweighs the downporting costs.

About your last iteration, yes, I think requiring base() to freeze the stream is a bit much.

How about renaming "internal_string" to "freeze"


// Freezes stringStream (no further modifications possible) and returns pointer to it.
// No-op if stream is frozen already.
const char* freeze();


"freeze" is snappy and clear in its meaning. And in release builds I also would freeze, allowing no further changes, apart from the debug-only assert. Since writes potentially reallocate the buffer, the char ptr may be invalid, better to have incomplete stringStream output than C-heap corruption (as improbable as it is).

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Wed Sep 14 13:32:46 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 14 Sep 2022 13:32:46 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v7]
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <jq5Ttm5h1nRhDypmOUmENNQKadgOAd3n9ar8wA7XxJU=.48501393-6107-4bdf-afe4-a1ebfdc9a24f@github.com>

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Rename to freeze

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10142/files
  - new: https://git.openjdk.org/jdk/pull/10142/files/f7e2a8a7..673bad51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=05-06

  Stats: 61 lines in 27 files changed: 1 ins; 0 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/10142.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Wed Sep 14 13:32:49 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 14 Sep 2022 13:32:49 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v6]
In-Reply-To: <eF1tI6dH4eEg0UCW_1EwY9ZxYaykni0YH6QiBD5dWN8=.3296c3db-18db-43ab-9aa8-17c0b01d27ab@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <eF1tI6dH4eEg0UCW_1EwY9ZxYaykni0YH6QiBD5dWN8=.3296c3db-18db-43ab-9aa8-17c0b01d27ab@github.com>
Message-ID: <MWgD6oL6WI6mUF_sGrnmx96pFXSaB-a03NWhWsMM9Jc=.27396354-8baf-4b8a-8c3d-ca5252ef33ec@github.com>

On Wed, 14 Sep 2022 12:03:52 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed fixes

Hi Thomas,

Thank you for your input. I agree, freeze is snappy. I applied your suggestion.

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Wed Sep 14 16:17:16 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 14 Sep 2022 16:17:16 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash with
 IU+aggressive mode
Message-ID: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>

Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.

Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.

At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.

The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`

	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());

But it looks like it is missing another important condition - the GC should be in marking phase.
i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
So the correct assertion should be:

	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());

In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:

	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());


Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.

Tested it by running following tests in fastdebug mode:

- hotspot_gc_shenandoah
- java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
- java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Commit messages:
 - 8293252: Shenandoah: ThreadMXBean synchronizer tests crash with IU+aggressive mode

Changes: https://git.openjdk.org/jdk/pull/10268/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293252
  Stats: 12 lines in 2 files changed: 8 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10268/head:pull/10268

PR: https://git.openjdk.org/jdk/pull/10268

From heidinga at openjdk.org  Wed Sep 14 18:59:39 2022
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 14 Sep 2022 18:59:39 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
Message-ID: <WlaLBOo9Q9fViWQQm9LJDoT0mvxfZQDNgmBWEnf0uYQ=.4e47bf32-a217-4323-8829-c8cea17f43ef@github.com>

On Wed, 14 Sep 2022 16:04:03 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
> 
> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
> 
> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
> 
> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
> 
> But it looks like it is missing another important condition - the GC should be in marking phase.
> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
> So the correct assertion should be:
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
> 
> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> 
> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
> 
> Tested it by running following tests in fastdebug mode:
> 
> - hotspot_gc_shenandoah
> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 179:

> 177: 
> 178:     template <typename T>
> 179:     static void oop_store_common(T* addr, oop value);

This is an implementation detail and a public part of the barrier set. We wouldn't expect users - other than the two existing callers - to ever use this api.

Can it be refactored out of this header and kept entirely within shenandoahBarrierSet.inline.hpp?

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Wed Sep 14 19:53:29 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Sep 2022 19:53:29 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
Message-ID: <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>

On Wed, 14 Sep 2022 16:04:03 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
> 
> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
> 
> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
> 
> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
> 
> But it looks like it is missing another important condition - the GC should be in marking phase.
> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
> So the correct assertion should be:
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
> 
> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> 
> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
> 
> Tested it by running following tests in fastdebug mode:
> 
> - hotspot_gc_shenandoah
> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Please help me understand why `VM_ThreadDump` would be modifying oops?

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 246:

> 244: inline void ShenandoahBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_common(T* addr, oop value) {
> 245:   shenandoah_assert_marked_if(NULL, value, !CompressedOops::is_null(value) && ShenandoahHeap::heap()->is_evacuation_in_progress());
> 246:   shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());

The collection set is chosen during final mark and should always be empty during concurrent mark, so restricting this assertion to run only when concurrent mark is in progress effectively disables it.

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

Changes requested by wkemper (no project role).

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Wed Sep 14 20:48:00 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 14 Sep 2022 20:48:00 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
Message-ID: <UN1RmHBGGdJWH1hzumXNyjHDo5HMOwhz30OicIx_mXU=.787a80b9-7ddc-472a-9a00-2fb57347aede@github.com>

On Wed, 14 Sep 2022 19:51:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Please help me understand why VM_ThreadDump would be modifying oops?

The relevant stack trace for the VMThread (at the point of assertion failure) is:


#8  0x00007fd7e35a0c09 in ShenandoahAsserts::assert_not_in_cset (interior_loc=interior_loc at entry=0x7fd5a00043c0, obj=..., 
    file=file at entry=0x7fd7e3a121c0 "/home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp", line=line at entry=246)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#9  0x00007fd7e27ca136 in ShenandoahBarrierSet::AccessBarrier<548932ul, ShenandoahBarrierSet>::oop_store_not_in_heap<oop> (value=..., addr=0x7fd5a00043c0)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#10 AccessInternal::PostRuntimeDispatch<ShenandoahBarrierSet::AccessBarrier<548932ul, ShenandoahBarrierSet>, (AccessInternal::BarrierType)0, 548932ul>::oop_access_barrier (addr=0x7fd5a00043c0, value=...)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/access.inline.hpp:69
#11 0x00007fd7e2d2cc93 in AccessInternal::RuntimeDispatch<548932ul, oop, (AccessInternal::BarrierType)0>::store (value=..., addr=0x7fd5a00043c0)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#12 AccessInternal::PreRuntimeDispatch::store<548932ul, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/accessBackend.hpp:682
#13 AccessInternal::store_reduce_types<548932ul, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/accessBackend.hpp:961
#14 AccessInternal::store<524292ul, oop, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/accessBackend.hpp:1114
#15 Access<524288ul>::oop_store<oop, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/access.hpp:252
#16 OopHandle::OopHandle (this=<optimized out>, storage=<optimized out>, obj=...) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopHandle.inline.hpp:47
#17 0x00007fd7e381e920 in ThreadConcurrentLocks::add_lock (this=this at entry=0x7fd5a0004310, o=...) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#18 0x00007fd7e381eac0 in ConcurrentLocksDump::add_lock (o=..., thread=<optimized out>, this=0x7fd5a6bfe820) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#19 ConcurrentLocksDump::add_lock (this=0x7fd5a6bfe820, thread=<optimized out>, o=...) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/services/threadService.cpp:832
#20 0x00007fd7e381ebf6 in ConcurrentLocksDump::build_map (this=this at entry=0x7fd5a6bfe820, aos_objects=aos_objects at entry=0x7fd5a0003f40)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#21 0x00007fd7e381f00a in ConcurrentLocksDump::dump_at_safepoint (this=0x7fd5a6bfe820) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/services/threadService.cpp:810
#22 0x00007fd7e38e4bbc in VM_ThreadDump::doit (this=0x7fd5a56c11b0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmOperations.cpp:280
#23 0x00007fd7e38e4f6a in VM_Operation::evaluate (this=this at entry=0x7fd5a56c11b0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmOperations.cpp:71
#24 0x00007fd7e390c4c8 in VMThread::evaluate_operation (this=0x7fd5a6bfea50, op=0x7fd5a56c11b0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:282
#25 VMThread::inner_execute (this=this at entry=0x7fd7dc2499f0, op=<optimized out>) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:429
#26 0x00007fd7e390d172 in VMThread::loop (this=this at entry=0x7fd7dc2499f0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:496
#27 0x00007fd7e390d3e0 in VMThread::run (this=0x7fd7dc2499f0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:175


The VMThread is creating a new OopHandle and as part of that it creates a new oop https://github.com/openjdk/jdk/blob/a75ddb836b2de0e75a65dbfa3b2f240db07a7d31/src/hotspot/share/oops/oopHandle.inline.hpp#L47

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Wed Sep 14 21:00:43 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 14 Sep 2022 21:00:43 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
Message-ID: <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>

On Wed, 14 Sep 2022 19:48:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
>> 
>> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
>> 
>> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
>> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
>> 
>> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
>> 
>> But it looks like it is missing another important condition - the GC should be in marking phase.
>> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
>> So the correct assertion should be:
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
>> 
>> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> 
>> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
>> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
>> 
>> Tested it by running following tests in fastdebug mode:
>> 
>> - hotspot_gc_shenandoah
>> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 246:
> 
>> 244: inline void ShenandoahBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_common(T* addr, oop value) {
>> 245:   shenandoah_assert_marked_if(NULL, value, !CompressedOops::is_null(value) && ShenandoahHeap::heap()->is_evacuation_in_progress());
>> 246:   shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> The collection set is chosen during final mark and should always be empty during concurrent mark, so restricting this assertion to run only when concurrent mark is in progress effectively disables it.

Are you suggesting we are better off removing this assertion completely, because the assertion that the `value` is not in collection set is also not correct as is evident from this issue.

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Wed Sep 14 22:55:45 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Sep 2022 22:55:45 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
Message-ID: <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>

On Wed, 14 Sep 2022 20:58:40 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 246:
>> 
>>> 244: inline void ShenandoahBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_common(T* addr, oop value) {
>>> 245:   shenandoah_assert_marked_if(NULL, value, !CompressedOops::is_null(value) && ShenandoahHeap::heap()->is_evacuation_in_progress());
>>> 246:   shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> The collection set is chosen during final mark and should always be empty during concurrent mark, so restricting this assertion to run only when concurrent mark is in progress effectively disables it.
>
> Are you suggesting we are better off removing this assertion completely, because the assertion that the `value` is not in collection set is also not correct as is evident from this issue.

I'm worried the assertion is correct and the thread dump is doing something wrong. Why is it writing an oop? Should it go through the load reference barrier first and evacuate the object?

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

PR: https://git.openjdk.org/jdk/pull/10268

From fyang at openjdk.org  Wed Sep 14 23:51:43 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 14 Sep 2022 23:51:43 GMT
Subject: RFR: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <YwWCSq_AYX7L1OIzPwagI3ZraTgmElIyKVnIV4brzRs=.deb28600-081f-4986-8f1a-9e2a38386220@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
 <YwWCSq_AYX7L1OIzPwagI3ZraTgmElIyKVnIV4brzRs=.deb28600-081f-4986-8f1a-9e2a38386220@github.com>
Message-ID: <bv9n0lyaOpa3ZMOnjmm9Q0pCrbqAkqOLWmvUfxrP2oM=.5cf0d9b7-e3c6-4f06-8ed2-14c32d19637e@github.com>

On Wed, 14 Sep 2022 03:40:30 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> This is similar to https://bugs.openjdk.org/browse/JDK-8293351
>> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
>> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
>> 
>> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.
>
> Looks good to me. Thanks for the cleanup.

@feilongjiang @shipilev : Thanks for reviewing this. Integrate then.

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

PR: https://git.openjdk.org/jdk/pull/10261

From fyang at openjdk.org  Wed Sep 14 23:53:07 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 14 Sep 2022 23:53:07 GMT
Subject: Integrated: 8293769: RISC-V: Add a second temporary register for
 BarrierSetAssembler::load_at
In-Reply-To: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
References: <nVHxGwBYQIM9qLPUpnuawBVgj9jrhGFGPGeRuHC3oZM=.c2cc93e7-05a0-490d-a8bc-bd8aa0949b24@github.com>
Message-ID: <U-Qhhmcg75niiUka92kpuQWSINFxr7byC2220gFJgc8=.9d987d0d-7705-4e64-b2cf-723ea606a961@github.com>

On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This is similar to https://bugs.openjdk.org/browse/JDK-8293351
> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64.
> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC.
> 
> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board.

This pull request has now been integrated.

Changeset: 7376c552
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7376c55219ce2107afb9197e2452e7122d86ef52
Stats:     327 lines in 13 files changed: 9 ins; 108 del; 210 mod

8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at

Reviewed-by: fjiang, shade

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

PR: https://git.openjdk.org/jdk/pull/10261

From rehn at openjdk.org  Thu Sep 15 11:49:43 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 15 Sep 2022 11:49:43 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v7]
In-Reply-To: <jq5Ttm5h1nRhDypmOUmENNQKadgOAd3n9ar8wA7XxJU=.48501393-6107-4bdf-afe4-a1ebfdc9a24f@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <jq5Ttm5h1nRhDypmOUmENNQKadgOAd3n9ar8wA7XxJU=.48501393-6107-4bdf-afe4-a1ebfdc9a24f@github.com>
Message-ID: <m-xSLSd6XFb4VXuWRv93cg_vPxM9HwffpBxplKgV5NE=.16b882e5-3933-41ae-a5cf-e387f1705afd@github.com>

On Wed, 14 Sep 2022 13:32:46 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi!
>> 
>> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
>> 
>> When I've left ResourceMarks in place I've also commented which calls requires them.
>> 
>> This passes tier1, tier2 tests.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to freeze

Seems fine, thanks.

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Thu Sep 15 19:57:44 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 15 Sep 2022 19:57:44 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
Message-ID: <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>

On Wed, 14 Sep 2022 22:52:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Are you suggesting we are better off removing this assertion completely, because the assertion that the `value` is not in collection set is also not correct as is evident from this issue.
>
> I'm worried the assertion is correct and the thread dump is doing something wrong. Why is it writing an oop? Should it go through the load reference barrier first and evacuate the object?

That was my first impression as well - that we are missing load reference barrier somewhere. But then I realized we do hit the LRB when the JVM tires to load oop from the OopHandle using `OopHandle::resolve`, as is done here [0]

That prompted me to think there is nothing wrong in `VM_ThreadDump` and the problem lies in the assert conditions, more so because `oop_store_in_heap()` has that additional condition of `is_concurrent_mark_in_progress()`.

With the additional condition I added in this PR, I am currently hitting another assert with the same test case in the same code area. The sequence of events leading to the new assertion failure are:

T1: GC cycle started and marked object A
T2: "Concurrent strong root" is completed which evacuates and updates the non-heap strong roots
T3: Concurrent evacuation started
T4: VMThread running VM_ThreadDump creates a new non-heap strong root R to object A (by creating OopHandle)
T5: VMThread completes VM_ThreadDump operation
T4: Concurrent evacuation moves object A
T5: GC cycle completes
T6: New GC cycle starts (in my case it was because the test was running with "aggressive" heuristics)
T7: Concurrent root marking comes across R and crashes trying to access A which has been evacuated

Initially I was thinking of resolving it by moving "Concurrent strong root" phase after "Concurrent evacuation" so that any new non-heap strong roots which may have been created during evacuation are also properly updated.

But now I am skeptic. It seems the underlying problem for both these asserts is the same - the object was not evacuated when it was handed over to VM_ThreadDump.

`VM_ThreadDump` calls `HeapInspection::find_instances_at_safepoint` to find instances of a particular class at safepoint which uses GC API `object_iterate()`. In case of Shenandoah GC core of this API is in `ObjectIterateScanRootClosure::do_oop_work()` [1] which does not have the code to evacuate the object. So probably the right way to fix these issues is to add a call to `_heap->evacuate_object()` in `ObjectIterateScanRootClosure::do_oop_work`. what do you think?

[0] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/services/management.cpp#L1288

[1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L1233

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Thu Sep 15 23:16:42 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Sep 2022 23:16:42 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
Message-ID: <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>

On Thu, 15 Sep 2022 19:55:30 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> I'm worried the assertion is correct and the thread dump is doing something wrong. Why is it writing an oop? Should it go through the load reference barrier first and evacuate the object?
>
> That was my first impression as well - that we are missing load reference barrier somewhere. But then I realized we do hit the LRB when the JVM tires to load oop from the OopHandle using `OopHandle::resolve`, as is done here [0]
> 
> That prompted me to think there is nothing wrong in `VM_ThreadDump` and the problem lies in the assert conditions, more so because `oop_store_in_heap()` has that additional condition of `is_concurrent_mark_in_progress()`.
> 
> With the additional condition I added in this PR, I am currently hitting another assert with the same test case in the same code area. The sequence of events leading to the new assertion failure are:
> 
> T1: GC cycle started and marked object A
> T2: "Concurrent strong root" is completed which evacuates and updates the non-heap strong roots
> T3: Concurrent evacuation started
> T4: VMThread running VM_ThreadDump creates a new non-heap strong root R to object A (by creating OopHandle)
> T5: VMThread completes VM_ThreadDump operation
> T4: Concurrent evacuation moves object A
> T5: GC cycle completes
> T6: New GC cycle starts (in my case it was because the test was running with "aggressive" heuristics)
> T7: Concurrent root marking comes across R and crashes trying to access A which has been evacuated
> 
> Initially I was thinking of resolving it by moving "Concurrent strong root" phase after "Concurrent evacuation" so that any new non-heap strong roots which may have been created during evacuation are also properly updated.
> 
> But now I am skeptic. It seems the underlying problem for both these asserts is the same - the object was not evacuated when it was handed over to VM_ThreadDump.
> 
> `VM_ThreadDump` calls `HeapInspection::find_instances_at_safepoint` to find instances of a particular class at safepoint which uses GC API `object_iterate()`. In case of Shenandoah GC core of this API is in `ObjectIterateScanRootClosure::do_oop_work()` [1] which does not have the code to evacuate the object. So probably the right way to fix these issues is to add a call to `_heap->evacuate_object()` in `ObjectIterateScanRootClosure::do_oop_work`. what do you think?
> 
> [0] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/services/management.cpp#L1288
> 
> [1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L1233

Hmm, `OopHandle::resolve` should have gone through the LRB, which should have evacuated the object. If the object is in the `cset` and it didn't get evacuated by the LRB, then it should be true that the gc is cancelled (out-of-memory during evac). Did this happen under low memory conditions? I wonder if the VM thread did _try_ to evacuate it and fail?

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Fri Sep 16 01:35:49 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 16 Sep 2022 01:35:49 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
Message-ID: <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>

On Thu, 15 Sep 2022 23:14:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> That was my first impression as well - that we are missing load reference barrier somewhere. But then I realized we do hit the LRB when the JVM tires to load oop from the OopHandle using `OopHandle::resolve`, as is done here [0]
>> 
>> That prompted me to think there is nothing wrong in `VM_ThreadDump` and the problem lies in the assert conditions, more so because `oop_store_in_heap()` has that additional condition of `is_concurrent_mark_in_progress()`.
>> 
>> With the additional condition I added in this PR, I am currently hitting another assert with the same test case in the same code area. The sequence of events leading to the new assertion failure are:
>> 
>> T1: GC cycle started and marked object A
>> T2: "Concurrent strong root" is completed which evacuates and updates the non-heap strong roots
>> T3: Concurrent evacuation started
>> T4: VMThread running VM_ThreadDump creates a new non-heap strong root R to object A (by creating OopHandle)
>> T5: VMThread completes VM_ThreadDump operation
>> T4: Concurrent evacuation moves object A
>> T5: GC cycle completes
>> T6: New GC cycle starts (in my case it was because the test was running with "aggressive" heuristics)
>> T7: Concurrent root marking comes across R and crashes trying to access A which has been evacuated
>> 
>> Initially I was thinking of resolving it by moving "Concurrent strong root" phase after "Concurrent evacuation" so that any new non-heap strong roots which may have been created during evacuation are also properly updated.
>> 
>> But now I am skeptic. It seems the underlying problem for both these asserts is the same - the object was not evacuated when it was handed over to VM_ThreadDump.
>> 
>> `VM_ThreadDump` calls `HeapInspection::find_instances_at_safepoint` to find instances of a particular class at safepoint which uses GC API `object_iterate()`. In case of Shenandoah GC core of this API is in `ObjectIterateScanRootClosure::do_oop_work()` [1] which does not have the code to evacuate the object. So probably the right way to fix these issues is to add a call to `_heap->evacuate_object()` in `ObjectIterateScanRootClosure::do_oop_work`. what do you think?
>> 
>> [0] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/services/management.cpp#L1288
>> 
>> [1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L1233
>
> Hmm, `OopHandle::resolve` should have gone through the LRB, which should have evacuated the object. If the object is in the `cset` and it didn't get evacuated by the LRB, then it should be true that the gc is cancelled (out-of-memory during evac). Did this happen under low memory conditions? I wonder if the VM thread did _try_ to evacuate it and fail?

If `OopHandle::resolve()` is hit, then the object gets evacuated through LRB, but the assertions happen before the code calls `resolve`.
The assertion `assert_not_in_cset` is hit when `OopHandle` is created (see frame 16 in the stack trace mentioned [here](https://github.com/openjdk/jdk/pull/10268#issuecomment-1247282078))
The new assertion that I mentioned in previous comment also happens before the `OopHandle` is resolved.

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

PR: https://git.openjdk.org/jdk/pull/10268

From zgu at openjdk.org  Fri Sep 16 13:23:41 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 16 Sep 2022 13:23:41 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
Message-ID: <71ZgJZcMUjwZhDaO7suP6LKcEwX0tVnEoplVQ1rNOmo=.8014be3c-ec57-47e7-8f36-5bd3dd68c22f@github.com>

On Fri, 16 Sep 2022 01:33:31 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Hmm, `OopHandle::resolve` should have gone through the LRB, which should have evacuated the object. If the object is in the `cset` and it didn't get evacuated by the LRB, then it should be true that the gc is cancelled (out-of-memory during evac). Did this happen under low memory conditions? I wonder if the VM thread did _try_ to evacuate it and fail?
>
> If `OopHandle::resolve()` is hit, then the object gets evacuated through LRB, but the assertions happen before the code calls `resolve`.
> The assertion `assert_not_in_cset` is hit when `OopHandle` is created (see frame 16 in the stack trace mentioned [here](https://github.com/openjdk/jdk/pull/10268#issuecomment-1247282078))
> The new assertion that I mentioned in previous comment also happens before the `OopHandle` is resolved.

> The collection set is chosen during final mark and should always be empty during concurrent mark, so restricting this assertion to run only when concurrent mark is in progress effectively disables it.

I believe it is true for satb mode, but not true for iu mode: iu mode has cset during concurrent marking.

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Fri Sep 16 18:54:48 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Sep 2022 18:54:48 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
Message-ID: <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>

On Fri, 16 Sep 2022 01:33:31 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Hmm, `OopHandle::resolve` should have gone through the LRB, which should have evacuated the object. If the object is in the `cset` and it didn't get evacuated by the LRB, then it should be true that the gc is cancelled (out-of-memory during evac). Did this happen under low memory conditions? I wonder if the VM thread did _try_ to evacuate it and fail?
>
> If `OopHandle::resolve()` is hit, then the object gets evacuated through LRB, but the assertions happen before the code calls `resolve`.
> The assertion `assert_not_in_cset` is hit when `OopHandle` is created (see frame 16 in the stack trace mentioned [here](https://github.com/openjdk/jdk/pull/10268#issuecomment-1247282078))
> The new assertion that I mentioned in previous comment also happens before the `OopHandle` is resolved.

Had some time to look at this a little more closely. The bad access comes from here. The heap walk gives out references to objects without putting them through the load barrier:
https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/memory/heapInspection.cpp#L633-L641

The assert happens when the heap inspection tries to create a pointer to an object in the collection set that was visited during this heap walk. The comment and the effort to keep the doomed object alive are concerning. I can think of two ways to address  this:
1. Have the inspection/heap walk put objects through the LRB before passing them on to closures.
2. Disable the assertion if it is running on a safepoint.

Option 1. is probably the Right Thing to do, but I'm no sure what would happen if the VMThread is unable to find memory for the evacuated object. Option 2. _might_ be safe, but I don't know what it means to be `published` here and can't be 100% certain the reference to the doomed object won't survive after the safepoint without knowing that.

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

PR: https://git.openjdk.org/jdk/pull/10268

From jsjolen at openjdk.org  Fri Sep 16 19:11:51 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 16 Sep 2022 19:11:51 GMT
Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when
 applicable [v6]
In-Reply-To: <7GN_5qAEZr9HjWItusy4UGLENSTyGRDADf7pVFdES84=.0567293e-927d-4281-ac99-500b767c9c3b@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
 <eF1tI6dH4eEg0UCW_1EwY9ZxYaykni0YH6QiBD5dWN8=.3296c3db-18db-43ab-9aa8-17c0b01d27ab@github.com>
 <7GN_5qAEZr9HjWItusy4UGLENSTyGRDADf7pVFdES84=.0567293e-927d-4281-ac99-500b767c9c3b@github.com>
Message-ID: <WypDxVrxxgEA57jdDlkNQujxLfEv5CJMVxClcO8EhZo=.c3594efe-01f1-48ff-94f2-ac9d78011db3@github.com>

On Wed, 14 Sep 2022 12:53:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed fixes
>
> Hi Johan,
> 
> please be aware that changes like these across the code base makes downporting more painful. So I would only do wholesale renames and replacements where the benefit clearly outweighs the downporting costs.
> 
> About your last iteration, yes, I think requiring base() to freeze the stream is a bit much.
> 
> How about renaming "internal_string" to "freeze"
> 
> 
> // Freezes stringStream (no further modifications possible) and returns pointer to it.
> // No-op if stream is frozen already.
> const char* freeze();
> 
> 
> "freeze" is snappy and clear in its meaning. And in release builds I also would freeze, allowing no further changes, apart from the debug-only assert. Since writes potentially reallocate the buffer, the char ptr may be invalid, better to have incomplete stringStream output than C-heap corruption (as improbable as it is).

@tstuefe, @robehn 
Alright tests are passing :). Would any of you mind sponsoring?

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

PR: https://git.openjdk.org/jdk/pull/10142

From duke at openjdk.org  Fri Sep 16 19:51:48 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 16 Sep 2022 19:51:48 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
Message-ID: <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>

On Fri, 16 Sep 2022 18:51:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The assert happens when the heap inspection tries to create a pointer to an object in the collection set that was visited during this heap walk

That's right.
I am inclined towards option 1 as it should (theoretically speaking) solve the other assertion failure as well.

> Option 1. is probably the Right Thing to do, but I'm no sure what would happen if the VMThread is unable to find memory for the evacuated object.

Can you please help me understand if we add LRB during heap inspection, why would VMThread ever be in situation where it fails to find memory for the evacuated object?

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

PR: https://git.openjdk.org/jdk/pull/10268

From jsjolen at openjdk.org  Fri Sep 16 19:57:51 2022
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 16 Sep 2022 19:57:51 GMT
Subject: Integrated: 8293251: Use stringStream::base() instead of as_string()
 when applicable
In-Reply-To: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
References: <kFMqyi01vncxm0QwcIZQ6jWjfYwjGrJrCL-6qj7zPJw=.272bf9fd-7e4c-41ce-82ca-307ef23489a0@github.com>
Message-ID: <np1yQB0pes_oHGCy7pCCZcrNbhrXbVWRM1OCtzpqXNo=.26e281ac-6db6-4243-94e0-15a4d06b7304@github.com>

On Fri, 2 Sep 2022 11:20:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi!
> 
> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods.
> 
> When I've left ResourceMarks in place I've also commented which calls requires them.
> 
> This passes tier1, tier2 tests.

This pull request has now been integrated.

Changeset: 4b8399b5
Author:    Johan Sj?len <jsjolen at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b8399b5f0b4dec2fa9452019cc9292bc6b57738
Stats:     76 lines in 27 files changed: 13 ins; 7 del; 56 mod

8293251: Use stringStream::base() instead of as_string() when applicable

Reviewed-by: rehn

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

PR: https://git.openjdk.org/jdk/pull/10142

From wkemper at openjdk.org  Fri Sep 16 20:34:43 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Sep 2022 20:34:43 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
Message-ID: <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>

On Fri, 16 Sep 2022 19:48:02 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Had some time to look at this a little more closely. The bad access comes from here. The heap walk gives out references to objects without putting them through the load barrier:
>> https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/memory/heapInspection.cpp#L633-L641
>> 
>> The assert happens when the heap inspection tries to create a pointer to an object in the collection set that was visited during this heap walk. The comment and the effort to keep the doomed object alive are concerning. I can think of two ways to address  this:
>> 1. Have the inspection/heap walk put objects through the LRB before passing them on to closures.
>> 2. Disable the assertion if it is running on a safepoint.
>> 
>> Option 1. is probably the Right Thing to do, but I'm no sure what would happen if the VMThread is unable to find memory for the evacuated object. Option 2. _might_ be safe, but I don't know what it means to be `published` here and can't be 100% certain the reference to the doomed object won't survive after the safepoint without knowing that.
>
>> The assert happens when the heap inspection tries to create a pointer to an object in the collection set that was visited during this heap walk
> 
> That's right.
> I am inclined towards option 1 as it should (theoretically speaking) solve the other assertion failure as well.
> 
>> Option 1. is probably the Right Thing to do, but I'm no sure what would happen if the VMThread is unable to find memory for the evacuated object.
> 
> Can you please help me understand if we add LRB during heap inspection, why would VMThread ever be in situation where it fails to find memory for the evacuated object?

I just meant it could suffer from an out-of-memory error just like any other evacuating thread, but I think it'd be fine. The LRB would cancel the GC and the from-space reference would be returned (cancelling the GC would nullify the assert). If the from-space reference is still reachable after the thread dump completes, the degenerated cycle should fix it up.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Fri Sep 16 20:49:48 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 16 Sep 2022 20:49:48 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
Message-ID: <trTnJzE3OICbH_gncF51napwgZHJmnOnr2NO-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>

On Fri, 16 Sep 2022 20:30:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>>> The assert happens when the heap inspection tries to create a pointer to an object in the collection set that was visited during this heap walk
>> 
>> That's right.
>> I am inclined towards option 1 as it should (theoretically speaking) solve the other assertion failure as well.
>> 
>>> Option 1. is probably the Right Thing to do, but I'm no sure what would happen if the VMThread is unable to find memory for the evacuated object.
>> 
>> Can you please help me understand if we add LRB during heap inspection, why would VMThread ever be in situation where it fails to find memory for the evacuated object?
>
> I just meant it could suffer from an out-of-memory error just like any other evacuating thread, but I think it'd be fine. The LRB would cancel the GC and the from-space reference would be returned (cancelling the GC would nullify the assert). If the from-space reference is still reachable after the thread dump completes, the degenerated cycle should fix it up.

Thanks for clarifying that.

For option 1, I don't see any access API that acts on oop directly. Is there any? 
Would it better to evacuate the oops explicitly in `ObjectIterateScanRootClosure` before handing out the oop to `FindInstanceClosure` in heapInspection.cpp.

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Fri Sep 16 21:38:45 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Sep 2022 21:38:45 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <trTnJzE3OICbH_gncF51napwgZHJmnOnr2NO-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
 <trTnJzE3OICbH_gncF51napwgZHJmnOnr2N
 O-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
Message-ID: <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>

On Fri, 16 Sep 2022 20:47:23 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> I just meant it could suffer from an out-of-memory error just like any other evacuating thread, but I think it'd be fine. The LRB would cancel the GC and the from-space reference would be returned (cancelling the GC would nullify the assert). If the from-space reference is still reachable after the thread dump completes, the degenerated cycle should fix it up.
>
> Thanks for clarifying that.
> 
> For option 1, I don't see any access API that acts on oop directly. Is there any? 
> Would it better to evacuate the oops explicitly in `ObjectIterateScanRootClosure` before handing out the oop to `FindInstanceClosure` in heapInspection.cpp.

`ObjectIterateScanRootClosure` should probably use `NativeAccess<AS_NO_KEEPALIVE>::oop_load` (or `HeapAccess`) rather than `RawAccess<>::oop_load(p);` (which bypasses the LRB).

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

PR: https://git.openjdk.org/jdk/pull/10268

From eosterlund at openjdk.org  Mon Sep 19 13:00:56 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 19 Sep 2022 13:00:56 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <Z_P3HOEvc3dF-30yeUEgZ0UjhLk468F96SVpAihl4HA=.94f22f3a-1de7-49f7-bf23-a3f75610402e@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> The Access API is same as in ZGC [1], [2]
> 
> [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215
> [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286
> 
> Test with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

@rkennke ping!

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

PR: https://git.openjdk.org/jdk/pull/10089

From rkennke at openjdk.org  Mon Sep 19 17:14:44 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 19 Sep 2022 17:14:44 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <KrX66HV5-GQPBHv113J90KooYuKoAv7I1KcRBRhudmc=.41298f72-d6ef-41d4-aa1e-b24d4d5a4053@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> The Access API is same as in ZGC [1], [2]
> 
> [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215
> [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286
> 
> Test with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Oh sorry, I've been deep in some other stuff. Thanks for reminding me.
The change looks good.
Does this mean we can now remove some of the GC specific paths in stack-chunk handling code?

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10089

From duke at openjdk.org  Tue Sep 20 18:07:17 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 20 Sep 2022 18:07:17 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <KrX66HV5-GQPBHv113J90KooYuKoAv7I1KcRBRhudmc=.41298f72-d6ef-41d4-aa1e-b24d4d5a4053@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
 <KrX66HV5-GQPBHv113J90KooYuKoAv7I1KcRBRhudmc=.41298f72-d6ef-41d4-aa1e-b24d4d5a4053@github.com>
Message-ID: <Yun9CbhbZF9GTm2Q8LMqqdr0ZdXnZ0_Hc9odWyAanKU=.b4f6c66e-e05d-4e90-85d1-3e7ef2ae1571@github.com>

On Mon, 19 Sep 2022 17:11:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
>> 
>> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
>> The Access API is same as in ZGC [1], [2]
>> 
>> [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215
>> [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286
>> 
>> Test with fastdebug build:
>> 
>> - [x] hotspot_loom
>> - [x] jdk_loom
>> - [x] hotspot_loom in Shenandoah IU mode
>> - [x] jdk_loom in Shenandoah IU mode
>> - [x] hotspot_loom in Shenandoah IU + aggressive
>> - [x] jdk_loom in Shenandoah IU + aggressive
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Oh sorry, I've been deep in some other stuff. Thanks for reminding me.
> The change looks good.
> Does this mean we can now remove some of the GC specific paths in stack-chunk handling code?

@rkennke @fisk thank you for reviewing the pr.

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

PR: https://git.openjdk.org/jdk/pull/10089

From duke at openjdk.org  Tue Sep 20 18:33:43 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 20 Sep 2022 18:33:43 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <KrX66HV5-GQPBHv113J90KooYuKoAv7I1KcRBRhudmc=.41298f72-d6ef-41d4-aa1e-b24d4d5a4053@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
 <KrX66HV5-GQPBHv113J90KooYuKoAv7I1KcRBRhudmc=.41298f72-d6ef-41d4-aa1e-b24d4d5a4053@github.com>
Message-ID: <og3a_jeMRDJ8mPRrzMdnShNnbOkEDuWF7TMrLe9yPkc=.bda1c421-c22a-484f-9ba9-67f8520a6a10@github.com>

On Mon, 19 Sep 2022 17:11:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Does this mean we can now remove some of the GC specific paths in stack-chunk handling code?

I guess you are referring to the checks for `UseShenandoahGC` in the continuations code. I am not sure we can get rid of it. I will need to dig deeper for that.

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

PR: https://git.openjdk.org/jdk/pull/10089

From wkemper at openjdk.org  Tue Sep 20 21:02:43 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Sep 2022 21:02:43 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
 <trTnJzE3OICbH_gncF51napwgZHJmnOnr2N
 O-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
 <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>
Message-ID: <-macGNEx5F-Izx0Jm_JsB5BDC7GjQmSAzK74ifM2Q8s=.1060e906-15ec-4863-a1b5-d34cc0c870fd@github.com>

On Fri, 16 Sep 2022 21:34:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Thanks for clarifying that.
>> 
>> For option 1, I don't see any access API that acts on oop directly. Is there any? 
>> Would it better to evacuate the oops explicitly in `ObjectIterateScanRootClosure` before handing out the oop to `FindInstanceClosure` in heapInspection.cpp.
>
> `ObjectIterateScanRootClosure` should probably use `NativeAccess<AS_NO_KEEPALIVE>::oop_load` (or `HeapAccess`) rather than `RawAccess<>::oop_load(p);` (which bypasses the LRB).

This looks related: https://bugs.openjdk.org/browse/JDK-8235324. The `CollectedHeap::keep_alive` API doesn't support the case where the given oop would need to be evacuated and return the new location.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Tue Sep 20 21:26:48 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 20 Sep 2022 21:26:48 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with IU+aggressive mode
In-Reply-To: <-macGNEx5F-Izx0Jm_JsB5BDC7GjQmSAzK74ifM2Q8s=.1060e906-15ec-4863-a1b5-d34cc0c870fd@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
 <trTnJzE3OICbH_gncF51napwgZHJmnOnr2N
 O-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
 <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>
 <-macGNEx5F-Izx0Jm_JsB5BDC7GjQmSAzK74ifM2Q8s=.1060e906-15ec-4863-a1b5-d34cc0c870fd@github.com>
Message-ID: <sjnE_EJ6xSEQKcSG0xKgJmr4TbeCc2UhaGgMtg1jb1U=.cf933a21-39e7-4075-94d9-76049ced6530@github.com>

On Tue, 20 Sep 2022 21:00:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> `ObjectIterateScanRootClosure` should probably use `NativeAccess<AS_NO_KEEPALIVE>::oop_load` (or `HeapAccess`) rather than `RawAccess<>::oop_load(p);` (which bypasses the LRB).
>
> This looks related: https://bugs.openjdk.org/browse/JDK-8235324. The `CollectedHeap::keep_alive` API doesn't support the case where the given oop would need to be evacuated and return the new location.

Thanks for pointing out that bug. It explains the need for the keep_alive API. But that API is solving a different issue than what we are facing here. I think we are on right track with respect to adding LRB during object iteration.

I am going to try changing `ObjectIterateScanRootClosure` to use `HeapAccess<AS_NO_KEEPALIVE>` instead of `RawAccess`.
I have been deliberating over the need for `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` check in `ObjectIterateScanRootClosure` after we switch to HeapAccess. The same check is executed by LRB [1] if `ON_PHANTOM_OOP_REF` decorator is also set, which makes me think we should probably use `HeapAccess<AS_NO_KEEPALIVE | ON_PHANTOM_OOP_REF>` and remove that check from `ObjectIterateScanRootClosure`. wdyt?

[1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L104-L108

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Wed Sep 21 14:31:31 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 21 Sep 2022 14:31:31 GMT
Subject: Integrated: 8288129: Shenandoah: Skynet test crashed with iu +
 aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <HeCl4_o6wHAuYaLgop8Rn0soQlrVy7r0lV4NBA-sjqk=.3f0a7897-676e-4d75-a917-da04c403d9f2@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> The Access API is same as in ZGC [1], [2]
> 
> [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215
> [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286
> 
> Test with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

This pull request has now been integrated.

Changeset: 84d7ff64
Author:    Ashutosh Mehra <asmehra at redhat.com>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84d7ff64d86388cc60cd8257b7b1fb5a6e8c6804
Stats:     36 lines in 9 files changed: 27 ins; 3 del; 6 mod

8288129: Shenandoah: Skynet test crashed with iu + aggressive

Reviewed-by: eosterlund, rkennke

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

PR: https://git.openjdk.org/jdk/pull/10089

From duke at openjdk.org  Thu Sep 22 01:45:42 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 01:45:42 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
Message-ID: <amweTUGQ_-i3fP68RU4oAkKRt4uo9QWOtSjxLT3nD4Q=.f5b555e8-07d4-44e3-88e5-7e4f4e5ea3c9@github.com>

> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
> 
> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
> 
> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
> 
> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
> 
> But it looks like it is missing another important condition - the GC should be in marking phase.
> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
> So the correct assertion should be:
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
> 
> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> 
> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
> 
> Tested it by running following tests in fastdebug mode:
> 
> - hotspot_gc_shenandoah
> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision:

 - Use HeapAccess instead of RawAccess when iterating the heap objects
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
 - Make oop_store_common() as private method and remove extraneous condition
   
   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10268/files
  - new: https://git.openjdk.org/jdk/pull/10268/files/41629506..ee36ab82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10268&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10268&range=00-01

  Stats: 18 lines in 3 files changed: 4 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/10268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10268/head:pull/10268

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 01:45:42 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 01:45:42 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <WlaLBOo9Q9fViWQQm9LJDoT0mvxfZQDNgmBWEnf0uYQ=.4e47bf32-a217-4323-8829-c8cea17f43ef@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <WlaLBOo9Q9fViWQQm9LJDoT0mvxfZQDNgmBWEnf0uYQ=.4e47bf32-a217-4323-8829-c8cea17f43ef@github.com>
Message-ID: <q65pN4n8zF3gfBzX2BU_SxBTagyeFX3UPAEUzMincN4=.5a73a05c-a745-4ef0-8847-ff1305404ad2@github.com>

On Wed, 14 Sep 2022 18:55:55 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use HeapAccess instead of RawAccess when iterating the heap objects
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Make oop_store_common() as private method and remove extraneous condition
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 179:
> 
>> 177: 
>> 178:     template <typename T>
>> 179:     static void oop_store_common(T* addr, oop value);
> 
> This is an implementation detail and a public part of the barrier set. We wouldn't expect users - other than the two existing callers - to ever use this api.
> 
> Can it be refactored out of this header and kept entirely within shenandoahBarrierSet.inline.hpp?

I have made `oop_store_common` a private method. It needs to be part of `ShenandoahBarrierSet::AccessBarrier` to be able to access `RawAccessBarrier::oop_store()`.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 02:01:16 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 02:01:16 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <sjnE_EJ6xSEQKcSG0xKgJmr4TbeCc2UhaGgMtg1jb1U=.cf933a21-39e7-4075-94d9-76049ced6530@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
 <trTnJzE3OICbH_gncF51napwgZHJmnOnr2N
 O-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
 <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>
 <-macGNEx5F-Izx0Jm_JsB5BDC7GjQmSAzK74ifM2Q8s=.1060e906-15ec-4863-a1b5-d34cc0c870fd@github.com>
 <sjnE_EJ6xSEQKcSG0xKgJmr4TbeCc2UhaGgMtg1jb1U=.cf933a21-39e7-4075-94d9-76049ced6530@github.com>
Message-ID: <SP01751cijVMhFtRh1zkURHd_ld3cjo9CWSsTx0ATUA=.a3db1bb0-ad21-47f4-82f0-6e4ca2501c18@github.com>

On Tue, 20 Sep 2022 21:24:36 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> This looks related: https://bugs.openjdk.org/browse/JDK-8235324. The `CollectedHeap::keep_alive` API doesn't support the case where the given oop would need to be evacuated and return the new location.
>
> Thanks for pointing out that bug. It explains the need for the keep_alive API. But that API is solving a different issue than what we are facing here. I think we are on right track with respect to adding LRB during object iteration.
> 
> I am going to try changing `ObjectIterateScanRootClosure` to use `HeapAccess<AS_NO_KEEPALIVE>` instead of `RawAccess`.
> I have been deliberating over the need for `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` check in `ObjectIterateScanRootClosure` after we switch to HeapAccess. The same check is executed by LRB [1] if `ON_PHANTOM_OOP_REF` decorator is also set, which makes me think we should probably use `HeapAccess<AS_NO_KEEPALIVE | ON_PHANTOM_OOP_REF>` and remove that check from `ObjectIterateScanRootClosure`. wdyt?
> 
> [1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L104-L108

I have added commit that replaces the `RawAccess` with `HeapAccess<AS_NO_KEEPALIVE>`. I think its better not to avoid the check `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` by using `ON_PHANTOM_OOP_REF` decorator as it relies on the assumption that weak oops in the VM are similar to phantomly reachable references (which is true and may remain so, but is not as explicit as the condition itself). I have therefore kept the check for `is_concurrent_weak_root_in_progress` as it is.

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Thu Sep 22 16:41:20 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Sep 2022 16:41:20 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <amweTUGQ_-i3fP68RU4oAkKRt4uo9QWOtSjxLT3nD4Q=.f5b555e8-07d4-44e3-88e5-7e4f4e5ea3c9@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <amweTUGQ_-i3fP68RU4oAkKRt4uo9QWOtSjxLT3nD4Q=.f5b555e8-07d4-44e3-88e5-7e4f4e5ea3c9@github.com>
Message-ID: <BO16HqHqWRvuK22EH1hp8T7TYTpoxuQIPk0jKcDNcmY=.e9b6ed3b-b1b9-475d-a8da-da09c11bbfc4@github.com>

On Thu, 22 Sep 2022 01:45:42 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
>> 
>> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
>> 
>> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
>> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
>> 
>> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
>> 
>> But it looks like it is missing another important condition - the GC should be in marking phase.
>> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
>> So the correct assertion should be:
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
>> 
>> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> 
>> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
>> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
>> 
>> Tested it by running following tests in fastdebug mode:
>> 
>> - hotspot_gc_shenandoah
>> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use HeapAccess instead of RawAccess when iterating the heap objects
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Make oop_store_common() as private method and remove extraneous condition
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

> 1338:   template <class T>
> 1339:   void do_oop_work(T* p) {
> 1340:     oop obj = HeapAccess<AS_NO_KEEPALIVE>::oop_load(p);

After taking a closer look at the LRB code, I think we should `or` in `ON_WEAK_OOP_REF` to the access decorators. With only the `AS_NO_KEEPALIVE` decorator, the LRB will fall through all the cases here and end up evacuating a doomed weak referent (i.e., keeping the object alive). 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L119

I'm worried that this access here could defeat the logic which is meant to keep weak references from being resurrected. It also looks like if we add in the `ON_WEAK_OOP_REF` decorator, the LRB will handle this case for the object iterator too:

if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj)) {
        // There may be dead oops in weak roots in concurrent root phase, do not touch them.
        return;
}

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Thu Sep 22 18:14:25 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Sep 2022 18:14:25 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <SP01751cijVMhFtRh1zkURHd_ld3cjo9CWSsTx0ATUA=.a3db1bb0-ad21-47f4-82f0-6e4ca2501c18@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
 <trTnJzE3OICbH_gncF51napwgZHJmnOnr2N
 O-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
 <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>
 <-macGNEx5F-Izx0Jm_JsB5BDC7GjQmSAzK74ifM2Q8s=.1060e906-15ec-4863-a1b5-d34cc0c870fd@github.com>
 <sjnE_EJ6xSEQKcSG0xKgJmr4TbeCc2UhaGgMtg1jb1U=.cf933a21-39e7-4075-94d9-76049ced6530@github.com>
 <SP01751cijVMhFtRh1zkURHd_ld3cjo9CWSsTx0ATUA=.a3db1bb0-ad21-47f4-82f0-6e4ca2501c18@github.com>
Message-ID: <l3SjOm7pYpLuIH9-1Nx2IG_Z8VIQhgbhQ0dKl5b-Fqw=.ee7bbb40-1025-4641-a8e1-eec0a663297c@github.com>

On Thu, 22 Sep 2022 01:59:08 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Thanks for pointing out that bug. It explains the need for the keep_alive API. But that API is solving a different issue than what we are facing here. I think we are on right track with respect to adding LRB during object iteration.
>> 
>> I am going to try changing `ObjectIterateScanRootClosure` to use `HeapAccess<AS_NO_KEEPALIVE>` instead of `RawAccess`.
>> I have been deliberating over the need for `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` check in `ObjectIterateScanRootClosure` after we switch to HeapAccess. The same check is executed by LRB [1] if `ON_PHANTOM_OOP_REF` decorator is also set, which makes me think we should probably use `HeapAccess<AS_NO_KEEPALIVE | ON_PHANTOM_OOP_REF>` and remove that check from `ObjectIterateScanRootClosure`. wdyt?
>> 
>> [1] https://github.com/openjdk/jdk/blob/6beeb8471ccf140e59864d7f983e1d9ad741309c/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L104-L108
>
> I have added commit that replaces the `RawAccess` with `HeapAccess<AS_NO_KEEPALIVE>`. I think its better not to avoid the check `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` by using `ON_PHANTOM_OOP_REF` decorator as it relies on the assumption that weak oops in the VM are similar to phantomly reachable references (which is true and may remain so, but is not as explicit as the condition itself). I have therefore kept the check for `is_concurrent_weak_root_in_progress` as it is.

It might be simpler to only change the one line in these object iterators:

obj = ShenandoahBarrierSet::resolve_forwarded_not_null(obj); 

to

obj = ShenandoahBarrierSet::load_reference_barrier(obj); 

This will evacuate objects in the cset after checking for unmarked concurrent weak roots. `resolve_forwarded_not_null` presumes the object has already been evacuated, but that may not be the case here.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 19:57:23 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 19:57:23 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <l3SjOm7pYpLuIH9-1Nx2IG_Z8VIQhgbhQ0dKl5b-Fqw=.ee7bbb40-1025-4641-a8e1-eec0a663297c@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
 <3fErZsTpkW76qGgvt60Ltch8PNROFpM3lN8W5e_vQlg=.bd68880f-9fe3-49bf-a184-e650649742c9@github.com>
 <TkPNJAmEqTl2MxyjjbYgpTo2NT2SLN35Bn-tOJvSfpc=.2440015e-772b-452c-9e74-8b0764a7a987@github.com>
 <w8LjPK0IBoCK6jKnIOmtlkTnCaFSIoTA9Mw-XpMn5F4=.2d3408bc-2d70-42c2-b81e-4061300efbf5@github.com>
 <CxGo5uzkgE5HxHQNHUagx4BlN3OHI8VWF7y6-muEyaU=.7f089139-684f-4838-9993-65dbd59a8371@github.com>
 <1vOUZxwl6PF8LZ1rVfQzV5JBLcHMyAGcZeb2O7uOakc=.bfa5b226-9a82-4570-bb7e-5da7f83b9b76@github.com>
 <v37P4VnYEG7tjWprSVfVSxsEHjuyONHd78SLTqQuUPk=.265acb5a-8af2-4c50-93f1-aa51c6cd6492@github.com>
 <aWJXXysUvxOa1rZwwTXJyB7GsTgM0u3LMgx09L4An98=.2878219f-17e4-44c8-a8be-ae7d6f503049@github.com>
 <cquAvWOdIpBf1F7j7AjbP26tubENcuLyjLb43JxQZDs=.6320f764-d74c-443e-b471-704d2d2a84d4@github.com>
 <trTnJzE3OICbH_gncF51napwgZHJmnOnr2N
 O-h8CYeQ=.82975bf9-39bf-49dc-9c89-2ca26ac877a7@github.com>
 <FBQJapVBqb8vXfA4urwrzyWD_v3u_MZgPuWFThvtPZA=.ad52b119-4886-49a7-a719-e4a72cbd3fe4@github.com>
 <-macGNEx5F-Izx0Jm_JsB5BDC7GjQmSAzK74ifM2Q8s=.1060e906-15ec-4863-a1b5-d34cc0c870fd@github.com>
 <sjnE_EJ6xSEQKcSG0xKgJmr4TbeCc2UhaGgMtg1jb1U=.cf933a21-39e7-4075-94d9-76049ced6530@github.com>
 <SP01751cijVMhFtRh1zkURHd_ld3cjo9CWSsTx0ATUA=.a3db1bb0-ad21-47f4-82f0-6e4ca2501c18@github.com>
 <l3SjOm7pYpLuIH9-1Nx2IG_Z8VIQhgbhQ0dKl5b-Fqw=.ee7bbb40-1025-4641-a8e1-eec0a663297c@github.com>
Message-ID: <NzIoEZSivzfIciAAp_KqtGGhu6xq-W2tPPoT3FfZWV0=.ddb0a5b7-13d2-4b15-8d50-4207fc183809@github.com>

On Thu, 22 Sep 2022 18:10:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I have added commit that replaces the `RawAccess` with `HeapAccess<AS_NO_KEEPALIVE>`. I think its better not to avoid the check `if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj))` by using `ON_PHANTOM_OOP_REF` decorator as it relies on the assumption that weak oops in the VM are similar to phantomly reachable references (which is true and may remain so, but is not as explicit as the condition itself). I have therefore kept the check for `is_concurrent_weak_root_in_progress` as it is.
>
> It might be simpler to only change the one line in these object iterators:
> 
> obj = ShenandoahBarrierSet::resolve_forwarded_not_null(obj); 
> 
> to
> 
> obj = ShenandoahBarrierSet::load_reference_barrier(obj); 
> 
> This will evacuate objects in the cset after checking for unmarked concurrent weak roots. `resolve_forwarded_not_null` presumes the object has already been evacuated, but that may not be the case here.

I missed the fact that the object referred by week root would have already been evacuated by the time we hit `is_concurrent_weak_root_in_progress` condition.
 I think it makes sense to just call `ShenandoahBarrierSet::load_reference_barrier` directly. Thanks for pointing that out.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 21:36:10 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 21:36:10 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
Message-ID: <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>

> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
> 
> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
> 
> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
> 
> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
> 
> But it looks like it is missing another important condition - the GC should be in marking phase.
> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
> So the correct assertion should be:
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
> 
> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> 
> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
> 
> Tested it by running following tests in fastdebug mode:
> 
> - hotspot_gc_shenandoah
> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Use lrb directly instead of using HeapAccess to avoid evacuating doomed
  objects referred by weak roots.
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10268/files
  - new: https://git.openjdk.org/jdk/pull/10268/files/ee36ab82..a4d6fd84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10268&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10268&range=01-02

  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10268.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10268/head:pull/10268

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 21:36:11 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 21:36:11 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <1S75IpusKZtrnvLSUQ1BZNGNXTz6k3JLhTYD0joCJWg=.9b76da3e-9f25-4d3c-b077-faaf31bd3209@github.com>
Message-ID: <0mNvAY5ozonj57tn-P6YtaxbmLr1EHzxgs2RVpLoAZw=.6e8202de-f410-42c5-8deb-43dd13e1676d@github.com>

On Wed, 14 Sep 2022 19:51:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>>   objects referred by weak roots.
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Please help me understand why `VM_ThreadDump` would be modifying oops?

@earthling-amzn as you suggested I have added another commit to call `load_reference_barrier` directly instead of using `HeapAccess`. That seems to be the safest approach to effect evacuation without meddling with other conditions.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 21:36:13 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 21:36:13 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v2]
In-Reply-To: <BO16HqHqWRvuK22EH1hp8T7TYTpoxuQIPk0jKcDNcmY=.e9b6ed3b-b1b9-475d-a8da-da09c11bbfc4@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <amweTUGQ_-i3fP68RU4oAkKRt4uo9QWOtSjxLT3nD4Q=.f5b555e8-07d4-44e3-88e5-7e4f4e5ea3c9@github.com>
 <BO16HqHqWRvuK22EH1hp8T7TYTpoxuQIPk0jKcDNcmY=.e9b6ed3b-b1b9-475d-a8da-da09c11bbfc4@github.com>
Message-ID: <ODLyw82-F7nPleevMassmskFOuUXmn4vI3PGpbJO4wA=.39b55683-ee56-46b3-9fc1-a8697b08c632@github.com>

On Thu, 22 Sep 2022 16:39:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use HeapAccess instead of RawAccess when iterating the heap objects
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Make oop_store_common() as private method and remove extraneous condition
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1340:
> 
>> 1338:   template <class T>
>> 1339:   void do_oop_work(T* p) {
>> 1340:     oop obj = HeapAccess<AS_NO_KEEPALIVE>::oop_load(p);
> 
> After taking a closer look at the LRB code, I think we should `or` in `ON_WEAK_OOP_REF` to the access decorators. With only the `AS_NO_KEEPALIVE` decorator, the LRB will fall through all the cases here and end up evacuating a doomed weak referent (i.e., keeping the object alive). 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L119
> 
> I'm worried that this access here could defeat the logic which is meant to keep weak references from being resurrected. It also looks like if we add in the `ON_WEAK_OOP_REF` decorator, the LRB will handle this case for the object iterator too:
> 
> if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj)) {
>         // There may be dead oops in weak roots in concurrent root phase, do not touch them.
>         return;
> }

I missed the fact that the object referred by week root would have already been evacuated by the time we hit is_concurrent_weak_root_in_progress condition.

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

PR: https://git.openjdk.org/jdk/pull/10268

From wkemper at openjdk.org  Thu Sep 22 22:03:25 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Sep 2022 22:03:25 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
Message-ID: <7oJKc8-cC5usNUBItYSj8sfiE2rJ3rQBrBmh56vPNXw=.d28208a3-eee3-46b5-8d5e-254f0238e0e3@github.com>

On Thu, 22 Sep 2022 21:36:10 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
>> 
>> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
>> 
>> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
>> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
>> 
>> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
>> 
>> But it looks like it is missing another important condition - the GC should be in marking phase.
>> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
>> So the correct assertion should be:
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
>> 
>> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> 
>> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
>> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
>> 
>> Tested it by running following tests in fastdebug mode:
>> 
>> - hotspot_gc_shenandoah
>> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>   objects referred by weak roots.
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

This looks good to me. Thank you for working through it with me!

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

Marked as reviewed by wkemper (no project role).

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Thu Sep 22 22:11:25 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Sep 2022 22:11:25 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <7oJKc8-cC5usNUBItYSj8sfiE2rJ3rQBrBmh56vPNXw=.d28208a3-eee3-46b5-8d5e-254f0238e0e3@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
 <7oJKc8-cC5usNUBItYSj8sfiE2rJ3rQBrBmh56vPNXw=.d28208a3-eee3-46b5-8d5e-254f0238e0e3@github.com>
Message-ID: <-FmkgEQV5HpR71AnD5HukWylZVfTKoF300JwRdvIYws=.c1e912f7-cdf0-4c41-af5f-d154bd6e8287@github.com>

On Thu, 22 Sep 2022 22:01:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>>   objects referred by weak roots.
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> This looks good to me. Thank you for working through it with me!

@earthling-amzn thank you for reviewing it and guiding the code changes.

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

PR: https://git.openjdk.org/jdk/pull/10268

From rkennke at openjdk.org  Fri Sep 23 15:31:07 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 23 Sep 2022 15:31:07 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
Message-ID: <x0jgzI_PZosZIDYGwrFMXjshHlwwxzqQo8OZK0OfXj8=.9bf508d6-a44c-4060-a401-8f794fb82601@github.com>

On Thu, 22 Sep 2022 21:36:10 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
>> 
>> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
>> 
>> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
>> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
>> 
>> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
>> 
>> But it looks like it is missing another important condition - the GC should be in marking phase.
>> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
>> So the correct assertion should be:
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
>> 
>> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> 
>> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
>> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
>> 
>> Tested it by running following tests in fastdebug mode:
>> 
>> - hotspot_gc_shenandoah
>> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>   objects referred by weak roots.
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Looks good to me, too. Thanks, Ashu!

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10268

From andrew at openjdk.org  Fri Sep 23 15:44:39 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 15:44:39 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u332-b01 for changeset
 ab90ea6d
Message-ID: <f4548695-9f3d-459b-86d1-460fcff5bec9@openjdk.org>

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


Changeset: ab90ea6d
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-02-01 19:54:57 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/ab90ea6dfeacebe04a5e94177c7e70da8f0f2fc1


From andrew at openjdk.org  Fri Sep 23 15:44:53 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 15:44:53 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 8294292: Adjust Shenandoah
 regular expression for tags to allow "shenandoah8u<x>-b<y>"
Message-ID: <2d95aad3-f8f2-4ea3-9cce-d13fbee24ae3@openjdk.org>

Changeset: aca7e004
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 16:34:49 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/aca7e0043218628a00af9b074fd84b0f3a54ced7

8294292: Adjust Shenandoah regular expression for tags to allow "shenandoah8u<x>-b<y>"

Reviewed-by: rkennke

! .jcheck/conf


From heidinga at openjdk.org  Fri Sep 23 15:49:15 2022
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 23 Sep 2022 15:49:15 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
Message-ID: <VFAH9OFUqy1Apv9OT8a4K7CnhqipXmm8sGuNOhnZ8ss=.f5c6ff8c-5f6a-484b-9bcf-627966795c71@github.com>

On Thu, 22 Sep 2022 21:36:10 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
>> 
>> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
>> 
>> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
>> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
>> 
>> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
>> 
>> But it looks like it is missing another important condition - the GC should be in marking phase.
>> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
>> So the correct assertion should be:
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
>> 
>> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> 
>> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
>> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
>> 
>> Tested it by running following tests in fastdebug mode:
>> 
>> - hotspot_gc_shenandoah
>> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>   objects referred by weak roots.
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by heidinga (no project role).

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Fri Sep 23 15:49:16 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 23 Sep 2022 15:49:16 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <x0jgzI_PZosZIDYGwrFMXjshHlwwxzqQo8OZK0OfXj8=.9bf508d6-a44c-4060-a401-8f794fb82601@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
 <x0jgzI_PZosZIDYGwrFMXjshHlwwxzqQo8OZK0OfXj8=.9bf508d6-a44c-4060-a401-8f794fb82601@github.com>
Message-ID: <iCZgYNZjAy-AVDxTz2wn3Aw2CeoNo2rZp3Ha6zcV0aY=.98725b95-a787-4b73-854d-2e0d4c579b36@github.com>

On Fri, 23 Sep 2022 15:28:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>>   objects referred by weak roots.
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Looks good to me, too. Thanks, Ashu!

@rkennke thank you for reviewing it.

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Fri Sep 23 15:49:18 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 23 Sep 2022 15:49:18 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <WlaLBOo9Q9fViWQQm9LJDoT0mvxfZQDNgmBWEnf0uYQ=.4e47bf32-a217-4323-8829-c8cea17f43ef@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <WlaLBOo9Q9fViWQQm9LJDoT0mvxfZQDNgmBWEnf0uYQ=.4e47bf32-a217-4323-8829-c8cea17f43ef@github.com>
Message-ID: <WRD-uW3L_IJWD0kxW3Sb85RwuRd6uDWUryuwoUqtwa4=.8fc6d7fd-ffa5-4058-95ce-e6722f863ef8@github.com>

On Wed, 14 Sep 2022 18:55:55 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>>   objects referred by weak roots.
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 179:
> 
>> 177: 
>> 178:     template <typename T>
>> 179:     static void oop_store_common(T* addr, oop value);
> 
> This is an implementation detail and a public part of the barrier set. We wouldn't expect users - other than the two existing callers - to ever use this api.
> 
> Can it be refactored out of this header and kept entirely within shenandoahBarrierSet.inline.hpp?

@DanHeidinga are you okay with the updates?

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

PR: https://git.openjdk.org/jdk/pull/10268

From heidinga at openjdk.org  Fri Sep 23 15:49:18 2022
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 23 Sep 2022 15:49:18 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <WRD-uW3L_IJWD0kxW3Sb85RwuRd6uDWUryuwoUqtwa4=.8fc6d7fd-ffa5-4058-95ce-e6722f863ef8@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <WlaLBOo9Q9fViWQQm9LJDoT0mvxfZQDNgmBWEnf0uYQ=.4e47bf32-a217-4323-8829-c8cea17f43ef@github.com>
 <WRD-uW3L_IJWD0kxW3Sb85RwuRd6uDWUryuwoUqtwa4=.8fc6d7fd-ffa5-4058-95ce-e6722f863ef8@github.com>
Message-ID: <cS13sx_HbXjSVm5kkN5UfQCHo-DtrISyNST3WkzBeF0=.00e1f6bc-a029-4f05-92a7-c1a9115ac99e@github.com>

On Fri, 23 Sep 2022 15:43:22 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 179:
>> 
>>> 177: 
>>> 178:     template <typename T>
>>> 179:     static void oop_store_common(T* addr, oop value);
>> 
>> This is an implementation detail and a public part of the barrier set. We wouldn't expect users - other than the two existing callers - to ever use this api.
>> 
>> Can it be refactored out of this header and kept entirely within shenandoahBarrierSet.inline.hpp?
>
> @DanHeidinga are you okay with the updates?

Looks good to me

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

PR: https://git.openjdk.org/jdk/pull/10268

From andrew at openjdk.org  Fri Sep 23 16:19:17 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 16:19:17 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u322-b04 for
 changeset d475f9eb
Message-ID: <36c6fdd0-5e17-4ae0-8565-5cd4764965dc@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 17:12:02 +0000

Added tag shenandoah8u322-b04 for changeset d475f9eb9bb
Changeset: d475f9eb
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:01 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d475f9eb9bbb9e91db6473679f7334dd8372c8f9


From andrew at openjdk.org  Fri Sep 23 16:19:20 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 16:19:20 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u322-b05 for
 changeset ac89ca95
Message-ID: <7b88dffa-5ab6-44b0-a272-8392f0d8f68e@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 17:13:56 +0000

Added tag shenandoah8u322-b05 for changeset ac89ca956d8
Changeset: ac89ca95
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:50:41 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/ac89ca956d86edd2fbe1952ee9e2ee5db9861899


From andrew at openjdk.org  Fri Sep 23 16:19:26 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 16:19:26 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u322-b06 for
 changeset d56198b0
Message-ID: <584e5015-0902-4b46-8ee6-dc779c609904@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 17:14:01 +0000

Added tag shenandoah8u322-b06 for changeset d56198b0d6f
Changeset: d56198b0
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:28 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d56198b0d6f27c09b878c2c52eadc33ab872607d


From andrew at openjdk.org  Fri Sep 23 16:19:31 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 16:19:31 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u332-b00 for
 changeset d56198b0
Message-ID: <1ae6d68c-9950-4a5f-8742-b6b37233387a@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 17:14:13 +0000

Added tag shenandoah8u332-b00 for changeset d56198b0d6f
Changeset: d56198b0
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-01-20 15:51:28 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d56198b0d6f27c09b878c2c52eadc33ab872607d


From andrew at openjdk.org  Fri Sep 23 16:19:36 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 23 Sep 2022 16:19:36 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u332-b01 for
 changeset aca7e004
Message-ID: <eb6f1ced-ce26-4893-850f-757aa6ee384c@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 17:08:15 +0000

Added tag shenandoah8u332-b01 for changeset aca7e004321
Changeset: aca7e004
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-23 16:34:49 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/aca7e0043218628a00af9b074fd84b0f3a54ced7


From duke at openjdk.org  Fri Sep 23 18:40:18 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 23 Sep 2022 18:40:18 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <x0jgzI_PZosZIDYGwrFMXjshHlwwxzqQo8OZK0OfXj8=.9bf508d6-a44c-4060-a401-8f794fb82601@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
 <x0jgzI_PZosZIDYGwrFMXjshHlwwxzqQo8OZK0OfXj8=.9bf508d6-a44c-4060-a401-8f794fb82601@github.com>
Message-ID: <rGdmeCdauoE8MuXij2K_OB4CLmTTyfoCo7FRwQtfIVI=.1be712c9-38bc-4cd7-80a0-321afd33c0ee@github.com>

On Fri, 23 Sep 2022 15:28:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>>   objects referred by weak roots.
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Looks good to me, too. Thanks, Ashu!

@rkennke can you please sponsor it as well?

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

PR: https://git.openjdk.org/jdk/pull/10268

From phh at openjdk.org  Fri Sep 23 18:47:22 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 23 Sep 2022 18:47:22 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
Message-ID: <bqsHO6dYCrRqJjY2hZl38Uc8dQ9fJfm24MwGG9TeKDM=.9a430e31-0019-4317-b3e7-b9de1c33d479@github.com>

On Thu, 22 Sep 2022 21:36:10 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
>> 
>> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
>> 
>> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
>> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
>> 
>> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
>> 
>> But it looks like it is missing another important condition - the GC should be in marking phase.
>> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
>> So the correct assertion should be:
>> 
>> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
>> 
>> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
>> 
>> 
>> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
>> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
>> 
>> Tested it by running following tests in fastdebug mode:
>> 
>> - hotspot_gc_shenandoah
>> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>   objects referred by weak roots.
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Lgtm. I'll sponsor.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Fri Sep 23 18:58:22 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 23 Sep 2022 18:58:22 GMT
Subject: Integrated: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics
In-Reply-To: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
Message-ID: <I8Z6sQqOEzCpwGi3YIQB0V3ZvwNHecU2rqmqnzycgAg=.89ab7258-221c-4d50-a8c5-b77d1e9b2009@github.com>

On Wed, 14 Sep 2022 16:04:03 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.
> 
> Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.
> 
> At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
> Assertion happened when the VMThread performs `NativeAccess<>::oop_store()` (as part of creating an `OopHandle`) on an object which has been marked and is in the collection set. But the failing assertion in `oop_store_not_in_heap()` expects the oop is not in the collection set.
> 
> The assertion is conditional on the statement `value != NULL && !ShenandoahHeap::heap()->cancelled_gc()`
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
> 
> But it looks like it is missing another important condition - the GC should be in marking phase.
> i.e. the assertion is valid only if it is protected by `ShenandoahHeap::heap()->is_concurrent_mark_in_progress()`.
> So the correct assertion should be:
> 
> 	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:
> 
> 	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());
> 
> 
> Also, it reads strange that `oop_store_in_heap()` would call `oop_store_not_in_heap()`.
> So I have moved the code to a separate method `oop_store_common()` that gets called by both `oop_store_in_heap()` and `oop_store_not_in_heap()`.
> 
> Tested it by running following tests in fastdebug mode:
> 
> - hotspot_gc_shenandoah
> - java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> - java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

This pull request has now been integrated.

Changeset: 3675f4c2
Author:    Ashutosh Mehra <asmehra at redhat.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3675f4c2afd10b5042948fc79e62caee5f3874ce
Stats:     16 lines in 3 files changed: 10 ins; 2 del; 4 mod

8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics

Reviewed-by: wkemper, rkennke, heidinga, phh

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

PR: https://git.openjdk.org/jdk/pull/10268

From duke at openjdk.org  Fri Sep 23 19:03:28 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 23 Sep 2022 19:03:28 GMT
Subject: RFR: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash
 with aggressive heuristics [v3]
In-Reply-To: <bqsHO6dYCrRqJjY2hZl38Uc8dQ9fJfm24MwGG9TeKDM=.9a430e31-0019-4317-b3e7-b9de1c33d479@github.com>
References: <_dV3ETjjJz7YF8NIg20873ePo_R4xtN3OAwf1VH5o_w=.7169f2e2-df45-4078-aeba-ee7ada6c911b@github.com>
 <rNrjCSULmgUS4b0p5AceUNpzWUUb1weSt4vpltumVNE=.c62e3640-8677-4e1d-82bf-ddb1615918d7@github.com>
 <bqsHO6dYCrRqJjY2hZl38Uc8dQ9fJfm24MwGG9TeKDM=.9a430e31-0019-4317-b3e7-b9de1c33d479@github.com>
Message-ID: <V8hOLMBm-rMZ1z1FoD9tXa4C_kq28bYtxajT_1ZRoSQ=.4fe9857e-40a8-4802-9376-296b0b1e35d1@github.com>

On Fri, 23 Sep 2022 18:45:11 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lrb directly instead of using HeapAccess to avoid evacuating doomed
>>   objects referred by weak roots.
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Lgtm. I'll sponsor.

@phohensee thank you!

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

PR: https://git.openjdk.org/jdk/pull/10268

From shade at openjdk.org  Tue Sep 27 12:28:49 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 Sep 2022 12:28:49 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
Message-ID: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>

There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.

C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.

Build-tested this with product of:
  - GCC 10
  - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
  - {server, zero}
  - {release, fastdebug}

Linux x86_64 fastdebug `tier1` is fine.

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

Commit messages:
 - Also javaClasses.cpp
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10444/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294438
  Stats: 44 lines in 5 files changed: 7 ins; 6 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/10444.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10444/head:pull/10444

PR: https://git.openjdk.org/jdk/pull/10444

From ihse at openjdk.org  Tue Sep 27 12:28:50 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Sep 2022 12:28:50 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <G3jrSR10NdHldEqtNL88YLoDMoaCP-nZXk21AgmNVtk=.bd6478c7-7112-4df7-8d1b-f16858137428@github.com>

On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

So enabling the warning actually exposed a bug? That's always nice to see, and a good argument for keeping up with the hygiene work of minimizing the amount of disabled warnings.

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

PR: https://git.openjdk.org/jdk/pull/10444

From shade at openjdk.org  Tue Sep 27 12:28:50 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 27 Sep 2022 12:28:50 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <G3jrSR10NdHldEqtNL88YLoDMoaCP-nZXk21AgmNVtk=.bd6478c7-7112-4df7-8d1b-f16858137428@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <G3jrSR10NdHldEqtNL88YLoDMoaCP-nZXk21AgmNVtk=.bd6478c7-7112-4df7-8d1b-f16858137428@github.com>
Message-ID: <antnXDpCa1uLb3wVxpy039APIUrJC_Bs8L5Tbqsy8JY=.896427ad-54c8-4a95-b065-8c04c7429090@github.com>

On Tue, 27 Sep 2022 11:02:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So enabling the warning actually exposed a bug? That's always nice to see, and a good argument for keeping up with the hygiene work of minimizing the amount of disabled warnings.

Yes. It is hard to judge how innocuous that bug really is, because (handwaves) compilers.

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

PR: https://git.openjdk.org/jdk/pull/10444

From ihse at openjdk.org  Tue Sep 27 14:36:43 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Sep 2022 14:36:43 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <jZqhQdY92Oju4XdKNGemqab0s_wjR4FbtG0ZxNltUn4=.8eb03eb1-66cb-4bc2-9147-7b3d11294ca0@github.com>

On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

The build part of this PR is OK

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10444

From dholmes at openjdk.org  Wed Sep 28 02:12:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 02:12:20 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <RKzQzwuRBtHcaLmQFGExJ79ftNlLW5eJ4dHVARV14dY=.f34f7891-d3fe-4f4c-9a1b-6e77b5954b18@github.com>

On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

Changes look good!

That C1 code is very strangely written!

Thanks

src/hotspot/share/classfile/javaClasses.cpp line 3926:

> 3924:   if (k == NULL)  return NULL;
> 3925:   InstanceKlass* ik = InstanceKlass::cast(k);
> 3926:   if (!ik->is_initialized())  ik->initialize(CHECK_NULL);

That's actually a bug!

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10444

From shade at openjdk.org  Wed Sep 28 06:04:19 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Sep 2022 06:04:19 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <RKzQzwuRBtHcaLmQFGExJ79ftNlLW5eJ4dHVARV14dY=.f34f7891-d3fe-4f4c-9a1b-6e77b5954b18@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <RKzQzwuRBtHcaLmQFGExJ79ftNlLW5eJ4dHVARV14dY=.f34f7891-d3fe-4f4c-9a1b-6e77b5954b18@github.com>
Message-ID: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com>

On Wed, 28 Sep 2022 02:06:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
>> 
>> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
>> 
>> Build-tested this with product of:
>>   - GCC 10
>>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>>   - {server, zero}
>>   - {release, fastdebug}
>> 
>> Linux x86_64 fastdebug `tier1` is fine.
>
> src/hotspot/share/classfile/javaClasses.cpp line 3926:
> 
>> 3924:   if (k == NULL)  return NULL;
>> 3925:   InstanceKlass* ik = InstanceKlass::cast(k);
>> 3926:   if (!ik->is_initialized())  ik->initialize(CHECK_NULL);
> 
> That's actually a bug!

How is this a bu... ah. Oh! The second statement from `CHECK_NULL` is effectively out of `if (!ik->is_initialized())` block!

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

PR: https://git.openjdk.org/jdk/pull/10444

From xlinzheng at openjdk.org  Wed Sep 28 06:37:06 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 06:37:06 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites
Message-ID: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>

A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.

This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.

Originally some non-patchable callsites:

;; 0x401ab1dc40
0x000000401372b324:   lui	t0,0x201
0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
0x000000401372b32c:   slli	t0,t0,0xb
0x000000401372b32e:   addi	t0,t0,1905
0x000000401372b332:   slli	t0,t0,0x6
0x000000401372b334:   jalr	t0

Now:

0x000000401b2bd9f4:   lui	t0,0x4003
0x000000401b2bd9f8:   addiw	t0,t0,-1275
0x000000401b2bd9fc:   slli	t0,t0,0xc
0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438

Not so much, but the main purpose is to clarify the usage of movptr and li.

The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.

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

Commit messages:
 - Further
 - Further cleanup
 - Change Non-patchable movptr to li, for movptr is defined implicitly for patchable usages

Changes: https://git.openjdk.org/jdk/pull/10462/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294492
  Stats: 75 lines in 8 files changed: 29 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/10462.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 06:58:15 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 06:58:15 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v2]
In-Reply-To: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
Message-ID: <it05wzeUyF2-340oA3qNvLof0z2x1WC7A-hKQmQvJXw=.50fe7640-40a5-437f-af90-f8c06d2174d6@github.com>

> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
> 
> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
> 
> Originally some non-patchable callsites:
> 
> ;; 0x401ab1dc40
> 0x000000401372b324:   lui	t0,0x201
> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
> 0x000000401372b32c:   slli	t0,t0,0xb
> 0x000000401372b32e:   addi	t0,t0,1905
> 0x000000401372b332:   slli	t0,t0,0x6
> 0x000000401372b334:   jalr	t0
> 
> Now:
> 
> 0x000000401b2bd9f4:   lui	t0,0x4003
> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
> 0x000000401b2bd9fc:   slli	t0,t0,0xc
> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
> 
> Not so much, but the main purpose is to clarify the usage of movptr and li.
> 
> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10462/files
  - new: https://git.openjdk.org/jdk/pull/10462/files/62cf62ca..ad15d6b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10462.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462

PR: https://git.openjdk.org/jdk/pull/10462

From ihse at openjdk.org  Wed Sep 28 08:03:21 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Sep 2022 08:03:21 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <RKzQzwuRBtHcaLmQFGExJ79ftNlLW5eJ4dHVARV14dY=.f34f7891-d3fe-4f4c-9a1b-6e77b5954b18@github.com>
 <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com>
Message-ID: <YQ8iEKEcwYcVeLgHaq978zVUH5uMfSv_s6cOlLzYnDA=.0079c5f7-c725-4898-b4a6-b407f7f103e2@github.com>

On Wed, 28 Sep 2022 06:00:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 3926:
>> 
>>> 3924:   if (k == NULL)  return NULL;
>>> 3925:   InstanceKlass* ik = InstanceKlass::cast(k);
>>> 3926:   if (!ik->is_initialized())  ik->initialize(CHECK_NULL);
>> 
>> That's actually a bug!
>
> How is this a bu... ah. Oh! The second statement from `CHECK_NULL` is effectively out of `if (!ik->is_initialized())` block!

Two, and counting. :-)

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

PR: https://git.openjdk.org/jdk/pull/10444

From dholmes at openjdk.org  Wed Sep 28 08:52:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 08:52:42 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <YQ8iEKEcwYcVeLgHaq978zVUH5uMfSv_s6cOlLzYnDA=.0079c5f7-c725-4898-b4a6-b407f7f103e2@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <RKzQzwuRBtHcaLmQFGExJ79ftNlLW5eJ4dHVARV14dY=.f34f7891-d3fe-4f4c-9a1b-6e77b5954b18@github.com>
 <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com>
 <YQ8iEKEcwYcVeLgHaq978zVUH5uMfSv_s6cOlLzYnDA=.0079c5f7-c725-4898-b4a6-b407f7f103e2@github.com>
Message-ID: <J9j5hxpmWevMSpftbMQkiMulxVZoHWHMm6fD8iAtqX8=.893fde08-524c-46e3-8cfa-608f6a9ed5f9@github.com>

On Wed, 28 Sep 2022 07:59:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> How is this a bu... ah. Oh! The second statement from `CHECK_NULL` is effectively out of `if (!ik->is_initialized())` block!
>
> Two, and counting. :-)

Yep another CHECK macro gotcha!

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

PR: https://git.openjdk.org/jdk/pull/10444

From dholmes at openjdk.org  Wed Sep 28 08:52:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Sep 2022 08:52:42 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <J9j5hxpmWevMSpftbMQkiMulxVZoHWHMm6fD8iAtqX8=.893fde08-524c-46e3-8cfa-608f6a9ed5f9@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
 <RKzQzwuRBtHcaLmQFGExJ79ftNlLW5eJ4dHVARV14dY=.f34f7891-d3fe-4f4c-9a1b-6e77b5954b18@github.com>
 <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com>
 <YQ8iEKEcwYcVeLgHaq978zVUH5uMfSv_s6cOlLzYnDA=.0079c5f7-c725-4898-b4a6-b407f7f103e2@github.com>
 <J9j5hxpmWevMSpftbMQkiMulxVZoHWHMm6fD8iAtqX8=.893fde08-524c-46e3-8cfa-608f6a9ed5f9@github.com>
Message-ID: <9l11mgsBpRrdHBND5x1HYGExEGWA_oJ0TQk_sRgFgLw=.0a1bb878-21ec-4d80-9192-6ead602b433d@github.com>

On Wed, 28 Sep 2022 08:47:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Two, and counting. :-)
>
> Yep another CHECK macro gotcha!

Harmless in this case as no pre-existing exception should be pending.

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

PR: https://git.openjdk.org/jdk/pull/10444

From fyang at openjdk.org  Wed Sep 28 09:18:35 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 28 Sep 2022 09:18:35 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v2]
In-Reply-To: <it05wzeUyF2-340oA3qNvLof0z2x1WC7A-hKQmQvJXw=.50fe7640-40a5-437f-af90-f8c06d2174d6@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <it05wzeUyF2-340oA3qNvLof0z2x1WC7A-hKQmQvJXw=.50fe7640-40a5-437f-af90-f8c06d2174d6@github.com>
Message-ID: <XG2CexVJY0DaSs2Aj5i52lhUFbeRapS482U-lwU343g=.9b353060-f0a0-4551-ad83-8705419d651c@github.com>

On Wed, 28 Sep 2022 06:58:15 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
>> 
>> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
>> 
>> Originally some non-patchable callsites:
>> 
>> ;; 0x401ab1dc40
>> 0x000000401372b324:   lui	t0,0x201
>> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
>> 0x000000401372b32c:   slli	t0,t0,0xb
>> 0x000000401372b32e:   addi	t0,t0,1905
>> 0x000000401372b332:   slli	t0,t0,0x6
>> 0x000000401372b334:   jalr	t0
>> 
>> Now:
>> 
>> 0x000000401b2bd9f4:   lui	t0,0x4003
>> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
>> 0x000000401b2bd9fc:   slli	t0,t0,0xc
>> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
>> 
>> Not so much, but the main purpose is to clarify the usage of movptr and li.
>> 
>> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix

I have several comments.

src/hotspot/cpu/riscv/assembler_riscv.cpp line 119:

> 117: }
> 118: 
> 119: void Assembler::li(Register Rd, int64_t imm, int32_t &offset) {

It looks to me that we don't need to introduce another 'li' function here. I think you can mask out the lower 12bits of the address and move the result to register with existing 'mv' function. And keep the lower 12bits in offset at the same time. This could be implemented in your new 'mv' function.

src/hotspot/cpu/riscv/assembler_riscv.cpp line 228:

> 226:   }
> 227: 
> 228:   INSN(call, x1);

Better to move functions like 'ret' and 'call' to macroAssembler_riscv.hpp

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 567:

> 565:                                        Label *retaddr) {
> 566:   push_reg(RegSet::of(t0, xmethod), sp);   // push << t0 & xmethod >> to sp
> 567:   call(entry_point, t0);

Looks like we could use the default temp register 't0' for all use of 'call'.

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

Changes requested by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 11:09:42 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 11:09:42 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v3]
In-Reply-To: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
Message-ID: <afl2VSB4U1CnB-zzIhwOTNe2UeWiv_WPuYlWajjPRSs=.56e42c2f-88a0-40bf-8e4c-0a9e9e961a9e@github.com>

> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
> 
> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
> 
> Originally some non-patchable callsites:
> 
> ;; 0x401ab1dc40
> 0x000000401372b324:   lui	t0,0x201
> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
> 0x000000401372b32c:   slli	t0,t0,0xb
> 0x000000401372b32e:   addi	t0,t0,1905
> 0x000000401372b332:   slli	t0,t0,0x6
> 0x000000401372b334:   jalr	t0
> 
> Now:
> 
> 0x000000401b2bd9f4:   lui	t0,0x4003
> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
> 0x000000401b2bd9fc:   slli	t0,t0,0xc
> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
> 
> Not so much, but the main purpose is to clarify the usage of movptr and li.
> 
> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Fix as to comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10462/files
  - new: https://git.openjdk.org/jdk/pull/10462/files/ad15d6b2..4985dcf4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=01-02

  Stats: 89 lines in 7 files changed: 16 ins; 57 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/10462.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 11:09:43 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 11:09:43 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v2]
In-Reply-To: <XG2CexVJY0DaSs2Aj5i52lhUFbeRapS482U-lwU343g=.9b353060-f0a0-4551-ad83-8705419d651c@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <it05wzeUyF2-340oA3qNvLof0z2x1WC7A-hKQmQvJXw=.50fe7640-40a5-437f-af90-f8c06d2174d6@github.com>
 <XG2CexVJY0DaSs2Aj5i52lhUFbeRapS482U-lwU343g=.9b353060-f0a0-4551-ad83-8705419d651c@github.com>
Message-ID: <jNJO1F47FruYzgkoq1VQoNzmuMaivhRxpkWy7UGlN-E=.c3eeb92c-16ed-4e37-a3b1-c4bce0056807@github.com>

On Wed, 28 Sep 2022 09:09:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix
>
> src/hotspot/cpu/riscv/assembler_riscv.cpp line 119:
> 
>> 117: }
>> 118: 
>> 119: void Assembler::li(Register Rd, int64_t imm, int32_t &offset) {
> 
> It looks to me that we don't need to introduce another 'li' function here. I think you can mask out the lower 12bits of the address and move the result to register with existing 'mv' function. And keep the lower 12bits in offset at the same time. This could be implemented in your new 'mv' function.

Thanks for the advice, very reasonable. I have changed that (need further testing). Others all done.

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

PR: https://git.openjdk.org/jdk/pull/10462

From fyang at openjdk.org  Wed Sep 28 11:43:35 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 28 Sep 2022 11:43:35 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v3]
In-Reply-To: <afl2VSB4U1CnB-zzIhwOTNe2UeWiv_WPuYlWajjPRSs=.56e42c2f-88a0-40bf-8e4c-0a9e9e961a9e@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <afl2VSB4U1CnB-zzIhwOTNe2UeWiv_WPuYlWajjPRSs=.56e42c2f-88a0-40bf-8e4c-0a9e9e961a9e@github.com>
Message-ID: <v4-g3qVD8dTj2pI7h7XTj8SgVKxqbjfnUPML5gHEdzM=.7c5c8683-6294-48b8-9a15-fc4a4e2bd9af@github.com>

On Wed, 28 Sep 2022 11:09:42 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
>> 
>> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
>> 
>> Originally some non-patchable callsites:
>> 
>> ;; 0x401ab1dc40
>> 0x000000401372b324:   lui	t0,0x201
>> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
>> 0x000000401372b32c:   slli	t0,t0,0xb
>> 0x000000401372b32e:   addi	t0,t0,1905
>> 0x000000401372b332:   slli	t0,t0,0x6
>> 0x000000401372b334:   jalr	t0
>> 
>> Now:
>> 
>> 0x000000401b2bd9f4:   lui	t0,0x4003
>> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
>> 0x000000401b2bd9fc:   slli	t0,t0,0xc
>> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
>> 
>> Not so much, but the main purpose is to clarify the usage of movptr and li.
>> 
>> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as to comments

Looks better. One extra suggestion.

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 531:

> 529:   // mv
> 530:   void mv(Register Rd, address addr)                  { li(Rd, (int64_t)addr); }
> 531:   void mv(Register Rd, address addr, int32_t &offset) {

We should add necessary comment for this function, like:
"Split address into a lower 12-bit sign-extended offset and the remainder so that the offset could be encoded in jalr or load/store instruction."

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

Changes requested by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 12:35:31 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 12:35:31 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v4]
In-Reply-To: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
Message-ID: <b7TRbsB1m1ykH6onEB6V4Q-6ecR7lkAUyX4CAU4DktU=.bf45e91c-93f0-4f0a-b9f6-152ef7025893@github.com>

> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
> 
> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
> 
> Originally some non-patchable callsites:
> 
> ;; 0x401ab1dc40
> 0x000000401372b324:   lui	t0,0x201
> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
> 0x000000401372b32c:   slli	t0,t0,0xb
> 0x000000401372b32e:   addi	t0,t0,1905
> 0x000000401372b332:   slli	t0,t0,0x6
> 0x000000401372b334:   jalr	t0
> 
> Now:
> 
> 0x000000401b2bd9f4:   lui	t0,0x4003
> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
> 0x000000401b2bd9fc:   slli	t0,t0,0xc
> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
> 
> Not so much, but the main purpose is to clarify the usage of movptr and li.
> 
> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Comments, with one &

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10462/files
  - new: https://git.openjdk.org/jdk/pull/10462/files/4985dcf4..60608a30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 12:35:34 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 12:35:34 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v3]
In-Reply-To: <v4-g3qVD8dTj2pI7h7XTj8SgVKxqbjfnUPML5gHEdzM=.7c5c8683-6294-48b8-9a15-fc4a4e2bd9af@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <afl2VSB4U1CnB-zzIhwOTNe2UeWiv_WPuYlWajjPRSs=.56e42c2f-88a0-40bf-8e4c-0a9e9e961a9e@github.com>
 <v4-g3qVD8dTj2pI7h7XTj8SgVKxqbjfnUPML5gHEdzM=.7c5c8683-6294-48b8-9a15-fc4a4e2bd9af@github.com>
Message-ID: <yzN18vFPSv4LOGcCxBTlhEKp1Y2CktTUWC3pvn69GJM=.3cce23a5-6e1f-49e6-8d3d-584272421803@github.com>

On Wed, 28 Sep 2022 11:37:53 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix as to comments
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 531:
> 
>> 529:   // mv
>> 530:   void mv(Register Rd, address addr)                  { li(Rd, (int64_t)addr); }
>> 531:   void mv(Register Rd, address addr, int32_t &offset) {
> 
> We should add necessary comment for this function, like:
> "Split address into a lower 12-bit sign-extended offset and the remainder so that the offset could be encoded in jalr or load/store instruction."

done - added.

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

PR: https://git.openjdk.org/jdk/pull/10462

From coleenp at openjdk.org  Wed Sep 28 13:00:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Sep 2022 13:00:25 GMT
Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot
In-Reply-To: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
References: <HD7TvGmoIxJ9QqJyf_LVdutwVXEoxRiWseOWQEe-zpo=.b22712aa-15a3-4702-b160-30df20d72cff@github.com>
Message-ID: <ToLLFRGvMxi9xEhAFmuJKHvWi5a2LKq4ta4MGJ0-qEU=.6242fc12-b210-4442-8e2c-4c06d7cf48cd@github.com>

On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good.
> 
> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check.
> 
> Build-tested this with product of:
>   - GCC 10
>   - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64}
>   - {server, zero}
>   - {release, fastdebug}
> 
> Linux x86_64 fastdebug `tier1` is fine.

Nice fix and enabling the warning.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10444

From fyang at openjdk.org  Wed Sep 28 13:25:25 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 28 Sep 2022 13:25:25 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v4]
In-Reply-To: <b7TRbsB1m1ykH6onEB6V4Q-6ecR7lkAUyX4CAU4DktU=.bf45e91c-93f0-4f0a-b9f6-152ef7025893@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <b7TRbsB1m1ykH6onEB6V4Q-6ecR7lkAUyX4CAU4DktU=.bf45e91c-93f0-4f0a-b9f6-152ef7025893@github.com>
Message-ID: <ewT2vao7PUHCB4YTGLFiaT2FvaPyxq0ofZc2UhmX738=.5a5705d2-d0d4-418b-bdad-67b1f3429cc8@github.com>

On Wed, 28 Sep 2022 12:35:31 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
>> 
>> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
>> 
>> Originally some non-patchable callsites:
>> 
>> ;; 0x401ab1dc40
>> 0x000000401372b324:   lui	t0,0x201
>> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
>> 0x000000401372b32c:   slli	t0,t0,0xb
>> 0x000000401372b32e:   addi	t0,t0,1905
>> 0x000000401372b332:   slli	t0,t0,0x6
>> 0x000000401372b334:   jalr	t0
>> 
>> Now:
>> 
>> 0x000000401b2bd9f4:   lui	t0,0x4003
>> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
>> 0x000000401b2bd9fc:   slli	t0,t0,0xc
>> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
>> 
>> Not so much, but the main purpose is to clarify the usage of movptr and li.
>> 
>> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments, with one &

Updated change looks good. Thanks.

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

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10462

From fyang at openjdk.org  Wed Sep 28 13:57:25 2022
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 28 Sep 2022 13:57:25 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v4]
In-Reply-To: <b7TRbsB1m1ykH6onEB6V4Q-6ecR7lkAUyX4CAU4DktU=.bf45e91c-93f0-4f0a-b9f6-152ef7025893@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <b7TRbsB1m1ykH6onEB6V4Q-6ecR7lkAUyX4CAU4DktU=.bf45e91c-93f0-4f0a-b9f6-152ef7025893@github.com>
Message-ID: <QgmjJTykr01UFy5H0_sB7NhJ74ZkkHVdfLF9Qf_vhB8=.2c9f7bf7-716f-4883-bf84-8d87ec3760ec@github.com>

On Wed, 28 Sep 2022 12:35:31 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
>> 
>> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
>> 
>> Originally some non-patchable callsites:
>> 
>> ;; 0x401ab1dc40
>> 0x000000401372b324:   lui	t0,0x201
>> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
>> 0x000000401372b32c:   slli	t0,t0,0xb
>> 0x000000401372b32e:   addi	t0,t0,1905
>> 0x000000401372b332:   slli	t0,t0,0x6
>> 0x000000401372b334:   jalr	t0
>> 
>> Now:
>> 
>> 0x000000401b2bd9f4:   lui	t0,0x4003
>> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
>> 0x000000401b2bd9fc:   slli	t0,t0,0xc
>> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
>> 
>> Not so much, but the main purpose is to clarify the usage of movptr and li.
>> 
>> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments, with one &

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 534:

> 532:     // Split address into a lower 12-bit sign-extended offset and the remainder,
> 533:     // so that the offset could be encoded in jalr or load/store instruction.
> 534:     offset = ((int32_t)(uintptr_t)addr << 20) >> 20;

Would you mind one more tweak here? Considering that the type of 'offset' is int32_t, I think it will be more readable here if we convert 'addr' into int64_t type instead of uintptr_t.

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

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 14:02:57 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 14:02:57 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v5]
In-Reply-To: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
Message-ID: <drqYYtb5irWzSdVcJQkGSkUEE6fG6POkSO_iL2gu8Wk=.d4b5fdb4-c576-445d-a2fd-1b9681dd8fbe@github.com>

> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
> 
> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
> 
> Originally some non-patchable callsites:
> 
> ;; 0x401ab1dc40
> 0x000000401372b324:   lui	t0,0x201
> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
> 0x000000401372b32c:   slli	t0,t0,0xb
> 0x000000401372b32e:   addi	t0,t0,1905
> 0x000000401372b332:   slli	t0,t0,0x6
> 0x000000401372b334:   jalr	t0
> 
> Now:
> 
> 0x000000401b2bd9f4:   lui	t0,0x4003
> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
> 0x000000401b2bd9fc:   slli	t0,t0,0xc
> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
> 
> Not so much, but the main purpose is to clarify the usage of movptr and li.
> 
> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Canonicalize signed extensions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10462/files
  - new: https://git.openjdk.org/jdk/pull/10462/files/60608a30..fe56ee07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Wed Sep 28 14:02:58 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Wed, 28 Sep 2022 14:02:58 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v4]
In-Reply-To: <QgmjJTykr01UFy5H0_sB7NhJ74ZkkHVdfLF9Qf_vhB8=.2c9f7bf7-716f-4883-bf84-8d87ec3760ec@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <b7TRbsB1m1ykH6onEB6V4Q-6ecR7lkAUyX4CAU4DktU=.bf45e91c-93f0-4f0a-b9f6-152ef7025893@github.com>
 <QgmjJTykr01UFy5H0_sB7NhJ74ZkkHVdfLF9Qf_vhB8=.2c9f7bf7-716f-4883-bf84-8d87ec3760ec@github.com>
Message-ID: <PCtb1ECA75HykDelAJ3RHALHK9EI4OFUmfGI5k8TMDI=.fa325d35-d54c-4b3f-9ce5-dc854581acb6@github.com>

On Wed, 28 Sep 2022 13:52:02 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments, with one &
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 534:
> 
>> 532:     // Split address into a lower 12-bit sign-extended offset and the remainder,
>> 533:     // so that the offset could be encoded in jalr or load/store instruction.
>> 534:     offset = ((int32_t)(uintptr_t)addr << 20) >> 20;
> 
> Would you mind one more tweak here? Considering that the type of 'offset' is int32_t, I think it will be more readable here if we convert 'addr' into int64_t type instead of uintptr_t.

Of course. Also changed other uintptr_t usages to int64_t.

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

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Thu Sep 29 03:28:44 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Thu, 29 Sep 2022 03:28:44 GMT
Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites [v5]
In-Reply-To: <drqYYtb5irWzSdVcJQkGSkUEE6fG6POkSO_iL2gu8Wk=.d4b5fdb4-c576-445d-a2fd-1b9681dd8fbe@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
 <drqYYtb5irWzSdVcJQkGSkUEE6fG6POkSO_iL2gu8Wk=.d4b5fdb4-c576-445d-a2fd-1b9681dd8fbe@github.com>
Message-ID: <15NhpCDCxb4wyMs-evRpPfO2igG5-hfegjRV539OSXQ=.6afe4711-b712-4bf9-a58e-aec42050a6b7@github.com>

On Wed, 28 Sep 2022 14:02:57 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
>> 
>> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
>> 
>> Originally some non-patchable callsites:
>> 
>> ;; 0x401ab1dc40
>> 0x000000401372b324:   lui	t0,0x201
>> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
>> 0x000000401372b32c:   slli	t0,t0,0xb
>> 0x000000401372b32e:   addi	t0,t0,1905
>> 0x000000401372b332:   slli	t0,t0,0x6
>> 0x000000401372b334:   jalr	t0
>> 
>> Now:
>> 
>> 0x000000401b2bd9f4:   lui	t0,0x4003
>> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
>> 0x000000401b2bd9fc:   slli	t0,t0,0xc
>> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
>> 
>> Not so much, but the main purpose is to clarify the usage of movptr and li.
>> 
>> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Canonicalize signed extensions

Hotspot tier1~4 seems okay on QEMU with fastdebug build. I guess we can move on if no other comments.

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

PR: https://git.openjdk.org/jdk/pull/10462

From xlinzheng at openjdk.org  Thu Sep 29 07:23:42 2022
From: xlinzheng at openjdk.org (Xiaolin Zheng)
Date: Thu, 29 Sep 2022 07:23:42 GMT
Subject: Integrated: 8294492: RISC-V: Use li instead of patchable movptr at
 non-patchable callsites
In-Reply-To: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
References: <CD9Pkt4Z1PmVOc-ePKKZs8015SKqICPhs6JadlgwDHU=.5854503a-db40-42c2-ab39-3dccfb870baa@github.com>
Message-ID: <hITQM5ONcBdps_T29ffnZsjNTO1GXP_L7Mcq-a9xR9I=.9db69ffc-8a7e-4782-90b5-7f0f54d78860@github.com>

On Wed, 28 Sep 2022 06:28:53 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them.
> 
> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before.
> 
> Originally some non-patchable callsites:
> 
> ;; 0x401ab1dc40
> 0x000000401372b324:   lui	t0,0x201
> 0x000000401372b328:   addi	t0,t0,-680 # 0x0000000000200d58
> 0x000000401372b32c:   slli	t0,t0,0xb
> 0x000000401372b32e:   addi	t0,t0,1905
> 0x000000401372b332:   slli	t0,t0,0x6
> 0x000000401372b334:   jalr	t0
> 
> Now:
> 
> 0x000000401b2bd9f4:   lui	t0,0x4003
> 0x000000401b2bd9f8:   addiw	t0,t0,-1275
> 0x000000401b2bd9fc:   slli	t0,t0,0xc
> 0x000000401b2bda00:   jalr	1080(t0) # 0x0000000004003438
> 
> Not so much, but the main purpose is to clarify the usage of movptr and li.
> 
> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1.

This pull request has now been integrated.

Changeset: 1decdcee
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1decdcee71eae3344aaf2c0223d40a2b57a044b9
Stats:     103 lines in 8 files changed: 21 ins; 52 del; 30 mod

8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites

Reviewed-by: fyang

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

PR: https://git.openjdk.org/jdk/pull/10462